Bugzilla Bug 172972

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 an attachment (id=115126) [edit]
build error log and system info 

created attachment with the needed info

Created an attachment (id=115127) [edit]
emerge --info

Created an attachment (id=115129) [edit]
build error log

(From update of attachment 115129 [edit])
wrong one and somehow unreadable

Created an attachment (id=115132) [edit]
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.