I am using the ~x86 version of KDE (actual 3.5.6) Every component of kde-base builds fine except kde-base/kcontrol-3.5.6 here are the last lines of the portage log: Reproducible: Always Steps to Reproduce: 1. set ~x86 keyword for all kde-base packages in /etc/portage/package.heywords 2. emerge kde-base/kcontrol Actual Results: here are the results of emerge log emerge --info uname -a http://nopaste.info/3794bede8f.html
Don't ever refer to pastebins when reporting bugs, please. Post/attach all relevant info here and reopen then.
hi, i got an error message saying that the comment was too long...
Created attachment 115126 [details] build error log and system info
created attachment with the needed info
Created attachment 115127 [details] emerge --info
Created attachment 115129 [details] build error log
Comment on attachment 115129 [details] build error log wrong one and somehow unreadable
Created attachment 115132 [details] build error log. the new one
And please make sure the attached one, is the real one. From the url: > distcc[23065] (dcc_writex) ERROR: failed to write: Connection reset by peer > distcc[23065] Warning: failed to distribute kdatetimedlg.cpp to 127.0.0.1, runni ng locally instead Sounds you've a somewhat messed up distributed build setup. Clean out /var/tmp/portage and retry to build _locally_ If it's still an issue, reopen.
(In reply to comment #9) > > distcc[23065] (dcc_writex) ERROR: failed to write: Connection reset by peer > > distcc[23065] Warning: failed to distribute kdatetimedlg.cpp to 127.0.0.1, runni ng locally instead > I get these all the time when I'm compiling something and don't have the remote host's distcc setup running. It is normal and I've never had it cause a failure to compile for that reason alone.
[quote] Sounds you've a somewhat messed up distributed build setup. Clean out /var/tmp/portage and retry to build _locally_ If it's still an issue, reopen. [/quote] I have cleaned up /var/tmp/portage and went to build everything locally (disabled distcc). According to some user's advice i upgraded openssl, qt and kdelibs to ~x86 unstable to make sure, there is no stable/unstable mixup issue. Still, when building kcontrol i got the same build error again.
Yesterday i noticed that my USE flags were messed up somehow. With the help of some freenode users (thanks) i realized that kdelibs kept compiling with disabled -ssl USE flag, even when make.conf has the global ssl useflag set and there was no entry in package.use about kdelibs. So i did an 'USE="ssl" emerge kdelibs kcontrol' and everything built fine. Going to do a complete world update today to make sure everything is correct now. still got to find out, why my USE flag hasn't been recognized, but that's out of topic. as you see, no bug, but a configuration fault by myself. sorry for hitting the alarm bells. thanks to all who tried to help me out with that issue.
Yes, noticed this in between, too. While you're apparently fine with it, it's still a bug.
Why is it a bug when i misconfigured portage somehow?
Carlo, whose bug is it, though? I don't think either of our eclasses caused this problem or the kdelibs ebuild. Or did I miss something? Personally, I think this was a local problem. If it was Portage, I think we would have heard about it.
(In reply to comment #15) > Carlo, whose bug is it, though? I don't think either of our eclasses caused > this problem or the kdelibs ebuild. Or did I miss something? > > Personally, I think this was a local problem. If it was Portage, I think we > would have heard about it. > Hi there, as i stated in my last comment, this was a configuration problem by myself ( i am the bug reporter). I have rebuild everything KDE related with the SSL use flag and it built fine. several times updating world since then goes without any problem. So as already stated, this is not an official bug, but configuration problem and the ticket can be closed. i will close it now. thanks for your effort.
Please stop resolving bugs, buksrol. If it were an PEBKAC problem, the correct solution would be INVALID and not FIXED. Since we still have to wait for use dependencies, the correct workaround for this bug would be to add some built_with_use() construct within pkg_setup(), but because there is bug 117860, other candidates for the same problem regarding openssl and I'm sick of these workarounds, my preferred solution would be to remove the use flag and make the OpenSSL dependency mandatory. Opinions?
(In reply to comment #17) > my preferred solution would be to remove the use flag and make the OpenSSL > dependency mandatory. Opinions? I agree because SSL is used all over the place anyway. And it would cure the symptom but if comment #12 is correct, though, the real reason of this, I think, must be a different one: "kdelibs kept compiling with disabled -ssl USE flag, even when make.conf has the global ssl useflag set and there was no entry in package.use about kdelibs." buksrol's --info (cf. comment #5) indeed has the ssl USE flag set (and even if it was added when trying to solve this, he recompiled recompiled kdelibs when it was set (cf. comment #11)) which is different from bug 117860 where ssl is at least not set globally. That's why I'm confused about this bug: - If we consider comment #12 as valid, there would have been an issue with Portage 2.1.2.2. -> Not our bug. - If we consider comment #12 as not entirely valid, it must be a local issue. -> Invalid. Furthermore, in make.defaults for x86, the ssl USE flag has been set since 22. 12. 2004. So unless it's explicitly disabled by the user (which obviously isn't the case here), it's set anyway. Don't misunderstand me: I'm fine with making openssl a hard dependency but I'm not sure if it's the right solution for *this* bug.
The error definitely stems from building kdelibs without ssl and then trying to build kcontrol with it. With kdeaddons-kfile-plugins it's the same problem. Making openssl mandatory may need a thick skin given that we really need to make zeroconf/avahi support mandatory and having the past in mind with users moaning about removing their options, sometimes without even having a clue how their software works. But hey, who cares. :)
Fixed with kdelibs-3.5.6-r7.
Making zeroconf/avahi dependencies mandatory is really an annoyance since it increases a minimal kde enormously. Why don't you solve the problem instead as other projects do: By calling built_with_use in the dependent packages when they need this feature?
gotta wonder why i suddenly have this avahi/mdns cruft being pulled in on my machine ... guess this is why huh
Among others, yes. Install it and ignore it, as I do.
if i wanted that sort of answer, i'd go install some crap like Fedora ... what's the point of USE flags if they arent respected this bug was about something core like openssl which you cant avoid without going truly embedded ... it wasnt about mdns/avahi
Sorry but with zeroconf enabled, and ignoring my useflags this KDE ebuild is broken and unstable! I'm not willing to weaken my network for arp poisoning attacks with zeroconf, and I do not need zeroconf. On my notebook I use OpenSuse and they do not use zeroconf at all, they do use the more secure net-libs/openslp as Service Location Protocol. Why Suse can build KDE without zeroconf? The only way to get a clean KDE 3.5.7 install for Gentoo is to download direct from www.kde.org and build in handwork. Sorry I'm ready with unstable KDE 3.5.7-r2.
