Not an exhaustive summary: sci-misc/boinc is currently the only package in portage tree which needs wxGTK built with USE=webkit Support will be dropped soon for USE=webkit on the older gtk2 slot to ease porting wxGTK to webkit-gtk:4 (newer API with security-related fixes)
gtk2 versions can not work with any security safe webkit-gtk, thus you HAVE to use 3.0-gtk3 WX_GTK_VER ASAP, so we can clean the security vulnerability from both SLOTS - removing webkit support from 3.0 and backporting patches to support webkit-gtk:4 for 3.0-gtk3. Removing of the older version using WX_GTK_VER=3.0 will be in a hurry as well, as I'd like to stabilize new and remove old version rather soon. Also as soon as it's bumped, there will be fun blockers then due to newest wxGTK:3.0 not having a USE=webkit anymore, but the old boinc deps on it.
I think my re-assigning/commenting might have collided with the GH bot trying to add a reference to a pull request (or it didn't work with force push). Adding manually.
This is the only consumer for wxGTK: USE=webkit
(In reply to kuzetsa from comment #3) > This is the only consumer for wxGTK: USE=webkit If I ever needed a strong reason to drop gtk2 based wxGTK support in BOINC, this is it. The current version works very well, so I'll have a look at this issue at the next week-end. Sorry, but this is the fastest I can do.
I'm not sure we wait that long with the addition of wxGTK:3.0 that does NOT have USE=webkit. Can we at least meanwhile change the old ebuild wxGTK dep to x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,webkit(-)] to minimize the issues? I think it might give better error messages about incompatibility of the new version of wxGTK, once added, and more automatically prevents the wxGTK:3.0 upgrade until boinc is fixed
(In reply to Mart Raudsepp from comment #5) > I'm not sure we wait that long with the addition of wxGTK:3.0 that does NOT > have USE=webkit. Can we at least meanwhile change the old ebuild wxGTK dep to > > x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,webkit(-)] > > to minimize the issues? I think it might give better error messages about > incompatibility of the new version of wxGTK, once added, and more > automatically prevents the wxGTK:3.0 upgrade until boinc is fixed Maybe we could do this for now? [ package.use.mask ] # pre-gtk3 versions deprecated, per bug #618642 x11-libs/wxGTK:3.0 webkit Haven't tested but that syntax looks right at first glance.
(In reply to kuzetsa from comment #6) > (In reply to Mart Raudsepp from comment #5) > > I'm not sure we wait that long with the addition of wxGTK:3.0 that does NOT > > have USE=webkit. Can we at least meanwhile change the old ebuild wxGTK dep to > > > > x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,webkit(-)] > > > > to minimize the issues? I think it might give better error messages about > > incompatibility of the new version of wxGTK, once added, and more > > automatically prevents the wxGTK:3.0 upgrade until boinc is fixed > > Maybe we could do this for now? > > [ package.use.mask ] > > # pre-gtk3 versions deprecated, per bug #618642 > x11-libs/wxGTK:3.0 webkit > > Haven't tested but that syntax looks right at first glance. Tree would be broken, unless sci-misc/boinc X is added to mask as well.
(In reply to Mart Raudsepp from comment #7) > (In reply to kuzetsa from comment #6) > > (In reply to Mart Raudsepp from comment #5) > > > I'm not sure we wait that long with the addition of wxGTK:3.0 that does NOT > > > have USE=webkit. Can we at least meanwhile change the old ebuild wxGTK dep to > > > > > > x11-libs/wxGTK:${WX_GTK_VER}[X,opengl,webkit(-)] > > > > > > to minimize the issues? I think it might give better error messages about > > > incompatibility of the new version of wxGTK, once added, and more > > > automatically prevents the wxGTK:3.0 upgrade until boinc is fixed > > > > Maybe we could do this for now? > > > > [ package.use.mask ] > > > > # pre-gtk3 versions deprecated, per bug #618642 > > x11-libs/wxGTK:3.0 webkit > > > > Haven't tested but that syntax looks right at first glance. > > Tree would be broken, unless sci-misc/boinc X is added to mask as well. Aye. It was a rude / vague [and probably bad] idea: Explicit sabotage until users who don't put in effort to manually unmask webkit support on the vulnerable slot: That process of opting in would bring it to their attention that these issues exist (particularly, because the comment on the preceding line is typically displayed when portage refuses to take an action) Using either an ewarn/einfo message, or the less drastic approach which you described would involve a revbump (or reinstall/rebuild). Either of those methods requires changes to the ebuild. The more ideal balance is probably somewhere between waiting on the maintainer or applying one or more changes without explicit permission. Alternatively - I did perform a quick build & runtest on the version from PR #6530, and any issues from the slot change should be cosmetic at worst, and limited to just the boincmgr GUI, nothing which will impact work performed for & submitted to the boinc grid itself.
I can't build the current in-tree boinc-7.8.1 - it fails in compile stage. Tonight I have some time to investigate. Hopefully we can have this done fast. I have some other bugs to close on boinc, but would prefer to concentrate on this one first. As I can see, the old boinc versions have been dropped already? Good!
Alright. I couldn't build boinc because of bug 639108 - which I fixed. But then I got stuck and am highly irritated and unnerved right now. tl;dr: I'd love to migrate boinc to wxGTK:3.0-gtk3, but can't build said wxGTK version. Long: I hit the wretched (...)/lib64/crt1.o: In function `_start': init.c: undefined reference to `main' collect2: ld returned 1 error when trying to build wxGTK:3.0-gtk3 Everything the internet could tell me was, that the build reacts quite sissy on -Wl,O1 LDFLAGS. I do not have those anywhere in /etc/portage set, but "ebuild (...) unpack" showed, that it got added by (some) profile. So I went and removed that flag from all *FLAGs in temp/environment, and built wxGTK without it. Unfortunately the merge failed with the very same error. All flags used look sane, so I have no clue where to look for a solution. And to top it all there was a fire in the main central station of hamburg, germany, this morning. My urban railway line to work got dropped, and I had to take another one, which was so crowded, that I couldn't whip out my laptop for some research about that issue. (The one with wxGTK not linking.) ---- Down the line I need some more time. I have no clue whether the boinc manager will compile and link against wxGTK:3.0-gtk3. And people will go nuts if we remove it. Any pointers on how to build wxGTK:3.0-gtk3 on a 17.0 profile (just finished emerge -e @world on sunday, which took over a week) are highly welcome.
I don't have a clue what the problem is, especially if you don't file a proper bug report on it. I just built 3.0.2.0-r301 on 17.0 profiles with gcc7 yesterday just fine with LDFLAGS="-Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu". the -O1 and --as-needed comes from profile and I happen to append the hash-style to it, which shouldn't affect anything (it intends to change the default --hash-style=both as I don't need the sysv hash, but only gnu might already be a default by now in our binutils). Seems like kuzetsa had some GUI thing working fine with boinc against gtk3 too? I don't see why it would fail linking due to not having a main function - this is a library, it mustn't have one. Maybe it's during a build of some executable inside, but as there's no proper bug report with build.log attached - no clue.
(In reply to Sven Eden from comment #9) > I can't build the current in-tree boinc-7.8.1 - it fails in compile stage. > > Tonight I have some time to investigate. Hopefully we can have this done > fast. I have some other bugs to close on boinc, but would prefer to > concentrate on this one first. > > As I can see, the old boinc versions have been dropped already? Good! I didn't check to see if the 7.8.1 version worked, just the bump.
(In reply to Mart Raudsepp from comment #11) > I don't have a clue what the problem is, especially if you don't file a > proper bug report on it. I just built 3.0.2.0-r301 on 17.0 profiles with > gcc7 yesterday just fine with LDFLAGS="-Wl,-O1 -Wl,--as-needed > -Wl,--hash-style=gnu". the -O1 and --as-needed comes from profile and I > happen to append the hash-style to it, which shouldn't affect anything (it > intends to change the default --hash-style=both as I don't need the sysv > hash, but only gnu might already be a default by now in our binutils). > > Seems like kuzetsa had some GUI thing working fine with boinc against gtk3 > too? > I wouldn't know, as I don't test against unstable gcc7. (My @system profile is on keyword-stabilized gcc 6.4) Yes, the ebuild I made for boinc 7.8.4 uses the 3.0-gtk3 slot.
(In reply to Sven Eden from comment #10) > Down the line I need some more time. I have no clue whether the boinc > manager will compile and link against wxGTK:3.0-gtk3. And people will go > nuts if we remove it. > > Any pointers on how to build wxGTK:3.0-gtk3 on a 17.0 profile (just finished > emerge -e @world on sunday, which took over a week) are highly welcome. Unmasking 3.0-gtk3 slot for me is stable and builds clean on my otherwise stable- keyworded system. "something weird" [tm] in a system-wide ~amd64 might cause a regression though (like I said - it works for me on stable.) I did have some weird breakage initially when I migrated to the 17.0 profile until I did the recommended @world rebuild. Pretty sure it was just the PIE / non-PIE mixing badly, as indicated by the eselect news entry for the profile change. YMMV May not have been clear from comment#8 so I'll clarify: I did test the boincmgr gui (but only for the bumped 7.8.4 ebuild). Upstream specifically added support for gtk3, so an older version (7.8.1 was before the upstream fixes) won't work with the wxGTK:3.0-gtk3 slot unless you backport the upstream changes which were made by the boinc team.
(In reply to Mart Raudsepp from comment #11) > I don't have a clue what the problem is, especially if you don't file a > proper bug report on it. I just built 3.0.2.0-r301 on 17.0 profiles with > gcc7 yesterday just fine with LDFLAGS="-Wl,-O1 -Wl,--as-needed > -Wl,--hash-style=gnu". Mart, there is no proper bug report, because I am absolutely convinced that the problem is somewhere between my chair and the screen. I can't file a bug on myself, can I? wxGTK:3.0 merged fine in may when I upgraded to gcc-7, and now I can build neither 3.0 nor 3.0-gtk3 <-- this can't be a problem with the packages. Just with me not doing the profile upgrade carefully enough. (In reply to kuzetsa from comment #14) > I did have some weird breakage initially when I migrated to the 17.0 > profile until I did the recommended @world rebuild. Pretty sure it > was just the PIE / non-PIE mixing badly, as indicated by the eselect > news entry for the profile change. YMMV It took me a week to do the emerge -e @world, as I have a developer machine with over 2,000 packages, all but three built with -ggdb and split-debug FEATURE. *BUT* I downgraded beforehand to gcc-6.4.0, as I (absolutely naively) dreamed of having a cuda enabled opencv again. What I did last night was to go back up to gcc-7.2, do a multiple (aka paranoid) toolchain rebuild, and then an "emerge -e @system". However, this was not enough, and I have to look through my package list very carefully whether something simply fiddles with portage functionality. (maybe the bashrc.d enhancement from the mv overlay?) Some packages failed with weird messages about some obscure xattr feature not being supported, so I had to deactivate xattr USE flag on portage. That worked for years. So something is really fishy here. In the meantime PR 6530 could be merged, so I can rebase on that version bump once I got the contumaciousness out of my laptop.
Thanks for the ACK, and sorry for assuming too much
(In reply to Mart Raudsepp from comment #16) > Thanks for the ACK, and sorry for assuming too much Don't worry. I was just pissed off by myself. ;-) In the meantime I have removed app-portage/portage-bashrc-mv (didn't have the time to really work with it anyway) and voilá, wxGTK:3.0-gtk3 built just fine. 8^D
I hereby confirm that both boinc-7.8.1 and boinc 7.8.4 just work with wxGTK:3.0-gtk3. There is no further adaptation needed. The wxWidgets team has done really really well! It would be great if PR 6530 could be merged soon, so I can continue with fixing the other issues.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=f371aa1404ec4ff581399ce81685ffe828270005 commit f371aa1404ec4ff581399ce81685ffe828270005 Author: kuzetsa <kuzetsa@gmail.com> AuthorDate: 2017-12-12 13:24:32 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2017-12-21 10:46:48 +0000 sci-misc/boinc: sci-misc/boinc: bump 7.8.4 & SLOT wxGTK:3.0-gtk3 Bug: https://bugs.gentoo.org/640822 Package-Manager: Portage-2.3.13, Repoman-2.3.3 sci-misc/boinc/Manifest | 1 + sci-misc/boinc/boinc-7.8.4.ebuild | 181 ++++++++++++++++++++++++++++++++++++++ 2 files changed, 182 insertions(+)}
This wasn't "Closes:" because we need old revisions removed for this bug to be fixed for the purposes of the bugs this bug entry blocks. So your followup "remove old" commit will have to do that. Also (Sven) see the followup commit and the note in PR #6530.
@Mart: Thank you very much, that icon cache thing was on my list, too. Only the "xlocale.h incident" left, and the clean-up. I'll but the "Closes:" tag in there on my PR. Hopefuly I can open my PR tomorrow.
> I'll but the "Closes:" tag in there on my PR. Hopefuly I can open my PR > tomorrow. *put not but. :-/
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e5f2f2be84c3b6a791f53864d397372d41308430 commit e5f2f2be84c3b6a791f53864d397372d41308430 Author: Sven Eden <yamakuzure@gmx.net> AuthorDate: 2017-12-24 14:24:24 +0000 Commit: Mart Raudsepp <leio@gentoo.org> CommitDate: 2017-12-27 11:55:54 +0000 sci-misc/boinc: Clean up old ebuilds As it was discussed in bug 640822, said bug is now closed with cleaning up the old ebuilds. The newest no longer depends on gtk2 based wxWidgets, and remains. Closes: https://bugs.gentoo.org/640822 Package-Manager: Portage-2.3.19, Repoman-2.3.6 sci-misc/boinc/Manifest | 1 - sci-misc/boinc/boinc-7.8.1-r1.ebuild | 189 ----------------------------------- sci-misc/boinc/boinc-7.8.1.ebuild | 181 --------------------------------- 3 files changed, 371 deletions(-)
