* boinc-7.8.4.tar.gz BLAKE2B SHA512 size ;-) ... [ ok ] >>> Downloading 'http://boinc.berkeley.edu/logo/boinc_glossy2_512_F.tif' --2018-01-04 03:24:54-- http://boinc.berkeley.edu/logo/boinc_glossy2_512_F.tif Resolving boinc.berkeley.edu... 208.68.240.115 Connecting to boinc.berkeley.edu|208.68.240.115|:80... connected. HTTP request sent, awaiting response... 404 Not Found 2018-01-04 03:24:55 ERROR 404: Not Found. !!! Couldn't download 'boinc.tif'. Aborting. Changing to https:// fixes it. Also, why is it RESTRICT="mirror", while LICENSES="LGPL-2"? just for that image, or what..? Also while checking that, I'd say LGPL-2 is wrong. I see source files that say LGPL-3 or later, so more like LICENSES="LGPL-3+". While there, are you sure fix_webview change to "webview" is correct, as opposed to "std,webview"? Though that'd include even more things, so perhaps a more verbose list would be appropriate (upstream). Anyhow, as it seems just "webview" works, so probably fine downstream (webview itself probably pulls in at least core, and so it must not be using xml, xrc and the other stuff included by std)
(In reply to Mart Raudsepp from comment #0) > While there, are you sure fix_webview change to "webview" is correct, as > opposed to "std,webview"? Though that'd include even more things, so perhaps > a more verbose list would be appropriate (upstream). Anyhow, as it seems > just "webview" works, so probably fine downstream (webview itself probably > pulls in at least core, and so it must not be using xml, xrc and the other > stuff included by std) Is this what has caused loss of the vertical scroll bar from the manager? I'd like it back, please, because I routinely have 150-250 tasks listed, and that's a lot of wheel scrolling. It seems like too many tasks, but I only have 1-2 days' work set. While I'm here, the project display has lost the second group of buttons linking to preferences, etc. This also is not helpful.
(In reply to Mart Raudsepp from comment #0) > http://boinc.berkeley.edu/logo/boinc_glossy2_512_F.tif > 2018-01-04 03:24:55 ERROR 404: Not Found. > > !!! Couldn't download 'boinc.tif'. Aborting. > > Changing to https:// fixes it. That is new. A few days ago it worked well. Thank you for the report! > Also, why is it RESTRICT="mirror", while LICENSES="LGPL-2"? just for that > image, or what..? > > Also while checking that, I'd say LGPL-2 is wrong. I see source files that > say LGPL-3 or later, so more like LICENSES="LGPL-3+". No, that is a left-over from the original stone-age ebuilds. With *GPL license the restriction makes no sense at all, that's true. > While there, are you sure fix_webview change to "webview" is correct, as > opposed to "std,webview"? Though that'd include even more things, so perhaps > a more verbose list would be appropriate (upstream). Anyhow, as it seems > just "webview" works, so probably fine downstream (webview itself probably > pulls in at least core, and so it must not be using xml, xrc and the other > stuff included by std) No. A (long) while ago wxWidgets were changed to no longer include webview in ${WX_LIBS}, so the patch was necessary to explicitly add webview. That's really all. Without it, boinc can not be linked. (In reply to peter@prh.myzen.co.uk from comment #1) > Is this what has caused loss of the vertical scroll bar from the manager? > I'd like it back, please, because I routinely have 150-250 tasks listed, and > that's a lot of wheel scrolling. It seems like too many tasks, but I only > have 1-2 days' work set. Boinc was changed to use a GTK-3 wxWidgets variant, which means that all scrollbars are only visible if a mouse moves somewhere in their vicinity. I find this behavior quite irritating, but that is the default. (This sometimes drives me nuts when I am working with Eclipse...) However, I found that the scrollbars do not always appear in the boinc manager unless the window was resized slightly. I guess that this is due to boinc being written for GTK+-2 wxWidgets. > While I'm here, the project display has lost the second group of buttons > linking to preferences, etc. This also is not helpful. When I looked this morning, everything was where it should be. But I'll take a second look tonight. Lost buttons are no fun at all.
> (In reply to peter@prh.myzen.co.uk from comment #1) > > Is this what has caused loss of the vertical scroll bar from the manager? > > I'd like it back, please, because I routinely have 150-250 tasks listed, and > > that's a lot of wheel scrolling. It seems like too many tasks, but I only > > have 1-2 days' work set. > > Boinc was changed to use a GTK-3 wxWidgets variant, which means that all > scrollbars are only visible if a mouse moves somewhere in their vicinity. I > find this behavior quite irritating, but that is the default. (This > sometimes drives me nuts when I am working with Eclipse...) > > However, I found that the scrollbars do not always appear in the boinc > manager unless the window was resized slightly. I guess that this is due to > boinc being written for GTK+-2 wxWidgets. Ah, I see it now. I did have the window maximised, but after restoring it and expanding it myself, the scroll bar has appeared again. > > While I'm here, the project display has lost the second group of buttons > > linking to preferences, etc. This also is not helpful. > > When I looked this morning, everything was where it should be. But I'll take > a second look tonight. Lost buttons are no fun at all. Something's definitely flaky here. When I fired up the manager window, the Task display showed only about a sixteenth of the content, in the top-left corner. Changing the size as above restored the display.
(In reply to Sven Eden from comment #2) > > While there, are you sure fix_webview change to "webview" is correct, as > > opposed to "std,webview"? Though that'd include even more things, so perhaps > > a more verbose list would be appropriate (upstream). Anyhow, as it seems > > just "webview" works, so probably fine downstream (webview itself probably > > pulls in at least core, and so it must not be using xml, xrc and the other > > stuff included by std) > > No. A (long) while ago wxWidgets were changed to no longer include webview > in ${WX_LIBS}, so the patch was necessary to explicitly add webview. That's > really all. Without it, boinc can not be linked. Yes, I'm aware, I re-ported that patch for wxGTK-3.0.3*. I'm saying that just webview means you won't be getting these libraries to the linking line: -lwx_gtk3u_xrc-3.0-gtk3 -lwx_gtk3u_html-3.0-gtk3 -lwx_gtk3u_qa-3.0-gtk3 -lwx_gtk3u_adv-3.0-gtk3 -lwx_gtk3u_core-3.0-gtk3 -lwx_baseu_xml-3.0-gtk3 -lwx_baseu_net-3.0-gtk3 It is extremely unlikely that you don't need at least core, you are just lucky that webview happens to pull it in indirectly. Compare: $ WX_ECLASS_CONFIG=/usr/lib64/wx/config/gtk3-unicode-3.0-gtk3 wx-config --libs -L/usr/lib64 -pthread -lwx_gtk3u_xrc-3.0-gtk3 -lwx_gtk3u_html-3.0-gtk3 -lwx_gtk3u_qa-3.0-gtk3 -lwx_gtk3u_adv-3.0-gtk3 -lwx_gtk3u_core-3.0-gtk3 -lwx_baseu_xml-3.0-gtk3 -lwx_baseu_net-3.0-gtk3 -lwx_baseu-3.0-gtk3 $ WX_ECLASS_CONFIG=/usr/lib64/wx/config/gtk3-unicode-3.0-gtk3 wx-config --libs webview -L/usr/lib64 -pthread -lwx_gtk3u_webview-3.0-gtk3 -lwx_baseu-3.0-gtk3 std is the keyword for the default, which includes core, xrc, adv and much more - so indeed, that's probably too excessive. And then you can add together what you need in a comma-separated list, e.g core,webview,what,else,is,needed > Boinc was changed to use a GTK-3 wxWidgets variant, which means that all > scrollbars are only visible if a mouse moves somewhere in their vicinity. I > find this behavior quite irritating, but that is the default. (This > sometimes drives me nuts when I am working with Eclipse...) This can be changed for gtk3 globally via some theme that forces scrollbars or via GTK_OVERLAY_SCROLLING=0 env var or something. To me of course it is annoying when stuff has always visible scrollbars - it wastes space and I always use mousewheel anyways. Well, at least if they aren't bugged by wxGTK. > However, I found that the scrollbars do not always appear in the boinc > manager unless the window was resized slightly. I guess that this is due to > boinc being written for GTK+-2 wxWidgets. > > > While I'm here, the project display has lost the second group of buttons > > linking to preferences, etc. This also is not helpful. > > When I looked this morning, everything was where it should be. But I'll take > a second look tonight. Lost buttons are no fun at all. Please make sure you test all these things against wxGTK-3.0.3-r300. It has a LOT of backported gtk3 fixes in there in a patchset I included in it, compared to 3.0.2.0-r301.
> Please make sure you test all these things against wxGTK-3.0.3-r300. It has > a LOT of backported gtk3 fixes in there in a patchset I included in it, > compared to 3.0.2.0-r301. And if some problems persist, might want to file bugs against that newer wxGTK here, so I can maybe go and hunt for more patches to fix these too. Not all was backported to the 3.0 branch (intended for a 3.0.4 release that may never happen), and some fixes I might need to go hunt from the development version, but I need to know what problems there are before I go down that rabbit hole.
(In reply to Mart Raudsepp from comment #4) > > No. A (long) while ago wxWidgets were changed to no longer include webview > > in ${WX_LIBS}, so the patch was necessary to explicitly add webview. That's > > really all. Without it, boinc can not be linked. > > It is extremely unlikely that you don't need at least core, you are just > lucky that webview happens to pull it in indirectly. It doesn't. ${WX_LIBS} already *has* everything needed *but* webview. ;-) > Please make sure you test all these things against wxGTK-3.0.3-r300. It has > a LOT of backported gtk3 fixes in there in a patchset I included in it, > compared to 3.0.2.0-r301. I have just upgraded, but hadn't had the time to test whether the behavior of boinc manager got better. Btw.: The value of 'eselect wxwidgets' is not influencing this, right? I had it set to the old 3.0 instead of 3.0-gtk3 by pure oversight.
(In reply to Sven Eden from comment #6) > (In reply to Mart Raudsepp from comment #4) > > > No. A (long) while ago wxWidgets were changed to no longer include webview > > > in ${WX_LIBS}, so the patch was necessary to explicitly add webview. That's > > > really all. Without it, boinc can not be linked. > > > > It is extremely unlikely that you don't need at least core, you are just > > lucky that webview happens to pull it in indirectly. > > It doesn't. ${WX_LIBS} already *has* everything needed *but* webview. ;-) ah okay, then probably the better place would be to change the place where WX_LIBS is set, if it overlinks xrc/adv/net/xml/etc there (if any is unused), which is likely if before wxGTK patches webview was included. But that's something for upstream perfection really, not necessarily important for us. > > Please make sure you test all these things against wxGTK-3.0.3-r300. It has > > a LOT of backported gtk3 fixes in there in a patchset I included in it, > > compared to 3.0.2.0-r301. > > I have just upgraded, but hadn't had the time to test whether the behavior > of boinc manager got better. > > Btw.: The value of 'eselect wxwidgets' is not influencing this, right? I had > it set to the old 3.0 instead of 3.0-gtk3 by pure oversight. The whole point of wxwidgets.eclass and the WX_ECLASS_CONFIG stuff it sets up for our extra wx-config wrapper is to ensure the user choice of wxwidgets doesn't influence and mess up the package manager bookkeeping, yes. eselect wxwidgets user choice shouldn't affect anything, but if things are buggy in the ebuild, then it might. Usually a proper build system with setup-wxwidgets call is good. Looks like you confirmed it works right, as you got gtk3 without having that as user choice ;)
(In reply to peter@prh.myzen.co.uk from comment #3) > Something's definitely flaky here. When I fired up the manager window, the > Task display showed only about a sixteenth of the content, in the top-left > corner. Changing the size as above restored the display. Turns out to have been my fault. I'd keyworded x11-libs/wxGTK to a particular version by prepending a '~'. Bad move, which I didn't uncover until today: that version had disappeared from portage. After removing the '~' and emerging -u, everything I complained about is fixed. Sorry about the noise.
(In reply to peter@prh.myzen.co.uk from comment #8) > Turns out to have been my fault. I'd keyworded x11-libs/wxGTK to a > particular version by prepending a '~'. Bad move, which I didn't uncover > until today: that version had disappeared from portage. After removing the > '~' and emerging -u, everything I complained about is fixed. Now another problem has appeared: the disk display tab is blank.
I'd love to investigate this further and eventually fix this. But unfortunately I have massive problems with my wretched Broadcom wifi. It just doesn't work any more on Linux. (it's that damn Broadcom-Sta thing) Today I finally cracked and ordered an Intel 7260 card. It should arrive next week and then I am back on. If you wonder, I am writing this using my cell phone. :-/
These issues should be fixed with PR https://github.com/gentoo/gentoo/pull/7531
I am still waiting for the PR merge, or Feedback at least, sorry.
The bug has been fixed by https://github.com/gentoo/gentoo/pull/7531 - But I forgot that the "Closes:" statements must be in the commit messages, and not only in the PR description. Sorry everybody, I failed to check with the bugs! I am currently waiting for some other PR to merge. Going back into BOINC for some version bumping and review is on my list to do next.
