[gentoo-user] jpg support

[gentoo-user] jpg support

[Michael P. Soulier]

Hi,

I built gqview and feh without the jpg USE flag in make.conf, and now
they refuse to display jpg images. I've added jpg to make.conf, and
ran

emerge -vu --newuse world

but gqview and feh aren't on the list of what's being rebuilt, and
when it's done I still have no jpg support in those programs.

Any suggestions?

Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

Re: [gentoo-user] jpg support

[Nicolas Sebrecht]

On Fri, Nov 07, 2008 at 11:48:24PM -0500, Michael P. Soulier wrote:

>                                    I've added jpg to make.conf, and
> ran
> 
> emerge -vu --newuse world
> 
> but gqview and feh aren't on the list of what's being rebuilt

I guess it's normal as both don't have a jpeg USE flag (as far as I can
see).

-- 
Nicolas Sebrecht

Re: [gentoo-user] jpg support

[Dirk Heinrichs]

Am Samstag, 8. November 2008 05:48:24 schrieb Michael P. Soulier:

> I built gqview and feh without the jpg USE flag in make.conf, and now
> they refuse to display jpg images. I've added jpg to make.conf, and
> ran
>
> emerge -vu --newuse world
>
> but gqview and feh aren't on the list of what's being rebuilt, and
> when it's done I still have no jpg support in those programs.

Just try to re-emerge those packages and see if they can show jpeg images 
afterwards. If yes, please file a bug on http://bugs.gentoo.org, so that the 
jpeg USE flag will be added to future versions of the packages.

Bye...

	Dirk

Re: [gentoo-user] jpg support

[Daniel Pielmeier]

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

Dirk Heinrichs schrieb am 08.11.2008 11:48:
> Am Samstag, 8. November 2008 05:48:24 schrieb Michael P. Soulier:
> 
>> I built gqview and feh without the jpg USE flag in make.conf, and now
>> they refuse to display jpg images. I've added jpg to make.conf, and
>> ran
>>
>> emerge -vu --newuse world
>>
>> but gqview and feh aren't on the list of what's being rebuilt, and
>> when it's done I still have no jpg support in those programs.
> 
> Just try to re-emerge those packages and see if they can show jpeg images 
> afterwards. If yes, please file a bug on http://bugs.gentoo.org, so that the 
> jpeg USE flag will be added to future versions of the packages.

At least for gqview there will be no jpg use flag. What do you think how
use flags work? Simply adding an use flag to an Ebuild will do nothing.
A use flag normally enables an option at configuration time. But there
is no such option for gqview. At least not until now. Even the
development version has only one configure option that counts and this is

--without-lcms          build without lcms support

So there are two possibilities. First there is no need for a jpg useflag
as it will work out of the box. Second the jpg support or needed
libraries if they are indeed needed are detected automagically which is
bad and a bug should be filed. But from a quick glance into the relevant
files I did not recognize such things.

So I guess rebuilding the affected packages and trying again is the best
option.

Regards,

Daniel


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

Re: [gentoo-user] jpg support

[Michael P. Soulier]

On Sat, Nov 8, 2008 at 6:15 AM, Daniel Pielmeier
<daniel.pielmeier@googlemail.com> wrote:
> So there are two possibilities. First there is no need for a jpg useflag
> as it will work out of the box. Second the jpg support or needed
> libraries if they are indeed needed are detected automagically which is
> bad and a bug should be filed. But from a quick glance into the relevant
> files I did not recognize such things.
>
> So I guess rebuilding the affected packages and trying again is the best
> option.

I tried rebuilding gqview and feh with no success. feh complains about
no imlib support for jpegs so I rebuild imlib, which didn't help.
Before going to bed I started a full world rebuild. I'll reboot after
that to ensure I pick up new shared libraries and we'll see what
happens. This violates the principle of least surprise though.

I am finding this about gentoo. On FreeBSD I could disable X11
support, but it's on by default. I agree with that. On gentoo I have
to explicitely enable jpg support?? Why the hell would I not want it?
I find that needlessly difficult. The default should be the common
case, not the uncommon one.

Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

Re: [gentoo-user] jpg support

[Dale]

Michael P. Soulier wrote:
> On Sat, Nov 8, 2008 at 6:15 AM, Daniel Pielmeier
> <daniel.pielmeier@googlemail.com> wrote:
>   
>> So there are two possibilities. First there is no need for a jpg useflag
>> as it will work out of the box. Second the jpg support or needed
>> libraries if they are indeed needed are detected automagically which is
>> bad and a bug should be filed. But from a quick glance into the relevant
>> files I did not recognize such things.
>>
>> So I guess rebuilding the affected packages and trying again is the best
>> option.
>>     
>
> I tried rebuilding gqview and feh with no success. feh complains about
> no imlib support for jpegs so I rebuild imlib, which didn't help.
> Before going to bed I started a full world rebuild. I'll reboot after
> that to ensure I pick up new shared libraries and we'll see what
> happens. This violates the principle of least surprise though.
>
> I am finding this about gentoo. On FreeBSD I could disable X11
> support, but it's on by default. I agree with that. On gentoo I have
> to explicitely enable jpg support?? Why the hell would I not want it?
> I find that needlessly difficult. The default should be the common
> case, not the uncommon one.
>
> Mike
>   

I just noticed this:

root@smoker / # euse -i jpg
global use flags (searching: jpg)
************************************************************
no matching entries found

local use flags (searching: jpg)
************************************************************
no matching entries found
root@smoker / # euse -i jpeg
global use flags (searching: jpeg)
************************************************************
[+ CD ] jpeg - Adds JPEG image support

local use flags (searching: jpeg)
************************************************************
no matching entries found
root@smoker / #


Are you putting in jpg or jpeg or is it a typo in the email?

Dale

:-)  :-) 

P. S.  I can send you a list of all the packages that use the jpeg USE
flag on my system if you need it.  Faster than a emerge -e world at least.

Re: [gentoo-user] jpg support

[Michael P. Soulier]

On Sat, Nov 8, 2008 at 9:31 AM, Dale <rdalek1967@gmail.com> wrote:
> Are you putting in jpg or jpeg or is it a typo in the email?

Pardon me while I scream expletives inappropriate for a public forum.

> Dale
>
> :-)  :-)
>
> P. S.  I can send you a list of all the packages that use the jpeg USE
> flag on my system if you need it.  Faster than a emerge -e world at least.

Sure. I'll try a basic --newuse rebuild first and see if that works.

*sigh* Thanks.
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

Re: [gentoo-user] jpg support

[Dale]

Michael P. Soulier wrote:
> On Sat, Nov 8, 2008 at 9:31 AM, Dale <rdalek1967@gmail.com> wrote:
>   
>> Are you putting in jpg or jpeg or is it a typo in the email?
>>     
>
> Pardon me while I scream expletives inappropriate for a public forum.
>   

May I suggest you try the -v option with emerge?  It shows all the USE
flags that are available and whether they are on, off or going to
change.  Yours may even be color coded.  If you just want to see what
will change before actually doing the emerge, try the -a or -p option. 
Those give you a chance to look at what will be done before doing it.

>   
>> Dale
>>
>> :-)  :-)
>>
>> P. S.  I can send you a list of all the packages that use the jpeg USE
>> flag on my system if you need it.  Faster than a emerge -e world at least.
>>     
>
> Sure. I'll try a basic --newuse rebuild first and see if that works.
>
> *sigh* Thanks.
>   

I hope that will work.  emerge -e world is a bit extreme for this. 

Dale

:-)  :-) 

Re: [gentoo-user] jpg support

[Michael P. Soulier]

On Sat, Nov 8, 2008 at 11:59 AM, Dale <rdalek1967@gmail.com> wrote:
> I hope that will work.  emerge -e world is a bit extreme for this.

It worked fine. For the record, I am using the default profile at the
moment, as I have not managed the profile in any way yet.

msoulier@anton:~$ ls -l /etc/make.profile
lrwxrwxrwx 1 root root 48 Nov  3 20:27 /etc/make.profile ->
../usr/portage/profiles/default/linux/x86/2008.0

Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

Re: [gentoo-user] jpg support

[Jorge Peixoto de Morais Neto]

On Sun, Nov 9, 2008 at 1:58 AM, Michael P. Soulier
<msoulier@digitaltorque.ca> wrote:
> On Sat, Nov 8, 2008 at 11:59 AM, Dale <rdalek1967@gmail.com> wrote:
>> I hope that will work.  emerge -e world is a bit extreme for this.
>
> It worked fine. For the record, I am using the default profile at the
> moment, as I have not managed the profile in any way yet.
>
> msoulier@anton:~$ ls -l /etc/make.profile
> lrwxrwxrwx 1 root root 48 Nov  3 20:27 /etc/make.profile ->
> ../usr/portage/profiles/default/linux/x86/2008.0

$ ls /usr/portage/profiles/default/linux/x86/2008.0
desktop  developer  parent  server

$ file /etc/make.profile
/etc/make.profile: symbolic link to
`..//usr/portage/profiles/default/linux/x86/2008.0/desktop'

-- 
Software is like sex: it is better when it is free - Linus Torvalds

Re: [gentoo-user] jpg support

[Michael P. Soulier]

On Sun, Nov 9, 2008 at 5:30 AM, Jorge Peixoto de Morais Neto
<please.no.spam.here@gmail.com> wrote:
> $ ls /usr/portage/profiles/default/linux/x86/2008.0
> desktop  developer  parent  server
>
> $ file /etc/make.profile
> /etc/make.profile: symbolic link to
> `..//usr/portage/profiles/default/linux/x86/2008.0/desktop'

Yeah, it's ok. I looked in desktop's USE flags and took what I want.
I'm currently using gentoo for a more streamlined desktop than most
distros are capable of providing, on older hardware.

Thanks,
Mike
-- 
Michael P. Soulier <msoulier@digitaltorque.ca>
"Any intelligent fool can make things bigger and more complex... It takes a
touch of genius - and a lot of courage to move in the opposite direction."
--Albert Einstein

Re: [gentoo-user] jpg support

[Alan McKinnon]

On Saturday 08 November 2008 16:08:22 Michael P. Soulier wrote:
> On Sat, Nov 8, 2008 at 6:15 AM, Daniel Pielmeier
>
> <daniel.pielmeier@googlemail.com> wrote:
> > So there are two possibilities. First there is no need for a jpg useflag
> > as it will work out of the box. Second the jpg support or needed
> > libraries if they are indeed needed are detected automagically which is
> > bad and a bug should be filed. But from a quick glance into the relevant
> > files I did not recognize such things.
> >
> > So I guess rebuilding the affected packages and trying again is the best
> > option.
>
> I tried rebuilding gqview and feh with no success. feh complains about
> no imlib support for jpegs so I rebuild imlib, which didn't help.
> Before going to bed I started a full world rebuild. I'll reboot after
> that to ensure I pick up new shared libraries and we'll see what
> happens. This violates the principle of least surprise though.

You are going about this the wrong way. Gentoo can't really make a package 
more configurable than what it's author provides. feh has no option 
to ./configure to explicitly enable jpeg support, thus there cannot be a USE 
flag for it, as described earlier in the thread. If you need/want to know 
what's going in with such things, emerge the package and look for the full 
build log in /var/log/portage/. Examine it, it will tell you how the package 
builds.

imlib is the same, no explicit switch for jpeg, so you have to rely on the 
autodetect voodoo^Wmagic. it sucks, it shouldn't be that way but gentoo 
didn't make it that way.

Why did you decide to rebuild world? That's a bit like a sledge hammer to kill 
a flea....

You can't validly claim this violates least surprise. Even if your 
expectations were correct and gentoo does violate them, it's not something 
gentoo can fix, the problem is in the configure script.
>
> I am finding this about gentoo. On FreeBSD I could disable X11
> support, but it's on by default. I agree with that. On gentoo I have
> to explicitely enable jpg support?? Why the hell would I not want it?
> I find that needlessly difficult. The default should be the common
> case, not the uncommon one.

I'll bet your profile points to a server profile, not a desktop one. For the 
server profile, the default is no X server and thus no jpeg. A quick search 
shows me that all the desktop profiles enable jpeg by default - the expected 
state for most users. You profile is dictated by what the /etc/make.profile 
symlink points to.

I think you need to re-read the gentoo handbook, the full thing from beginning 
to end. As you have made several mistakes thus far that show me you don't 
know where or how to select the thing you want.


-- 
alan dot mckinnon at gmail dot com

Re: [gentoo-user] jpg support

[Daniel Pielmeier]

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

Alan McKinnon schrieb am 08.11.2008 16:00:
> On Saturday 08 November 2008 16:08:22 Michael P. Soulier wrote:
>> On Sat, Nov 8, 2008 at 6:15 AM, Daniel Pielmeier
>>
>> <daniel.pielmeier@googlemail.com> wrote:
>>> So there are two possibilities. First there is no need for a jpg useflag
>>> as it will work out of the box. Second the jpg support or needed
>>> libraries if they are indeed needed are detected automagically which is
>>> bad and a bug should be filed. But from a quick glance into the relevant
>>> files I did not recognize such things.
>>>
>>> So I guess rebuilding the affected packages and trying again is the best
>>> option.
>> I tried rebuilding gqview and feh with no success. feh complains about
>> no imlib support for jpegs so I rebuild imlib, which didn't help.
>> Before going to bed I started a full world rebuild. I'll reboot after
>> that to ensure I pick up new shared libraries and we'll see what
>> happens. This violates the principle of least surprise though.
> 
> You are going about this the wrong way. Gentoo can't really make a package 
> more configurable than what it's author provides. feh has no option 
> to ./configure to explicitly enable jpeg support, thus there cannot be a USE 
> flag for it, as described earlier in the thread. If you need/want to know 
> what's going in with such things, emerge the package and look for the full 
> build log in /var/log/portage/. Examine it, it will tell you how the package 
> builds.
> 
> imlib is the same, no explicit switch for jpeg, so you have to rely on the 
> autodetect voodoo^Wmagic. it sucks, it shouldn't be that way but gentoo 
> didn't make it that way.
> 
> Why did you decide to rebuild world? That's a bit like a sledge hammer to kill 
> a flea....
> 
> You can't validly claim this violates least surprise. Even if your 
> expectations were correct and gentoo does violate them, it's not something 
> gentoo can fix, the problem is in the configure script.
>> I am finding this about gentoo. On FreeBSD I could disable X11
>> support, but it's on by default. I agree with that. On gentoo I have
>> to explicitely enable jpg support?? Why the hell would I not want it?
>> I find that needlessly difficult. The default should be the common
>> case, not the uncommon one.
> 
> I'll bet your profile points to a server profile, not a desktop one. For the 
> server profile, the default is no X server and thus no jpeg. A quick search 
> shows me that all the desktop profiles enable jpeg by default - the expected 
> state for most users. You profile is dictated by what the /etc/make.profile 
> symlink points to.
> 
> I think you need to re-read the gentoo handbook, the full thing from beginning 
> to end. As you have made several mistakes thus far that show me you don't 
> know where or how to select the thing you want.
> 

Thank you Alan for your always helpful answers. While having nothing to
do I investigated a bit more on this issue and have something to add here.

First USE _jpeg_ should be enabled by default for desktop profiles.

I can view jpegs without problems in gqview and gqview doesn't require
anything jpeg related to view them. qgview only requires gtk+.

I took a look at the shared libraries (1) linked against gqview and with
the help of the reverse dependencies (2) of the packages owning that
shared libraries I was able to validate that gqview only needs gtk+
because all libraries used by gqview need gtk+ in some way. So the gtk+
dependency pulls in everything needed for gqview.

Now I took a look at the output of strace gqview (3). Here are the
relevant lines:

read(4, " 5 \"gtk20\" \"The JPEG image format"..., 1024) = 1024
stat64("/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so",
{st_mode=S_IFREG|0755, st_size=17756, ...}) = 0
open("/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so",
O_RDONLY) = 6
open("/usr/lib/libjpeg.so.62", O_RDONLY) = 6

Owners of the relevant libraries:
/usr/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-jpeg.so is owned by
x11-libs/gtk+-2.12.11
/usr/lib/libjpeg.so.62 is owned by media-libs/jpeg-6b-r8

So gtk+ can open jpegs but why can't you on your system?

USE flags for gtk+:
x11-libs/gtk+-2.12.11  USE="X cups jpeg tiff -debug -doc -vim-syntax
-xinerama"

The answer is gqview does not need a jpeg use flag nor does probably
feh, but gtk+ has to be built with jpeg support.

So there is no need for rebuilding world, adding the jpeg flag to gtk
should be enough. Or better if you use Gentoo on a desktop enable the
desktop profile. Plus instead of blaming Gentoo, learn how it works and
to use it properly. I know nothing about FreeBSD so I would not allow me
any prejudices against it. *sigh*


Just for your information I used the following commands for investigation

1) Packages needed by qgview by finding the owners of the shared
libraries needd by gqview:

ldd /usr/bin/gqview | sed -n 's/\s*\(.*\)\s=>\s.*/\1/p' | xargs qfile
--nocolor

2) Reverse dependencies of said Packages:

ldd /usr/bin/gqview | sed -n 's/\s*\(.*\)\s=>\s.*/\1/p' | xargs qfile
--nocolor | sed -n 's/\(.*\)\s.*/\1/p' | xargs emerge -pv --depclean

3) strace

strace gqview some.jpg  2>&1 | tee strace



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

[gentoo-user] desktop & sever profiles; was: Re: jpg support

[Stroller]

On 8 Nov 2008, at 15:55, Daniel Pielmeier wrote:
> Alan McKinnon schrieb am 08.11.2008 16:00:
>> ...
>> I'll bet your profile points to a server profile, not a desktop  
>> one. For the
>> server profile, the default is no X server and thus no jpeg. A  
>> quick search
>> shows me that all the desktop profiles enable jpeg by default - the  
>> expected
>> state for most users. You profile is dictated by what the /etc/ 
>> make.profile
>> symlink points to.
>> ...
>
> ... if you use Gentoo on a desktop enable the
> desktop profile. ...

I wouldn't be inclined to assume a new user might be using a server  
profile because last time I checked these spit out an ugly warning  
message about "this profile being untested" for EVERY SINGLE package  
emerged.

Eventually - after enabling PORTAGE_ELOG_* and being inundated with  
warning spam for packages which had compiled without problems - I was  
unable to tolerate this behaviour any longer & switched to a desktop  
profile instead.

So has something changed since I experienced this, or have many other  
people just been ignoring the nuisance of the warning messages?

I guess I chose a server profile in the first place because it seemed  
more "correct" for me to do so (seeing as all my machines are  
servers), but since I'm quite happy to put USE="-X -gtk -qt &c" in my  
make.conf I can't see that it makes much difference.

Stroller.

Re: [gentoo-user] desktop & sever profiles; was: Re: jpg support

[Daniel Pielmeier]

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

Stroller schrieb am 08.11.2008 18:13:
> 
> I wouldn't be inclined to assume a new user might be using a server
> profile because last time I checked these spit out an ugly warning
> message about "this profile being untested" for EVERY SINGLE package
> emerged.
> 
> Eventually - after enabling PORTAGE_ELOG_* and being inundated with
> warning spam for packages which had compiled without problems - I was
> unable to tolerate this behaviour any longer & switched to a desktop
> profile instead.
> 
> So has something changed since I experienced this, or have many other
> people just been ignoring the nuisance of the warning messages?
> 
> I guess I chose a server profile in the first place because it seemed
> more "correct" for me to do so (seeing as all my machines are servers),
> but since I'm quite happy to put USE="-X -gtk -qt &c" in my make.conf I
> can't see that it makes much difference.

I don't know if the server profile is untested. I for myself neither use
a server nor a desktop profile. Here is my profile symlink.

/etc/make.profile ->
/media/system/repositories/portage/profiles/default/linux/x86/2008.0

As you can see you don't need to choose either desktop or server at all,
as this works fine here and I don't get annoying messages.

For more information take a look at [1] Chapter 6b Choosing the Right
Profile

[1]
http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?style=printable&full=1#book_part1_chap6


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

Re: [gentoo-user] desktop & sever profiles; was: Re: jpg support

[Stroller]

On 8 Nov 2008, at 17:35, Daniel Pielmeier wrote:

> Stroller schrieb am 08.11.2008 18:13:
>>
>> I wouldn't be inclined to assume a new user might be using a server
>> profile because last time I checked these spit out an ugly warning
>> message about "this profile being untested" for EVERY SINGLE package
>> emerged.
>> ...
>
> I don't know if the server profile is untested. I for myself neither  
> use
> a server nor a desktop profile. Here is my profile symlink.
>
> /etc/make.profile ->
> /media/system/repositories/portage/profiles/default/linux/x86/2008.0


I assume you're aware that if you look inside that directory you'll  
find "desktop" and "server" subdirectories?

   $ ls /usr/portage/profiles/default/linux/x86/2008.0/
   desktop  developer  parent  server
   $ ls -l /etc/make.profile
   lrwxrwxrwx 1 root root 46 Oct  8 07:01 /etc/make.profile -> /usr/ 
portage/profiles/default/linux/x86/2008.0
   $ ls /etc/make.profile
   desktop  developer  parent  server
   $

In this case I had assumed the "default" was for Portage simply to  
assume desktop.

Stroller.

Re: [gentoo-user] desktop & sever profiles; was: Re: jpg support

[Dale]

Stroller wrote:
>
> On 8 Nov 2008, at 17:35, Daniel Pielmeier wrote:
>
>> Stroller schrieb am 08.11.2008 18:13:
>>>
>>> I wouldn't be inclined to assume a new user might be using a server
>>> profile because last time I checked these spit out an ugly warning
>>> message about "this profile being untested" for EVERY SINGLE package
>>> emerged.
>>> ...
>>
>> I don't know if the server profile is untested. I for myself neither use
>> a server nor a desktop profile. Here is my profile symlink.
>>
>> /etc/make.profile ->
>> /media/system/repositories/portage/profiles/default/linux/x86/2008.0
>
>
> I assume you're aware that if you look inside that directory you'll
> find "desktop" and "server" subdirectories?
>
> $ ls /usr/portage/profiles/default/linux/x86/2008.0/
> desktop developer parent server
> $ ls -l /etc/make.profile
> lrwxrwxrwx 1 root root 46 Oct 8 07:01 /etc/make.profile ->
> /usr/portage/profiles/default/linux/x86/2008.0
> $ ls /etc/make.profile
> desktop developer parent server
> $
>
> In this case I had assumed the "default" was for Portage simply to
> assume desktop.
>
> Stroller.
>
>
>

From my understanding, portage doesn't look in the subdirectories, just
the files in the directory. If that is still correct, then it doesn't
matter what is below that.

Also, keep in mind that back in the early days, there was no desktop or
server profiles.

Dale

:-) :-)

Re: [gentoo-user] desktop & sever profiles; was: Re: jpg support

[Daniel Pielmeier]

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

Stroller schrieb am 08.11.2008 19:06:
> I assume you're aware that if you look inside that directory you'll find
> "desktop" and "server" subdirectories?

Yes I am, but what is the problem with that?

>   $ ls /usr/portage/profiles/default/linux/x86/2008.0/
>   desktop  developer  parent  server
>   $ ls -l /etc/make.profile
>   lrwxrwxrwx 1 root root 46 Oct  8 07:01 /etc/make.profile ->
> /usr/portage/profiles/default/linux/x86/2008.0
>   $ ls /etc/make.profile
>   desktop  developer  parent  server
>   $
> 
> In this case I had assumed the "default" was for Portage simply to
> assume desktop.

No, if you want the desktop profile you have to specify this explicitly
by using /usr/portage/profiles/default/linux/x86/2008.0/desktop for
example as symlink.

Only relevant are the files in the directory of the chosen profile and
not the subdirectories. The "parent" file points to the relevant files
that create the profile.

cat ${PORTDIR}/profiles/default/linux/x86/2008.0/parent
..
../../../../releases/2008.0

cat ${PORTDIR}/profiles/default/linux/x86/2008.0/desktop/parent
..
../../../../../targets/desktop

cat ${PORTDIR}/profiles/default/linux/x86/2008.0/server/parent
..
../../../../../targets/server

As you can see profiles go always up in the directory structure and not
down. So if you choose 2008.0. Server, developer and desktop profiles
are omitted.

Regards,

Daniel


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

Re: [gentoo-user] desktop & sever profiles; was: Re: jpg support

[Alan McKinnon]

On Saturday 08 November 2008 19:13:15 Stroller wrote:
> > ... if you use Gentoo on a desktop enable the
> > desktop profile. ...
>
> I wouldn't be inclined to assume a new user might be using a server  
> profile because last time I checked these spit out an ugly warning  
> message about "this profile being untested" for EVERY SINGLE package  
> emerged.
>
> Eventually - after enabling PORTAGE_ELOG_* and being inundated with  
> warning spam for packages which had compiled without problems - I was  
> unable to tolerate this behaviour any longer & switched to a desktop  
> profile instead.
>
> So has something changed since I experienced this, or have many other  
> people just been ignoring the nuisance of the warning messages?
>
> I guess I chose a server profile in the first place because it seemed  
> more "correct" for me to do so (seeing as all my machines are  
> servers), but since I'm quite happy to put USE="-X -gtk -qt &c" in my  
> make.conf I can't see that it makes much difference.

I tend to do the same as you. I like the idea of desktop, server and hardened 
profiles but if the server profile is untested, then one has to ask the 
question - why is it even there? Can profiles be "masked" in a way analogous 
to packages?

-- 
alan dot mckinnon at gmail dot com