A new version of librime has been released. http://code.google.com/p/rimeime/downloads/detail?name=librime-1.1.tar.gz Reproducible: Always
It failed to build under gcc-4.7.3, probably because of the bug below. We need to upgrade to gcc 4.8.0 or newer version to build successfully without any changes. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53613
Hi @YeLee, thanks for reporting, I've already noticed this. (and I queued them in my proxy repo, also for app-i18n/rime-data, app-i18n/ibus-rime) force user to upgrade to gcc 4.8 won't be a good idea, how about the users who still stick to stable version? (gcc 4.8 still not go stable..) could you report this bug to upstream, and provide the link back here? seems there is already one simple fix. thanks
@Dennis 'dlan' Lan, I have reported this bug to upstream, but I wrote it in Chinese, I hope you can understand. :) http://code.google.com/p/rimeime/issues/detail?id=553
Ok to add it to the tree, obviously ~arch? gcc 4.8 is also ~arch and we can add in a DEPEND on it, and rename this bug to "app-i18n/librime-1.1 fails to build with gcc <4.8" ?
Created attachment 366688 [details] librime-1.1.ebuild @Yelee, thanks for reporting to upstream @swift, Ok, fine by me. So, let's restrict the gcc version dependency. I've also added a version check in pkg_setup(), let's keep it until we have better solution. changes to librime 1) drop to unstable/testing keywords 2) drop patches which is already included by upstream 3) gcc version check also please help bumping following ebuilds which released by upstream in the same time. a) app-i18n/ibus-rime-1.1 (you just copy from version 0.9.9) b) app-i18n/rime-data-0.32 (copy 0.22, drop to unstable keywords, bump EPAI=5) also, you can checkout those ebuilds from my git repo. $ git clone -b for-yngwin git://github.com/dlanx/proxy-maint.git
(In reply to Yixun 'dlan' Lan from comment #5) > Created attachment 366688 [details] > librime-1.1.ebuild > > @Yelee, thanks for reporting to upstream > > @swift, Ok, fine by me. So, let's restrict the gcc version dependency. I've > also added a version check in pkg_setup(), let's keep it until we have > better solution. No no no. Restricting gcc dependency makes no sense because the user may have 4.8 and 4.6 installed, so the dependency is satisfied, but have 4.6 as the default one. Better, detect running gcc version in src_prepare and die if 4.8 is not used. Unfortunately I can't think of another way to mitigate this problem for now.
(In reply to Markos Chandras from comment #6) > (In reply to Yixun 'dlan' Lan from comment #5) > > Created attachment 366688 [details] > > librime-1.1.ebuild > > > > @Yelee, thanks for reporting to upstream > > > > @swift, Ok, fine by me. So, let's restrict the gcc version dependency. I've > > also added a version check in pkg_setup(), let's keep it until we have > > better solution. > > No no no. Restricting gcc dependency makes no sense because the user may > have 4.8 and 4.6 installed, so the dependency is satisfied, but have 4.6 as > the default one. Better, detect running gcc version in src_prepare and die > if 4.8 is not used. Unfortunately I can't think of another way to mitigate > this problem for now. ...or wait until upstream provide a fix and then use it in the ebuild to allow old gcc version to be used as well
(In reply to Markos Chandras from comment #6) > No no no. Restricting gcc dependency makes no sense because the user may > have 4.8 and 4.6 installed, so the dependency is satisfied, but have 4.6 as > the default one. Better, detect running gcc version in src_prepare and die > if 4.8 is not used. Unfortunately I can't think of another way to mitigate > this problem for now. didn't look at the attached ebuild?! we *did* actually check the active gcc version in pkg_setup(), and emit die if not satisfied > ...or wait until upstream provide a fix and then use it in the ebuild to > allow old gcc version to be used as well I'd rather not to wait, we can push this solution now, and amend later when we find better solution, either 1) librime upstream fix the code 2) or patches for gcc backported.
I'm afraid, probably we won't have much choices here, librime upstream just mark this bug as "won't fix" and force it depend on >=gcc-4.8.. And I'd personally against carry patches which won't be accepted by upstream, it would be rather burden for maintenance...
The ebuild needs fixing I believe. pkg_setup is also executed for binary packages so gcc || die should not be there. Better move it to src_prepare or check if the package is not binary.
Created attachment 366804 [details] librime-1.1.ebuild (In reply to Markos Chandras from comment #10) > The ebuild needs fixing I believe. pkg_setup is also executed for binary > packages so gcc || die should not be there. Better move it to src_prepare or > check if the package is not binary. ooops, I obviously missed this.. sorry let's check if the package is binary. I don't think checking in src_prepare is a good iea, because it runs at post-unpack, check in this phase will result in unnecessary unpacking when install from source and <gcc-4.8. also example from leechcraft.eclass do this check in pkg_pretend(). this phase can't grantee the dependencies will be met, so gcc-4.8 maybe not even installed (install from source). we definitely want to check after gcc installed.
Created attachment 366856 [details] librime-1.1.ebuild 19:03:49< dlan> hwoarang: one thing still, you don't agree to put >=gcc-4.8 into DEPEND? 19:03:56< hwoarang> dlan: yeah because there will be at least one gcc installed 19:04:11< hwoarang> dlan: no because it means nothing. the package will pull and install gcc-4.8 but not select it as active 19:04:22< hwoarang> the error message is good enough to let the user know what he needs to do 19:04:28< hwoarang> meaning "install and enable gcc-4.8" 19:04:32< hwoarang> no need to pull it from the ebuild 19:05:19< dlan> oh, I see your point.. 19:05:56< dlan> my original idea was 1) put into DEPEND, so it will automatically installed for user 2) then user only need to active the correct version 19:06:15< hwoarang> yeah but we usually do not list @system deps 19:06:36< hwoarang> unless necessary, for example, package foo needs glibc-2.18 19:06:45< hwoarang> because only one glibc can be installed 19:07:04< hwoarang> but with gcc and slots, you can have 10 of them installed, and the DEPEND= does not guarantee that the good one will be selected updated with 1) gcc removed from DEPEND 2) check in pkg_pretend(), so it will die early
+*librime-1.1 (03 Jan 2014) + + 03 Jan 2014; Markos Chandras <hwoarang@gentoo.org> +librime-1.1.ebuild: + Version bump. Bug #496080. Thanks to Yixun Lan <dennis.yxun@gmail.com> +
There are some patches for older gcc. https://build.opensuse.org/package/view_file/M17N/librime/librime-1.1-gcc53613.patch https://build.opensuse.org/package/view_file/M17N/librime/librime-1.1-BOOST_NO_SCOPED_ENUMS.patch This bug might fix in the msvc10 branch as well: https://github.com/lotem/librime/issues/9
+*librime-1.1-r1 (08 Apr 2014) + + 08 Apr 2014; Yixun Lan <dlan@gentoo.org> +librime-1.1-r1.ebuild, + +files/librime-1.1-BOOST_NO_SCOPED_ENUMS.patch, + +files/librime-1.1-gcc53613.patch: + backport patchhes for <gcc-4.8, thanks @YeLee +
