Created attachment 519842 [details, diff] Patch to replace diffently encoded strings with utf-8 encoded ones >=glib-2.53 is not yet in portage but is needed for Gnome 3.26 and up, so this should be fixed first. libgda sources are a mix of different encodings, which will lead to a build failure. I used recode to generate the patch like for f in $(find libgda-5.2.4 -type f -exec file "{}" \; | grep "C source" | cut -d ':' -f1); do recode ISO-8859-1..UTF-8 "${f}" done
Please put a proper description of the problem in the Summary.
YES! buils fails References: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870741 https://github.com/voidlinux/void-packages/issues/9101 https://github.com/voidlinux/void-packages/commit/f16a2d557e84f5d7f5ece8b2022aab4fd17aa0ce
I see the warnings, but I don't see any failures. Please show a build.log where it actually fails? Or what issues does it cause?
Created attachment 535546 [details] build.log build.log from libgda emerged with USE="berkdb gnome-keyring gtk introspection ldap mysql ssl -canvas -debug (-firebird) -graphviz -http -java -json -mdb -oci8 -postgres -reports -sourceview -vala" PYTHON_TARGETS="python2_7"
Show how dev-libs/glib is emerged please. I guess it's python2 only (or at least PYTHON_SINGLE_TARGET)?
Created attachment 535628 [details] emerge --info glib Yes, since the glib ebuild still has only PYTHON_COMPAT=( python2_7 ) set: https://gitweb.gentoo.org/proj/gnome.git/tree/dev-libs/glib/glib-2.56.1.ebuild My python settings are otherwise the standard one from 17.0 profile (see attached emerge-glib.info)
(In reply to Maik from comment #6) > Created attachment 535628 [details] > emerge --info glib > > Yes, since the glib ebuild still has only PYTHON_COMPAT=( python2_7 ) set: > https://gitweb.gentoo.org/proj/gnome.git/tree/dev-libs/glib/glib-2.56.1. > ebuild > My python settings are otherwise the standard one from 17.0 profile (see > attached emerge-glib.info) Ah, right, that pending 2.56 in overlay that's newer than 2.54. https://gitweb.gentoo.org/repo/gentoo.git/tree/dev-libs/glib/glib-2.54.3-r6.ebuild Those fixes are still being worked on for porting back to overlay. Though we probably should then either drop python2 support, or fix libgda and any other ones (and the warning with python3 is a bit scary too). Just the error shouldn't be so common, as hopefully most people will be using it with python3 (once overlay ebuilds get the changes, that is)
Just a heads up regarding glib-2.54, I had the experience that you can only decide if bugs are triggered with webkit-gtk (glib-2.54.2) or libreoffice(-bin) (glib-2.54.3). I'll try to refind the relevant bug reports. glib-2.56.1 doesn't have any of those issues so far to my experience.
(In reply to Maik from comment #8) > Just a heads up regarding glib-2.54, I had the experience that you can only > decide if bugs are triggered with webkit-gtk (glib-2.54.2) or > libreoffice(-bin) (glib-2.54.3). I'll try to refind the relevant bug > reports. glib-2.56.1 doesn't have any of those issues so far to my > experience. I added patchset to in-tree 2.54.3-r6 that should solve those issues, but I don't know the details of your specific issues. At least it should solve a libreoffice hang.
Ah, ok. I'll check. Regarding this bug report being meant as mere heads up and now being 4 months old most of my experiences from back then are probably irrelevant/invalid by now with current ebuilds.
PS: If these bug reports are still open, would be good to know which they are to add an explanation and FIXED status or so; when I looked before (I found the relevant patches from glib upstream stable branch unreleased, not based on knowing the problem beforehand), I didn't find any, but hard to search for me.
Bug report: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=887404 The 'fix' at that time was reverting a patch introduced for fixing a webkit-gtk issue. It's just irrelevant now as the issue apparently only appeared with libreoffice-5. Now with libreoffice-6 being the only ebuild in gentoo tree the issue is gone (just tested with glib-2.54.3-r6/libreoffice-bin-6.0.3.2). So looks like some issues disappear if you just wait long enough;)
I meant any open gentoo bugzilla bugs that we could close. The issue probably disappeared because I added a patch to 2.54.3 to fix libreoffice hangs, as I said. That patch was included in 2.56.1 release from upstream, which is why gnome overlay 2.56 didn't have problems, but 2.54.3 didn't include it before I added the patchset to main tree.
This bug report being a trial balloon for reporting in advance issues for not (yet) in tree versions, I didn't care to report any more of those since nobody else cared. So nothing to close on my behalf.
I am now running into this: Traceback (most recent call last): File "/usr/bin/glib-mkenums", line 709, in <module> process_file(fname) File "/usr/bin/glib-mkenums", line 441, in process_file line = curfile.readline() File "/usr/lib64/python2.7/codecs.py", line 314, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) File "/usr/bin/glib-mkenums", line 93, in replace_and_warn err.object[err.start - 7:err.end + 7])) UnicodeDecodeError: 'ascii' codec can't decode byte 0xf3 in position 7: ordinal not in range(128) Traceback (most recent call last): File "/usr/bin/glib-mkenums", line 709, in <module> process_file(fname) File "/usr/bin/glib-mkenums", line 441, in process_file line = curfile.readline() File "/usr/lib64/python2.7/codecs.py", line 314, in decode (result, consumed) = self._buffer_decode(data, self.errors, final) File "/usr/bin/glib-mkenums", line 93, in replace_and_warn err.object[err.start - 7:err.end + 7])) UnicodeDecodeError: 'ascii' codec can't decode byte 0xf3 in position 7: ordinal not in range(128) make[2]: *** [Makefile:999: s-enum-types-c] Error 1 make[2]: *** Waiting for unfinished jobs.... make[2]: *** [Makefile:986: s-enum-types-h] Error 1 make[2]: Leaving directory '/var/tmp/portage/gnome-extra/libgda-5.2.4-r2/work/libgda-5.2.4/libgda/sql-parser' make[1]: *** [Makefile:1284: all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/gnome-extra/libgda-5.2.4-r2/work/libgda-5.2.4/libgda' make: *** [Makefile:745: all-recursive] Error 1 * ERROR: gnome-extra/libgda-5.2.4-r2::gentoo failed (compile phase): * emake failed * * If you need support, post the output of `emerge --info '=gnome-extra/libgda-5.2.4-r2::gentoo'`, * the complete build log and the output of `emerge -pqv '=gnome-extra/libgda-5.2.4-r2::gentoo'`. * The complete build log is located at '/var/tmp/portage/gnome-extra/libgda-5.2.4-r2/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/gnome-extra/libgda-5.2.4-r2/temp/environment'. * Working directory: '/var/tmp/portage/gnome-extra/libgda-5.2.4-r2/work/libgda-5.2.4' * S: '/var/tmp/portage/gnome-extra/libgda-5.2.4-r2/work/libgda-5.2.4' !!! When you file a bug report, please include the following information: GENTOO_VM= CLASSPATH="" JAVA_HOME="" JAVACFLAGS="" COMPILER="" and of course, the output of emerge --info =libgda-5.2.4
Running glib-2.54.3-r6
(In reply to Kobboi from comment #16) > Running glib-2.54.3-r6 See and reply about comment #5. Per comment #7, yes, there's stuff to fix here, but it shouldn't really happen out of the box, only if you build glib for python2.7 for some reason - hence the question to confirm in comment #5. The fix is to either just drop python2 support from glib, or to patch libgda to proper encoding. The patch provided here is too large, I'd be happier with a patch that only fixes it for only relevant files (that glib-genmarshal/glib-mkenums actually are pointed at, instead of ALL files). But I'm seriously contemplating just dropping python2 support, unless you confirm it's an issue with python3 glib python_single_target as well.
(In reply to Mart Raudsepp from comment #17) > See and reply about comment #5. [?] dev-libs/glib Available versions: (2) 2.50.3-r1 2.52.3 [M](~)2.54.3-r6{tbz2} {dbus debug fam +mime selinux static-libs systemtap test utils xattr ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32" KERNEL="linux" PYTHON_SINGLE_TARGET="python2_7 python3_5 python3_6" PYTHON_TARGETS="python2_7 python3_5 python3_6"} Installed versions: 2.54.3-r6(2){tbz2}(12:16:42 PM 06/12/2018)(dbus mime xattr -debug -fam -selinux -static-libs -systemtap -test -utils ABI_MIPS="-n32 -n64 -o32" ABI_PPC="-32 -64" ABI_S390="-32 -64" ABI_X86="64 -32 -x32" KERNEL="linux" PYTHON_SINGLE_TARGET="python2_7 -python3_5 -python3_6" PYTHON_TARGETS="python2_7 python3_5 -python3_6")
(Please ignore the [M] around 2.54. Being too lazy, I was just now attempting to mask it)
Why do you have it using PYTHON_SINGLE_TARGET=python2_7 instead of (default) python3_5 or python3_6? Note that gnome overlay 2.56 is broken in this regard and only support 2.7, triggering the issue here.
My package.use says it's for app-admin/packagekit-base although I don't seem to have that installed anymore and can't remember why I had it in the first place
(In reply to Kobboi from comment #21) > My package.use says it's for app-admin/packagekit-base although I don't seem > to have that installed anymore and can't remember why I had it in the first > place python2 support in glib is required by app-admin/packagekit-base, app-text/xiphos, dev-libs/libmateweather, dev-python/python-virtkey (all reverse deps of glib[python])
Why not try to run iconv over relevant files to fix encodings instead of applying the big patch?
I see that Arch opted for simply changing unicodes too: https://git.archlinux.org/svntogit/packages.git/plain/trunk/0001-Convert-files-to-Unicode.patch?h=packages/libgda https://git.archlinux.org/svntogit/packages.git/plain/trunk/glib-2.54-ftbfs-2.patch?h=packages/libgda https://git.archlinux.org/svntogit/packages.git/plain/trunk/glib-2.54-ftbfs.patch?h=packages/libgda
(In reply to Pacho Ramos from comment #22) > (In reply to Kobboi from comment #21) > > My package.use says it's for app-admin/packagekit-base although I don't seem > > to have that installed anymore and can't remember why I had it in the first > > place > > python2 support in glib is required by app-admin/packagekit-base, > app-text/xiphos, dev-libs/libmateweather, dev-python/python-virtkey (all > reverse deps of glib[python]) All of these deps are wrong and should be fixed. No python is exposed by dev-libs/glib and it's only a fake dep that PYTHON_TARGETS satisfied. glib in practice doesn't even use or "support" ever when PYTHON_SINGLE_TARGET is python3_5 or python3_6 - there's nothing to support, it's just what interpreter a CLI utility happens to be launched with.
Yes, running recode or iconv is one option, if it works, and doesn't introduced unnecessary extra deps (recode would, iconv would not for glibc based system but not sure of others). Or just patching it with a patch (mind the 20 or 30kB limit for $FILESDIR total). Feel free to do either of those :)
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e45cb8298f71921b26ee6dc1f5def07585359cfd commit e45cb8298f71921b26ee6dc1f5def07585359cfd Author: Mart Raudsepp <leio@gentoo.org> AuthorDate: 2018-08-20 06:39:46 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2018-08-20 06:39:46 +0000 dev-util/glib-utils: drop python2 from compat python2 handles non-utf8 files badly for glib-mkenums, while it seems to be just a warning with python3. So drop python2 support, at least for now. Before it was kept due to bad glib[$PYTHON_USEDEP] deps, when mkenums was part of dev-libs/glib, but that's not a concern with this new package. Bug: https://bugs.gentoo.org/647892 Package-Manager: Portage-2.3.47, Repoman-2.3.10 dev-util/glib-utils/glib-utils-2.56.2.ebuild | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
I think the libgda files were fixed upstream for libgda-5.2.5 and newer, and old glib is now gone, so we only have glib-utils with py3 only left. So I think we are good either way now, so lets call this "fixed" by now.
