Created attachment 9204 crash backtrace I'm preparing an update to the FreeBSD thunar port. The latest version crashes on startup due to the additions in commit https://git.xfce.org/xfce/thunar/commit/?id=a3e178cb82f6b41b0e3f3cac18e7d83cca70eade I'm attaching a backtrace of the crash. In the FreeBSD ports tree we have pango 1.42.4 and glib 2.56.3. I suspect the crash is caused by these versions of these libraries not working well with this code: standard_view->name_renderer = g_object_new (GTK_TYPE_CELL_RENDERER_TEXT, "attributes", thunar_pango_attr_disable_hyphens (), "alignment", PANGO_ALIGN_CENTER, "xalign", 0.5, FALSE); where thunar_pango_attr_disable_hyphens () actually return a pointer to a NULL when pango is not 1.44. I've created a patch which works for me, by removing that call to thunar_pango_attr_disable_hyphens when pango is not 1.44. I'l be committing this patch to the ports tree to make it work. Could it be imported in thunar mainline code?
Created attachment 9205 Proposed fix
(In reply to Guido Falsi from comment #1) > Created attachment 9205 > Proposed fix Guido, instead to use the PANGO_VERSION_1_44 macro, I suggest to use PANGO_VERSION_CHECK (see bug #16136).
Created attachment 9206 Proposed fix As suggested by Olivier, I'm posting a new patch using the PANGO_VERSION_CHECK macro.
Comment on attachment 9206 Proposed fix Fwiw, similar crash on OpenBSD with pango 1.42.4 & glib 2.62.2. This patch fixes the crash for me too.
Created attachment 9209 patch Sorry for the trouble, and thanks alot for the patches ! I plan to apply a mix of your patches. IMO we should have the pango dependency listed in configure.ac.in, like proposed in the patch of bug #16136 In addition I think it is a good idea to #IFDEF not only the concrete call, but as well #IFDEF the set of the gobject property in order to show that the property is set conditionally, like proposed in attachment 9206 I still dont understand why PANGO_VERSION_1_44 seems to be defined for you / the related code in the current ifdef is executed ... but whatever :) After you tested my patch, I would push it and release thunar 1.8.11, to prevent possible further breakage for other packagers.
(In reply to alexxcons from comment #5) > I still dont understand why PANGO_VERSION_1_44 seems to be defined for you / > the related code in the current ifdef is executed ... but whatever :) A wait, stupid me, re-reading the first post of this thread I finally got the problem ... the pango version check actually worked, though returing NULL is no option for that method, thats why it actually is required to #IFDEF the whole method.
(In reply to alexxcons from comment #5) > Created attachment 9209 > patch > > Sorry for the trouble, and thanks alot for the patches ! > [...] > > After you tested my patch, I would push it and release thunar 1.8.11, to > prevent possible further breakage for other packagers. The code changes in your patches are the same as mine, and they work fine. I'm not using thunar from git right now, bur patches 1.8.10 with the part of your patch that applies there. Do you need me to test with thunar from git? That will take a little more time.
(In reply to Guido Falsi from comment #7) > > The code changes in your patches are the same as mine, and they work fine. > > I'm not using thunar from git right now, bur patches 1.8.10 with the part of > your patch that applies there. Do you need me to test with thunar from git? > That will take a little more time. Thanks alot for testing ! Test with thunar 1.8.10 should be sufficient, no need to as well test with git master.
Created attachment 9229 Backtrace Fwiw, same crash on my Gentoo Linux system (and probably other unstable-configured systems as well). Backtrace attached. Pango 1.42.4 , glib 2.60.7 too lazy to test patches but they should work :P
Patch applied for master and 4.14 branch ( the bot pasted the references to Bug #16136 ) Will see if I can do a 1.8.11 release this or next evening. Thank you all for your help !
*** Bug 16136 has been marked as a duplicate of this bug. ***
What is the minimal pango version really? 1.42.0 is not available in openSUSE Leap. e1acdf12 compiles at least with 1.40.0.
Thanks for that info! Good to know that before releasing 1.8.11 ;) Just checked the pango methods used in "thunar-pango-extensions.c" .. against version requirements on https://developer.gnome.org/pango/unstable/pango-Text-Attributes.html Actually the only method thunar uses, having a version requirement mentioned at all on this doc page is "pango_attr_insert_hyphens_new" which we already wrapped with the PANGO_VERSION_CHECK So I would just follow the pango requirements of our gtk version: gtk3.22 requires at least pango 1.37.3 https://github.com/GNOME/gtk/blob/gtk-3-22/configure.ac#L57 Wonder why that number is odd .. thats a dev version? I would say, lets use 1.38.0 as a minimum. You think that should do it ?
Sure, I only tested 1.40.0.
Alexander Schwinn referenced this bugreport in commit 4d415ac223bb6a3ab8b88213b427e3303f0f0e86 lower minimum required pango version to 1.38.0 (Bug #16138) https://git.xfce.org/xfce/thunar/commit?id=4d415ac223bb6a3ab8b88213b427e3303f0f0e86
Alexander Schwinn referenced this bugreport in commit e67cb725b805c5d615722587872fd7499ca2b2d3 lower minimum required pango version to 1.38.0 (Bug #16138) https://git.xfce.org/xfce/thunar/commit?id=e67cb725b805c5d615722587872fd7499ca2b2d3
done .. 1.8.11 released now.
Package name should start with a capital T though.
(In reply to Davide Palma from comment #18) > Package name should start with a capital T though. Why? It was an exception contrasting normal practice for most OSS projects. I think it is good for the capital to to be gone from there.