ubuntustudio-bugs team mailing list archive
-
ubuntustudio-bugs team
-
Mailing list archive
-
Message #09606
[Bug 1873944] Re: Upgrade rapid-photo-downloader to version 0.9.23
Hi Erich, I have revamped the bug report description using the guide you
suggested. Apologies if it is now too long!
** Description changed:
- I'm the developer of Rapid Photo Downloader. Version 0.9.23 (already
- released) contains an important bug fix for a segfault that occurs on
- some but not all systems due to Gtk being called incorrectly during
- application startup.
+ [Bug Description Edited June 2, 2020]
- Version 0.9.23 contains other bug fixes which are less critical but
- still welcome. If an SRU is created in my opinion it would be best to
- include these additional fixes as they are extremely unlikely to cause
- any further problems.
+ [Impact]
- The changes from 0.9.22 to 0.9.23 are as follows, in order of
- importance:
+ Rapid Photo Downloader 0.9.22 contains a bug that means for some users,
+ it causes a segfault during startup every time it is launched. (Other
+ users are unaffected. For example, I have never been able to replicate
+ the bug on any of my systems.) There is no workaround for the bug except
+ to upgrade it to a newer release.
- - Fixed bug #1872338 segfault on startup. When running under a Gtk-based
- desktop, the application now queries xsettings to detect if monitor
- scaling is enabled. In the previous release, Gtk was queried directly,
- which caused segfaults on some systems.
+ This is a report from a user who encountered the problem (left in a
+ review in Ubuntu Software):
- - Fixed bug #1872188: sqlite3.OperationalError when generating
- thumbnails.
+ "When I reinstalled my OS to upgrade to 20.04 (Studio), this app came
+ preinstalled, but it wouldn't open. I tried uninstalling and
+ reinstalling from Snap Store, but issue persisted. Installed using
+ script from main website (Version 0.9.24) and works fine now."
- - Fixed bug #1873233: RAW and JPG don't synchronize when using stored
- number.
+ The backstory: Rapid Photo Downloader is written using Qt5. Earlier this
+ year I improved the program to function properly on HighDPI screens. A
+ side effect of this fix was that for a handful of users on displays with
+ no screen scaling, a bug somewhere in the X window / Qt rendering chain
+ made the program UI utterly broken. For a screenshot, see
+ https://discuss.pixls.us/t/graphical-issues-on-xubuntu-18-04/17405
- - Fixed bug where HEIF/HEIC thumbnails on a camera were not being generated
- until they were downloaded.
+ My solution to this problem was to disable HighDPI support on systems
+ where the screen scaling factor was set to 1.0. Why enable it when it's
+ not needed, right? But this requires querying the screen scaling before
+ initializing Rapid Photo Downloader's UI, because Qt5 requires HighDPI
+ be set before instantiating QApplication. Unfortunately when running
+ under X, Gtk and Qt/KDE use incompatible methods to enable and report
+ screen scaling.
- - Fixed bug #1873057: Add ORI to list of supported image formats.
+ So in sum, Rapid Photo Downloader needs to query the system's screen
+ scaling before initializing its own application window, and how it does
+ that depends on whether it is running in a Gtk or Qt based desktop.
- - When generating video thumbnails for phones and tablets, the entire video
- will now be downloaded and cached. Previously only a portion of the video was
- downloaded, in the hope that this portion could generate the thumbnail, but
- unfortunately it did not always render. This new behavior will slow down
- thumbnail generation, but does ensure the thumbnail will be rendered.
+ The bug in Rapid Photo Downloader 0.9.22 is caused by calling the
+ Gtk/GDK API without first calling gtk_init() during application startup.
+ Upon becoming aware of the bug, I (the application developer) discussed
+ the problem with Emmanuele Bassi and Matthias Clasen, and they strong
+ urged me to query screen scaling using XSETTINGS, and not the GTK/GDK
+ API. They were correct. Querying XSETTINGS has fixed the bug.
- The tarball is available here:
- https://launchpad.net/rapid/pyqt/0.9.23/+download/rapid-photo-
- downloader-0.9.23.tar.gz
+ [Test Case]
- ProblemType: Bug
- DistroRelease: Ubuntu 20.04
- Package: rapid-photo-downloader 0.9.22-0ubuntu1
- ProcVersionSignature: Ubuntu 5.4.0-25.29-generic 5.4.30
- Uname: Linux 5.4.0-25-generic x86_64
- NonfreeKernelModules: nvidia_modeset nvidia
- ApportVersion: 2.20.11-0ubuntu27
- Architecture: amd64
- CasperMD5CheckResult: skip
- CurrentDesktop: ubuntu:GNOME
- Date: Mon Apr 20 14:47:15 2020
- InstallationDate: Installed on 2020-03-18 (33 days ago)
- InstallationMedia: Ubuntu 20.04 LTS "Focal Fossa" - Alpha amd64 (20200315)
- PackageArchitecture: all
- ProcEnviron:
- TERM=xterm-256color
- PATH=(custom, no user)
- XDG_RUNTIME_DIR=<set>
- LANG=en_US.UTF-8
- SHELL=/bin/bash
- SourcePackage: rapid-photo-downloader
- UpgradeStatus: No upgrade log present (probably fresh install)
+ Because the bug in 0.9.22 only occurs on some systems and not others, it
+ will either occur on a test system every time the program is started, or
+ it will not. There appears to be no in-between.
+
+ When the bug does occur, a segfault always results.
+
+ If the program UI renders normally upon program startup an upgraded
+ system version in a system in which 0.9.22 crashes, the problem is
+ fixed.
+
+
+ [Regression Potential]
+
+ If there are to be any regression, it would be in querying XSETTINGS.
+
+ The actual code to query XSETTINGS is copied directly from Ubuntu and
+ Debian developer Dmitry Shachnev's ReText program (which like Rapid
+ Photo Downloader, is coded using Python and Qt5). Dmitry's code has been
+ in use for five years, so it appears stable. This is the original
+ source:
+
+ https://github.com/retext-project/retext/blob/master/ReText/xsettings.py
+
+ The call to query XSETTINGS in wrapped in try / except Python block that
+ catches all exceptions, so the only way a problem would manifest in this
+ code block would be a segfault. Knowing what might cause a segfault in
+ such circumstances is well beyond my understanding of how X works.
+
+ The great news is that after the bug fix, I have had no bug reports
+ relating to HighDPI screen scaling or application startup. Screen
+ scaling is working for those who use HighDPI screens, and for those who
+ are not, the program UI renders as expected. Just as importantly, no
+ user has reported a segfault during program startup in 0.9.23 or 0.9.24
+ (or after startup either).
+
+ I have tested versions 0.9.23 and 0.9.24 on as many desktop environments
+ as I have been able to, both popular and obscure, using both X and where
+ possible Wayland, toggling screen scaling on systems that allow it. The
+ program UI renders properly in all the environments I tested it.
+
+ Version 0.9.23 was released on 2020-04-16, and 0.9.24 on 2020-05-03.
+ Both versions contain the bug fix for the segfault startup problem, but
+ they also contain other bug fixes and translation updates. Given the
+ potential of other regressions, and assuming either 0.9.23 or 0.9.24
+ will be used for the SRU, I will discuss them briefly here too.
+
+ I recommend 0.9.24 for the SRU. Compared to 0.9.22, 0.9.24 contains 9
+ other bug fixes. Every fix is localized to the specific problem itself,
+ and does not affect any other areas of the program. For all nine fixes,
+ the problem was resolved with no follow-up issues reported. In all
+ honesty, while I assume there are possibilities for regressions caused
+ by these nine fixes, I am unaware of what they are! As far as I'm
+ concerned, the problems are fixed, and no other problems have been
+ caused because of them.
+
+ There is a new feature in 0.9.24 which is a more realistic candidate for
+ regressions: the feature to provide the use the option of automatically
+ creating a tar file of the program configuration file and log files when
+ submitting a bug report. See this documentation for an illustration:
+
+ https://damonlynch.net/rapid/documentation/#reportproblem
+
+ I tested the code extensively, and exceptions are caught when creating
+ the tar (e.g. in case of problems such as no space left on the file
+ system). But nonetheless, given the dialog automatically appears in case
+ of any uncaught program exception, it's possible that an unstable
+ program condition might somehow cause problems in the generation of the
+ tar file. To mitigate this possibility, no compression of the files
+ included in the tar is performed, and the tar itself is not compressed.
+ So while a bug report tar file not being created properly is possible, I
+ judge it unlikely, and if it does occur, any side effects should be
+ neglible.
+
+ No user has reported a problem using this new feature (having said that,
+ I've had only one bug report in which it was used).
+
+ [Other Info]
+
+ The full changelog for all versions is available here:
+
+ https://launchpad.net/rapid/pyqt/0.9.24/+download/CHANGES.rst
+
+ Thank you.
--
You received this bug notification because you are a member of Ubuntu
Studio Bugs, which is subscribed to rapid-photo-downloader in Ubuntu.
Matching subscriptions: Ubuntu Studio Bugs
https://bugs.launchpad.net/bugs/1873944
Title:
Upgrade rapid-photo-downloader to version 0.9.23
Status in rapid-photo-downloader package in Ubuntu:
Confirmed
Bug description:
[Bug Description Edited June 2, 2020]
[Impact]
Rapid Photo Downloader 0.9.22 contains a bug that means for some
users, it causes a segfault during startup every time it is launched.
(Other users are unaffected. For example, I have never been able to
replicate the bug on any of my systems.) There is no workaround for
the bug except to upgrade it to a newer release.
This is a report from a user who encountered the problem (left in a
review in Ubuntu Software):
"When I reinstalled my OS to upgrade to 20.04 (Studio), this app came
preinstalled, but it wouldn't open. I tried uninstalling and
reinstalling from Snap Store, but issue persisted. Installed using
script from main website (Version 0.9.24) and works fine now."
The backstory: Rapid Photo Downloader is written using Qt5. Earlier
this year I improved the program to function properly on HighDPI
screens. A side effect of this fix was that for a handful of users on
displays with no screen scaling, a bug somewhere in the X window / Qt
rendering chain made the program UI utterly broken. For a screenshot,
see https://discuss.pixls.us/t/graphical-issues-on-xubuntu-18-04/17405
My solution to this problem was to disable HighDPI support on systems
where the screen scaling factor was set to 1.0. Why enable it when
it's not needed, right? But this requires querying the screen scaling
before initializing Rapid Photo Downloader's UI, because Qt5 requires
HighDPI be set before instantiating QApplication. Unfortunately when
running under X, Gtk and Qt/KDE use incompatible methods to enable and
report screen scaling.
So in sum, Rapid Photo Downloader needs to query the system's screen
scaling before initializing its own application window, and how it
does that depends on whether it is running in a Gtk or Qt based
desktop.
The bug in Rapid Photo Downloader 0.9.22 is caused by calling the
Gtk/GDK API without first calling gtk_init() during application
startup. Upon becoming aware of the bug, I (the application developer)
discussed the problem with Emmanuele Bassi and Matthias Clasen, and
they strong urged me to query screen scaling using XSETTINGS, and not
the GTK/GDK API. They were correct. Querying XSETTINGS has fixed the
bug.
[Test Case]
Because the bug in 0.9.22 only occurs on some systems and not others,
it will either occur on a test system every time the program is
started, or it will not. There appears to be no in-between.
When the bug does occur, a segfault always results.
If the program UI renders normally upon program startup an upgraded
system version in a system in which 0.9.22 crashes, the problem is
fixed.
[Regression Potential]
If there are to be any regression, it would be in querying XSETTINGS.
The actual code to query XSETTINGS is copied directly from Ubuntu and
Debian developer Dmitry Shachnev's ReText program (which like Rapid
Photo Downloader, is coded using Python and Qt5). Dmitry's code has
been in use for five years, so it appears stable. This is the original
source:
https://github.com/retext-
project/retext/blob/master/ReText/xsettings.py
The call to query XSETTINGS in wrapped in try / except Python block
that catches all exceptions, so the only way a problem would manifest
in this code block would be a segfault. Knowing what might cause a
segfault in such circumstances is well beyond my understanding of how
X works.
The great news is that after the bug fix, I have had no bug reports
relating to HighDPI screen scaling or application startup. Screen
scaling is working for those who use HighDPI screens, and for those
who are not, the program UI renders as expected. Just as importantly,
no user has reported a segfault during program startup in 0.9.23 or
0.9.24 (or after startup either).
I have tested versions 0.9.23 and 0.9.24 on as many desktop
environments as I have been able to, both popular and obscure, using
both X and where possible Wayland, toggling screen scaling on systems
that allow it. The program UI renders properly in all the environments
I tested it.
Version 0.9.23 was released on 2020-04-16, and 0.9.24 on 2020-05-03.
Both versions contain the bug fix for the segfault startup problem,
but they also contain other bug fixes and translation updates. Given
the potential of other regressions, and assuming either 0.9.23 or
0.9.24 will be used for the SRU, I will discuss them briefly here too.
I recommend 0.9.24 for the SRU. Compared to 0.9.22, 0.9.24 contains 9
other bug fixes. Every fix is localized to the specific problem
itself, and does not affect any other areas of the program. For all
nine fixes, the problem was resolved with no follow-up issues
reported. In all honesty, while I assume there are possibilities for
regressions caused by these nine fixes, I am unaware of what they are!
As far as I'm concerned, the problems are fixed, and no other problems
have been caused because of them.
There is a new feature in 0.9.24 which is a more realistic candidate
for regressions: the feature to provide the use the option of
automatically creating a tar file of the program configuration file
and log files when submitting a bug report. See this documentation for
an illustration:
https://damonlynch.net/rapid/documentation/#reportproblem
I tested the code extensively, and exceptions are caught when creating
the tar (e.g. in case of problems such as no space left on the file
system). But nonetheless, given the dialog automatically appears in
case of any uncaught program exception, it's possible that an unstable
program condition might somehow cause problems in the generation of
the tar file. To mitigate this possibility, no compression of the
files included in the tar is performed, and the tar itself is not
compressed. So while a bug report tar file not being created properly
is possible, I judge it unlikely, and if it does occur, any side
effects should be neglible.
No user has reported a problem using this new feature (having said
that, I've had only one bug report in which it was used).
[Other Info]
The full changelog for all versions is available here:
https://launchpad.net/rapid/pyqt/0.9.24/+download/CHANGES.rst
Thank you.
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/rapid-photo-downloader/+bug/1873944/+subscriptions
References