[gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[lin pro]

Hi,
Here is an attempt to complete a minimal stage4 with catalyst.
There is only one package in the spec file for stage4:
media-sound/ardour

catalyst terminates with this message:

checking for msgfmt... /usr/bin/msgfmt
checking for gmsgfmt... /usr/bin/gmsgfmt
checking for perl... /usr/bin/perl
checking for perl >= 5.8.1... 5.16.3
checking for XML::Parser... configure: error: XML::Parser perl module
is required for intltool
!!! Please attach the following file when seeking support:
!!! /var/tmp/portage/gnome-base/libgnomecanvas-2.30.3/work/libgnomecanvas-2.30.3/config.log
 * ERROR: gnome-base/libgnomecanvas-2.30.3::gentoo failed (configure phase):
 *   econf failed

Ok, then one more package is added to the stage4/packages list:

stage4/packages:
    dev-perl/XML-Parser
    media-sound/ardour


and the error is the same.
I understand that I am in a chroot environment after catalyst is
launched. Should I manually chroot there and try to fix stuff, or is
there something in the spec that I could do?

Ben


-- 
best regards
linforpros

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 474 bytes --]

On Friday 27 December 2013 21:11:44 lin pro wrote:
> checking for XML::Parser... configure: error: XML::Parser perl module
> is required for intltool

most likely the perl module is installed, but broken.  it needs to be rebuilt.

look at the config.log file the log referred you to to see the exact error:

> !!! Please attach the following file when seeking support:
> !!!
> /var/tmp/portage/gnome-base/libgnomecanvas-2.30.3/work/libgnomecanvas-2.30
> .3/config.log
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 626 bytes --]

On Fri, Dec 27, 2013 at 08:11:44PM -0600, lin pro wrote:
> checking for XML::Parser... configure: error: XML::Parser perl module
> is required for intltool

That's odd, it looks like dev-perl/XML-Parser *is* listed as a DEPEND
in dev-util/intltool-0.50.2-r1, which would mean it should have been
pulled in before packages using intltool are built.  You might want to
post the whole Catalyst log to give us a better feel for what's going
on.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 887 bytes --]

On Fri, 2013-12-27 at 21:37 -0500, Mike Frysinger wrote:
> On Friday 27 December 2013 21:11:44 lin pro wrote:
> > checking for XML::Parser... configure: error: XML::Parser perl module
> > is required for intltool
> 
> most likely the perl module is installed, but broken.  it needs to be rebuilt.
> 
> look at the config.log file the log referred you to to see the exact error:
> 
> > !!! Please attach the following file when seeking support:
> > !!!
> > /var/tmp/portage/gnome-base/libgnomecanvas-2.30.3/work/libgnomecanvas-2.30
> > .3/config.log
> -mike

This exact breakage has been coming up in gentoo systems for the last
few weeks.  There was a perl upgrade or many that broke it.  Running
perl-cleaner --reallyall fixes it.

I don't know if catalyst can do that or not and whether it can detect it
to run perl-cleaner.
-- 
Brian Dolbec <dolsen@gentoo.org>

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 2042 bytes --]

On Saturday 28 December 2013 01:11:08 Brian Dolbec wrote:
> On Fri, 2013-12-27 at 21:37 -0500, Mike Frysinger wrote:
> > On Friday 27 December 2013 21:11:44 lin pro wrote:
> > > checking for XML::Parser... configure: error: XML::Parser perl module
> > > is required for intltool
> > 
> > most likely the perl module is installed, but broken.  it needs to be
> > rebuilt.
> > 
> > look at the config.log file the log referred you to to see the exact error:
> > > !!! Please attach the following file when seeking support:
> > > !!!
> > > /var/tmp/portage/gnome-base/libgnomecanvas-2.30.3/work/libgnomecanvas-2
> > > .30 .3/config.log
> 
> This exact breakage has been coming up in gentoo systems for the last
> few weeks.  There was a perl upgrade or many that broke it.  Running
> perl-cleaner --reallyall fixes it.
> 
> I don't know if catalyst can do that or not and whether it can detect it
> to run perl-cleaner.

catalyst certainly could grow code for handling perl-cleaner & friends.  but 
i'm not sure if it makes sense.  if stage3->stage4 is seeing a perl upgrade, 
then it could be via different routes:
 - your stage3 is outdated; solution: upgrade your stage3 to a recent one
 - you're manually forcing a perl upgrade by modifying the list of accepted 
keywords (either KEYOWRDS or package.keywords or something else)
 - i don't think this comes up in the stage1->stage2->stage3 transition due to 
how those each occur (a fresh ROOT build and then chroot and upgrade and such)

this second one is a reasonable use case, but detecting & supporting it might 
be kind of pain w/out deploying specific checks.  like doing a pretend emerge 
and analyzing the resulting list of upgrades.  is a perl upgrade found ?  if 
so, manually upgrade perl, then run perl-cleaner, then move on to the next 
step.  is a python upgrade found ?  if so, manually upgrade python, then run 
python-cleaner, then move on to the next step.  all various upgrades run ?  do 
a general @world/@system update then.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[W. Trevor King]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Sat, Dec 28, 2013 at 06:54:28AM -0500, Mike Frysinger wrote:
> On Saturday 28 December 2013 01:11:08 Brian Dolbec wrote:
> > I don't know if catalyst can do that or not and whether it can
> > detect it to run perl-cleaner.
> 
> catalyst certainly could grow code for handling perl-cleaner &
> friends.

This sounds like a job for Portage and @preserved-rebuild ;).  It has
already absorbed revdep-rebuild.  Hopefully absorbing perl-cleaner,
python-updater, and similar is just a matter of time :p.

Cheers,
Trevor

-- 
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[Brian Dolbec]

[-- Attachment #1: Type: text/plain, Size: 1687 bytes --]

On Sat, 2013-12-28 at 08:05 -0800, W. Trevor King wrote:
> On Sat, Dec 28, 2013 at 06:54:28AM -0500, Mike Frysinger wrote:
> > On Saturday 28 December 2013 01:11:08 Brian Dolbec wrote:
> > > I don't know if catalyst can do that or not and whether it can
> > > detect it to run perl-cleaner.
> > 
> > catalyst certainly could grow code for handling perl-cleaner &
> > friends.
> 
> This sounds like a job for Portage and @preserved-rebuild ;).  It has
> already absorbed revdep-rebuild.  Hopefully absorbing perl-cleaner,
> python-updater, and similar is just a matter of time :p.
> 
> Cheers,
> Trevor
> 

No, it didn't absorb revdep-rebuild.  It just does early (live)
detection.

Actually, with the new python version of revdep-rebuild, there was talk
of it absorbing python-updater and perl-cleaner (also coded in python)
as part of it's normal revdep call.  Then it would be a one stop call.

Actually, I think in this case. the original error would have been
avoided if the user had used the same snapshot for all stages of the
build.  stage1 through livecd-*.  I believe he/she just grabbed a stage3
and a current tree snapshot.

We could however change catalyst to accept a stage3 and perform an
update, perl-cleaner, python-updater, revdep-rebuild,... before
commencing with the build process, but I feel that is a step better done
by hand.  It would also need to wait for catalyst to move to using
emerge/portage through the api.  From there it could get the list of
atoms to be updated and handle any calls on an as needed basis to
perl-cleaner, etc..  That would also require me to complete the
public_api work I was doing for portage.   

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 620 bytes --]

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[lin pro]

Hi,
Here is the progress report on the error.
After having read all your answers I did the following:

catalyst -s 20131229

grabbed a new stage3 dated 20131226 from a gentoo mirror

and then:
1. rebuilt a new stage1 based on the seed stage above
2. rebuild a new stage2 based ong the stage1 above
3 rebuilt a new stage3 based on the stage2 above

and now the stage4 stops at the same libgnomecanvas package.
 http://bpaste.net/show/162890/

The spec for stage4 is as follows:
 http://bpaste.net/show/162892/

any help would be greately appreciated
Thank you very much
Ben

-- 
best regards
linforpros

Re: [gentoo-catalyst] how to tell catalyst to resolve dependency, dev-perl/xml-parser

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 244 bytes --]

On Sunday 29 December 2013 19:12:48 lin pro wrote:
> and now the stage4 stops at the same libgnomecanvas package.
>  http://bpaste.net/show/162890/

again, the config.log is necessary

is that the full stage4 log ?  seems a little short.
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]