Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#35899 - [shotwell] fails to start with vala/gtk errors
Attached to Project:
Community Packages
Opened by David Raymond (djraymondnm) - Sunday, 23 June 2013, 00:52 GMT
Last edited by Sergej Pupykin (sergej) - Wednesday, 28 August 2013, 10:40 GMT
Opened by David Raymond (djraymondnm) - Sunday, 23 June 2013, 00:52 GMT
Last edited by Sergej Pupykin (sergej) - Wednesday, 28 August 2013, 10:40 GMT
|
DetailsDescription:
When trying to start shotwell, it fails with a series of error messages to the invoking terminal involving an error in vala and subsequent gtk errors. Additional info: * package version(s) shotwell 0.14.1-4 (previous version also failed) * config and/or log files etc. Here is what happens when I try to start shotwell: swallow:~/src$ shotwell L 15572 2013-06-22 18:28:26 [CRT] Resources.vala:874: Unable to load stock icon\ shotwell-crop: Failed to open file '/bin/icons/crop.svg': No such file or dire\ ctory (shotwell:15572): Gtk-CRITICAL **: gtk_icon_set_new_from_pixbuf: assertion `pix\ buf != NULL' failed (shotwell:15572): Gtk-CRITICAL **: gtk_icon_factory_add: assertion `icon_set !=\ NULL' failed L 15572 2013-06-22 18:28:26 [CRT] Resources.vala:874: Unable to load stock icon\ shotwell-redeye: Failed to open file '/bin/icons/redeye.png': No such file or \ directory (shotwell:15572): Gtk-CRITICAL **: gtk_icon_set_new_from_pixbuf: assertion `pix\ buf != NULL' failed (shotwell:15572): Gtk-CRITICAL **: gtk_icon_factory_add: assertion `icon_set !=\ NULL' failed L 15572 2013-06-22 18:28:26 [CRT] Resources.vala:874: Unable to load stock icon\ shotwell-adjust: Failed to open file '/bin/icons/image-adjust.svg': No such fi\ le or directory (shotwell:15572): Gtk-CRITICAL **: gtk_icon_set_new_from_pixbuf: assertion `pix\ buf != NULL' failed (shotwell:15572): Gtk-CRITICAL **: gtk_icon_factory_add: assertion `icon_set !=\ NULL' failed L 15572 2013-06-22 18:28:26 [CRT] Resources.vala:874: Unable to load stock icon\ shotwell-pin-toolbar: Failed to open file '/bin/icons/pin-toolbar.svg': No suc\ h file or directory ... (ETC.) More similar messages appear and shotwell quits. Steps to reproduce: Attempt to launch shotwell on the command line. Note: My system is up to date as of 22 June 2013. In particular, I did the manual update that moves all binary files to /usr/bin. Please let me know if you need additional information. |
This task depends upon
Closed by Sergej Pupykin (sergej)
Wednesday, 28 August 2013, 10:40 GMT
Reason for closing: Fixed
Additional comments about closing: patch applied
Wednesday, 28 August 2013, 10:40 GMT
Reason for closing: Fixed
Additional comments about closing: patch applied
I downloaded the source from upstream, applied the patches in the Arch repository,
compiled, and installed in /usr/local/ on my machine. In this case, shotwell
does not fail on launch and seems to run fine.
Rebuilding the package using makepkg on the PKGBUILD file resulted in a version
that failed just like the original did.
testing shotwell. Same problem; it fails with a lot of text and pops up
an error message box. So, there is not something odd with my laptop. (Unless
there is a common mode oddness between the two machines. Possible I suppose,
as I administer both and some people consider me to be a rather odd fellow!)
Something very curious in the error output: It is looking for various bitmap
files in /bin, e.g., /bin/icons/image-adjust.svg.
At first I could not replicate your issue with the shotwell binary I have installed. But when I build my own from ABS in /tmp then that binary did cause an error similar to yours (/usr/bin instead of /bin) when executed from it's build directory (I never installed the package I built). It seems shotwell checks if the path of the executable lies within the path specified in the ./configure step. ie is your binary inside /usr? If not, then get_install_dir returns a null which causes shotwell to try to load the resources from the same folder as the binary.
What do you get for "which shotwell"? I get /usr/bin/shotwell. I just want to make sure you're not running it weirdly.
Running package from /usr/bin/shotwell → no error
Running package from /tmp/shotwell/pkg/shotwell/usr/bin/shotwell → error
Running "which shotwell" yields "/bin/shotwell". However, I have done the
conversion in which /bin is now a symbolic link to /usr/bin. If I run just
"shotwell", it fails with the original error message. If I run "/bin/shotwell",
it similarly fails. However, if I run "/usr/bin/shotwell", shotwell runs
normally.
This sure sounds like an issue introduced by putting everything in "/usr/bin"
and making the other binary directory links to this directory. What is
strange is that "which" now comes up with /bin rather than /usr/bin/.
I notice that the EXEC command in the /usr/share/applications/shotwell.desktop
file is an unqualified "shotwell". The problem could presumably fixed for fancy
desktop users if this were changed to "/usr/bin/shotwell". However, the
problem would still exist if one launched it as "shotwell" on the
command line.
Yes, I just noticed that the PATH in my home directory still had /bin first. When I removed all references to /bin, /sbin, and /usr/sbin in my path, shotwell started correctly. Maybe this simplification to /usr/bin should contain a warning that these now-extraneous directories should be removed from one's path.
FS#35973Associated revision: http://redmine.yorba.org/projects/shotwell/repository/revisions/4f635ba4236dbbb8cb3f8b7bdd201432961fb283