Hi all,
I noticed during current builgs, on Ubuntu 16.10 (Yakkety) and now also on
Debian 9 (Stretch) was changed the default compiler to GCC6. This brings
the number of new FTBFS. That's why I started to concentrate on these
FTBFS. Note - for this reason the packages for Yakkety in Preliminary
Stable Builds are now inconsistent.
As a first, of course, I started with tdelibs. Most were simple conflict
signed / unsigned char or int. However, one serious problem is here.
In the 'kjs' and 'tdehtml/ecma' is used HashEntry structure that contains
the item 'value' of type short int - see 'kjs/lookup.h'. Into this item
was stored values DOM::NodeFilter::ShowCode::SHOW_ALL = 0xFFFFFFFF (see
tdehtml/dom/dom2_traversal.h) and kjs event CHANGE with value 32768 (see
tdehtml/ecma/kjs_events.cpp). Both are therefore outside the range of
short int.
Changing the type of 'value' in HashEntry from short to long would
apparently cause a change in ABI - kjs/lookup.h is part of the public
includes. That's why I made the change values 0xFFFFFFFF and 32768 to -1.
I think that GCC compilers version less than 6 will store these values in
the same way. Therefore, I believe that the proposed patch would not
cause problems == can be pushed. What is your opinion?
Cheers
--
Slávek
All,
Recently I filled in the automated crash report and sent it on its way.
I don't see this in the current bug list.
Do those reports go anywhere or should I fill in a new bug report by
hand via the web site?
Thanks.
Jim
I asked about a possible solution to this elsewhere, generating no response
as yet:
https://mail.gnome.org/archives/gtk-devel-list/2016-July/msg00028.htmlhttps://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org/t…
Apparently, a fix from mozilla.org is unlikely forthcoming, while a
particular Gnome commit is highly likely responsible for the regression in
Firefox and SeaMonkey built by mozilla.org with GTK3 toolkit:
"UI text sizes no longer inherited from Linux system"
https://bugzilla.mozilla.org/show_bug.cgi?id=1269274
Screenshot of mozilla.org's FF48 in TDE on openSUSE 1920x1080 @132DPI display
showing the problem:
http://fm.no-ip.com/SS/Moz/uifontsRV48-s422tde-132.jpg
Screenshot of mozilla.org's FF48 in TDE on openSUSE 1680x1050 @108DPI display
showing the problem:
http://fm.no-ip.com/SS/Moz/uifontsRV48-s422tde-108.jpg
Screenshot of mozilla.org's FF48 in TDE on openSUSE 1680x1050 @108DPI display
showing no such problem before the update of GTK3 from 3.16 to 3.20:
http://fm.no-ip.com/SS/Moz/uifontsRV48-s421tde-108.jpg
Screenshot of mozilla.org's FF48 and FF45 on Fedora 24 with Plasma5 @168DPI
display showing problem is not unique to TDE, and doesn't exist in FF45:
http://fm.no-ip.com/SS/Moz/uifontsRV48-f24K5-168.jpgMozilla.org's FF ESR 45 is still built with GTK2, so doesn't have the
problem. SeaMonkey 2.40 is also built with GTK2, so also has no problem. All
the mozilla.org alphas and betas are being built with GTK3, so all manifest
the problem unless used with system GTK3 libs 3.16 or older.
Whether this problem shows up in Firefox or SeaMonkey provided by individual
distros depends on which toolkit is used to build them. In Fedora, the switch
to GTK3 has been made, as have been the GTK3 libs past 3.16, the last before
the upstream patch. Thus, all current rpms from Fedora produce the problem.
In openSUSE Tumbleweed, Firefox 48 is still built with GTK2, so even though
it has switched to 3.20 GTK3 libs, the problem there hasn't yet appeared.
Stretch has 3.20 GTK3 libs, builds FF 45ESR with GTK2, so has the problem in
FF with mozilla.org builds but not with its available FF .deb package. Jessie
is OK, with only GTK3 lib 3.14. Buntu 16.04's GTKs3 lib is 3.18. Its FF 48
buildconfig screen doesn't include the string gtk anywhere, but apparently
it's using the GTK3 default, and thus also not obeying TDE's UI font
specification.
So, to eventually restore parity to all distro and version installations,
always having the Geckos use the UI fonts specified in Trinity desktop
settings, something needs to be done. The question is where. Is getting
upstream patch reversion the right answer? Would some new or altered
gtk-*qt*-trinity package be good, only, or better answer? Would some new or
altered theme package be a right answer? Is there already some solution that
just hasn't been installed yet?
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
Hi,
in the past few days I found some time to revive my work on the libkcal
testing, but I noticed that no debug information is printed out by the test
programs.
I suspect it is because it gets compiled without debugging, but I am not
sure, as (if you recall I asked you how to compile the project and you
instructed to use the debian/rules file) I don't know where and how to tell
the rules file to add/activate debugging.
I use something like
DEB_MAKE_CHECK_TARGET=testing fakeroot debian/rules build
at the moment.
I'll appreciate some ideas. Thank you in advance
regards
hi folks - all working, just thought you might like to know.
installation was very straightforward, and unlike a couple of months
ago on a devuan amd64 system worked perfectly without package
conflicts.
can i recommend that you put devuan on the list of OSes as it's
clearly much much faster, and hugely less hassle.
l.
---
crowd-funded eco-conscious hardware: campaign running LIVE:
https://www.crowdsupply.com/eoma68/micro-desktop