Mailing List Archive: Re: KDE-Sunset : kdelibs problem

Re: KDE-Sunset : kdelibs problem

Oct 29, 2012, 10:01 AM

Post #1 of 8 (3397 views)

121029 Fat-Zer wrote:
> 2012/10/29 E. Liddell <ejlddll@googlemail.com>
>> Your real problem was that you were trying to emerge kdelibs-3.5.10-*r6*,
>> rather than 3.5.10-r10, which has a patch for openssl > 1.0.0
>> and compiled just fine for me as of Thursday.
> The truth is yours: it compiles.

I did realise that & tried it, but what I then got was :

root:506 ~> USE="avahi qt3" emerge kdelibs:3.5
...
>>> Emerging (1 of 3) net-dns/avahi-0.6.30-r1 from kde-sunset
* avahi-0.6.30.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ]
>>> Unpacking source...
>>> Unpacking avahi-0.6.30.tar.gz to /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work
>>> Source unpacked in /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work
>>> Preparing source in /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work/avahi-0.6.30 ...
* Applying avahi-0.6.30-optional-gtk-utils.patch ... [ ok ]
* Running eautoreconf in '/z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work/avahi-0.6.30' ...
* Running glib-gettextize --copy --force ... [ ok ]
* Running intltoolize --automake --copy --force ... [ ok ]
* Running libtoolize --install --copy --force --automake ... [ ok ]
* Running aclocal -I common ... [ ok ]
* Running autoconf ... [ ok ]
* Running autoheader ... [ ok ]
* Running automake --add-missing --copy --foreign ... [ !! ]
* Failed Running automake !
* Include in your bugreport the contents of:
* /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/temp/automake.out

which contains :

***** automake *****
***** PWD: /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work/avahi-0.6.30
***** automake --add-missing --copy --foreign
configure.ac:143: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
configure.ac:143: the top level
configure.ac:300: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
configure.ac:300: the top level
service-type-database/Makefile.am:21: `pkglibdir' is not a legitimate directory for `DATA'

Do either of you have further suggestions ? -- thanks so far (smile)

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Re: KDE-Sunset : kdelibs problem [ In reply to ]

ejlddll at googlemail

Oct 29, 2012, 3:29 PM

Post #2 of 8 (3361 views)

Permalink

On Mon, 29 Oct 2012 13:01:19 -0400
Philip Webb <purslow@ca.inter.net> wrote:

> 121029 Fat-Zer wrote:
> > 2012/10/29 E. Liddell <ejlddll@googlemail.com>
> >> Your real problem was that you were trying to emerge kdelibs-3.5.10-*r6*,
> >> rather than 3.5.10-r10, which has a patch for openssl > 1.0.0
> >> and compiled just fine for me as of Thursday.
> > The truth is yours: it compiles.
>
> I did realise that & tried it, but what I then got was :
>
> root:506 ~> USE="avahi qt3" emerge kdelibs:3.5
> ...
> >>> Emerging (1 of 3) net-dns/avahi-0.6.30-r1 from kde-sunset
> * avahi-0.6.30.tar.gz RMD160 SHA1 SHA256 size ;-) ... [ ok ]
> >>> Unpacking source...
> >>> Unpacking avahi-0.6.30.tar.gz to /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work
> >>> Source unpacked in /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work
> >>> Preparing source in /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work/avahi-0.6.30 ...
> * Applying avahi-0.6.30-optional-gtk-utils.patch ... [ ok ]
> * Running eautoreconf in '/z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work/avahi-0.6.30' ...
> * Running glib-gettextize --copy --force ... [ ok ]
> * Running intltoolize --automake --copy --force ... [ ok ]
> * Running libtoolize --install --copy --force --automake ... [ ok ]
> * Running aclocal -I common ... [ ok ]
> * Running autoconf ... [ ok ]
> * Running autoheader ... [ ok ]
> * Running automake --add-missing --copy --foreign ... [ !! ]
> * Failed Running automake !
> * Include in your bugreport the contents of:
> * /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/temp/automake.out
>
> which contains :
>
> ***** automake *****
> ***** PWD: /z/portage-tmp/portage/net-dns/avahi-0.6.30-r1/work/avahi-0.6.30
> ***** automake --add-missing --copy --foreign
> configure.ac:143: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> ../../lib/autoconf/general.m4:2591: _AC_COMPILE_IFELSE is expanded from...
> ../../lib/autoconf/general.m4:2607: AC_COMPILE_IFELSE is expanded from...
> ../../lib/m4sugar/m4sh.m4:606: AS_IF is expanded from...
> ../../lib/autoconf/general.m4:2032: AC_CACHE_VAL is expanded from...
> ../../lib/autoconf/general.m4:2053: AC_CACHE_CHECK is expanded from...
> configure.ac:143: the top level
> configure.ac:300: warning: AC_LANG_CONFTEST: no AC_LANG_SOURCE call detected in body
> ../../lib/autoconf/lang.m4:194: AC_LANG_CONFTEST is expanded from...
> configure.ac:300: the top level
> service-type-database/Makefile.am:21: `pkglibdir' is not a legitimate directory for `DATA'
>
> Do either of you have further suggestions ? -- thanks so far (smile)

If I'm reading that correctly, your compile failure is in avahi itself, not any of
the kde-sunset packages. avahi is still in the main tree, so complaints about it
should be addressed to the main Gentoo Bugzilla . . . and it looks like
avahi-0.6.30-r3 is the current stable ebuild for nearly all arches, not -r1,
unless it's been rolled back since I last did emerge --sync.

As for what to do with kdelibs, my advice would be to compile it with -avahi and
let it fall back on mDNSResponder instead. If that is unacceptable to you for
some reason, and you get avahi to compile, you could try hacking the avahi ebuild
to turn QT3 support back on (try replacing the line that says "--disable-qt3 \" with
"--enable-qt3 \")--that probably won't help, mind you, but it's worth a try.

The next step after that would involve checking both the Trinity and the OpenSUSE
KDE3 repos for patches to kdnssd-avahi and seeing if they have something that
fixes the problem (may require patch tweaking). If there's nothing relevant, writing
a patch from scratch is the only workable approach, and it's probably more trouble
than you want to go to.

Re: KDE-Sunset : kdelibs problem [ In reply to ]

purslow at ca

Oct 29, 2012, 4:11 PM

Post #3 of 8 (3345 views)

Permalink

121029 E. Liddell wrote:
> your compile failure is in avahi itself, not any of the kde-sunset packages.
> avahi is still in the main tree, so complaints about it should be addressed
> to the main Gentoo Bugzilla and it looks like avahi-0.6.30-r3
> is the current stable ebuild for nearly all arches, not -r1.

Yes & in fact, as I now see, I already have that version installed.
Apparently, kdelibs:3.5 wants the -r1 version instead.

> As for what to do with kdelibs, my advice would be to compile it with -avahi
> and let it fall back on mDNSResponder instead.

That's not in the Gentoo tree anymore, so that's impossible.

> you could try hacking the avahi ebuild ...
> The next step checking Trinity and OpenSUSE KDE3 repos
> for patches to kdnssd-avahi ...

That's hardly worth it just to restore 1 game & 1 useful toy !

Clearly enough, the Sunset version of KDE is terminally dead
& my best bet is to try compiling Trinity from source.
There is a Trinity doc with detailed advice how to go about that,
so when I have time to spare, I may have a go at it.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Re: KDE-Sunset : kdelibs problem [ In reply to ]

ejlddll at googlemail

Oct 29, 2012, 6:35 PM

Post #4 of 8 (3340 views)

Permalink

On Mon, 29 Oct 2012 19:11:42 -0400
Philip Webb <purslow@ca.inter.net> wrote:

> 121029 E. Liddell wrote:
> > your compile failure is in avahi itself, not any of the kde-sunset packages.
> > avahi is still in the main tree, so complaints about it should be addressed
> > to the main Gentoo Bugzilla and it looks like avahi-0.6.30-r3
> > is the current stable ebuild for nearly all arches, not -r1.
>
> Yes & in fact, as I now see, I already have that version installed.
> Apparently, kdelibs:3.5 wants the -r1 version instead.
>
> > As for what to do with kdelibs, my advice would be to compile it with -avahi
> > and let it fall back on mDNSResponder instead.
>
> That's not in the Gentoo tree anymore, so that's impossible.

Apologies. Like an idiot, I misread the ebuild.

The following USE flag settings allow kdelibs to compile successfully for me:

[ebuild R ~] kde-base/kdelibs-3.5.10-r10::kde-sunset USE="acl alsa branding jpeg2k spell tiff
-arts -avahi -bindist -cups -debug -doc -fam -kdehiddenvisibility -kerberos -legacyssl -lua -openexr
-utempter"

Re: KDE-Sunset : kdelibs problem [ In reply to ]

purslow at ca

Oct 30, 2012, 5:06 AM

Post #5 of 8 (3341 views)

Permalink

121029 E. Liddell wrote:
> The following USE flags allow kdelibs to compile successfully for me:
> [ebuild R ~] kde-base/kdelibs-3.5.10-r10::kde-sunset USE="acl alsa branding jpeg2k spell tiff -arts -avahi -bindist -cups -debug -doc -fam -kdehiddenvisibility -kerberos -legacyssl -lua -openexr -utempter"

What I get is :

root:519 ~> USE="acl alsa branding jpeg2k spell tiff -arts -avahi -bindist -cups -debug -doc -fam -kdehiddenvisibility -kerberos -legacyssl -lua -openexr -utempter" emerge -pv =kde-base/kdelibs-3.5.10-r10

These are the packages that would be merged, in order:
Calculating dependencies... done!

emerge: there are no ebuilds to satisfy "net-misc/mDNSResponder".
(dependency required by "kde-base/kdelibs-3.5.10-r10[-bindist,-avahi]" [ebuild])
(dependency required by "=kde-base/kdelibs-3.5.10-r10" [argument])

How do you manage to get away with "-avahi" ?

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Re: KDE-Sunset : kdelibs problem [ In reply to ]

ejlddll at googlemail

Oct 30, 2012, 2:23 PM

Post #6 of 8 (3364 views)

Permalink

On Tue, 30 Oct 2012 08:06:03 -0400
Philip Webb <purslow@ca.inter.net> wrote:

> 121029 E. Liddell wrote:
> > The following USE flags allow kdelibs to compile successfully for me:
> > [ebuild R ~] kde-base/kdelibs-3.5.10-r10::kde-sunset USE="acl alsa branding jpeg2k spell tiff -arts -avahi -bindist -cups -debug -doc -fam -kdehiddenvisibility -kerberos -legacyssl -lua -openexr -utempter"
>
> What I get is :
>
> root:519 ~> USE="acl alsa branding jpeg2k spell tiff -arts -avahi -bindist -cups -debug -doc -fam -kdehiddenvisibility -kerberos -legacyssl -lua -openexr -utempter" emerge -pv =kde-base/kdelibs-3.5.10-r10
>
> These are the packages that would be merged, in order:
> Calculating dependencies... done!
>
> emerge: there are no ebuilds to satisfy "net-misc/mDNSResponder".
> (dependency required by "kde-base/kdelibs-3.5.10-r10[-bindist,-avahi]" [ebuild])
> (dependency required by "=kde-base/kdelibs-3.5.10-r10" [argument])
>
> How do you manage to get away with "-avahi" ?

A-*ha*.

It looks like mDNSResponder was lastrited out of the main Portage tree only
three months ago. Presumably I "got away" with -avahi because I had
mDNSResponder installed previous to its removal from the Portage tree,
so it exists on my system as a sort of phantom (Portage knows it's installed
and can link stuff to it, but there's no associated ebuild).

mDNSResponder ebuilds should be obtainable from
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/mDNSResponder/?hideattic=0

As the changelog indicates that the last tweak to this package was ~6 months
ago, I would expect it to still compile.

If anyone from kde-sunset is still reading this thread, I would suggest adopting
this package into the overlay.

Re: KDE-Sunset : kdelibs problem [ In reply to ]

purslow at ca

Oct 30, 2012, 5:14 PM

Post #7 of 8 (3340 views)

Permalink

121030 E. Liddell wrote:
> mDNSResponder ebuilds should be obtainable from
> http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/mDNSResponder/?hideattic=0

OK, next problem : I copied all the stuff into net-misc/mDNSResponder/ ,
but the ebuilds are 7 bytes longer than the size in the Manifest
& of course if I edit that file, the checksums are incorrect.

I'm willing to pursue this if you have further suggestions,
but it looks like a very temporary fix,
which will fail again with some further change in other Gentoo pkgs.
The future has to be Trinity -- if there is one -- ,
so what's really needed is a Trinity overlay for Gentoo.

--
========================,,============================================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

Re: KDE-Sunset : kdelibs problem [ In reply to ]

wired at gentoo

Oct 30, 2012, 5:34 PM

Post #8 of 8 (3344 views)

Permalink

On Oct 31, 2012 2:17 AM, "Philip Webb" <purslow@ca.inter.net> wrote:
>
> 121030 E. Liddell wrote:
> > mDNSResponder ebuilds should be obtainable from
> >
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/mDNSResponder/?hideattic=0
>
> OK, next problem : I copied all the stuff into net-misc/mDNSResponder/ ,
> but the ebuilds are 7 bytes longer than the size in the Manifest
> & of course if I edit that file, the checksums are incorrect.

Run "repoman manifest" in net-misc/mDNSResponder/ :)

Alex | wired