Bug#1072717: stow: New upstream release (2.4.0, 2024-04-07)
Package: stow Version: 2.3.1-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, Upstream released a new version a couple of months ago, 2.4.0, which should fix bug #941940 here. https://www.gnu.org/software/stow/ http://git.savannah.gnu.org/cgit/stow.git/tree/NEWS Please could it be uploaded to unstable/testing when you have a chance? many thanks, Andrew
Bug#1066997: mlterm cannot launch mlconfig because it doesn’t support --geometry
Package: mlterm
Version: 3.9.3-1+b1
Severity: important
Tags: a11y
X-Debbugs-Cc: a.t.chadw...@gmail.com
Dear Maintainer,
The mlconfig helper does not support --geometry, so it can’t be invoked by
the user using its Ctrl+MouseButton3 binding, which tries to use this
option. If mlterm is run from a different terminal, it instead prints the
message “Unknown option --geometry” when this combination is pressed,
without giving any other indication of what it’s trying to do. See the
trace below for that detail.
I think that mlterm should invoke this command without --geometry, or the
mlconfig helper should be patched to support the --geometry option. I can
confirm that this functionality was working correctly under Debian 12’s
version of mlterm and its supporting binaries.
thanks for looking at this,
Andrew
-- Trace for message:
$ rm -fr ~/.mlterm
$ strace -ff mlterm 2>&1 | grep geometry
[pid 136423] execve("mlconfig", ["mlconfig", "--geometry", "+1371+345",
"--display", ":0.0"], 0x7fffd47338b8 /* 59 vars */) = -1 ENOENT (No such file
or directory)
[pid 136423] execve("/usr/lib/x86_64-linux-gnu/mlterm/mlconfig",
["/usr/lib/x86_64-linux-gnu/mlterm"..., "--geometry", "+1371+345", "--display",
":0.0"], 0x7fffd47338b8 /* 59 vars */) = 0
[pid 136423] write(2, "Unknown option --geometry\n", 26Unknown option --geometry
-- System Information:
Debian Release: trixie/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'unstable-debug'), (500,
'testing-debug'), (5, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 6.6.15-amd64 (SMP w/8 CPU threads; PREEMPT)
Kernel taint flags: TAINT_USER
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 mlterm depends on:
ii libc62.37-15
ii libfreetype6 2.13.2+dfsg-1+b1
ii libgdk-pixbuf-2.0-0 2.42.10+dfsg-3+b1
ii libglib2.0-0 2.78.4-1
ii libx11-6 2:1.8.7-1
ii mlterm-common3.9.3-1+b1
Versions of packages mlterm recommends:
ii mlterm-tools 3.9.3-1+b1
Versions of packages mlterm suggests:
pn fonts-arphic-bsmi00lp
pn fonts-arphic-gbsn00lp
ii fonts-freefont-ttf20211204+svn4273-2
ii fonts-ipafont-gothic [fonts-japanese-gothic] 00303-23
ii fonts-nanum 20200506-1
pn mlterm-im-m17nlib
pn mlterm-im-scim
pn mlterm-im-uim
pn t1-cyrillic
ii unifont 1:15.1.01-1
pn xfonts-efont-unicode
-- no debconf information
Bug#1066185: pekwm: New upstream version available: 0.3.0
Package: pekwm Version: 0.1.18-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, A new version of pekwm, 0.30.0, has been available from upstream since Jan 2023. I understand that it comes with a bunch of desktop-focused utilities now. Please can you consider updating the version in Debian, when convenient, for the next stable release? https://github.com/pekwm/pekwm/releases/tag/release-0.3.0 https://pekdon.pekwm.se/posts/pekwm_release_history/ many thanks, Andrew
Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
On Sat, 2024-03-09 at 07:49 +0100, Sebastiaan Couwenberg wrote: > the workaround is to add the OSM Carto layer first, and then > add the Bing layer. This proposed workaround does not work for me. I need to kill and restart a hung JOSM, and launch it again to get working a Bing layer. Then (for my main working JOSM), the problem is worked around for a few hours (estimated) while I edit. The hang even affects the GUI: nothing responds within it as soon as the menu item is selected, and the menu itself becomes unresponsive and does not withdraw. I have commented upstream that for now this seems to be a Debian issue. See the comments at https://josm.openstreetmap.de/ticket/23540 for further detail. Summary: I cannot reproduce this with upstream's josm- tested.jar, but only with the jarfile in Debian's DFSG build. I am using the same Debian Java for both tests, using $ java -Djosm.home=/tmp/something_new_and_unique \ -jar path/to/a/josm.jar \ --skip-plugins --debug for consistency. I will continue reporting here, since this seems to be a Debian- specific issue. I don't have much else to add, however. Happy to try out fixes as they emerge. regards, Andrew
Bug#1065678: josm: JOSM hangs when downloading Bing imagery, but only the first time in a session
Package: josm
Version: 0.0.svn18969+dfsg-1
Severity: normal
X-Debbugs-Cc: a.t.chadw...@gmail.com
Dear Maintainer,
When JOSM is instructed to download Bing background satellite and aerial
imagery, it hangs the first time JOSM is launched on a day of map editing.
It seems to be a key caching issue. If JOSM is then killed, and
subsequently launched again, it downloads the Bing imagery just fine.
If enough time then elapses without launching JOSM, the situation repeats.
For me this is usually about a day, but the timeframe is probably a lot
shorter.
I would expect Bing background imagery to be downloaded fine every time,
without causing JOSM to hang.
## Minimal Steps to Reproduce
The hang will happen in all ordinary usage when Bing imagry is used, but in
order to rule out config files and settings, you can run JOSM as
$ JAVA_OPTS="-Djosm.home=/tmp/josmhome.$$" josm --skip-plugins --debug
This prevents it from loading your personal config file or any downloaded
plugins. As soon as the main interface loads, add a Bing layer using
Imagery → Bing aerial imagery
If this is the *first* time the josm.home location is being used (i.e. it
didn’t exist before), JOSM will then hang with the final debug messages
shown immediately below. JOSM then hangs and has to be killed with ^C or
using xkill.
---8<--
[...]
2024-03-08 20:12:56.115 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:12:56.120 FINE: Contacting Server...
2024-03-08 20:12:56.120 FINE: REQUEST HEADERS: {Accept=*/*,
Accept-Encoding=gzip, deflate}
2024-03-08 20:12:56.223 INFO: GET
https://dev.virtualearth.net/REST/v1/Imagery/Metadata/AerialOSM?include=ImageryProviders=xml=...stripped...
-> HTTP/1.1 200 (102 ms)
2024-03-08 20:12:56.223 FINE: RESPONSE HEADERS: {Transfer-Encoding=[chunked],
null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE],
x-azure-ref=[20240308T201256Z-39saph36ah08xe5gfvn6y1z8pw00083g01pm],
X-BM-TraceID=[cbf82a8a7dda1cbe233823c5d9cd1a91], Alt-Svc=[h3=":443";
ma=86400], Access-Control-Allow-Origin=[*], Access-Control-Allow-Methods=[POST,
GET, OPTIONS], X-BM-FE-Elapsed=[5], Connection=[keep-alive],
Access-Control-Allow-Headers=[Content-Type,X-FD-Features,X-FD-FLIGHT,PreferAnonymous],
Date=[Fri, 08 Mar 2024 20:12:56 GMT], Cache-Control=[no-cache],
X-AspNet-Version=[4.0.30319], X-BM-Srv=[mapsplatform-frontend-55b6b7bd84-p2lfw,
DU3064], Content-Encoding=[gzip], Vary=[Accept-Encoding],
X-MS-BM-WS-INFO=[0], X-Powered-By=[ASP.NET], Content-Type=[application/xml;
charset=utf-8]}
2024-03-08 20:12:56.223 FINE: Downloading data...
2024-03-08 20:12:56.224 INFO: Successfully loaded Bing attribution data.
[hangs, ^C]
--->8--
If it’s the *second* time around (within some unknown number of minutes),
JOSM does not hang, and goes on to print messages like
---8<--
2024-03-08 20:17:01.005 FINE: Unsupported savable layer type: TMSLayer
2024-03-08 20:17:01.033 FINE: Reading Bing logo from
https://dev.virtualearth.net/Branding/logo_powered_by.png
2024-03-08 20:17:01.038 FINE: Contacting Server...
2024-03-08 20:17:01.039 FINE: REQUEST HEADERS: {Accept=*/*,
Accept-Encoding=gzip, deflate}
2024-03-08 20:17:01.420 INFO: GET
https://dev.virtualearth.net/Branding/logo_powered_by.png -> HTTP/1.1 200 (381
ms; 1.17 kB)
2024-03-08 20:17:01.420 FINE: RESPONSE HEADERS: {Accept-Ranges=[bytes],
null=[HTTP/1.1 200 OK], X-Cache=[CONFIG_NOCACHE], Alt-Svc=[h3=":443";
ma=86400], Cache-Control=[max-age=86400], ETag=["1da6b47d7e7e12e"],
Last-Modified=[Thu, 29 Feb 2024 19:45:27 GMT],
X-Azure-Ref=[0PXLrZQBRV4dQ4FinSYsXKjq3EwHuTE9OMjFFREdFMTgxMgBmMTI3MDYwYi1mNDk4LTRlMjAtYjVkZi1hZWIyMzczZWM5NWU=],
Content-Length=[1198], Date=[Fri, 08 Mar 2024 20:17:00 GMT],
Content-Type=[image/png]}
2024-03-08 20:17:01.421 FINE: Downloading data...
2024-03-08 20:17:01.480 INFO: AbstractTileSourceLayer: estimated visible tiles:
54, estimated cache size: 466
2024-03-08 20:17:01.484 FINE: zoomChanged(): 2
2024-03-08 20:17:01.580 INFO: AbstractTileSourceLayer: estimated visible tiles:
54, estimated cache size: 466
2024-03-08 20:17:01.629 INFO: AbstractTileSourceLayer: estimated visible tiles:
54, estimated cache size: 466
2024-03-08 20:17:01.631 INFO: Allocate for tile source layer: 116 MB of memory.
Available: 3 914 MB.
2024-03-08 20:17:01.644 FINE: zoomChanged(): 14
2024-03-08 20:17:01.645 FINE: JCS - Submitting job for execution for url:
https://ecn.t2.tiles.virtualearth.net/tiles/a30.jpeg?g=14355=odbl
2024-03-08 20:17:01.646 FINE: JCS - Submitting job for execution for url:
https://ecn.t1.tiles.virtualearth.net/tiles/a21.jpeg?g=14355=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url:
https://ecn.t2.tiles.virtualearth.net/tiles/a30.jpeg?g=14355=odbl
2024-03-08 20:17:01.646 FINE: JCS - starting fetch of url:
Bug#1064942: libexo-2-dev: new upstream available: 4.19.0
Package: libexo-2-dev Version: 4.18.0-1+b1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Debian Xfce maintainers, A new unstable upstream version of libexo-2 is available: 4.19.0 (Oct 2023). This version is now a build requirement of Thunar from git, since c5d8bfaa (Oct 2023), and probably other parts of Future Xfce too. Please could you consider uploading a 4.19.0 build to experimental to support development work, as was done during the bookworm development cycle? thanks, Andrew [... ./autogen.sh-ing thunar-dev ...] checking for pkg-config... /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for gtk-doc... yes checking for gtkdoc-check... gtkdoc-check.test checking for gtkdoc-check... /usr/bin/gtkdoc-check checking for gtkdoc-rebase... /usr/bin/gtkdoc-rebase checking for gtkdoc-mkpdf... /usr/bin/gtkdoc-mkpdf checking whether to build gtk-doc documentation... no checking for glib-2.0 >= 2.10.0 gobject-2.0 >= 2.10.0... yes checking for pkg-config... (cached) /usr/bin/pkg-config checking pkg-config is at least version 0.9.0... yes checking for exo-2 >= 4.19.0... found, but 4.18.0 *** The required package exo-2 was found on your system, *** but the installed version (4.18.0) is too old. *** Please upgrade exo-2 to atleast version 4.19.0, or adjust *** the PKG_CONFIG_PATH environment variable if you installed *** the new version of the package in a nonstandard prefix so *** pkg-config is able to find it. make: *** [Makefile:28: configure] Error 1
Bug#1055479: fonts-fantasque-sans: New upstream version 1.8.0 (16 Nov 2019)
Package: fonts-fantasque-sans Version: 1.7.2~alpha.3~dfsg-2 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, Upstream have released a new version of this font. Please can the Debian package be updated? https://github.com/belluzj/fantasque-sans/releases/tag/v1.8.0 many thanks, Andrew
Bug#1042008: xrdp: Please add an override for needrestart to avoid accidentally breaking apt upgrades
Package: xrdp
Version: 0.9.21.1-1
Severity: normal
X-Debbugs-Cc: a.t.chadw...@gmail.com
Dear Maintainer,
XRDP should be integrated with needrestart so that the default behaviour of
NeedRestart::UI::Debconf’s dialogs becomes safer. Currently, the xrdp and
xrdp-sesman services are selected automatically for restarting when
libraries affecting running desktop packages in xrdp session are updated.
This is unlike all normal local display managers, which have a specific
exemption because the user might be running their system upgrade from a
graphical session.
$ cat /etc/needrestart/needrestart.conf
[...]
# Override service default selection (hash of regex).
$nrconf{override_rc} = {
[...]
# display managers
qr(^gdm) => 0,
qr(^kdm) => 0,
qr(^nodm) => 0,
qr(^sddm) => 0,
qr(^wdm) => 0,
[...]
These overrides prevent the upgrade getting accidentally terminated should
the admin applying the upgrade click through the dialogs without looking,
by giving them safe default behaviour.
This hash defined in the main conffile can be extended to support
additional service regexes with a drop-in conffile stub:
$ cat /etc/needrestart/conf.d/xrdp.conf
# Ensure that the xrdp display manager isn’t offered for restart.
$nrconf{override_rc}{qr(^xrdp)} = 0;
This causes the XRDP services to be initially *deselected* in the
needrestart dialogs that are hooked by apt, instead of *selected*
initially. This is safer because clicking through the needrestart dialog
does not cause an apt or apt-get launched in a graphical session to
terminate when xrdp restarts. Xrdp becomes like any other graphical display
manager.
(Brought to you by me having to remember to do this every time. Sometimes I
am lazy and, well, oops.)
many thanks,
Andrew
Bug#1032556: neovim-qt: New upstream version available: 0.2.17 (2022-07-02)
Package: neovim-qt Version: 0.2.16-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainers, There is a new version of neovim-qt available upstream. Please could the Debian repos be updated with it when it’s convenient? https://github.com/equalsraf/neovim-qt/tags https://github.com/equalsraf/neovim-qt/releases/tag/v0.2.17 https://tracker.debian.org/pkg/neovim-qt Version 0.2.17 in particular fixes a number of emoji rendering bugs: please see https://github.com/equalsraf/neovim-qt/issues/482#issuecomment-751175003 for an example and a list. many thanks, Andrew Chadwick
Bug#1032492: xfce4-goodies: Please consider adding xfce4-docklike-plugin
Package: xfce4-goodies Version: 4.18.0 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainers, Would it be possible to package the new(-ish) “Docklike Taskbar” plugin for Xfce? A proper dock-ish launcher on the panel is something Xfce could really do with. - https://docs.xfce.org/panel-plugins/start - https://docs.xfce.org/panel-plugins/xfce4-docklike-plugin/start - https://gitlab.xfce.org/panel-plugins/xfce4-docklike-plugin This plugin was languishing for about a year, but it seems to be getting some code love again upstream from a new maintainer. regards, Andrew Chadwick
Bug#1032083: python-editor: New upstream version 1.0.4, *BUT* name conflict with PyPi
Source: python-editor Version: 1.0.3-3 Severity: normal X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, There is a new upstream version of this package available, version 1.0.4, released in Feb 2019. Please can it be packaged for Debian? Git: https://github.com/fmoo/python-editor PyPi: none? Interface: editor.edit() Author: fmoo However, and perhaps more notably, there is an unrelated package called “editor” in PyPi that does the same thing, but which turns out to be significantly more modern and more regularly maintained. Git: https://github.com/rec/editor PyPi: https://pypi.org/project/editor/ Interface: editor.editor() Author: rec (Tom Ritchford) I suspect that *this* is what many Python application devs will be using when they need to launch an editor, because they’ll be looking in PyPi first. I’ve made that mistake myself, thinking it’s a newer version of the Debian packaged “editor”, then got worried by the apparently huge version bump and changed interface before twigging that the two projects are unrelated. I suppose handling the name clash is really a policy matter for Debian’s Python team. Does it even matter? Do, or should, Debian builds of python packages generally have the same name as their PyPi equivalents? It’s pretty confusing if they don’t match up. Perhaps the solution would be to rename “python-editor” to “python-editor-fmoo” or similar, with sensible migration headers, and package a new “python-editor” whose name matches PyPi. Or some virtual package or Alternatives mechanism, maybe. Anyway, thanks for your consideration, whichever way this goes :) regards, Andrew
Bug#1024334: nano: New upstream version: 7.0 (15 Nov 2022)
Package: nano Version: 6.4-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, Version 7.0 of nano is now available from its upstream. Please could the Debian repositories be updated with it, when you have a chance? * https://www.nano-editor.org/download.php * https://lists.gnu.org/archive/html/info-gnu/2022-11/msg5.html * https://qa.debian.org/cgi-bin/watch?pkg=nano many thanks, Andrew
Bug#1023752: visidata: New upstream version: v2.10.2 (Oct 8, 2022)
Hi Anja - Thanks for the response! Yes, I can confirm that 2.10.2 feels pretty stable, although I'm very much a beginner with the program. I wonder if it would be possible to add Suggests: headers for a "nice" subset of the packages required to open certain kinds of file in the next upload. Specifically, the ones listed in * short: https://jsvine.github.io/intro-to-visidata/basics/opening-files/#compatible-filetypes * full: https://www.visidata.org/docs/formats/ It wouldn't be right to list them in Recommends:, I feel, but a Suggests: header feels like a really nice packaging enhancement for end users who want to explore more. I'd understand if you can't list them all, because there are a lot, and they might not all have Debian packages yet. And it's inherently a choice, a matter of judgment, if you decide against trying to list all of them. I'm not 100% sure about what feels like a "nice" subset, or what the criteria for such a list should be. Entries for common simple local file formats (Excel, LibreOffice, XML, YAML) and important Open Source databases (MySQL/MariaDB, Postgres) would seem good as a starting point, however. Also, the Debian-Edu team might be interested in seeing visidata's package announce support for big stats package file formats (Stata, pandas, SAS, Numpy, ...) cheers, Andrew On Wed, 9 Nov 2022 at 17:40, Anja wrote: > > Hi Andrew! > > We tend to wait to update the Homebrew and Debian until we are sure of the > solidity of a release. Having said that, 2.10.2 does feel pretty solid, so we > are likely to prioritise a Debian release for that one. =)
Bug#1023752: visidata: New upstream version: v2.10.2 (Oct 8, 2022)
Package: visidata Version: 2.2.1-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, Version 2.10.2 of visidata is now available from its upstream. Please could the Debian repositories be updated with it, when you have a chance? * https://github.com/saulpw/visidata/tags * https://www.visidata.org/releases/ * https://qa.debian.org/cgi-bin/watch?pkg=visidata many thanks, Andrew
Bug#1019526: gnome-control-center: color management broken after update, segfault
Package: gnome-control-center Version: 1:43.0-1 Followup-For: Bug #1019526 X-Debbugs-Cc: a.t.chadw...@gmail.com Confirmed in 43.0 from sid. The Colour panel segfaults, and Night Light is also nonfunctional. The control panel app is now “sticky”, so if you switch to a panel that segfaults and then try to start the app again, it will try to start with the panel you were on before. This makes it segfault again immediately, preventing access to other control panels. From a user perspective, to recover from this situation enough to use other control panels, you can use the command line to start it on a different panel, e.g. Displays: $ gnome-control-center display You can also choose “Display Settings” or “Change Background…” from the desktop right button/longpress menu. Those do the same thing The crash can be reproduced from the command line with the following. The “--verbose” option is not necessary to reproduce, it’s just there to provide more context. Note the line about the missing NightLightSupported property, in passing. I don’t know if the broken night light functionality is related or a separate bug. The warning appears when switching to the Display panel too, before accessing the Night Light controls card (is that the right term?) $ gnome-control-center --verbose color 01:07:27.0390(null):DEBUG: No extra argument (gnome-control-center:17422): dconf-DEBUG: 01:07:27.390: change_fast (gnome-control-center:17422): dconf-DEBUG: 01:07:27.390: change_notify: /org/gnome/control-center/last-panel (gnome-control-center:17422): dconf-DEBUG: 01:07:27.396: watch_fast: "/org/freedesktop/color-helper/" (establishing: 0, active: 0) (gnome-control-center:17422): dconf-DEBUG: 01:07:27.396: unwatch_fast: "/org/freedesktop/color-helper/" (active: 0, establishing: 1) (gnome-control-center:17422): dconf-DEBUG: 01:07:27.396: watch_fast: "/org/gnome/settings-daemon/plugins/color/" (establishing: 0, active: 2) (gnome-control-center:17422): dconf-DEBUG: 01:07:27.396: watch_fast: "/org/freedesktop/color-helper/" (establishing: 0, active: 0) (gnome-control-center:17422): dconf-DEBUG: 01:07:27.397: watch_established: "/org/freedesktop/color-helper/" (establishing: 1) (gnome-control-center:17422): dconf-DEBUG: 01:07:27.397: watch_established: "/org/freedesktop/color-helper/" (establishing: 0) 01:07:27.0398 cc-window:DEBUG: Time to open panel 'Colour': 0.007625s 01:07:27.0398 cc-window:DEBUG: Added 'display' to the previous panels 01:07:27.0402 display-cc-panel: WARNING: Missing property 'NightLightSupported' on DisplayConfig API 01:07:27.0402 cc-object-storage:DEBUG: Finished creating D-Bus proxy for CcObjectStorage::dbus-proxy(org.gnome.SettingsDaemon.Color,/org/gnome/SettingsDaemon/Color,org.freedesktop.DBus.Properties) 01:07:27.0402 cc-object-storage:DEBUG: Adding object GDBusProxy (CcObjectStorage::dbus-proxy(org.gnome.SettingsDaemon.Color,/org/gnome/SettingsDaemon/Color,org.freedesktop.DBus.Properties) → 0x5573e60c44b0) to the storage 01:07:27.0402 cc-object-storage:DEBUG: Finished creating D-Bus proxy for CcObjectStorage::dbus-proxy(org.gnome.SettingsDaemon.Color,/org/gnome/SettingsDaemon/Color,org.gnome.SettingsDaemon.Color) 01:07:27.0402 cc-object-storage:DEBUG: Adding object GDBusProxy (CcObjectStorage::dbus-proxy(org.gnome.SettingsDaemon.Color,/org/gnome/SettingsDaemon/Color,org.gnome.SettingsDaemon.Color) → 0x5573e5f3bd10) to the storage 01:07:27.0402 display-cc-panel:DEBUG: setting adjustment 22.000 to 22:00 01:07:27.0402 display-cc-panel:DEBUG: setting adjustment 7.000 to 7:00 01:07:27.0402 cc-object-storage:DEBUG: Finished creating D-Bus proxy for CcObjectStorage::dbus-proxy(org.gnome.Shell,/org/gnome/Shell,org.gnome.Shell) 01:07:27.0403 diagnostics-cc-panel:DEBUG: ABRT vanished 01:07:27.0403 display-cc-panel:DEBUG: setting adjustment 22.000 to 22:00 01:07:27.0403 display-cc-panel:DEBUG: setting adjustment 7.000 to 7:00 Segmentation fault -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (5, 'unstable'), (1, 'experimental-debug'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.19.0-1-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_USER 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 gnome-control-center depends on: ii accountsservice 22.08.8-1 ii apg 2.2.3.dfsg.1-5+b2 ii colord1.4.6-1 ii desktop-base
Bug#1018154: restic: New upstream version 0.14.0
Package: restic Version: 0.13.1-1+b1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainers, It would be lovely if v0.14.0 could be packaged for Debian. It introduces compression (with a new default repo format), and it adds a few nice performance and efficiency boosts generally: https://restic.net/blog/2022-08-25/restic-0.14.0-released/ > /tmp/restic-0.13.1$ uscan --no-download > uscan: Newest version of restic on remote site is 0.14.0, local version is > 0.13.1 > uscan: => Newer package available from: > => https://github.com/restic/restic/archive/refs/tags/v0.14.0.tar.gz Oddly, https://tracker.debian.org/pkg/restic has not picked it up yet, though. thanks, Andrew
Bug#1011756: cloud.debian.org: Vagrant debian/testing64: sshd rejects default insecure ssh-rsa key, hangs waiting for SSH
Yeah, I initially thought this was a problem with the debian/testing64 box, since debian/bullseye64 running on a bullseye host comes up cleanly. The problem lies with the Debian vagrant version and its way of invoking Net::SSH. I think that reassigning this report is the right course of action, and your summation sounds right too. Pointing the FAQ here would help users trying testing on stable via vagrant out a lot. It looks like there's a nice upstream patch (containing a monkeypatch?) that can be applied to the version of vagrant in stable too: https://github.com/hashicorp/vagrant/pull/12298/files. It's targeted at exactly the Net::SSH 6.1.0 that's in Debian stable right now. The vagrant maintainers will have the option of backporting the patch or releasing a newer vagrant in the next Debian 11 point release: up to them. I'm happy to test things out ;) - Andrew
Bug#1011756: cloud.debian.org: Vagrant debian/testing64: sshd rejects default insecure ssh-rsa key, hangs waiting for SSH
Package: cloud.debian.org Followup-For: Bug #1011756 X-Debbugs-Cc: a.t.chadw...@gmail.com ## Workaround 2 (neater) Testing a bit more, I can confirm that installing vagrant 2.2.19 from Debian Testing fixes this on Debian 11 (buster) hosts when trying to connect to debian/testing64 box images. I guess Vagrant uses ruby-net-ssh for the initial connection using the insecure default key, the connection it uses to replace that key on the new machine with the creating user’s. This is why it also ignores config.ssh.extra_args in Vagrantfiles for that initial connection, but respects them at “vagrant ssh” time. Debian 11 users only need to update the vagrant package for now, iupdating from stable’s 2.2.14+dfsg-1 to testing’s 2.2.19+dfsg-1. They will need to employ apt pinning to stay on stable while updating vagrant from testing. One HOWTO is here: https://coderwall.com/p/aatvta/apt-pinning-in-debian, or see https://wiki.debian.org/AptConfiguration for a deeper dive. Vagrant’s written in Ruby, and it is packaged to be pretty tolerant about its dependencies’ versions in Debian. - Andrew
Bug#1011756: cloud.debian.org: Vagrant debian/testing64: sshd rejects default insecure ssh-rsa key, hangs waiting for SSH
Package: cloud.debian.org Followup-For: Bug #1011756 X-Debbugs-Cc: a.t.chadw...@gmail.com I should add that the debian/bullseye64 image works perfectly using the instructions given. No need to fiddle with the SSH config while it’s half-up. - Andrew
Bug#1011756: cloud.debian.org: Vagrant debian/testing64: sshd rejects default insecure ssh-rsa key, hangs waiting for SSH
Package: cloud.debian.org Severity: normal X-Debbugs-Cc: a.t.chadw...@gmail.com Dear base box maintainers: I don’t know if this should be a documentation fix or an image fix. I’ll just lay out the problem with as much detail as I can so that people can search it and find better workarounds. I think the FAQ at https://wiki.debian.org/Teams/Cloud/VagrantBaseBoxes should probably be updated, given that it’s linked from https://app.vagrantup.com/debian, a place where people sill be looking. OpenSSH have addressed a weakness of SHA-1 by removing the ssh-rsa public key signature algorithm from their list of supported key types. The openssh-server 1:9.0p1-1 package in the debian/testing64 image incorporates this change. However the vagrant 2.2.14+dfsg-1 package shipped with Debian 11 “bullseye” has a default “vagrant insecure public key” which requires ssh-rsa. See - https://github.com/hashicorp/vagrant/issues/11783 - https://github.com/hashicorp/packer/issues/10074 ## Symptoms The current debian/testing64 image hangs during “vagrant up”. If I follow the instructions at https://wiki.debian.org/Teams/Cloud/VagrantQuickStart, the following happens. I already have vagrant and vagrant-libvirt installed and configured enough for me to use them. I am using the current Debian 11 versions. > ~ $ cd "$(mktemp -d)" > tmp.1PuBegzk6c $ vagrant init debian/testing64 > tmp.1PuBegzk6c $ vagrant up > ==> default: Checking if box 'debian/testing64' version '20220414.1' is up to > date... > ==> default: Creating image (snapshot of base box volume). > ==> default: Creating domain with the following settings... > [...] > ==> default: Starting domain. > ==> default: Waiting for domain to get an IP address... > ==> default: Waiting for SSH to become available... > [... hangs here, but leave it running ...] However, I can SSH in to the running virtual just fine from another window. Why this is, I don’t know. > ~ $ cd /tmp/tmp.1PuBegzk6c > tmp.1PuBegzk6c $ vagrant ssh > Linux testing 5.16.0-6-amd64 #1 SMP PREEMPT Debian 5.16.18-1 (2022-03-29) > x86_64 > > The programs included with the Debian GNU/Linux system are free software; > the exact distribution terms for each program are described in the > individual files in /usr/share/doc/*/copyright. > > Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent > permitted by applicable law. > vagrant@testing:~$ cat .ssh/authorized_keys > ssh-rsa > B3NzaC1yc2EBIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIFo9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9WhQ== > vagrant insecure public key However, connections from the still-running vagrant command on the host are still failing, as a quick check of auth.log will confirm. What the heck! > vagrant@testing:~$ sudo tail /var/log/auth.log > [...] > May 26 11:49:18 testing sshd[1644]: userauth_pubkey: signature algorithm > ssh-rsa not in PubkeyAcceptedAlgorithms [preauth] > May 26 11:49:18 testing sshd[1644]: Connection closed by authenticating user > vagrant 192.168.121.1 port 34488 [preauth] ## Workaround One way to fix it from the user perspective is to grab @dustymabe’s fix from https://github.com/hashicorp/vagrant/issues/11783#issuecomment-720822960, and apply it over our mysteriously working SSH connection > vagrant@testing:~$ sudo tee >/dev/null > /etc/ssh/sshd_config.d/10-vagrant-insecure-rsa-key.conf < # For now the vagrant insecure key is an rsa key > # https://github.com/hashicorp/vagrant/issues/11783 > PubkeyAcceptedKeyTypes=+ssh-rsa > EOF > vagrant@testing:~$ sudo systemctl restart ssh This allows the hung vagrant to resume immediately: > default: > default: Vagrant insecure key detected. Vagrant will automatically replace > default: this with a newly generated keypair for better security. > default: > default: Inserting generated public key within guest... > default: Removing insecure key from the guest if it's present... > default: Key inserted! Disconnecting and reconnecting using new SSH key... > ==> default: Installing NFS client... > ==> default: Exporting NFS shared folders... > ==> default: Preparing to edit /etc/exports. Administrator privileges will be > required... > ==> default: Mounting NFS shared folders... > > ==> default: Machine 'default' has a post `vagrant up` message. This is a > message > ==> default: from the creator of the Vagrantfile, and not from Vagrant itself: > ==> default: > ==> default: Vanilla Debian box. See https://app.vagrantup.com/debian for > help and bug reports thanks for keeping the boxes fresh - Andrew
Bug#1010285: thunar: New upstream development version (4.17.8) available
Package: thunar Version: 4.17.7-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Hi there. A new upstream development version of Thunar is available: https://gitlab.xfce.org/xfce/thunar/-/tags/thunar-4.17.8 This version adds a number of useful features that could probably use a bit of wider user testing, including recursive search and a graphical shortcuts editor. Please can you consider packaging it in experimental, replacing 4.17.7? thanks, Andrew -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (5, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-6-amd64 (SMP w/8 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 thunar depends on: ii desktop-file-utils 0.26-1 ii exo-utils4.17.1-1 ii libatk1.0-0 2.38.0-1 ii libc62.33-7 ii libcairo21.16.0-5 ii libexo-2-0 4.17.1-1 ii libgdk-pixbuf-2.0-0 2.42.8+dfsg-1 ii libglib2.0-0 2.72.1-1 ii libgtk-3-0 3.24.33-1 ii libgudev-1.0-0 237-2 ii libice6 2:1.0.10-1 ii libnotify4 0.7.9-3 ii libpango-1.0-0 1.50.6+ds-2 ii libsm6 2:1.2.3-1 ii libthunarx-3-0 4.17.7-1 ii libxfce4ui-2-0 4.17.3-1 ii libxfce4util74.17.1-1 ii libxfconf-0-34.16.0-2 ii shared-mime-info 2.1-2 ii thunar-data 4.17.7-1 Versions of packages thunar recommends: ii dbus-user-session [default-dbus-session-bus] 1.14.0-1 ii dbus-x11 [dbus-session-bus] 1.14.0-1 ii gnome-shell [polkit-1-auth-agent] 42.0-4 ii gvfs 1.50.0-1 ii libxfce4panel-2.0-4 4.16.3-1 ii policykit-1-gnome [polkit-1-auth-agent] 0.105-7+b1 ii polkit-kde-agent-1 [polkit-1-auth-agent] 4:5.24.4-1 ii thunar-volman 4.16.0-1 ii tumbler 4.16.0-1 ii udisks2 2.9.4-1 ii xdg-user-dirs 0.17-2 Versions of packages thunar suggests: ii gvfs-backends 1.50.0-1 pn thunar-archive-plugin pn thunar-media-tags-plugin -- no debconf information
Bug#1008647: greybird-gtk-theme: New upstream version available, 3.23.1
Package: greybird-gtk-theme Version: 3.22.15-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, A new upstream version is available. Please can it be uploaded? https://github.com/shimmerproject/Greybird/releases cheers, Andrew -- System Information: Debian Release: bookworm/sid APT prefers testing APT policy: (900, 'testing'), (5, 'unstable'), (1, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 5.16.0-5-amd64 (SMP w/8 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 greybird-gtk-theme depends on: ii gtk2-engines-murrine 0.98.2-3+b1 greybird-gtk-theme recommends no packages. greybird-gtk-theme suggests no packages. -- no debconf information
Bug#994742: kupfer: New upstream version available: v321
Package: kupfer Version: 0+v320-1 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainers, Kupfer has a new version available upstream, v321. Please could the repositories be updated with it, when it’s convenient for you do so? https://github.com/kupferlauncher/kupfer/releases/tag/v321 thanks, Andrew
Bug#994632: libjpeg-turbo: New upstream version available
Source: libjpeg-turbo Version: 1:2.0.6-4 Severity: wishlist X-Debbugs-Cc: a.t.chadw...@gmail.com Dear Maintainer, A new upstream release, version 2.1.1, is available. At your convenience, please can the Debian package be updated? https://github.com/libjpeg-turbo/libjpeg-turbo/releases https://sourceforge.net/projects/libjpeg-turbo/files/2.1.1/ Thanks, Andrew Chadwick
Bug#880504: Fixed upstream
Patching with Ronnie Sahlberg's f74bc7c[1] on top of the otherwise affected Debian linux-image-4.14.0-rc7-amd64 using the handbook test-patches instructions[2] fixes this bug for me. This was merged upstream in 89db69d yesterday, and should be included in the next -rc or 4.14.0 proper. [1] https://github.com/torvalds/linux/commit/f74bc7c6679200a4a83156bb89cbf6c229fe8ec0.patch [2] https://kernel-handbook.alioth.debian.org/ch-common-tasks.html#s4.2.2 -- Andrew Chadwick
Bug#880504: Update
Relevant upstream commit merge: https://github.com/torvalds/linux/commit/89db69d670a11274c323af48479841d3d765bd49 Not tested it yet, but I'll try to report back. -- Andrew Chadwick
Bug#880504: multiuser cifs: spurious ETOOLONG, file writes & dir reads broken since 4.12.6 [message: "File name too long"]
tory. Root itself does not have any Kerberos identity upon first login in this setup. Some relevant upstream commits: U1. https://github.com/torvalds/linux/commit/d3edede29f74d335f81d95a4588f5f136a9f7dcf - might have introduced the regression. U2. https://github.com/torvalds/linux/commit/6e3c1529c39e92ed64ca41d53abadabbaa1d5393 - I had hoped this might fix it. No dice :( I'm using cifs-utils 2:6.7-1. The unaffected kernel above is the one included in D-I alpha1 for buster. If anyone needs to revert, a .deb is available inside the iso-cd netinst images under https://cdimage.debian.org/cdimage/buster_di_alpha1/ -- Andrew Chadwick
Bug#872876: Not fixed by g-s-d 3.22
Unfortunately, I can confirm that downgrading gnome-settings-daemon to a matching 3.22.2-2+deb9u2 downloaded from http://ftp.uk.debian.org/debian/pool/main/g/gnome-settings-daemon/ is *not* sufficient to fix the non-detection of my 13HD in Wayland. Other tablets will probably be the same.
Bug#872875: Wacom: crash, "schema 'org.gnome.settings-daemon.peripherals.wacom' is not installed"
I can confirm that downgrading gnome-settings-daemon to 3.22.2-2+deb9u2 downloaded from http://ftp.uk.debian.org/debian/pool/main/g/gnome-settings-daemon/ fixes the gnome-control-center crash in Xorg. Since this makes gnome-control-center's Wacom panel unusable, can the missing schemas please be added to the gnome-control-center package until it hits 3.24 too? I am happy to test changes you make with a wider variety of real hardware after the 29th: I'm a MyPaint developer, and I seem to have acquired a pile of random graphics tablets as a result. On 22 August 2017 at 10:14, Andreas Henriksson <andr...@fatal.se> wrote: > Control: block -1 by 860396 > > Hello Andrew Chadwick, > > On Tue, Aug 22, 2017 at 01:44:49AM +0100, Andrew Chadwick wrote: >> Package: gnome-control-center >> Version: 1:3.22.2-3 >> Severity: important >> >> Dear Maintainer, >> >> The "Wacom Tablet" control panel applet crashes under Xorg any time my > [...] > > Thanks for your detailed bug report. This seems to be an issue with > mixing gnome-settings-daemon 3.24 (which dropped the wacom schema) > and gnome-control-center 3.22 (which hasn't been updated for that change). > > More information can be found in the relevant g-s-d commit: > https://git.gnome.org/browse/gnome-settings-daemon/commit/?h=gnome-3-24=7901013addca6abb7b4e6eff3a4397ef9f3a087d > > See also: > https://git.gnome.org/browse/gsettings-desktop-schemas/commit/?id=ddd425ba00ec1c62ced3e4815e3bb81f8b5dcb75 > (and the relevant mutter changes) > > Unfortunately since mutter is in the mix and updating that is blocked > by getting a newer mozjs version into Debian it might take some time > to get this resolved in buster/sid. > (See the referenced bug report at the top of this mail.) > > Regards, > Andreas Henriksson -- Andrew Chadwick
Bug#872876: gnome-control-center: Wacom Tablet [on Wayland]: No tablet detected
Package: gnome-control-center Version: 1:3.22.2-3 Severity: normal Dear Maintainer, The GNOME control center has stopped displaying the configuration options for my [known working and good] Cintiq 13HD. When the tablet is powered up and plugged in using its USB cable, the Wacom Tablet page of gnome-control-center in Wayland still displays: > No tablet detected > Please plug in or turn on your Wacom tablet See also bug#872875: under Xorg, this operation just crashes. Could this Wayland problem be related? One other discrepancy on my system: gnome-settings-daemon was recently updated to 3.24.3-1 from 3.22.2-5. gnome-control-center is languishing at a 3.22 version. I don't know if that is significant, so feel free to refile this report if needed. I can provide further info as needed, just let me know what to look at. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (50, 'unstable'), (5, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-control-center depends on: ii accountsservice0.6.43-1 ii apg2.2.3.dfsg.1-4+b1 ii colord 1.3.3-2 ii desktop-file-utils 0.23-2 ii gnome-control-center-data 1:3.22.2-3 ii gnome-desktop3-data3.22.2-1 ii gnome-settings-daemon 3.24.3-1 ii gsettings-desktop-schemas 3.24.0-2 ii libaccountsservice00.6.43-1 ii libatk1.0-02.24.0-1 ii libc6 2.24-14 ii libcairo-gobject2 1.14.10-1 ii libcairo2 1.14.10-1 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libcheese-gtk253.22.1-1+b1 ii libcheese8 3.22.1-1+b1 ii libclutter-1.0-0 1.26.2+dfsg-1 ii libclutter-gtk-1.0-0 1.8.2-2 ii libcolord-gtk1 0.1.26-1.1 ii libcolord2 1.3.3-2 ii libcups2 2.2.4-3 ii libfontconfig1 2.12.3-0.2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.53.6-1 ii libgnome-bluetooth13 3.20.1-1 ii libgnome-desktop-3-12 3.22.2-1 ii libgoa-1.0-0b 3.22.5-1 ii libgoa-backend-1.0-1 3.22.5-1 ii libgrilo-0.3-0 0.3.3-2 ii libgtk-3-0 3.22.18-1 ii libgtop-2.0-10 2.34.2-1 ii libgudev-1.0-0 230-3 ii libibus-1.0-5 1.5.14-3 ii libkrb5-3 1.15.1-2 ii libmm-glib01.6.8-1 ii libnm0 1.8.2-1 ii libnma01.8.2-1 ii libpango-1.0-0 1.40.6-1 ii libpangocairo-1.0-01.40.6-1 ii libpolkit-gobject-1-0 0.105-18 ii libpulse-mainloop-glib010.0-2 ii libpulse0 10.0-2 ii libpwquality1 1.3.0-1+b1 ii libsmbclient 2:4.6.5+dfsg-8 ii libsoup2.4-1 2.56.0-2 ii libupower-glib30.99.5-3 ii libwacom2 0.25-0local ii libx11-6 2:1.6.4-3 ii libxi6 2:1.7.9-1 ii libxml22.9.4+dfsg1-3 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.2-5+b1 ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.22.0.1-1+b1 ii gnome-online-accounts 3.22.5-1 ii gnome-user-guide 3.22.0-1 ii gnome-user-share 3.18.3-1+b1 ii iso-codes 3.75-1 ii libcanberra-pulse 0.30-3 ii libnss-myhostname 234-2 ii mousetweaks 3.12.0-1+b1 ii network-manager-gnome 1.8.2-1 ii policykit-1 0.105-18 ii pulseaudio-module-bluetooth 10.0-2 pn realmd ii rygel 0.32.1-3+b1 ii rygel-tracker 0.32.1-3+b1 ii system-config-printer-common 1.5.9-2 Versions of packages gnome-control-center suggests: ii gstreamer1.0-pulseaudio 1.12.2-1 ii libcanberra-gtk-module 0.30-3 ii libcanberra-gtk3-module 0.30-3 ii x11-xserver-utils7.7+7+b1 -- no debconf information Aug 22 01:58:05 spatula kernel: [ 2856.921605] usb 1-1: new high-speed USB device number 23 using xhci_hcd Aug 22 01:58:05 spatula kernel: [ 2857.061947] usb 1-1: New USB device found, idVendor=056a, idProduct=0305 Aug 22 01:58:05 spatula kernel: [ 2857.061953] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Aug 22 01:58:05 spatula kernel: [ 2857.061956] usb 1-1: Product: Wacom Cintiq 13HD USB Hub Aug 22 01:58:05 spatula kernel: [ 2857.061958] usb 1-1: Manufacturer: Wacom Co., Ltd. Aug 22 01:58:05
Bug#872875: Wacom: crash, "schema 'org.gnome.settings-daemon.peripherals.wacom' is not installed"
Package: gnome-control-center Version: 1:3.22.2-3 Severity: important Dear Maintainer, The "Wacom Tablet" control panel applet crashes under Xorg any time my Cintiq 13HD is plugged in via its USB connection. The fault seems to be a missing schema definition. Affects completely new system users with a new home dir. Q: What led up to the situation? I needed to configure my Wacom tablet in the normal fashion on a GNOME desktop. I knew a recent update had apparently changed several things in the Debian GNOME setup, and I was comparing Xorg behaviour against Wayland behaviour to see if it was worth taking the jump yet (spoiler: it's not). Q: What exactly did you do (or not do) that was effective (or ineffective)? Attempted to run the Wacom Tablet control panel applet when the tablet's USB connector was 1. plugged in to the computer 2. not plugged in. Q: What was the outcome of this action? 1: crash. 2: no crash. In all cases, no ability to configure my tablet. A run of "gdb -ex r --args gnome-control-center wacom" seemed to indicate that this was due to a missing schema definition. reportbug permitting, you should find attached a full backtrace run under a freshly-created user account. Q: What outcome did you expect instead? No crash in all cases. The ability to configure my tablet. *** End of the template - remove these template lines *** -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (500, 'unstable-debug'), (500, 'testing-debug'), (50, 'unstable'), (5, 'experimental'), (1, 'experimental-debug') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-control-center depends on: ii accountsservice0.6.43-1 ii apg2.2.3.dfsg.1-4+b1 ii colord 1.3.3-2 ii desktop-file-utils 0.23-2 ii gnome-control-center-data 1:3.22.2-3 ii gnome-desktop3-data3.22.2-1 ii gnome-settings-daemon 3.24.3-1 ii gsettings-desktop-schemas 3.24.0-2 ii libaccountsservice00.6.43-1 ii libatk1.0-02.24.0-1 ii libc6 2.24-14 ii libcairo-gobject2 1.14.10-1 ii libcairo2 1.14.10-1 ii libcanberra-gtk3-0 0.30-3 ii libcanberra0 0.30-3 ii libcheese-gtk253.22.1-1+b1 ii libcheese8 3.22.1-1+b1 ii libclutter-1.0-0 1.26.2+dfsg-1 ii libclutter-gtk-1.0-0 1.8.2-2 ii libcolord-gtk1 0.1.26-1.1 ii libcolord2 1.3.3-2 ii libcups2 2.2.4-3 ii libfontconfig1 2.12.3-0.2 ii libgdk-pixbuf2.0-0 2.36.5-2 ii libglib2.0-0 2.53.6-1 ii libgnome-bluetooth13 3.20.1-1 ii libgnome-desktop-3-12 3.22.2-1 ii libgoa-1.0-0b 3.22.5-1 ii libgoa-backend-1.0-1 3.22.5-1 ii libgrilo-0.3-0 0.3.3-2 ii libgtk-3-0 3.22.18-1 ii libgtop-2.0-10 2.34.2-1 ii libgudev-1.0-0 230-3 ii libibus-1.0-5 1.5.14-3 ii libkrb5-3 1.15.1-2 ii libmm-glib01.6.8-1 ii libnm0 1.8.2-1 ii libnma01.8.2-1 ii libpango-1.0-0 1.40.6-1 ii libpangocairo-1.0-01.40.6-1 ii libpolkit-gobject-1-0 0.105-18 ii libpulse-mainloop-glib010.0-2 ii libpulse0 10.0-2 ii libpwquality1 1.3.0-1+b1 ii libsmbclient 2:4.6.5+dfsg-8 ii libsoup2.4-1 2.56.0-2 ii libupower-glib30.99.5-3 ii libwacom2 0.25-0local (see bug 872871 :-) ii libx11-6 2:1.6.4-3 ii libxi6 2:1.7.9-1 ii libxml22.9.4+dfsg1-3 Versions of packages gnome-control-center recommends: ii cracklib-runtime 2.9.2-5+b1 ii cups-pk-helper0.2.6-1+b1 ii gkbd-capplet 3.22.0.1-1+b1 ii gnome-online-accounts 3.22.5-1 ii gnome-user-guide 3.22.0-1 ii gnome-user-share 3.18.3-1+b1 ii iso-codes 3.75-1 ii libcanberra-pulse 0.30-3 ii libnss-myhostname 234-2 ii mousetweaks 3.12.0-1+b1 ii network-manager-gnome 1.8.2-1 ii policykit-1 0.105-18 ii pulseaudio-module-bluetooth 10.0-2 pn realmd ii rygel 0.32.1-3+b1 ii rygel-tracker 0.32.1-3+b1 ii system-config-printer-common 1.5.9-2 Versions of packages gnome-control-center suggests: ii gstreamer1.0-pulseaudio 1.12.2-1 ii libcanberra-gtk-module 0.30-3 ii libcanberra-gtk3-module 0.30-3 ii x11-xserver-utils
Bug#872871: libwacom2: New upstream version available (0.25)
Package: libwacom2 Version: 0.24 Severity: normal Dear Maintainer, A new upstream version of libwacom is available: 0.25. It builds cleanly with the current 0.24-1 debian/ subtree and a fresh ChangeLog entry for 0.25-0whatever. Q. What led up to the situation? I'm investigating a Cintiq 13HD configuration which has stopped working on a recent GNOME update (... Wayland has become the default...) Q. What exactly did you do (or not do) that was effective (or ineffective)? Was unable to use the GNOME Wacom control panel: it either crashed (X11) or refused to recognised the tablet (Wayland). My new libwacom2 build does not solve this problem, but it may be relevant for GNOME Wacom setups in other ways during the current Time of Great Change. -- System Information: Debian Release: buster/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.12.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8), LANGUAGE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages libwacom2 depends on: ii libc62.24-14 ii libglib2.0-0 2.53.4-3 ii libgudev-1.0-0 230-3 ii libwacom-common 0.25-0local Versions of packages libwacom2 recommends: ii libwacom-bin 0.25-0local libwacom2 suggests no packages. -- no debconf information
Bug#855816: unblock: mypaint/1.2.0-4
Package: release.debian.org
Severity: normal
User: release.debian@packages.debian.org
Usertags: unblock
Please unblock package mypaint.
MyPaint 1.2.0-4, currently in unstable for 17 days, contains a targetted fix
for bug 848356. This bug has been assigned a severity of important becuase it
largely makes MyPaint useless in fullscreen mode with the version of
libgtk-3-0 which is due to be relesed with stretch.
Fullscreen mode is a primary way of using this package, and fullscreen state
is remembered across restarts of the app.
Debian bug being targetted:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=848356
This patch originates from upstream:
https://github.com/mypaint/mypaint/commit/c225d1132a7da956a35a32534e91a42d22cdb8e1
This bug is fixed in the latest upstream release (1.2.1),i which will not be
part of stretch, but I've backported and tested this fix for Stretch's 1.2.0.
Upstream bug reference:
https://github.com/mypaint/mypaint/issues/735
There are no unrelated changes in unstable, or included in this unblock.
Please cross-check it with the upstream patch to verify that it is the same
code. This is my first unblock request, so I hope I've mentioned the right
version in the subject and below.
Debdiff follows, as requested.
--8<
diff -Nru mypaint-1.2.0/debian/changelog mypaint-1.2.0/debian/changelog
--- mypaint-1.2.0/debian/changelog 2016-11-22 08:02:02.0 +
+++ mypaint-1.2.0/debian/changelog 2017-02-02 14:39:42.0 +
@@ -1,3 +1,10 @@
+mypaint (1.2.0-4) unstable; urgency=medium
+
+ * Add debian/patches/fix-gtk-3.22.4-canvas-disappearance.patch to fix
+fullscreen mode. (Closes: #848356)
+
+ -- Andrew Chadwick <a.t.chadw...@gmail.com> Thu, 02 Feb 2017 14:39:42 +
+
mypaint (1.2.0-3) unstable; urgency=medium
* Update d/rules to use dh sequencer. Fixes arch-indep FTBFS.
diff -Nru
mypaint-1.2.0/debian/patches/fix-gtk-3.22.4-canvas-disappearance.patch
mypaint-1.2.0/debian/patches/fix-gtk-3.22.4-canvas-disappearance.patch
--- mypaint-1.2.0/debian/patches/fix-gtk-3.22.4-canvas-disappearance.patch
1970-01-01 01:00:00.0 +0100
+++ mypaint-1.2.0/debian/patches/fix-gtk-3.22.4-canvas-disappearance.patch
2017-02-02 13:06:12.0 +
@@ -0,0 +1,63 @@
+diff --git a/gui/workspace.py b/gui/workspace.py
+index 7f4f4abe..2af856a5 100644
+--- a/gui/workspace.py
b/gui/workspace.py
+@@ -223,6 +223,7 @@ class Workspace (Gtk.VBox, Gtk.Buildable):
+ lpaned.pack1(lscrolls, resize=False, shrink=False)
+ lpaned.pack2(rpaned, resize=True, shrink=False)
+ rpaned.pack2(rscrolls, resize=False, shrink=False)
++rpaned.pack1(cscrolls, resize=True, shrink=False)
+ self.pack_start(lpaned, True, True, 0)
+ # Autohide
+ self._autohide_enabled = True
+@@ -397,43 +398,21 @@ class Workspace (Gtk.VBox, Gtk.Buildable):
+ def set_canvas(self, widget):
+ """Canvas widget (setter)"""
+ assert self.get_canvas() is None
+-self._rpaned.pack1(widget, resize=True, shrink=False)
+-self._update_canvas_scrolledwindow()
++widget = self._canvas_scrolls.add(widget)
+
+ def get_canvas(self):
+ """Canvas widget (getter)"""
+-widget = self._rpaned.get_child1()
+-if widget is self._canvas_scrolls:
+-widget = widget.get_child()
++widget = self._canvas_scrolls.get_child()
+ return widget
+
+ def _update_canvas_scrolledwindow(self):
+-"""Update whether the canvas has a surrounding ScrolledWindow
+-
+-In fullscreen mode, the ScrolledWindow is removed from the widget
+-hierarchy so that the canvas widget can occupy the full size of the
+-screen. In nonfullscreen mode, the scrollers provide a pretty frame.
+-"""
+-canvas = self.get_canvas()
+-parent = canvas.get_parent()
++"""Update the canvas ScrolledWindow's border."""
++parent = self._canvas_scrolls
+ if not self._is_fullscreen:
+-if parent is self._canvas_scrolls:
+-return
+-logger.debug("Adding GtkScrolledWindow around canvas")
+-assert parent is self._rpaned
+-self._rpaned.remove(canvas)
+-self._rpaned.pack1(self._canvas_scrolls, resize=True,
shrink=False)
+-self._canvas_scrolls.add(canvas)
+-self._canvas_scrolls.show_all()
++parent.set_shadow_type(Gtk.ShadowType.NONE)
+ else:
+-if parent is self._rpaned:
+-return
+-logger.debug("Removing GtkScrolledWindow around canvas")
+-assert parent is self._canvas_scrolls
+-self._canvas_scrolls.remove(canvas)
+-self._rpaned.remove(self._canvas_scroll
Bug#848356: Reproduced
I've uploaded a fix for this bug via Mentors. Please can someone review it and maybe upload it into unstable? https://mentors.debian.net/package/mypaint I, or someone else, then prepare an unblock bug as described in https://release.debian.org/stretch/freeze_policy.html
Bug#848356: Reproduced
Reproduced with mypaint 1.2.0-3 and libgtk-3-0 3.22.6-1 on a Debian testing VM during freeze for stretch. -- Andrew Chadwick
Bug#848356: Upstream patch available for 1.2.0
Upstream bug report: https://github.com/mypaint/mypaint/issues/735
I have been made aware that testing is frozen
https://release.debian.org/stretch/freeze_policy.html
This bug may also be heavily dependent on your exact GTK version
numbers, since the regression in MyPaint was introduced by an upgrade
to GTK 3.22.4 and no other change.
Aleksey: please could you re-test with MyPaint 1.2.0-3 from testing/unstable?
A patch is available upstream:
https://github.com/mypaint/mypaint/commit/c225d1132a7da956a35a32534e91a42d22cdb8e1
Raw patch follows.
-8<
diff --git a/gui/workspace.py b/gui/workspace.py
index 7f4f4abe..2af856a5 100644
--- a/gui/workspace.py
+++ b/gui/workspace.py
@@ -223,6 +223,7 @@ class Workspace (Gtk.VBox, Gtk.Buildable):
lpaned.pack1(lscrolls, resize=False, shrink=False)
lpaned.pack2(rpaned, resize=True, shrink=False)
rpaned.pack2(rscrolls, resize=False, shrink=False)
+rpaned.pack1(cscrolls, resize=True, shrink=False)
self.pack_start(lpaned, True, True, 0)
# Autohide
self._autohide_enabled = True
@@ -397,43 +398,21 @@ class Workspace (Gtk.VBox, Gtk.Buildable):
def set_canvas(self, widget):
"""Canvas widget (setter)"""
assert self.get_canvas() is None
-self._rpaned.pack1(widget, resize=True, shrink=False)
-self._update_canvas_scrolledwindow()
+widget = self._canvas_scrolls.add(widget)
def get_canvas(self):
"""Canvas widget (getter)"""
-widget = self._rpaned.get_child1()
-if widget is self._canvas_scrolls:
-widget = widget.get_child()
+widget = self._canvas_scrolls.get_child()
return widget
def _update_canvas_scrolledwindow(self):
-"""Update whether the canvas has a surrounding ScrolledWindow
-
-In fullscreen mode, the ScrolledWindow is removed from the widget
-hierarchy so that the canvas widget can occupy the full size of the
-screen. In nonfullscreen mode, the scrollers provide a pretty frame.
-"""
-canvas = self.get_canvas()
-parent = canvas.get_parent()
+"""Update the canvas ScrolledWindow's border."""
+parent = self._canvas_scrolls
if not self._is_fullscreen:
-if parent is self._canvas_scrolls:
-return
-logger.debug("Adding GtkScrolledWindow around canvas")
-assert parent is self._rpaned
-self._rpaned.remove(canvas)
-self._rpaned.pack1(self._canvas_scrolls, resize=True, shrink=False)
-self._canvas_scrolls.add(canvas)
-self._canvas_scrolls.show_all()
+parent.set_shadow_type(Gtk.ShadowType.NONE)
else:
-if parent is self._rpaned:
-return
-logger.debug("Removing GtkScrolledWindow around canvas")
-assert parent is self._canvas_scrolls
-self._canvas_scrolls.remove(canvas)
-self._rpaned.remove(self._canvas_scrolls)
-self._rpaned.pack1(canvas, resize=True, shrink=False)
-self._canvas_scrolls.hide()
+parent.set_shadow_type(Gtk.ShadowType.IN)
+ # TODO: this should really be done with CSS now.
## Tool widgets
->8
--
Andrew Chadwick
Bug#766931: Cannot reproduce: please retest?
Hi - can you try and reproduce this with a fresh config and MyPaint 1.2.0 or 1.2.1 from Debian please? Alternatively, with 1.3.0-alpha from upstream git ☺ You can run MyPaint in a fuller debugging mode with a completely fresh temporary configuration like this, assuming you're using the default shell: $ MYPAINT_DEBUG=1 mypaint -c "/tmp/throwaway_config_$$" -- Andrew Chadwick
Bug#833786: More likely to be a driver/config issue? Please retest.
Hi Hamed -- You don't say what windowing environment and desktop environment you are using, so I am assuming GNOME on X11. You also don't say how the tablet fails to operate, so I am assuming that it's what I have seen in the past with this exact model: cursor moves to where you tap, but no pressure and no subsequent cursor updates. Good news: this *should* be fixed with newer GTK or kernel or X11 libinput/evdev drivers (you don't say which you are using, but I always allow mine to select the default) The i405X is part of my testing hardware for MyPaint, and I believe it *currently* works fine with current stretch/testing, with the defaults. It didn't before; I suspect I may have bought it because lots of people were complaining about it not working. Please can you test again, and let us know a) whether the tablet works correctly and does pressure, and b) the output of the following commands: dpkg -l | grep xserver-xorg-input dpkg -l | grep mypaint uname -a One way you can help Debian and MyPaint is by reporting what happens with the "Event Axes" tester in gtk3-demo. It got renamed recently to "Touch and Drawing Tablets", so look for that too! This demo shows blobs for pressure, crosshairs for position tracking, and the name of the tablet as the GTK/GDK backend sees it. If you test with it, it will reveal whether this is a GTK/X11/kernel bug or a MyPaint application bug because its codebase is entirely unrelated to MyPaint. One caveat: I test with v1.2.1 or 1.3.0-alpha. We have one notable fix in these revisions for Genius-like tablets (random pressure dropouts during continuous strokes), but I can't remember whether it is in v1.2.0. I suspect it isn't the bug you're seeing, however. -- Andrew Chadwick
Bug#759508: Fixed in 1.2.0
MyPaint version 1.2.0 has been inn the Debian repos for ages, and it has more sensible defaults and a separate debugging mode with a longer interval for developers. Debian maintainer: please can this bug be closed? -- Andrew Chadwick
Bug#848356: Fixed upstream
This bug is fixed upstream, with the release of 1.2.1. There is an open Debian bug about this package not being present in the testing/sid environment, #853938. -- Andrew Chadwick
Bug#710864: Fixed in 1.2.0?
This bug should have been fixed with the upload of 1.2.0. MyPaint now uses GTK3, which hard-depends on hicolor-icon-theme. Please retest, and if it's still breaking please send feedback. -- Andrew Chadwick
Bug#853938: mypaint: new upstream release: version 1.2.1
Package: mypaint Version: 1.2.0-3 MyPaint version 1.2.1 has been released upstream, and should fix some bugs which have been reported here. https://github.com/mypaint/mypaint/releases/tag/v1.2.1 https://github.com/mypaint/mypaint/releases/download/v1.2.1/mypaint-1.2.1.tar.xz https://github.com/mypaint/mypaint/releases/download/v1.2.1/SHA256SUMS-sources.txt We maintain our own Ubuntu PPA Debianization of MyPaint, and encourage Debian and derived OSes to consult it, feed back changes to us via Github PRs, and steal chunks of it. https://github.com/mypaint/mypaint.deb/tree/v1.2.x -- Andrew Chadwick
Bug#838050: Fix now in upstream
The fix is included upstream in modified form as https://git.gnome.org/browse/mutter/commit/?id=3137ddb1a1071407f557a181121695e37e5faf3d. I have not tested this exact patch, but it should work. This bug will be fixed by mutter 3.22.0, which seems to have just been tagged upstream. -- Andrew Chadwick
Bug#838050: Patched upstream
Apologies for the big messy merge. Upstream now have a patch for this, currently pending review, which applies cleanly to Debian mutter 3.21.92-1 and fixes the knock-on problems in gnome-shell etc. https://bugzilla.gnome.org/show_bug.cgi?id=771628 https://bugzilla.gnome.org/attachment.cgi?id=335863=diff With my patched local build, all the hardware I've tested now works and doesn't crash gnome-shell in wayland or xorg. -- Andrew Chadwick
Bug#838047: Confirmed: breaks *all* tablets
Okay, found time for some more testing. It seems that libwacom2 0.19 is probably off the hook here: the problem can be made to go away by merely switching versions of mutter (+ libmutter) for all tablets on my test bench. Thank you for the update to 0.22, nevertheless. Doubtless it will be needed before too long. BTW, the debian/watch file appears to be broken according to qa.debian - perhaps that's why some releases weren't noticed? On 18 September 2016 at 02:23, Andrew Chadwick <a.t.chadw...@gmail.com> wrote: > GNOME sessions with gnome-shell 3.21.91-2 and libwacom2 0.22-1 still > segfault when any any of my USB tablet devices are attached. This > includes the Wacom USB Wireless Accessory Kit: it's fine after being > plugged in initially without the tablet being turned on, but when the > tablet is turned on and begins communicating wirelessly, the session > dies just as above. > > I've tried a plain old USB optical mouse, a USB keyboard, and a couple > of USB joypads too - those are unaffected. > > From the console, libwacom-list-local-devices 0.22 detects the plugged > device and lists its features like it should. No segfaults there. -- Andrew Chadwick
Bug#838050: GDM3-only behaviour; Wayland not totally broken; bad tablets break even that
Reported upstream as a gnome-shell bug initially at https://bugzilla.gnome.org/show_bug.cgi?id=771628 I can confirm that downgrading mutter and its support files and libs fixes the problem. In a picture such as gnome-shell3.21.91-2 gnome-session 3.20.2-1 libwacom2 0.22-1 <<< ***OR 0.19-1, doesn't matter! xserver-xorg 1:7.7+16 xwayland 2:1.18.4-1 mutter 3.21.92-1 <<< *** gnome-shell segfaults Downgrading mutter (& its lib and -common package) to 3.21.91 fixes the segfaults, in both Xorg and Xwayland. mutter 3.21.91-2 <<< +++ no segfaults, all tablets OK Quick workaround for people having problems right now: # apt-get install mutter=3.21.91-2 mutter-common=3.21.91-2 libmutter0i=3.21.91-2 # apt-mark hold mutter mutter-common libmutter0i
Bug#838050: GDM3-only behaviour; Wayland not totally broken; bad tablets break even that
The behaviour in gdm3 alone (outside of a user session) is different from tablet to tablet. * Wacom Intuos5 USB: no crashes, pen functions as a second crosshair pointer * HUION H610PRO USB: no crashes, pen functions as a second crosshair pointer * Genius EasyPen i405X USB: crashes gnome-session in this environment as well, repeatedly, same segfault from gnome-shell. systemd appears to be desperately trying to launch Xorg instead afterwards? Which then *also* segfaults repeatedly. The Huion and Wacom tablets work inside GNOME-on-Wayland user sessions, and gtk3-demo's "Touch and Drawing Tablets" module presents their extra axes (pressure, or pressure+tilt+distance, respectively). However using Wayland is not really a great workaround currently given how crashy it is (xwayland 2:1.18.4-1, pressing Alt kills Chromium, wow.) The Genius tablet is well known as a horrid crashy mess generally, which is why I bought it. This behaviour is new even for that, however. -8<- Sep 18 03:17:32 spatula kernel: [50703.338856] usb 2-1: new low-speed USB device number 35 using xhci_hcd Sep 18 03:17:32 spatula kernel: [50703.532827] usb 2-1: New USB device found, idVendor=0458, idProduct=5010 Sep 18 03:17:32 spatula kernel: [50703.532834] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0 Sep 18 03:17:32 spatula kernel: [50703.532838] usb 2-1: Product: EasyPen i405X Sep 18 03:17:32 spatula kernel: [50703.532841] usb 2-1: Manufacturer: Genius Sep 18 03:17:32 spatula kernel: [50703.561689] input: Genius EasyPen i405X as /devices/pci:00/:00:14.0/usb2/2-1/2-1:1.0/0003:0458:5010.0040/input/input175 Sep 18 03:17:32 spatula kernel: [50703.615183] kye 0003:0458:5010.0040: input,hiddev0,hidraw2: USB HID v1.11 Device [Genius EasyPen i405X] on usb-:00:14.0-1/input0 Sep 18 03:17:32 spatula mtp-probe: checking bus 2, device 35: "/sys/devices/pci:00/:00:14.0/usb2/2-1" Sep 18 03:17:32 spatula mtp-probe: bus: 2, device: 35 was not an MTP device Sep 18 03:17:33 spatula gnome-shell[29393]: Could not get tablet information for 'Genius EasyPen i405X': (null) Sep 18 03:17:33 spatula kernel: [50704.317185] gnome-shell[29393]: segfault at 10 ip 7fd62869e844 sp 7ffe16cebae0 error 4 in libwacom.so.2.5.0[7fd62869b000+9000] Sep 18 03:17:33 spatula org.gnome.Shell.desktop[29393]: (EE) Sep 18 03:17:33 spatula org.gnome.Shell.desktop[29393]: Fatal server error: Sep 18 03:17:33 spatula org.gnome.Shell.desktop[29393]: (EE) failed to dispatch Wayland events: Broken pipe Sep 18 03:17:33 spatula org.gnome.Shell.desktop[29393]: (EE) [... one more segfault ...] Sep 18 03:17:35 spatula gdm3: Child process -29545 was already dead. Sep 18 03:17:35 spatula gdm3: Child process 29534 was already dead. Sep 18 03:17:35 spatula gdm3: Unable to kill session worker process Sep 18 03:17:35 spatula systemd[1]: Started Session c22 of user Debian-gdm. Sep 18 03:17:35 spatula udev-acl.ck[29583]: g_slice_set_config: assertion 'sys_page_size == 0' failed Sep 18 03:17:35 spatula /usr/lib/gdm3/gdm-x-session[29582]: (--) Log file renamed from "/var/lib/gdm3/.local/share/xorg/Xorg.pid-29585.log" to "/var/lib/gdm3/.local/share/xorg/Xorg.0.log" Sep 18 03:17:35 spatula /usr/lib/gdm3/gdm-x-session[29582]: X.Org X Server 1.18.4 Sep 18 03:17:35 spatula /usr/lib/gdm3/gdm-x-session[29582]: Release Date: 2016-07-19 Sep 18 03:17:35 spatula /usr/lib/gdm3/gdm-x-session[29582]: X Protocol Version 11, Revision 0 [... starts up, then a stream of new segfaults ...] ->8-
Bug#838050: Breaks all tablets, no good workaround
My first through was the common Debian situation where there's a mismatch between libwacom2 (which lags releases regularly) and GNOME (which advances fast). It may well not be libwacom at fault, but without a debugging trace we can't tell yet. A recent update to libwacom 0.22 doesn't fix this issue, however. See also Bug#838047 < https://bugs.debian.org/838047 >. This breaks gnome-shell with all the Wacom and non-Wacom graphics tablets I've tried, crashing gnome-shell at or shortly after the point when they are connected. However the non-tablet USB devices I've tried seem OK, including my (non-Wacom, non-pen, regular multitouch) touchscreen. See bug 838047 for details and log traces. I cannot get the suggested rmmod workaround to work on my system. The non-Wacom tablets still cause gnome-shell to crash immediately upon being plugged in, and when a Wacom tablet is plugged in, the "wacom" kernel module is automatically loaded and stays loaded. I am using Wayland gdm3, and Xorg user gnome-shell sessions. gnome-shell 3.21.91-2 gdm3 3.21.90-1 libwacom2 0.22-1 -- Andrew Chadwick
Bug#838047: Confirmed: breaks *all* tablets
GNOME sessions with gnome-shell 3.21.91-2 and libwacom2 0.22-1 still segfault when any any of my USB tablet devices are attached. This includes the Wacom USB Wireless Accessory Kit: it's fine after being plugged in initially without the tablet being turned on, but when the tablet is turned on and begins communicating wirelessly, the session dies just as above. I've tried a plain old USB optical mouse, a USB keyboard, and a couple of USB joypads too - those are unaffected. >From the console, libwacom-list-local-devices 0.22 detects the plugged device and lists its features like it should. No segfaults there.
Bug#825560: Downstream testing; 2.10.3 now available
Version 2.10.3 has been released (or at least, tagged) upstream, and fixes this regression. https://cgit.freedesktop.org/xorg/driver/xf86-input-evdev/log/ Some of our MyPaint downstream reporters have been testing, and the patch in question does indeed fix this regression. A patched third-party 2.10.2 deb is now available via the downstream bug report. https://github.com/mypaint/mypaint/issues/732 Please could 2.10.3 be uploaded to unstable as soon as possible? A lack of any positive, nonzero pressure when pressure is declared as an axis completely breaks the primary use for tablet hardware: painting programs. A wide variety of readily available, inexpensive hardware is affected by this bug. -- Andrew Chadwick
Bug#822784: mypaint: Does not start "TypeError: GLib.filename_to_utf8() takes exactly 2 arguments (4 given)"
Upstream dev hat: on. 1.2.1-beta.0 is out as a prerel, and should contain a fix for this issue. Upstream bug: https://github.com/mypaint/mypaint/issues/634 -- Andrew Chadwick
Bug#810553: unison: Please package Unison's fsmonitor.py
Package: unison Version: 2.48.3-1 Severity: normal Dear Maintainer, Please could the fsmonitor.py script and fsmonitor package in the Unison distribution be packaged for Debian? It might be sensible to package them as an external Python lib and script package, given the differing runtime requirements. fsmonitor is required for Unison's file system monitoring features to work I believe. It appears to be receiving some love upstream. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-updates'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 4.2.0-1-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages unison depends on: ii libc6 2.19-22 Versions of packages unison recommends: ii openssh-client [ssh-client] 1:7.1p1-5 Versions of packages unison suggests: pn unison-all -- no debconf information
Bug#781103: Fix confirmed
Simply upgrading the package restores a working Wacom setup in GNOME. Fix confirmed; thank you! -- Andrew Chadwick
Bug#781103: libwacom2: Needs update for 3.17 and above
Reproduced. This presumably is the source of the software rot I've been experiencing with my tablet of late *sigh* Below are my findings with various available kernels on my system, and links to other bugs I've reported. libwacom2 0.15 is available in Ubuntu presently. http://packages.ubuntu.com/search?keywords=libwacom2 Timo: please provide a package for Debian too, or mark this package as orphaned in Debian, because it functionally is right now. https://www.debian.org/devel/wnpp/ Linux spatula 4.0.0-2-amd64 #1 SMP Debian 4.0.8-2 (2015-07-22) x86_64 GNU/Linux * gnome-control-center 3.16.3-1 does not recognise my tablet at all * might be accidentally reported as https://bugs.debian.org/793059 Linux spatula 3.16-3-amd64 #1 SMP Debian 3.16.5-1 (2014-10-10) x86_64 GNU/Linux * gnome-control-center 3.16.3-1 recognises tablet - button mappings UI is presented, but is unexpectedly basic * gnome-settings-daemon 3.16.3-1 does not apply configured button mappings - https://bugs.debian.org/791530 - Buttons configured to send keypresses don't - Instead, they act as numbered buttons from the Wacom Intuos5 touch M Pen pad device Linux spatula 3.14-2-amd64 #1 SMP Debian 3.14.13-2 (2014-07-24) x86_64 GNU/Linux * Experience just like kernel 3.16.3-amd64. * However my laptop's touchpad no longer sends scroll events or multi- tap button press events... complete side issue there though. -- Andrew Chadwick
Bug#793059: Possible cause: old libwacom2
It's just possible that this is caused by libwacom2 being the best part of 2 years outdated w.r.t. GNOME https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781103 -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#793059: gnome-control-center: Wacom module no longer detects when a tablet is plugged in
Package: gnome-control-center Version: 1:3.16.2-2+b1 Severity: important The Wacom module in gnome-control-center no longer detects when my Intuos 5 is plugged in to the USB port. *** Reporter, please consider answering these questions, where appropriate *** * What led up to the situation? I wanted to evaluate whether debian bug 791530 was fixed yet. https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=791530 Related/indicative of some upstream changes that haven't been fully integrated into Debian yet? * What exactly did you do (or not do) that was effective (or ineffective)? I attempted to plug in my graphics tablet, a Wacom Intuos 5 touch M (PTH-650/K, 056a:0027) to the USB port on my laptop while the Wacom control panel was open. * What was the outcome of this action? When inserting this tablet, which was supported fully until recently (and is new enough to matter), all that is shown is the default No tablet detected / Please plug in or turn on your Wacom tablet message. Xorg appears fully in tune with this model of tablet (see log), and the tablet is listed (see list) and testable (all axes including pressure, x-tilt and y-tilt) in xinput. * What outcome did you expect instead? I would expect the message above to be replaced almost immediately with a full, working interface allowing me to configure my tablet's buttons, as has happened with earlier Debian GNOME. -- $ xinput list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ SYNAPTICS Synaptics Large Touch Screenid=9[slave pointer (2)] ⎜ ↳ DLL060A:00 06CB:2734 id=11 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Finger id=14 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pad pad id=15 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen stylus id=16 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen eraser id=17 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen cursor id=18 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Power Button id=6[slave keyboard (3)] ↳ Video Bus id=7[slave keyboard (3)] ↳ Power Button id=8[slave keyboard (3)] ↳ Integrated_Webcam_HD id=10 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=12 [slave keyboard (3)] ↳ Dell WMI hotkeys id=13 [slave keyboard (3)] - syslog --- (on plugging the device in) Jul 20 23:30:16 spatula kernel: [ 108.512318] wacom 0003:056A:0027.0003: hidraw2: USB HID v1.10 Mouse [Wacom Co.,Ltd. Intuos5 touch M] on usb-:00:14.0-2/input0 Jul 20 23:30:16 spatula kernel: [ 108.512980] input: Wacom Intuos5 touch M Finger as /devices/pci:00/:00:14.0/usb1/1-2/1-2:1.1/0003:056A:0027.0004/input/input19 Jul 20 23:30:16 spatula kernel: [ 108.513126] wacom 0003:056A:0027.0004: hidraw3: USB HID v1.10 Device [Wacom Co.,Ltd. Intuos5 touch M] on usb-:00:14.0-2/input1 [multiple lines duplicated from Xorg.0.log omitted] Jul 20 23:30:16 spatula org.gnome.ControlCenter.SearchProvider[1710]: (gnome-control-center:2383): wacom-cc-panel-WARNING **: Failed to create fallback wacom device for '/dev/input/event15': Unsupported bus 'hid' (5) Jul 20 23:30:16 spatula org.gnome.ControlCenter.SearchProvider[1710]: (gnome-control-center:2383): wacom-cc-panel-WARNING **: Failed to create fallback wacom device for '/dev/input/event14': Unsupported bus 'hid' (5) Jul 20 23:30:16 spatula org.gnome.ControlCenter.SearchProvider[1710]: (gnome-control-center:2383): wacom-cc-panel-WARNING **: Failed to create fallback wacom device for '/dev/input/event14': Unsupported bus 'hid' (5) Jul 20 23:30:16 spatula org.gnome.ControlCenter.SearchProvider[1710]: (gnome-control-center:2383): wacom-cc-panel-WARNING **: Failed to create fallback wacom device for '/dev/input/event14': Unsupported bus 'hid' (5) Jul 20 23:30:16 spatula gnome-session[1654]: (gnome-settings-daemon:1729): wacom-plugin-WARNING **: Failed to create fallback wacom device for '/dev/input/event15': Unsupported bus 'hid' (5) Jul 20 23:30:16 spatula gnome-session[1654]: (gnome-settings-daemon:1729): wacom-plugin-WARNING **: Failed to create fallback wacom device for '/dev/input/event14': Unsupported bus 'hid' (5) Xorg.0.log -- (on plugging the device in) [ 108.456] (II) config/udev: Adding input device Wacom Intuos5 touch M Finger (/dev/input/mouse3) [ 108.456] (**) Wacom Intuos5 touch M Finger: Ignoring device from InputClass touchpad
Bug#791530: Possible cause: old libwacom2
It's just possible that this is caused by libwacom2 being the best part of 2 years outdated w.r.t. GNOME https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=781103 -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#791530: gsdwacom: button mappings configured in gnome-control-center are not applied
Package: gnome-settings-daemon Version: 3.16.2-3 Severity: normal Hi there -- The button map settings I have configured in gnome-control-center are not being applied: * immediately after I add the button bindings in g-c-c, * when I plug my tablet in after unplugging it, * after I restart GNOME. My tablet is an Intuos 5 touch M, PTH-650, connected over USB. Xorg knows about it, and I can see using `xinput test` that its pressure and tilt events are coming through OK. It's a perfetly working stylus when tested with MyPaint, I'm just not getting the settings I've configured in GNOME. $ lsusb [...] Bus 001 Device 013: ID 056a:0027 Wacom Co., Ltd Intuos5 touch M [...] $ xinput list ⎡ Virtual core pointer id=2[master pointer (3)] ⎜ ↳ Virtual core XTEST pointerid=4[slave pointer (2)] ⎜ ↳ SYNAPTICS Synaptics Large Touch Screenid=11 [slave pointer (2)] ⎜ ↳ DLL060A:00 06CB:2734 id=13 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Finger id=9[slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen stylus id=10 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen eraser id=16 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen cursor id=17 [slave pointer (2)] ⎜ ↳ Wacom Intuos5 touch M Pen pad id=18 [slave pointer (2)] ⎣ Virtual core keyboard id=3[master keyboard (2)] ↳ Virtual core XTEST keyboard id=5[slave keyboard (3)] ↳ Power Button id=6[slave keyboard (3)] ↳ Video Bus id=7[slave keyboard (3)] ↳ Power Button id=8[slave keyboard (3)] ↳ Integrated_Webcam_HD id=12 [slave keyboard (3)] ↳ AT Translated Set 2 keyboard id=14 [slave keyboard (3)] ↳ Dell WMI hotkeys id=15 [slave keyboard (3)] I would expect the button map to work immediately after being configured, and in all the other cases identified above, because this worked fine under 3.14 (I think). Under that version: * gnome-control-center presents a full-screen overlay with an actual picture of my correctly-identified tablet e.g. https://people.redhat.com/ofourdan/libwacom/misc/Intuos5-M-layout-viewer.png * button mappings set up for button1-button8 all get applied * button mappings for the touch ring CW and CCW bindings get applied * the touch ring's centre button switches it between its 4 modes, moving the hardware LED on to its next position each time Under 3.16.2, none of the above apply. The mode switcher button doesn't switch modes (and acts as button1 on the pad device), the mode LED stays at its first position, the tablet buttons 1..8 act as buttons 2..9 of the pad device, and no keystroke bindings are applied Additionally, the UI for g-c-c seems to have regressed to a regular window containing a config list with buttons, dropdowns for the action (I tried Send Keystroke a lot on the middle column), and a slot for the key to send. It looks similar to the 3.10 setup as I recall it, and is similar to http://www.kesigomu.hu/wacom-es-a-linux/ but with a much more button-like appearance for the middle column dropdowns. I have tried this with a fresh user with all relevant group memberships set, and with my regular user account, configuring it from scratch. I get the same problem with both accounts. $ dpkg -l gnome-control-center* | grep '^.. ' ii gnome-control-center 1:3.16.2-2+b1 amd64utilities to configure the GNOME desktop ii gnome-control-center-data 1:3.16.2-2all configuration applets for GNOME - data files $ dpkg -l libwacom* | grep '^.. ' ii libwacom-common 0.8-1all Wacom model feature query library (common files) un libwacom0 none none (no description available) ii libwacom2:amd64 0.8-1amd64Wacom model feature query library I am not using xsetwacom, although the following lines will re-bind the relevant buttons $ xsetwacom --set Wacom Intuos5 touch M Pen pad button 2 key z $ xsetwacom --set Wacom Intuos5 touch M Pen pad button 3 key y $ zzyyyzyzyzy [... works fine, hold does not repeat ...] Let me know if you need any more information about this apparent regression. -- System Information: Debian Release: stretch/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-updates'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16.0-4-amd64 (SMP w/4 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages gnome-settings-daemon depends on: ii
Bug#791530: Confirmation: regression between jessie=stable and stretch=testing
After a little VM testing, I can confirm that this is a regression between Jessie=stable and Stretch=testing. [jessie-vm: bug not present] $ dpkg -l gnome-control-center gnome-settings-daemon [...] ii gnome-control- 1:3.14.2-3 amd64utilities to configure the GNOME ii gnome-settings 3.14.2-3 amd64daemon handling the GNOME session [stretch-vm: bug present] $ dpkg -l gnome-control-center gnome-settings-daemon [...] ii gnome-control- 1:3.16.2-2+b amd64utilities to configure the GNOME ii gnome-settings 3.16.2-3 amd64daemon handling the GNOME session Let me know if any more information is required here. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#742761: workaround for evince search issue
It's not much of a workaround, but in 3.14.1 turning on Continuous view from the View options menu before clicking around in the search results sidebar allows Evince to jump to the results. Having to do this is intensely irritating if you prefer page-focussed PDF reading most of the time. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#766184: maya-calendar-daemon does not autostart
Package: maya-calendar-daemon Version: 0.3-1~experimental1 Severity: normal The notification daemon for Maya does not automatically start in new GNOME desktop sessions. It appears that this is due to a spurious OnlyShowIn=Pantheon in its /etc/xdg/autostart entry (a symlink to /usr/share/applications/maya-calendar-daemon.desktop) which prevents the daemon from starting in GNOME. Removing the line allows the notification daemon to start when the user logs into GNOME: --- /etc/xdg/autostart/maya-calendar-daemon.desktop.BAK 2014-10-21 12:31:04.911379607 +0100 +++ /etc/xdg/autostart/maya-calendar-daemon.desktop 2014-10-21 12:42:34.798006432 +0100 @@ -7,5 +7,4 @@ Type=Application Categories=System -OnlyShowIn=Pantheon NoDisplay=true X-GNOME-AutoRestart=true -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (500, 'testing-updates'), (50, 'unstable'), (5, 'experimental') Architecture: amd64 (x86_64) Kernel: Linux 3.16-2-amd64 (SMP w/8 CPU cores) Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages maya-calendar-daemon depends on: ii libatk1.0-0 2.14.0-1 ii libc6 2.19-11 ii libcairo-gobject2 1.12.16-5 ii libcairo2 1.12.16-5 ii libcamel-1.2-49 3.12.6-1.1 ii libchamplain-0.12-0 0.12.9-1 ii libchamplain-gtk-0.12-0 0.12.9-1 ii libclutter-1.0-01.20.0-1 ii libclutter-gtk-1.0-01.6.0-1 ii libcogl-pango20 1.18.2-2 ii libcogl-path20 1.18.2-2 ii libcogl20 1.18.2-2 ii libdrm2 2.4.58-2 ii libecal-1.2-16 3.12.6-1.1 ii libedataserver-1.2-18 3.12.6-1.1 ii libegl1-mesa [libegl1-x11] 10.2.8-1 ii libgbm1 10.2.8-1 ii libgdk-pixbuf2.0-0 2.31.1-2+b1 ii libgee-0.8-20.14.0-3 ii libgeocode-glib03.14.0-1 ii libglib2.0-02.42.0-2 ii libgranite2 0.3.0-1~experimental1 ii libgtk-3-0 3.14.1-1 ii libical11.0-1 ii libjson-glib-1.0-0 1.0.2-1 ii libmaya-calendar0 0.3-1~experimental1 ii libnotify4 0.7.6-2 ii libnspr42:4.10.7-1 ii libnss3 2:3.17.1-1 ii libpango-1.0-0 1.36.8-2 ii libpangocairo-1.0-0 1.36.8-2 ii libsecret-1-0 0.18-1+b1 ii libsoup2.4-12.48.0-1 ii libsqlite3-03.8.6-1 ii libwayland-client0 1.6.0-2 ii libwayland-cursor0 1.6.0-2 ii libwayland-egl1-mesa [libwayland-egl1] 10.2.8-1 ii libwayland-server0 1.6.0-2 ii libx11-62:1.6.2-3 ii libxcomposite1 1:0.4.4-1 ii libxdamage1 1:1.1.4-2 ii libxext62:1.3.3-1 ii libxfixes3 1:5.0.1-2 ii libxi6 2:1.7.4-1 ii libxkbcommon0 0.4.3-2 ii libxml2 2.9.1+dfsg1-4 ii libxrandr2 2:1.4.2-1 maya-calendar-daemon recommends no packages. maya-calendar-daemon 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#766300: cinnamon-settings-daemon: Synaptics touchpads: 3-touch tap is ignored (TapButton3 always 0)
Package: cinnamon-settings-daemon
Version: 2.2.4.repack-6~atc1
Severity: normal
Tags: patch
Hi there --
csd 2.2.4.repack-6 always turns off 3-tap middle button on my Dell XPS13
Developer Edition's fancy Synaptics clickpad. This is quite a newly supported
device, but looking at the code, other kinds of touchpad will be affected too.
The problem is however more apparent with a clickpad.
This omission appears to be deliberate (see the patch), but it is also
fundamentally incorrect behaviour and damn inconvenient. Moreover, it appears
to have been disabled in order to support gestures with the touchpad which
do not appear to have suppport elsewhere in Cinnamon, and which I do not want.
Please consider permitting csd to set up touchpads with working middle button
support via tap.
3-touch taps for middle button work fine in Xfce4 and GNOME on my hardware
without any special fiddling (other than a visit to the prefs).
8--
--- plugins/mouse/csd-mouse-manager.c.BAK 2014-06-08 13:01:44.0
+0100
+++ plugins/mouse/csd-mouse-manager.c 2014-10-22 02:27:40.692238266 +0100
@@ -658,5 +658,5 @@
data[4] = (state) ? ((left_handed) ? 3 : 1) : 0;
data[5] = (state) ? ((left_handed) ? 1 : 3) : 0;
-data[6] = 0; /* Disable three touch tap so gestures work */
+data[6] = (state) ? 2 : 0;
XChangeDeviceProperty (GDK_DISPLAY_XDISPLAY
(gdk_display_get_default ()), xdevice, prop, XA_INTEGER, 8,
PropModeReplace, data, nitems);
8--
*** Reporter, please consider answering these questions, where appropriate ***
* What led up to the situation?
Attempting to get my touchpad working correctly. As I see it.
* What exactly did you do (or not do) that was effective (or
ineffective)?
1. Configured System Settings - Mouse Touchpad - Touchpad - General -
Enable mouseclicks with touchpad to on.
2. (when that only provided {single,double} tap button {1,3}), I then
configured /etc/X11/xorg.conf.d/50-synaptics.conf appropriately:
Section InputClass
Identifier touchpad catchall
Driver synaptics
MatchIsTouchpad on
Option CoastingSpeed 0
# These too, or they won't work in gdm/lightdm
# Might improve Cinnamon's handling of touchpads? -- atc
Option TapButton1 1
Option TapButton2 3
Option TapButton3 2
EndSection
* What was the outcome of this action?
Neither approach worked: although my dm was happier, Cinnamon was not. Checking
with synclient after setting Enable mouseclicks with touchpad to on produces
the following output:
8--
$ synclient
Parameter settings:
[...]
TapButton1 = 1
TapButton2 = 3
TapButton3 = 0
ClickFinger1= 1
ClickFinger2= 3
ClickFinger3= 2
[...]
8--
Experimenting a bit more reveals that csd touches TapButton{1,2,3} always, but
never touches ClickFinger{1,2,3}.
* What outcome did you expect instead?
Note the disparity between the clickpad's multi-finger clicks and its multi-
finger taps. These two sections should (IMO) match: I expect *tapping* with
three fingers to send a middle button press event because *clicking* with three
fingers does this.
*** End of the template - remove these template lines ***
-- System Information:
Debian Release: jessie/sid
APT prefers testing
APT policy: (900, 'testing'), (500, 'testing-updates'), (50, 'unstable'), (5,
'experimental')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16-2-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_GB.utf8, LC_CTYPE=en_GB.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages cinnamon-settings-daemon depends on:
ii dconf-gsettings-backend [gsettings-backend] 0.22.0-1
ii gsettings-desktop-schemas3.14.0-1
ii libc62.19-11
ii libcairo21.12.16-5
ii libcanberra-gtk3-0 0.30-2.1
ii libcanberra0 0.30-2.1
ii libcinnamon-desktop4 2.2.3-2
ii libcolord2 1.2.1-1+b1
ii libcups2 1.7.5-4+b1
ii libdbus-glib-1-2 0.102-1
ii libfontconfig1 2.11.0-6.1
ii libgdk-pixbuf2.0-0 2.31.1-2+b1
ii libglib2.0-0 2.42.0-2
ii libgnomekbd8 3.6.0-1
ii libgtk-3-0 3.14.1-1
ii libgudev-1.0-0 215-5+b1
ii liblcms2-2 2.6-3+b2
ii libnotify4 0.7.6-2
ii libnspr4
Bug#752425: [Pkg-xfce-devel] Bug#752425: Bug#752425: xfce4-session: upower-1.0 transition
My concern was lack of a suspend (or hibernate) button in the logout dialog after recent dist-upgrades. Testing in a VM, I can confirm that installing xfce4-session 4.10.1-7 restores the missing suspend and hibernate buttons, and that downgrading to 4.10.1-6 causes the suspend and hibernate buttons to go missing from the logout dialog again. Short form: upgrading to 4.10.1-7 fixes my frustrating logout dialog button problem after logging out and back in again; thank you maintainers! -- Andrew Chadwick
Bug#756387: cinnamon-common: cinnamon-settings: Backgrounds shows no choices after wallpapers are added
Package: cinnamon-common Version: 2.2.14-3 Severity: normal Tags: upstream patch Dear Maintainer, The Backgrounds module in the Cinnamon System Settings program does not show any wallpaper previews, either by default (which is probably reasonable), or after the user has clicked on Add and added a valid wallaper image (which is not reasonable). This prevents this settings module from building up a library of background images, making it entirely useless. It's fixable by patching /usr/share/cinnamon/cinnamon-settings/bin/imtools.py to be a bit more careful with its checks - the guts of PIL can't compare Images with None right now. Currently an exception is caught, printed and discarded by cs_backgrounds.py when mangling the cached preview thumbnails for display. Symptom: no wallpapers visible in the list - and 8- $ cinnamon-settings Could not find bluetooth module; is the cinnamon-control-center package installed? __init__ took 81.983 ms Loading Backgrounds module Failed to convert /home/testuser/.cinnamon/backgrounds/Dark_Ivy.jpg: 'NoneType' object has no attribute 'mode' [...] 8- and so on dumped the terminal after image files have been added. Patch: 8- --- imtools.py.BAK 2014-07-29 12:32:57.256599508 +0100 +++ imtools.py 2014-07-29 13:04:51.216999888 +0100 @@ -860,5 +860,5 @@ # Paste on top -if source == mask: +if mask and (source == mask): if has_alpha(source): # invert_alpha = the transparant pixels of the destination 8- Should cinnamon-common also depend on python-pil? PIL is clearly being pulled in though some other route by installing cinnamon though. I've not gone digging through the dependencies to check from where. -- System Information: Debian Release: jessie/sid APT prefers testing APT policy: (900, 'testing'), (50, 'unstable') Architecture: amd64 (x86_64) Kernel: Linux 3.14-1-amd64 (SMP w/2 CPU cores) Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Versions of packages cinnamon-common depends on: ii dconf-gsettings-backend [gsettings-backend] 0.20.0-2 ii gir1.2-meta-muffin-0.0 2.2.6-2 ii python 2.7.8-1 cinnamon-common recommends no packages. cinnamon-common 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#710864: #710864: any updates?
Hello, Harishankar Are you able to update http://bugs.debian.org/710864 with any information which would help me reproduce the problem? Please be specific about any error messages you get from apt-get. Pasting the command lines you are using will be helpful, as would the contents of your /etc/apt/sources.list* and any instructions you can supply about how this problem can be demonstrated starting from a blank slate. Please be as detailed as you can, because I have not been able to reproduce this problem by myself using the information given. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710864: #710864: any updates?
On 5 June 2013 11:16, Harishankar v.harishan...@gmail.com wrote:
I don't get any apt-get install errors. I also tried deleting
the .mypaint/ folder from my home folder but it still doesn't work.
[...]
I am using amd64 distribution have also enabled multi-arch support on my
system. I am running Gnome Shell.
Still unable to reproduce with a fresh minimal gnome-shell install on
an amd64 vm with i386 multiarch support. MyPaint runs just fine and
finds its icons. Sources are presumably OK.
It looks as though you have the right packages installed, and these
should contain the icons. Please verify that /usr/share/icons/* is
populated with lots of icon files with the prefix mypaint-.
$ find /usr/share/icons/hicolor -name 'mypaint*' -o -name
'brush-blend-mode*' | sort
$ dpkg -L mypaint-data | grep /usr/share/icons | sort
these two commands should produce identical lists of files, although
one lists the folders and the other does not. If the find incantation
does not list any files, please purge and reinstall mypaint-data and
mypaint.
Have you ever deployed MyPaint manually, to a prefix other than /usr,
on this system? If so, please check every folder prefix listed in the
Icon search path: in your initial report using the find
incantation above. These files should be checked for readability by
your desktop user and/or removed.
If any of these prefixes contain icons in the hicolor theme, the
corresponding hicolor/icon-theme.cache must also be a) up to date and
b) readable to the desktop user: see
https://gitorious.org/mypaint/mypaint/blobs/master/README for details.
Actually you can delete it as well; it's just a cache of what icons
are present or absent in its corresponding folder.
From your icon search order, which is a normal one for MyPaint, you
might want to check for an outdated cache in '/home/hari/.icons',
'/home/hari/.local/share/icons', '/usr/share/gnome/icons', and
'/usr/local/share/icons' because those are the ones that'll shadow the
/usr/share/icons location.
(I *can* reproduce the error message by running with a copy of
manually backed-up /usr/share/icons/hicolor/icon-theme.cache created
by the hicolor-icon-theme's post-install hooks at a time when
mypaint-data was not installed. But that's not very interesting
considering that I wrote that test in the first place :) Anyway, if
you don't have a shadowing and outdated cache file, could you please
verify that these postinst hooks are running correctly by deinstalling
and reinstalling mypaint-data and mypaint a few times and checking to
see if the /usr/share/icons cache file's timestamp changes?)
Finally, are you configured in such away as to prevent GTK from using
the hicolor theme as a fallback? If so, please revert this
configuration.
FYI, mypaint checks for mypaint.{svg,png} and
mypaint-tool-brush.{svg,png} during that check.
--
Andrew Chadwick
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710864: #710864 [mypaint] MyPaint cannot find icons - does not start up
Please install the dependencies listed in your bug report and try again. The icons MyPaint needs are found in the mypaint-data package, and version 1.1.0-3 is required for this version of MyPaint. mypaint-data-extras is optional (Suggests rather than Depends), and MyPaint should run with or without it. Thanks for testing! -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#710864: #710864: cannot reproduce
Control: tags -1 + moreinfo unreproducible Cannot reproduce on a fresly-upgraded jessie+sid system pinned at jessie with: # apt-get install -t sid --no-install-recommends mypaint which installs at least mypaint and mypaint-data. I don't know how you're installing or building mypaint here, so I can't help you further without more information. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#708524: New upstream version, 0.11
Package: json-c Version: 0.10-1.2 There is a new upstream release of json-c available: https://s3.amazonaws.com/json-c_releases/releases/index.html (see also debian bug#693518) as linked from https://github.com/json-c/json-c/wiki (see also debian bug#704918) Importantly, this version changes the name used by pkg-config from json[.pc] to json-c[.pc] as spotted by one of our (=MyPaint devs') testers at https://gna.org/bugs/?20817 . Looks like the soname is changing too: https://github.com/json-c/json-c/commit/30dd367c0a2467dc292f653ea3afd6ad4c6e034b but I've not investigated further. Fun times ahead :) -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704927: bug 704927
Same underlying problem as bug 704935, which is reported upstream as https://gna.org/bugs/?20754 -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#704935: (bug update)
Workaround in SVN now. Investigating bug 704927 at the same time - seems related. Reported upstream as https://gna.org/bugs/?20754 -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691827: ITA: mypaint -- Paint program to be used with Wacom tablets
On 7 January 2013 23:47, Axel Beckert a...@debian.org wrote: Hi Andrew! Andrew Chadwick wrote: On 04/01/13 13:20, Daniel Baumann wrote: anyhow, if you need a sponsor to upload the package, let me know. I was also thinking about ITA'ing mypaint, because I don't want that it drops from Debian and, like Daniel, I sponsored it in the past, too. So I'm happy to see that someone else seems to care more than I would have done, and I'd be happy to sponsor it again, too. Excellent news, and thank you for the offer! A new build, 1.1.0-1, is up at mentors.debian.net: https://mentors.debian.net/package/mypaint [Responding below to Axel's comments re 1.1.0-1] A short review: I miss one thing in the changelog: You fixed http://bugs.debian.org/660881 but didn't mention that in the changelog. Fixed in 1.1.0-2. Another thing which makes me wonder is this lintian warning: I: mypaint: arch-dep-package-has-big-usr-share 3497kB 86% So, despite there is already a mypaint-data package, the mypaint package contains 86% arch-independent stuff? This seems to be a regression from 1.0.0-1, as http://lintian.debian.org/maintainer/gur...@phys.ethz.ch.html#mypaint doesn't list that warning. Migrated icons and message catalogs to mypaint-data, which gets it in under the limit. I'm loath to move anything else because I'm not sure what the effect would be of moving all the python libs. However, if more is needed, I could look at that. I'd like to see the above issues fixed before uploading the package. Other lintian warnings which are less severe, but should be easily fixed: I: mypaint source: unused-license-paragraph-in-dep5-copyright cc-by-3.0-us (paragraph at line 388) Fixed in 1.1.0-2. Should be linked up now. I: mypaint: desktop-entry-contains-encoding-key usr/share/applications/mypaint.desktop:3 Encoding Fixed upstream: https://gitorious.org/mypaint/mypaint/commit/1887c034981085d3e933aa86e6303a099a27307c FIXED for Debian in 1.1.0-2 (cherry-picked patch in quilt format) I: mypaint: spelling-error-in-copyright developper developer I: mypaint-data: spelling-error-in-copyright developper developer Fixed upstream: https://gitorious.org/mypaint/mypaint/commit/163503525c0a707e50714478e81ab192cfca4fac FIXED for Debian in 1.1.0-2 (cherry-picked patch in quilt format) While I'd be happy to see them fixed in 1.1.0-1, too, I'd sponsor 1.1.0-1 without them being fixed if they'll be fixed in 1.1.0-2. :-) I consider 1.1.0-1 to be irrevocably in the wild because it has been published at mentors.debian.net. 1.1.0-2 also. In order to be rigorous with version numbers, I will never upload new signed packages having the same version strings as previous uploads. If you still wish to sponsor, please would you sponsor the latest version on mentors, which is currently 1.1.0-2. Thanks! Oh, and a very minor style thingie: In the changelog entry, you sometimes use # before a bug number and sometimes not. I'd decide for one way and stay with it. Done! with public git-buildpackage style git repository at https://github.com/achadwick/mypaint-debian if you'd like to take a look or comment on it. There are a couple of issues that need addressing right now, so thanks for the offer. I see you're already working on the next steps. Cool! One question here: Why changing http://mypaint.intilinux.com/ to http://mypaint.info/ when http://mypaint.info/ redirects to http://mypaint.intilinux.com/? It's shorter and more memorable, the domain matches our project wiki, and the URL is that used in the about box of the application itself since 2009-08-27 ( https://gitorious.org/mypaint/mypaint/commit/8cb950a9 ). -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#691827: ITA: mypaint -- Paint program to be used with Wacom tablets
On 04/01/13 13:20, Daniel Baumann wrote: On 01/04/2013 02:18 PM, Daniel Baumann wrote: any progress on this? err, nevermind.. i just saw you retitled the bug yesterday. anyhow, if you need a sponsor to upload the package, let me know. Heh :) I'm working on a package up for review at https://mentors.debian.net/package/mypaint with public git-buildpackage style git repository at https://github.com/achadwick/mypaint-debian if you'd like to take a look or comment on it. There are a couple of issues that need addressing right now, so thanks for the offer. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#660881: mypaint-data package is too big, mostly optional, should be split
Package: mypaint-data
Version: 1.0.0-1
The mypaint-data package is roughly 31.3 MiB in size, and is currently a
hard dependency of MyPaint. It mostly consists of high resolution
background images in version 1.0.0-1. Not every user will want to
download or use those files, and they are optional. Please could
mypaint-data be split into a core set of backgrounds and brushes, and an
optional mypaint-data-extra package consisting of the hi-res backgrounds
only?
Patch attached for doing this and using dh_install to manage the split.
The package sizes with this patch on my system are:
mypaint 0.6 MiB (required)
mypaint-data 2.6 MiB (required)
mypaint-data-extra 28.8 MiB (optional)
The patch also updates the descriptions in the source package's
debian/control in line with the best practices documented in the Debian
Developer's Reference version 3.4.7 [1], and mentions a few features
added since 0.9.
[1]
http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-debian-control
--
Andrew Chadwick
diff -rNU2 mypaint-1.0.0.orig/debian/control mypaint-1.0.0.new/debian/control
--- mypaint-1.0.0.orig/debian/control 2011-05-03 14:59:58.0 +0100
+++ mypaint-1.0.0.new/debian/control 2012-02-22 13:31:54.102038334 +
@@ -10,9 +10,21 @@
Architecture: any
Depends: ${shlibs:Depends}, ${misc:Depends}, ${python:Depends}, mypaint-data (= ${source:Version}), python-numpy, python-gtk2
-Description: Paint program to be used with Wacom tablets
- This is a pressure sensitive Wacom tablet paint program. It comes with a large
- brush collection including charcoal and ink to emulate real media, but the
- highly configurable brush engine allows you to experiment with your own
- brushes and with not-quite-natural painting.
+Suggests: mypaint-data-extra
+Description: paint program for use with graphics tablets
+ MyPaint is a program for painting bitmap images which works well with
+ graphics tablets such as those made by Wacom.
+ .
+ MyPaint comes with a large brush collection including charcoal and ink to
+ simulate real media, and has a highly configurable brush engine which allows
+ you to experiment with your own brushes and with not-quite-natural painting.
+ It supports tilt- and pressure-sensitive tablets to the extent reported by
+ GTK+. The canvas is infinite, limited only by available memory, making it
+ especially appropriate for rapid design and sketching. MyPaint's interface
+ is quite simple, focusing on a fullscreen workflow and getting out of the
+ artist's way after choosing a brush and a color. It features arbitrary
+ zooming, rotation, and flipping of the canvas. Simple work in layers is
+ possible, but MyPaint does not support extensive filters or much in the way
+ of even basic image manipulation. MyPaint uses the OpenRaster format by
+ default, and can save and export to common simple raster formats.
Package: mypaint-data
@@ -20,8 +32,44 @@
Depends: ${misc:Depends}
Description: Brushes and backgrounds for the mypaint program
- This is a pressure sensitive Wacom tablet paint program. It comes with a large
- brush collection including charcoal and ink to emulate real media, but the
- highly configurable brush engine allows you to experiment with your own
- brushes and with not-quite-natural painting.
+ MyPaint is a program for painting bitmap images which works well with
+ graphics tablets such as those made by Wacom.
+ .
+ MyPaint comes with a large brush collection including charcoal and ink to
+ simulate real media, and has a highly configurable brush engine which allows
+ you to experiment with your own brushes and with not-quite-natural painting.
+ It supports tilt- and pressure-sensitive tablets to the extent reported by
+ GTK+. The canvas is infinite, limited only by available memory, making it
+ especially appropriate for rapid design and sketching. MyPaint's interface
+ is quite simple, focusing on a fullscreen workflow and getting out of the
+ artist's way after choosing a brush and a color. It features arbitrary
+ zooming, rotation, and flipping of the canvas. Simple work in layers is
+ possible, but MyPaint does not support extensive filters or much in the way
+ of even basic image manipulation. MyPaint uses the OpenRaster format by
+ default, and can save and export to common simple raster formats.
.
This package contains the data files needed for the program.
+
+Package: mypaint-data-extra
+Architecture: all
+Depends: ${misc:Depends}
+Description: Additional, high-resolution backgrounds for MyPaint
+ MyPaint is a program for painting bitmap images which works well with
+ graphics tablets such as those made by Wacom.
+ .
+ MyPaint comes with a large brush collection including charcoal and ink to
+ simulate real media, and has a highly configurable brush engine which allows
+ you to experiment with your own brushes and with not-quite-natural painting.
+ It supports tilt- and pressure-sensitive tablets to the extent reported by
+ GTK
Bug#618792: New upstream available
Package: mypaint Version: 0.9.0-1 As described at http://mypaint.intilinux.com/?p=486 , a new stable release 0.9.1 is available containing several bugfixes. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#550230: New upstream version available: 0.70
Package: shared-mime-info Version: 0.60-2 http://www.freedesktop.org/wiki/Software/shared-mime-info lists version 0.70 as available in tarball form. When it's convenient, could you update the Debian package? Thanks. Tangentially noticed when eyeballing for updates on Debian bug #545396. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545650: Reproducible and patched
Tags: patch
For some reason, the scons invocation does some building - generating
brushlib/brushsettings.pyc - and because debain/rules's $(shell find
...) is evaluated when make initialises, the clean target fails to
clean up properly. Repeated invocations of clean flip the package
directory between a state where it has a brushlib/brushsettings.pyc and
a state where that file is absent. Running the find after scons has
run makes the problem go away.
Patch attached. This one should be applied after the one pending in bug
545387 ideally, but does not depend on it.
--
Andrew Chadwick
diff -rU3 mypaint-0.7.1/debian/rules mypaint-0.7.1+ftbfsfix/debian/rules
--- mypaint-0.7.1/debian/rules 2009-09-21 12:49:40.0 +0100
+++ mypaint-0.7.1+ftbfsfix/debian/rules 2009-09-21 12:48:50.602277362 +0100
@@ -14,7 +14,8 @@
dh_testroot
rm -f build-stamp
scons -c
- rm -f lib/mypaintlib_wrap.cpp options.cache .sconsign.dblite $(shell find . -name *.pyc)
+ rm -f lib/mypaintlib_wrap.cpp options.cache .sconsign.dblite
+ find . -type f -name *.pyc -exec rm -vf {} \;
dh_clean
install: build
Bug#545396: .ora files look like zip archives! (... really openraster support bugs: no mime-info, no thumbnailer)
[Cc:ed the named Debian krita maintainers and Bernd (maintainer of gimp-plugin-registry). Hi guys; Martin is the upstream maintainer of oratools, a bundle of plugins and desktop support for the OpenRaster file format: http://gitorious.org/mypaint/oratools . Any comments?] Martin Renold wrote: I was wondering whether MyPaint should really have this mime? Anyway, there is one in the source in desktop/mime/mypaint.xml. And Krita also has one, not sure if it gets installed, but it's probably somewhat different. Wouldn't there be conflicts if more than one application installs this? Provided everything uses different files, then shared-mime-info shouldn't get too confused when it updates. It's still better practice to put behaviour only in one place, I think. 2. Since the package is targeted at artists and visually-thinking people, it'd be really nice to have a thumbnailer for the most common desktop environments :) I fully agree. The thing (if I'm up-to-date) is that we haven't figured out yet whom to ask to integrate those thumbnailers into which project. As far as oratools - yourself and Jon - are concerned, oratools could just package the mime-info XML and the thumbnailer scripts (disclaimer: I've not played with the KDE one), plus the existing GIMP package. Leave the installation details to the distros. It's still useful to have everything in one place, for everyone's sake. Ana Beatriz, Raúl: would that seem acceptable from a KDE/krita perspective? I've no idea how KDE integrates thumbnailers, sadly. (To fulfil the expectation created by the tools name, perhaps oratools could bundle some conversion scripts as well as the desktop and gimp integration stuff...? :) Perhaps a new package for openraster desktop support could be created for these two issues together? and it certainly wouldn't be something limited to just MyPaint: Krita (SVN), Drawpile, and GIMP (via the unofficial ORA loader/saver plugin) would all benefit. Initially it could live in the mypaint package I suppose, since mypaint is the program which would most immediately benefit. I was planning to move thumbnailers and mime stuff also into the oratools repository (where the GIMP plugin is), away from the mypaint source, until the respective desktop environments take over maintainence. Do you think this should grow into its own independent project instead, for distributions to package? Seems like the best plan, simply from the perspective of keeping everything in one place for maintainers. Making it fully independent of mypaint might be a nice thing too, from a political perspective... :) One caveat from the packaging perspective: don't force KDE stuff on Gnome people or /vice versa/. If I were packaging for Debian, I'd split it into: oratools: Description: MIME setup and GIMP plugin for OpenRaster images Recommends: oratools-thumbnailer-gnome | oratools-thumbnailer-kde Enhances: gimp Depends: shared-mime-info Suggests: oratools-thumbnailer-gnome | oratools-thumbnailer-kde oratools-thumbnailer-kde: Description: KDE thumbnailer for OpenRaster images Enhances: kdebase Depends: oratools, $KDE_STUFF oratools-thumbnailer-gnome: Description: GNOME-style thumbnailer for OpenRaster images Enhances: gnome-desktop-environment, thunar Depends: oratools, $GNOME_STUFF and arrange for actual paint programs which use OpenRaster - krita, mypaint - to use Recommends: oratools-thumbnailer-gnome | oratools-thumbnailer-kde With this setup, people grabbing mypaint or krita using a Debian package manager that automatically selects Recommended packages should automatically pull in the right thumbnailers for their system. Thunar uses GNOME-style thumbnailers if they're available, according to http://goodies.xfce.org/projects/thunar-plugins/thunar-thumbnailers/ Seems like KDE use shared-mime-info these days: http://lists.kde.org/?l=kde-core-develm=117439505315489 , but their own style of binary thumbnailer blivets. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545398: Add OpenRaster import/export plugin
Actually, I may have jumped the gun a little with this. If there's agreement, oratools may end up in its own package, enhancing gimp: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=545396 If that comes to pass, no need to update gimp-plugin-registry. As they say, watch this space. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545387: No desktop icons; .desktop file uses %U incorrectly
Package: mypaint Version: 0.7.1-1 Tags: patch upstream No desktop icons are visible in mypaint_0.7.1-1 after installation because upstream's installer puts things in a strange place. No action needed to reproduce this problem other than installing the package on a clean system. Patch attached (Debian BTS permitting). In addition, the upstream .desktop file incorrectly uses %U (multiple URLs) for its Exec field rather then the correct %f (one file only). Able to confirm with multiple existent files on the command line $ mypaint hello1.ora hello2.ora Cannot open more than one file! $ and with remote existent SSH URIs: $ mypaint ssh://projects/tmp/hello1.ora File ssh://projects/tmp/hello1.ora does not exist! $ mypaint ssh://projects/tmp/hello1.ora ssh://projects/tmp/hello2.ora File ssh://projects/tmp/hello1.ora does not exist! $ I've included this in the patch because not using %f might break some DEs, and will certainly confuse anyone trying to load multiple files at once. I'm using stock Ubuntu 9.04 and GNOME, but these issues should be visible on all Debian-based systems. -- Andrew Chadwick diff -rU2 mypaint-0.7.1/debian/rules mypaint-0.7.1+iconfix/debian/rules --- mypaint-0.7.1/debian/rules 2009-09-06 21:55:24.0 +0100 +++ mypaint-0.7.1+iconfix/debian/rules 2009-09-06 21:51:42.0 +0100 @@ -29,4 +29,19 @@ mv $(CURDIR)/debian/mypaint/usr/share/mypaint/backgrounds/* $(CURDIR)/debian/mypaint-data/usr/share/mypaint/backgrounds/ find $(CURDIR)/debian/mypaint/usr/share/mypaint/ -type d -empty -delete + # Dirty workaround for broken icons. Really, upstream should be patched + # to make this unnecessary. + for s in 16x16 22x22 24x24 32x32 48x48 scalable ; do \ + mkdir -p $(CURDIR)/debian/mypaint/usr/share/icons/hicolor/$$s/apps; \ + done + for s in 16x16 22x22 24x24 32x32 48x48 scalable ; do \ + cp $(CURDIR)/debian/mypaint/usr/share/mypaint/desktop/$$s/*.* \ + $(CURDIR)/debian/mypaint/usr/share/icons/hicolor/$$s/apps/ ; \ + done + mkdir -p $(CURDIR)/debian/mypaint/usr/share/pixmaps + cp $(CURDIR)/debian/mypaint/usr/share/mypaint/desktop/mypaint_48.png \ + $(CURDIR)/debian/mypaint/usr/share/pixmaps/mypaint.png + cp $(CURDIR)/debian/mypaint/usr/share/mypaint/desktop/mypaint.ico \ + $(CURDIR)/debian/mypaint/usr/share/pixmaps/ + # Build architecture-independent files here. @@ -46,4 +61,6 @@ dh_strip dh_compress + dh_icons + dh_desktop dh_fixperms dh_installdeb diff -rU2 mypaint-0.7.1/desktop/mypaint.desktop mypaint-0.7.1+iconfix/desktop/mypaint.desktop --- mypaint-0.7.1/desktop/mypaint.desktop 2009-09-06 21:55:24.0 +0100 +++ mypaint-0.7.1+iconfix/desktop/mypaint.desktop 2009-09-06 21:35:11.0 +0100 @@ -2,10 +2,10 @@ Version=1.0 Name=MyPaint -Exec=mypaint %U +Exec=mypaint %f Comment=Paint images from scratch GenericName=Image Editor MimeType=image/openraster;image/png;image/jpeg; Type=Application -Icon=mypaint_48 +Icon=mypaint Categories=Graphics; Terminal=false
Bug#545396: .ora files look like zip archives! (... really openraster support bugs: no mime-info, no thumbnailer)
Package: mypaint Version: 0.7.1-1 Severity: minor OpenRaster files created by MyPaint are indistinguishable from Zip archives when viewed in Nautilus, to the extent of being shown with an incorrect MIME type (application/zip instead of image/openraster). Plus of course the icon is that of a zipfile. Breaking it down, this is really another two-issue bug report (sorry) but these really are related, I promise! 1. MyPaint does not ship with a mime-info entry for OpenRaster files, meaning that ORA files appear in file manager programs as though they were ZIP archives. 2. Since the package is targeted at artists and visually-thinking people, it'd be really nice to have a thumbnailer for the most common desktop environments :) Perhaps a new package for openraster desktop support could be created for these two issues together? Fixing 1. is a prerequisite of fixing 2. There's software available out there for this: http://create.freedesktop.org/wiki/OpenRaster http://gitorious.org/mypaint/mypaint/commit/043b64da68d47718fd96e64d04d710a46592526a and it certainly wouldn't be something limited to just MyPaint: Krita (SVN), Drawpile, and GIMP (via the unofficial ORA loader/saver plugin) would all benefit. Initially it could live in the mypaint package I suppose, since mypaint is the program which would most immediately benefit. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#545398: Add OpenRaster import/export plugin
Package: gimp-plugin-registry Version: 2.2-1 Severity: minor Bernd, hi -- It would be really nice if the GIMP could load and save files in OpenRaster format via the oratools plugin, since MyPaint and Drawpile both use this format by default these days. There may be some upstream support coming for this for the GIMP (can't remember offhand, sorry). However, right now there's: http://create.freedesktop.org/wiki/OpenRaster#Implementations http://gitorious.org/mypaint/oratools which seems to work well enough on my little Ubuntu 9.04 playpen, at least as a bridge between MyPaint 0.7.1 and GIMP 2.6.6. -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#544684: exaile: new upstream: 3.0 series
Package: exaile Version: 0.2.14+debian-2 The Exaile bods have released version 3.0.0: http://www.exaile.org/ https://code.launchpad.net/exaile although it seems that some of the fiddlier/more complex features weren't reimplemented for the new player (These should return in 0.3.1). Not sure which ones these are, but presumably the new series is functional and mostly bug-free... -- Andrew Chadwick -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
