[gentoo-user] cups-filters failing to build

[gentoo-user] cups-filters failing to build

[Alec Ten Harmsel]

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

Hey guys,

I've been having a really strange issue with net-print/cups-filters for
the last few weeks, wondering whether or not it's a bug or I just have
something configured wrong. Somehow ${S} is defined as:

    /var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10

and the build predictably fails. Normally this wouldn't bother me (I
don't use cups at all), except that cups is a build-time dependency for
dev-java/icedtea.

Build log and output of `emerge --info` attached.

Regards,

Alec

[-- Attachment #2: build.log --]
[-- Type: text/plain, Size: 3283 bytes --]

^[[32;01m * ^[[39;49;00mPackage:    net-print/cups-filters-1.0.53
^[[32;01m * ^[[39;49;00mRepository: gentoo
^[[32;01m * ^[[39;49;00mMaintainer: printing@gentoo.org
^[[32;01m * ^[[39;49;00mUSE:        abi_x86_64 amd64 dbus elibc_glibc foomatic kernel_linux userland_GNU
^[[32;01m * ^[[39;49;00mFEATURES:   preserve-libs sandbox userpriv usersandbox
^[[32;01m * ^[[39;49;00mPackage:    net-print/cups-filters-1.0.53
^[[32;01m * ^[[39;49;00mRepository: gentoo
^[[32;01m * ^[[39;49;00mMaintainer: printing@gentoo.org
^[[32;01m * ^[[39;49;00mUSE:        abi_x86_64 amd64 dbus elibc_glibc foomatic kernel_linux userland_GNU
^[[32;01m * ^[[39;49;00mFEATURES:   preserve-libs sandbox userpriv usersandbox
>>> Unpacking source...
>>> Unpacking cups-filters-1.0.53.tar.xz to /var/tmp/portage/net-print/cups-filters-1.0.53/work
>>> Source unpacked in /var/tmp/portage/net-print/cups-filters-1.0.53/work
 ^[[31;01m*^[[0m ERROR: net-print/cups-filters-1.0.53::gentoo failed (prepare phase):
 ^[[31;01m*^[[0m   The source directory '/var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10' doesn't exist
 ^[[31;01m*^[[0m 
 ^[[31;01m*^[[0m Call stack:
 ^[[31;01m*^[[0m            ebuild.sh, line 714:  Called __ebuild_main 'prepare'
 ^[[31;01m*^[[0m   phase-functions.sh, line 955:  Called __dyn_prepare
 ^[[31;01m*^[[0m   phase-functions.sh, line 369:  Called die
 ^[[31;01m*^[[0m The specific snippet of code:
 ^[[31;01m*^[[0m   		die "The source directory '${S}' doesn't exist"
 ^[[31;01m*^[[0m 
 ^[[31;01m*^[[0m If you need support, post the output of `emerge --info '=net-print/cups-filters-1.0.53::gentoo'`,
 ^[[31;01m*^[[0m the complete build log and the output of `emerge -pqv '=net-print/cups-filters-1.0.53::gentoo'`.
 ^[[31;01m*^[[0m The complete build log is located at '/var/tmp/portage/net-print/cups-filters-1.0.53/temp/build.log'.
 ^[[31;01m*^[[0m The ebuild environment file is located at '/var/tmp/portage/net-print/cups-filters-1.0.53/temp/environment'.
 ^[[31;01m*^[[0m Working directory: '/usr/lib64/portage/pym'
 ^[[31;01m*^[[0m S: '/var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10'
 ^[[31;01m*^[[0m ERROR: net-print/cups-filters-1.0.53::gentoo failed (prepare phase):
 ^[[31;01m*^[[0m   The source directory '/var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10' doesn't exist
 ^[[31;01m*^[[0m 
 ^[[31;01m*^[[0m Call stack:
 ^[[31;01m*^[[0m            ebuild.sh, line 714:  Called __ebuild_main 'prepare'
 ^[[31;01m*^[[0m   phase-functions.sh, line 955:  Called __dyn_prepare
 ^[[31;01m*^[[0m   phase-functions.sh, line 369:  Called die
 ^[[31;01m*^[[0m The specific snippet of code:
 ^[[31;01m*^[[0m   		die "The source directory '${S}' doesn't exist"
 ^[[31;01m*^[[0m 
 ^[[31;01m*^[[0m If you need support, post the output of `emerge --info '=net-print/cups-filters-1.0.53::gentoo'`,
 ^[[31;01m*^[[0m the complete build log and the output of `emerge -pqv '=net-print/cups-filters-1.0.53::gentoo'`.
 ^[[31;01m*^[[0m The complete build log is located at '/var/tmp/portage/net-print/cups-filters-1.0.53/temp/build.log'.
 ^[[31;01m*^[[0m The ebuild environment file is located at '/var/tmp/portage/net-print/cups-filters-1.0.53/temp/environment'.
 ^[[31;01m*^[[0m Working directory: '/usr/lib64/portage/pym'
 ^[[31;01m*^[[0m S: '/var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10'

[-- Attachment #3: emerge.info --]
[-- Type: application/x-info, Size: 4682 bytes --]

[gentoo-user] Re: cups-filters failing to build

[walt]

On 11/24/2014 02:24 PM, Alec Ten Harmsel wrote:
> Hey guys,
> 
> I've been having a really strange issue with net-print/cups-filters for
> the last few weeks, wondering whether or not it's a bug or I just have
> something configured wrong. Somehow ${S} is defined as:
> 
>     /var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10

You're right.  That is a *really* strange error :)  Where did that 3.2.10 come
from?  I can't reproduce the same error here so I can only guess.  Have you
tried grepping for 3.2.10 in /var/tmp/portage/net-print/ ?

Running emerge with the -d flag can sometimes shed some light.  More light than
you probably want :)

> and the build predictably fails. Normally this wouldn't bother me (I
> don't use cups at all), except that cups is a build-time dependency for
> dev-java/icedtea.

I see there is a cups USEFLAG for icedtea.  Could you unset that flag for
icedtea as a workaround?

A question of my own:  the ebuilds for icedtea list the cups flag as +cups.
So far I haven't discovered a man page that explains the + prefix.  Is there
such a man page?

Re: [gentoo-user] Re: cups-filters failing to build

[wraeth]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 25/11/14 12:26, walt wrote:
> A question of my own:  the ebuilds for icedtea list the cups flag
> as +cups. So far I haven't discovered a man page that explains the
> + prefix.  Is there such a man page?

I just had a look through the man pages of emerge, portage and ebuild,
plus at the Gentoo Devmanual and couldn't find anything; however I'm
reasonably certain that in the context of an ebuild, a use flag
defined as "+flag" means that it is defaulted to enabled by the ebuild.

- -- 
wraeth <wraeth@wraeth.id.au>
GnuPG Key: B2D9F759
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iF4EAREIAAYFAlRz3N4ACgkQXcRKerLZ91kGugD+Kw/CZZ5wOV7xmRnqmU3HBhfi
A7I5SYFxNMY+2NXJiDgA/iP5AFhnber9k0mqGM1egNAQqoG9mrh0CruNpzFwP70H
=ihGQ
-----END PGP SIGNATURE-----

Re: [gentoo-user] Re: cups-filters failing to build

[Alec Ten Harmsel]

On 11/24/2014 08:35 PM, wraeth wrote:
> On 25/11/14 12:26, walt wrote:
> > A question of my own:  the ebuilds for icedtea list the cups flag
> > as +cups. So far I haven't discovered a man page that explains the
> > + prefix.  Is there such a man page?
>
> I just had a look through the man pages of emerge, portage and ebuild,
> plus at the Gentoo Devmanual and couldn't find anything; however I'm
> reasonably certain that in the context of an ebuild, a use flag
> defined as "+flag" means that it is defaulted to enabled by the ebuild.
>

Yes, this is correct.

> Running emerge with the -d flag can sometimes shed some light.  More light than
> you probably want 

I'll get right on this. Didn't know about (or forgot about) -d.

> I see there is a cups USEFLAG for icedtea.  Could you unset that flag for
> icedtea as a workaround?


icedtea is weird - according to equery, +cups makes cups a build-time
only dependency, instead a build *and* runtime dependency.

Also, I just installed with and without '-d', and it now works. So I
guess this has been solved, but it's still strange. It might be that I
installed just cups-filters with --oneshot, but who knows.

Alec

Re: [gentoo-user] Re: cups-filters failing to build

[Neil Bothwick]

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

On Tue, 25 Nov 2014 12:35:26 +1100, wraeth wrote:

> I just had a look through the man pages of emerge, portage and ebuild,
> plus at the Gentoo Devmanual and couldn't find anything; however I'm
> reasonably certain that in the context of an ebuild, a use flag
> defined as "+flag" means that it is defaulted to enabled by the ebuild.

It's documented in the ebuild man page - man 5 ebuild.


-- 
Neil Bothwick

Walking on water and writing software to specification is easy if they're
frozen.

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

Re: [gentoo-user] cups-filters failing to build

[Andreas K. Huettel]

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


Hi Alec,

> I've been having a really strange issue with net-print/cups-filters for
> the last few weeks, wondering whether or not it's a bug or I just have
> something configured wrong. Somehow ${S} is defined as:
> 
>     /var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10
> 
> and the build predictably fails.

this is a really weird error. 

The only idea that I have is that some unusual environment variable is set 
outside Portage, and then somehow leaks into the Portage internals. 

You could check (before running emerge) if you see the "3.2.10" anywhere in 
your environment ("set|less")... or if maybe $PV or $S is set outside emerge 
somewhere.

If this doesnt go away, we can ask the portage guys for advice.

Best,
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

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

Re: [gentoo-user] cups-filters failing to build

[Alec Ten Harmsel]

On 11/25/2014 04:49 AM, Andreas K. Huettel wrote:
> Hi Alec,
>
>> I've been having a really strange issue with net-print/cups-filters for
>> the last few weeks, wondering whether or not it's a bug or I just have
>> something configured wrong. Somehow ${S} is defined as:
>>
>>     /var/tmp/portage/net-print/cups-filters-1.0.53/work/cups-filters-3.2.10
>>
>> and the build predictably fails.
> this is a really weird error. 
>
> The only idea that I have is that some unusual environment variable is set 
> outside Portage, and then somehow leaks into the Portage internals. 
>
> You could check (before running emerge) if you see the "3.2.10" anywhere in 
> your environment ("set|less")... or if maybe $PV or $S is set outside emerge 
> somewhere.

Wow, incredible. I never thought to check my environment, but these:

    MODULE_VERSION=3.2.10
    MODULE_VERSION_STACK=3.2.10

could be a problem? Both of these variables are for the modules
environment management package, which I use to manage switching between
ruby interpreters.

> If this doesnt go away, we can ask the portage guys for advice.
>
> Best,
> Andreas
>

This was also affecting dev-libs/stfl for me; unsetting MODULE_VERSION
causes this to succeed. The only eclasses they have in common are
"eutils" and "perl-module", if that's important.

Andreas, if this is a bug that needs fixing, let me know who to contact
get this dealt with.

Regards,

Alec

Re: Re: [gentoo-user] cups-filters failing to build

[Andreas K. Huettel]

> > You could check (before running emerge) if you see the "3.2.10" anywhere
> > in
> > your environment ("set|less")... or if maybe $PV or $S is set outside
> > emerge somewhere.
> 
> Wow, incredible. I never thought to check my environment, but these:
> 
>     MODULE_VERSION=3.2.10
>     MODULE_VERSION_STACK=3.2.10
> 

:)

Yes. It's MODULE_VERSION, which is used in perl-module.eclass. 

> This was also affecting dev-libs/stfl for me; unsetting MODULE_VERSION
> causes this to succeed.

It can in principle affect many things inheriting perl-module.eclass, I'll 
check later what these two do different.

The best workaround is probably to make a short script wrapper for emerge that 
unsets the variables and then calls real emerge. A real fix would be to rename 
the variable in the eclass, but that would mean fixing 1800 ebuilds...

> Andreas, if this is a bug that needs fixing, let me know who to contact
> get this dealt with.

I'm probably the best address myself, but there is no easy solution. I'll 
think about it.

Cheers, 
Andreas

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council

Re: [gentoo-user] cups-filters failing to build

[Alec Ten Harmsel]

On 11/25/2014 10:41 AM, Andreas K. Huettel wrote:
>>> You could check (before running emerge) if you see the "3.2.10" anywhere
>>> in
>>> your environment ("set|less")... or if maybe $PV or $S is set outside
>>> emerge somewhere.
>> Wow, incredible. I never thought to check my environment, but these:
>>
>>     MODULE_VERSION=3.2.10
>>     MODULE_VERSION_STACK=3.2.10
>>
> :)
>
> Yes. It's MODULE_VERSION, which is used in perl-module.eclass. 
>
>> This was also affecting dev-libs/stfl for me; unsetting MODULE_VERSION
>> causes this to succeed.
> It can in principle affect many things inheriting perl-module.eclass, I'll 
> check later what these two do different.
>
> The best workaround is probably to make a short script wrapper for emerge that 
> unsets the variables and then calls real emerge. A real fix would be to rename 
> the variable in the eclass, but that would mean fixing 1800 ebuilds...
>

Yes, I will just remember to do this every time I update. Not a problem.

>> Andreas, if this is a bug that needs fixing, let me know who to contact
>> get this dealt with.
> I'm probably the best address myself, but there is no easy solution. I'll 
> think about it.
>
> Cheers, 
> Andreas
>

Don't worry about it too much; modules is a pretty exotic package,
mostly used in super-computing sites afaik. I am just wondering, though,
why aren't all internal variables prefixed with PORTAGE_ or the like to
prevent this sort of thing?

Thank you for the help,

Alec

Re: Re: [gentoo-user] cups-filters failing to build

[Andreas K. Huettel]

Am Dienstag 25 November 2014, 12:56:00 schrieb Alec Ten Harmsel:

> I am just wondering, though,
> why aren't all internal variables prefixed with PORTAGE_ or the like to
> prevent this sort of thing?
> 

it's not really internal, just defined in an eclass... and these are regular 
environment variables. if the eclass does not keep a naming scheme...

-- 
Andreas K. Huettel
Gentoo Linux developer
kde, council