[gentoo-user] local overlay problem

[gentoo-user] local overlay problem

[Philip Webb]

Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound;
this is still the case with USE="-alsa".

I want to test what happens if I try to compile it without that dep,
so I copied the ebuild to /var/lib/layman/local/www-client/firefox/ 
& commented the relevant line to remove the RDEPEND.
When I then tried 'ebuild <newpkgname>...ebuild manifest',
it started to download xillions of little .xpi files into  distfiles ,
apparently  1  for each of the World's many languages
(this didn't happen at my last 'eix-sync').

Can anyone suggest a way to avoid this problem ?

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

Re: [gentoo-user] local overlay problem

[Dustin C. Hatch]

On 1/31/2013 20:41, Philip Webb wrote:
> Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound;
> this is still the case with USE="-alsa".
>
> I want to test what happens if I try to compile it without that dep,
> so I copied the ebuild to /var/lib/layman/local/www-client/firefox/
> & commented the relevant line to remove the RDEPEND.
> When I then tried 'ebuild <newpkgname>...ebuild manifest',
> it started to download xillions of little .xpi files into  distfiles ,
> apparently  1  for each of the World's many languages
> (this didn't happen at my last 'eix-sync').
>
> Can anyone suggest a way to avoid this problem ?
>
It's downloading those files so it can recalculate the file hashes. When 
running `ebuild <file> digest`, it has to have all possible files 
available in order to update the Manifest file.

Those languages won't be installed when you actually install your 
modified package. You'll probably want to keep them around until you're 
finished making changes, though.

-- 
♫Dustin

Re: [gentoo-user] local overlay problem

[Philip Webb]

130131 Dustin C. Hatch wrote:
> On 1/31/2013 20:41, Philip Webb wrote:
>> Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound;
>> this is still the case with USE="-alsa".
>> I want to test what happens if I try to compile it without that dep,
>> so I copied the ebuild to /var/lib/layman/local/www-client/firefox/
>> & commented the relevant line to remove the RDEPEND.
>> When I then tried 'ebuild <newpkgname>...ebuild manifest',
>> it started to download xillions of little .xpi files into  distfiles ,
>> apparently  1  for each of the World's many languages
>> (this didn't happen at my last 'eix-sync').
> It's downloading those files so it can recalculate the file hashes.

That's what I suspected (smile).

> When running `ebuild <file> digest`, it has to have
> all possible files available in order to update the Manifest file.
> Those languages won't be installed when you actually install
> your modified package. You'll probably want to keep them around
> until you're finished making changes, though.

Why doesn't this happen when I do my weekly 'eix-sync' ?
Perhaps it silently downloads them, then deletes them again,
or perhaps it simply downloads the Manifest on those occasions,
but has to calculate it specially for the non-Portage overlay.

I'll give it another try, but suggestions are still welcome.
Thanks for this one.

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

Re: [gentoo-user] local overlay problem

[Yohan Pereira]

On 31/01/13 at 11:38pm, Philip Webb wrote:
> I'll give it another try, but suggestions are still welcome.
> Thanks for this one.

Maybe you can try adding alsa-lib to package.provided and see if it
builds/works?  
 

-- 

- Yohan Pereira

The difference between a Miracle and a Fact is exactly the difference
between a mermaid and a seal.
                -- Mark Twain

Re: [gentoo-user] local overlay problem

[Alan McKinnon]

On Thu, 31 Jan 2013 23:38:27 -0500
Philip Webb <purslow@ca.inter.net> wrote:

> > When running `ebuild <file> digest`, it has to have
> > all possible files available in order to update the Manifest file.
> > Those languages won't be installed when you actually install
> > your modified package. You'll probably want to keep them around
> > until you're finished making changes, though.  
> 
> Why doesn't this happen when I do my weekly 'eix-sync' ?
> Perhaps it silently downloads them, then deletes them again,
> or perhaps it simply downloads the Manifest on those occasions,
> but has to calculate it specially for the non-Portage overlay.

The Manifest was already calculated by the dev for all those little
files in the original, so portage didn't need to redo it.

The only file you changed is the ebuild itself. So copy the manifest
over from the original, delete the line for the ebuild and run digest
again.



-- 
Alan McKinnon
alan.mckinnon@gmail.com

Re: [gentoo-user] local overlay problem

[Michael Hampicke]

Am 01.02.2013 03:41, schrieb Philip Webb:
> Firefox 17.0.2 requires alsa-lib , which I don't want as I don't use sound;
> this is still the case with USE="-alsa".
> 
> I want to test what happens if I try to compile it without that dep,
> so I copied the ebuild to /var/lib/layman/local/www-client/firefox/ 
> & commented the relevant line to remove the RDEPEND.
> When I then tried 'ebuild <newpkgname>...ebuild manifest',
> it started to download xillions of little .xpi files into  distfiles ,
> apparently  1  for each of the World's many languages
> (this didn't happen at my last 'eix-sync').

What about not using the local overlay and simply do emerge --nodeps
firefox and see what happens? I know, crude.... but simple :)

Re: [gentoo-user] local overlay problem

[Neil Bothwick]

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

On Fri, 01 Feb 2013 10:07:24 +0100, Michael Hampicke wrote:

> What about not using the local overlay and simply do emerge --nodeps
> firefox and see what happens? I know, crude.... but simple :)

Because every emerge @world will want to install ALSA.

You may find it will not compile without alsa-lib being present, you could
try moving the dep from RDEPEND to DEPEND, then you can remove alsa-lib
once the emerge has completed.

BTW, /var/lib/layman is for layman-managed overlays, local overlays are
best kept separate.


-- 
Neil Bothwick

Don't count the days, make the days count.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] local overlay problem

[Dale]

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

Neil Bothwick wrote:
> On Fri, 01 Feb 2013 10:07:24 +0100, Michael Hampicke wrote:
>
>> What about not using the local overlay and simply do emerge --nodeps
>> firefox and see what happens? I know, crude.... but simple :)
>
> Because every emerge @world will want to install ALSA.
>
> <<<SNIP>>>
>

Don't add it to the world file then, just upgrade it manually each
time.  Maybe at some point, there will be a way to install it the way
the OP wants it, no sound.

I wonder if a bug report would help on this?

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 1128 bytes --]

Re: [gentoo-user] local overlay problem

[Neil Bothwick]

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

On Fri, 01 Feb 2013 04:42:38 -0600, Dale wrote:

> >> What about not using the local overlay and simply do emerge --nodeps
> >> firefox and see what happens? I know, crude.... but simple :)  
> >
> > Because every emerge @world will want to install ALSA.

> Don't add it to the world file then, just upgrade it manually each
> time.

Then portage will want to depclean it. It is always best to try to use
the methods portage provides instead of trying to be clever than it.


-- 
Neil Bothwick

Did you know that eskimos have 17 different words for linguist?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] local overlay problem

[Dale]

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

Neil Bothwick wrote:
> On Fri, 01 Feb 2013 04:42:38 -0600, Dale wrote:
>
>>>> What about not using the local overlay and simply do emerge --nodeps
>>>> firefox and see what happens? I know, crude.... but simple :)
>>>
>>> Because every emerge @world will want to install ALSA.
>
>> Don't add it to the world file then, just upgrade it manually each
>> time.
>
> Then portage will want to depclean it. It is always best to try to use
> the methods portage provides instead of trying to be clever than it.
>
>


When you start working AROUND portage with one thing, then you have to
work AROUND portage with a lot of things.  This would include depclean. 
Run depclean with -p and remove packages manually.  If that is to much
trouble, let depclean remove it and just emerge -k the package again
after depclean is done.

I'm not saying either of us is wrong, I'm just saying that when you try
to override portage, you have to deal with the issues that creates. 
Either way will work but nether way is going to be easy in the long
run.  Either way, portage is going to want to fix whatever it thinks is
broken, even if it is not.  Every time there is a update, time to fix
the ebuild again. Pick a poison and swallow hard.  lol 

I think the best way is to talk to the dev that maintains it and find
out of he can make sound a option.  If a person does not have a system
capable of sound, why have it built in anyway.  I can certainly see that
as I have had systems in the past that had no sound.  Then again, there
is the mute option.  ;-)

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 2387 bytes --]

Re: [gentoo-user] local overlay problem

[Michael Hampicke]

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

2013/2/1 Neil Bothwick <neil@digimed.co.uk>

> On Fri, 01 Feb 2013 10:07:24 +0100, Michael Hampicke wrote:
>
> > What about not using the local overlay and simply do emerge --nodeps
> > firefox and see what happens? I know, crude.... but simple :)
>
> Because every emerge @world will want to install ALSA.
>
> You may find it will not compile without alsa-lib being present, you could
> try moving the dep from RDEPEND to DEPEND, then you can remove alsa-lib
> once the emerge has completed.
>
> BTW, /var/lib/layman is for layman-managed overlays, local overlays are
> best kept separate.


I understand that, but Philip wrote that he wanted to find out if he could
compile ff without alsa-lib beeing present. To just test this case, emerge
--nodeps ff is perfect. If he finds out that ff would infact compile
without alsa-lib, he could open a bug rebort at b.g.o to make alsa-lib
optional. (or for that matter, create a patched ebuild in his local overlay)

[-- Attachment #2: Type: text/html, Size: 1278 bytes --]

Re: [gentoo-user] local overlay problem

[Neil Bothwick]

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

On Fri, 01 Feb 2013 05:35:06 -0600, Dale wrote:

> >> Don't add it to the world file then, just upgrade it manually each
> >> time.  
> >
> > Then portage will want to depclean it. It is always best to try to use
> > the methods portage provides instead of trying to be clever than it.

> When you start working AROUND portage with one thing, then you have to
> work AROUND portage with a lot of things.  This would include depclean. 

Which is why I think you shouldn't try to work around portage. It
provides a clean way of doing this, overlays, use them.


-- 
Neil Bothwick

The sooner you fall behind the more time you'll have to catch up.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] local overlay problem

[Dale]

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

Neil Bothwick wrote:
> On Fri, 01 Feb 2013 05:35:06 -0600, Dale wrote:
>
>>>> Don't add it to the world file then, just upgrade it manually each
>>>> time.
>>>
>>> Then portage will want to depclean it. It is always best to try to use
>>> the methods portage provides instead of trying to be clever than it.
>
>> When you start working AROUND portage with one thing, then you have to
>> work AROUND portage with a lot of things. This would include depclean.
>
> Which is why I think you shouldn't try to work around portage. It
> provides a clean way of doing this, overlays, use them.
>
>

Then you have to update those too.  As I said, either way in the long
term, you have to work at overriding portage defaults.  Both ways will
give the same result, both ways require work.  The best thing is what I
mentioned and someone else mentioned, talk to the dev and ask if it can
be a option instead of a requirement.  That would fix the whole thing
maybe even for others too.

Lots of options.  OP just needs to pick whatever will work for him. 
After all, it will be him working on this not us.  ;-)

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 1884 bytes --]

Re: [gentoo-user] local overlay problem

[Neil Bothwick]

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

On Fri, 01 Feb 2013 06:59:43 -0600, Dale wrote:

> >> work AROUND portage with a lot of things. This would include
> >> depclean.  
> >
> > Which is why I think you shouldn't try to work around portage. It
> > provides a clean way of doing this, overlays, use them.

> Then you have to update those too.  As I said, either way in the long
> term, you have to work at overriding portage defaults.

But an overlay is working with portage, the other options are trying to
trick it.

> Both ways will
> give the same result, both ways require work.  The best thing is what I
> mentioned and someone else mentioned, talk to the dev and ask if it can
> be a option instead of a requirement.  That would fix the whole thing
> maybe even for others too.

Agreed, we don't even know if it is possible to compile Firefox without
alsa-lib. However, devs help those who help themselves, providing a
modified ebuild that works, even partially, is more likely to get a
resolution in the tree.

The other option is to file a bug. Why is alsa in IUSE if the ebuild
depends on alsa-lib either way?


-- 
Neil Bothwick

We can sympathize with a child who is afraid of the dark, but the
tragedy of life is that most people are afraid of the light.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] local overlay problem

[Dale]

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

Neil Bothwick wrote:
> On Fri, 01 Feb 2013 06:59:43 -0600, Dale wrote:
>
>>>> work AROUND portage with a lot of things. This would include
>>>> depclean.
>>>
>>> Which is why I think you shouldn't try to work around portage. It
>>> provides a clean way of doing this, overlays, use them.
>
>> Then you have to update those too. As I said, either way in the long
>> term, you have to work at overriding portage defaults.
>
> But an overlay is working with portage, the other options are trying to
> trick it.

I'm not saying it is.  I'm saying that the OP would then have to
maintain the overlay which requires work.  Depending on his skills, he
may not REALLY want to do that.

>
>
>> Both ways will
>> give the same result, both ways require work. The best thing is what I
>> mentioned and someone else mentioned, talk to the dev and ask if it can
>> be a option instead of a requirement. That would fix the whole thing
>> maybe even for others too.
>
> Agreed, we don't even know if it is possible to compile Firefox without
> alsa-lib. However, devs help those who help themselves, providing a
> modified ebuild that works, even partially, is more likely to get a
> resolution in the tree.
>
> The other option is to file a bug. Why is alsa in IUSE if the ebuild
> depends on alsa-lib either way?
>
>

That's what I would do too.  Why does Firefox really need sound to
compile?  I go to a LOT of sites that don't use sound and even those
that do need it, I generally keep things muted anyway.  I hate clicking
on a link in a email so that it can load while I read another email then
all of a sudden my speakers start blasting at a fire truck siren volume
level.  Then I have to switch desktops, figure out which tab it is that
has the sound.  Muting is always best for me.  I hate autoplay too.

Dale

:-)  :-)

-- 
I am only responsible for what I said ... Not for what you understood or
how you interpreted my words!


[-- Attachment #2: Type: text/html, Size: 2892 bytes --]

Re: [gentoo-user] local overlay problem

[Neil Bothwick]

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

On Fri, 01 Feb 2013 07:32:24 -0600, Dale wrote:

> >> Then you have to update those too. As I said, either way in the long
> >> term, you have to work at overriding portage defaults.  
> >
> > But an overlay is working with portage, the other options are trying
> > to trick it.  
> 
> I'm not saying it is.  I'm saying that the OP would then have to
> maintain the overlay which requires work.  Depending on his skills, he
> may not REALLY want to do that.

He may not need to. Once he gets it working with a proper -alsa, he can
file a bug report with the fixed ebuild, which could then make it into
the tree.

Or he may find that compiling without alsa is no feasible, in which case
the tree could still be changed, to remove the +alsa from IUSE.

Either way, trying to lie to portage or prevent it doing what it wants is
generally a bad idea.


-- 
Neil Bothwick

Why do kamikaze pilots wear helmets?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] local overlay problem

[Philip Webb]

130201 Michael Hampicke wrote:
> What about not using the local overlay
> and simply do 'emerge --nodeps firefox' and see what happens?
> Philip wants to find out if he can compile FF without alsa-lib.
> To just test this case, 'emerge --nodeps ff' is perfect.
> If he finds out that ff would infact compile without alsa-lib,
> he could open a bug rebort at b.g.o to make alsa-lib optional
> or for that matter, create a patched ebuild in his local overlay.

I did submit Bug 454330 with the result you can see :
it looks as if the real problem is upstream
& that the Gentoo developer had a hard time getting FF 17 to stabilise.
I am not satisfied, but need to offer some effort of my own
before I can reasonably re-open the bug or submit a bug to FF itself.

I do feel very strongly that Gentoo should not force sound on anyone
& that the issue is basic, not some personal preference.
KDE requires a hook for sound, but not sound software itself,
so users can compile 'USE="gstreamer" --nodeps media-sound/phonon',
after which Kdelibs will emerge successfully.
That's what's needed for Firefox.

Thanks for all the replies : I will explore further & report back.

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

Re: [gentoo-user] Firefox no-sound problem (was local overlay problem)

[Philip Webb]

130201 Philip Webb wrote:
> Thanks for all the replies : I will explore further & report back.

I tested the suggestions :

(1) rename the local ebuild '-r99', copy the regular Manifest
& delete the 17.0.2 line, recreate it, try to emerge ;
this fails with the same msg as I reported in Bug 454330 :

  checking for alsa...
    Package alsa was not found in the pkg-config search path.
  ... configure: error: Need alsa for Ogg, Wave or WebM decoding on Linux.
    Disable with --disable-ogg --disable-wave --disable-webm.

(2) put 'alsa-lib' in  package.provided : it starts to emerge alsa-lib .

(3) try '--nodeps' with regular ebuild : fails to configure as with (1).

Is there any way to apply the raw flags in (1)
-- '--disable-ogg' etc -- when using Portage ?
It looks as if the Firefox developers upstream
have created a device to allow users to compile without sound,
but that the Gentoo developer has ignored it
or perhaps has tried to make it work, but failed.

This looks like the next path to explore.
If '--disable ogg' etc don't work, I can file a bug with Firefox.

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

Re: [gentoo-user] Firefox no-sound problem (was local overlay problem)

[Sebastian Beßler]

On 02.02.2013 04:54, Philip Webb wrote:

>   checking for alsa...
>     Package alsa was not found in the pkg-config search path.
>   ... configure: error: Need alsa for Ogg, Wave or WebM decoding on Linux.
>     Disable with --disable-ogg --disable-wave --disable-webm.
>
> This looks like the next path to explore.
> If '--disable ogg' etc don't work, I can file a bug with Firefox.

It should be enough to set

mozconfig_annotate '' --disable-ogg
mozconfig_annotate '' --disable-wave
mozconfig_annotate '' --disable-webm

in the src_configure() part of the ebuild.

Greetings
Sebastian

Re: [gentoo-user] Firefox no-sound problem (was local overlay problem)

[Neil Bothwick]

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

On Fri, 1 Feb 2013 22:54:07 -0500, Philip Webb wrote:

> (1) rename the local ebuild '-r99', copy the regular Manifest
> & delete the 17.0.2 line, recreate it, try to emerge ;
> this fails with the same msg as I reported in Bug 454330 :
> 
>   checking for alsa...
>     Package alsa was not found in the pkg-config search path.
>   ... configure: error: Need alsa for Ogg, Wave or WebM decoding on
> Linux. Disable with --disable-ogg --disable-wave --disable-webm.
> 
> (2) put 'alsa-lib' in  package.provided : it starts to emerge alsa-lib .
> 
> (3) try '--nodeps' with regular ebuild : fails to configure as with (1).
> 
> Is there any way to apply the raw flags in (1)

With most ebuilds, you can define EXTRA_ECONF with these options and they
will be passed to configure.


-- 
Neil Bothwick

I backed up my hard drive and ran into a bus.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-user] Firefox won't compile without sound

[Philip Webb]

130202 Sebastian Beßler wrote:
> On 02.02.2013 04:54, Philip Webb wrote:
>>   checking for alsa...
>>     Package alsa was not found in the pkg-config search path.
>>   ... configure: error: Need alsa for Ogg, Wave or WebM decoding on Linux.
>>     Disable with --disable-ogg --disable-wave --disable-webm.
> It should be enough to set
>   mozconfig_annotate '' --disable-ogg
>   mozconfig_annotate '' --disable-wave
>   mozconfig_annotate '' --disable-webm
> in the src_configure() part of the ebuild.

I did that & avoided the cfg stumble & FF begins to compile.
However, it fails with an error :

  fatal error : nsAudioStream.h : no such file

I tried again with  'USE="gstreamer" ... --nodeps ... '
-- this is the way to get Kdelibs to compile without sound -- ,
but the same error hit again.

It looks as if this is a bug to report upstream.

Further comments or suggestions welcome.

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

Re: [gentoo-user] Firefox won't compile without sound

[Philip Webb]

130202 Philip Webb wrote:
> 130202 Sebastian Beßler wrote:
>> On 02.02.2013 04:54, Philip Webb wrote:
>>>   checking for alsa...
>>>     Package alsa was not found in the pkg-config search path.
>>>   ... configure: error: Need alsa for Ogg, Wave or WebM decoding on Linux.
>>>     Disable with --disable-ogg --disable-wave --disable-webm.
>> It should be enough to set
>>   mozconfig_annotate '' --disable-ogg
>>   mozconfig_annotate '' --disable-wave
>>   mozconfig_annotate '' --disable-webm
>> in the src_configure() part of the ebuild.
> I did that & avoided the cfg stumble & FF begins to compile.
> However, it fails with an error :
> 
>   fatal error : nsAudioStream.h : no such file
> 
> I tried again with  'USE="gstreamer" ... --nodeps ... '
> -- this is the way to get Kdelibs to compile without sound -- ,
> but the same error hit again.

I have added a further msg to Bug 454330
& plan to report the bug upstream.

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