[gentoo-user] @kde-4.2

[gentoo-user] @kde-4.2

[James]

OK,

I've got portage 2.2 working and kde4.2 seems to be
ready to install. However, I'm getting a sting of packages
I need to put in the package.keywords file:

kde-base/plasma-workspace:4.2   ~amd64
kde-base/kwin:4.2               ~amd64


So I Must have missed something, like a wildcard or whatever
so  I do not have to listed tons of packages? I.E. how do I 
unmask everything related to kde-4.2 without doing it individually?

'autounmask kde-4.2' did not work.....


What did I miss?


James

Re: [gentoo-user] @kde-4.2

[Dale]

James wrote:
> OK,
>
> I've got portage 2.2 working and kde4.2 seems to be
> ready to install. However, I'm getting a sting of packages
> I need to put in the package.keywords file:
>
> kde-base/plasma-workspace:4.2   ~amd64
> kde-base/kwin:4.2               ~amd64
>
>
> So I Must have missed something, like a wildcard or whatever
> so  I do not have to listed tons of packages? I.E. how do I 
> unmask everything related to kde-4.2 without doing it individually?
>
> 'autounmask kde-4.2' did not work.....
>
>
> What did I miss?
>
>
> James
>
>   

Hi,

Try autounmask.  It will add everything to the files for you.  Works
pretty good here.

Dale

:-)  :-) 


root@smoker / # eix autounmask
[I] app-portage/autounmask
     Available versions:  0.15 0.21 0.23
     Installed versions:  0.23(22:13:43 01/01/09)
     Homepage:            http://download.mpsna.de/opensource/autounmask/
     Description:         autounmask - Unmasking packages the easy way

root@smoker / # 

[gentoo-user] Re: @kde-4.2

[James]

Dale <rdalek1967 <at> gmail.com> writes:


> > 'autounmask kde-4.2' did not work.....
> >

> Try autounmask.  It will add everything to the files for you.  Works
> pretty good here.
> 

I get:


autounmask kde-4.2

 autounmask version 0.23 (using PortageXS-0.02.09 and portage-2.2_rc23)

 * Using repository: /usr/portage

 * The given category/package-version does not seem to exist. Listing existing
versions:

 * gentoo (/usr/portage):
     none

 * Please pick one of the versions given above and try again.

Same result with either:
autounmask @james-kde-4.2 (acutally name of my sets)
or
autounmask james-kde-4.2

Any other ideas?

Re: [gentoo-user] @kde-4.2

[Volker Armin Hemmann]

On Montag 09 März 2009, James wrote:
> OK,
>
> I've got portage 2.2 working and kde4.2 seems to be
> ready to install. However, I'm getting a sting of packages
> I need to put in the package.keywords file:
>
> kde-base/plasma-workspace:4.2   ~amd64
> kde-base/kwin:4.2               ~amd64
>
>
> So I Must have missed something, like a wildcard or whatever
> so  I do not have to listed tons of packages? I.E. how do I
> unmask everything related to kde-4.2 without doing it individually?
>
> 'autounmask kde-4.2' did not work.....
>
>
> What did I miss?
>
>
> James

all the packages are in the set - just copy that stuff to keywords and unmask. 

Re: [gentoo-user] Re: @kde-4.2

[Dale]

James wrote:
> Dale <rdalek1967 <at> gmail.com> writes:
>
>
>   
>>> 'autounmask kde-4.2' did not work.....
>>>
>>>       
>
>   
>> Try autounmask.  It will add everything to the files for you.  Works
>> pretty good here.
>>
>>     
>
> I get:
>
>
> autounmask kde-4.2
>
>  autounmask version 0.23 (using PortageXS-0.02.09 and portage-2.2_rc23)
>
>  * Using repository: /usr/portage
>
>  * The given category/package-version does not seem to exist. Listing existing
> versions:
>
>  * gentoo (/usr/portage):
>      none
>
>  * Please pick one of the versions given above and try again.
>
> Same result with either:
> autounmask @james-kde-4.2 (acutally name of my sets)
> or
> autounmask james-kde-4.2
>
> Any other ideas?
>
>   

It's been a little bit since I used it but try this:

autounmask kde-base/kde-meta-4.2.1

There is not "man" page but there is a help option.  Real short but it
is there.

root@smoker / # autounmask -h

 autounmask version 0.23 (using PortageXS-0.02.09 and portage-2.2_rc23)

 Usage:
   autounmask category/package-version

 Options:
   -h, --help             : Show this help.
   -p, --pretend          : Just pretend.
   -n, --noversions       : Do not append version when unmasking a package.

root@smoker / #


Notice the usage section.  It has to have the category and package. 

Dale

:-)  :-)

[gentoo-user] Re: @kde-4.2

[James]

Volker Armin Hemmann <volkerarmin <at> googlemail.com> writes:

>
> > 'autounmask kde-4.2' did not work.....
> >
> >
> > What did I miss?
> >
> >
> > James
> 
> all the packages are in the set - just copy that stuff 
to keywords and unmask. 
> 
> 

So I copied all of alan list that he posted plus these 
where additionally unmasked:


~dev-util/cmake-2.6.2
~kde-base/qimageblitz-0.0.4
~sys-apps/sandbox-1.3.2
~x11-apps/xinit-1.0.5-r2
~dev-libs/libical-0.33-r1
~dev-python/PyQt4-4.4.4-r1

in package.keywords

now it's compiling 230 kde-4.2 packages.....


thx,
James

Re: [gentoo-user] @kde-4.2

[Neil Bothwick]

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

On Mon, 9 Mar 2009 02:09:34 +0000 (UTC), James wrote:

> 'autounmask kde-4.2' did not work.....

So autounmask does not understand sets. Either append the set file to
package.keywords

cat /etc/portage/sets/kde4.3 >>/etc/portage/package.keywords

Or make package.keywordsa directory and simply put a copy of the sets
file in there (or a symlink to the sets file). This is the more
manageable option.


-- 
Neil Bothwick

Don't hate yourself in the morning, sleep until noon.

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

Re: [gentoo-user] @kde-4.2

[Robin Atwood]

On Monday 09 Mar 2009, Neil Bothwick wrote:
> On Mon, 9 Mar 2009 02:09:34 +0000 (UTC), James wrote:
> > 'autounmask kde-4.2' did not work.....
>
> So autounmask does not understand sets. Either append the set file to
> package.keywords
>
> cat /etc/portage/sets/kde4.3 >>/etc/portage/package.keywords
>
> Or make package.keywordsa directory and simply put a copy of the sets
> file in there (or a symlink to the sets file). This is the more
> manageable option.

Another approach is:

ACCEPT_KEYWORDS="~*" emerge -pv --columns @kde-4.2 | awk '{ print $4 " ~*" }' 
> kde4

which worked for me. (You will have to top'n'tail the output a bit.)

HTH
-Robin
-- 
----------------------------------------------------------------------
Robin Atwood.

"Ship me somewheres east of Suez, where the best is like the worst,
 Where there ain't no Ten Commandments an' a man can raise a thirst"
         from "Mandalay" by Rudyard Kipling
----------------------------------------------------------------------

[gentoo-user] Re: @kde-4.2

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:



> > 'autounmask kde-4.2' did not work.....

> So autounmask does not understand sets. Either append the set file to
> package.keywords

Ok, 
On my next 4.2.x kde install, I'll try this approach with autounmask.

> cat /etc/portage/sets/kde4.3 >>/etc/portage/package.keywords 
> Or make package.keywordsa directory and simply put a copy of the sets
> file in there (or a symlink to the sets file). This is the more
> manageable option.


Interesting approach. I usually like to follow the gentoo recommended
practices. I get the feeling that "sets" via portage 2.2 is very
much a work in progress. So which of these approaches is likely
to become the de'facto method?


Also, I omitted the "~amd64" at the end of all of those manual
entries into my package.keywords file. It work without them.
So my question is the "-amd64" entry on every line of my package.keywords
deprecated now with portage 2.2?


James

[gentoo-user] Re: @kde-4.2

[James]

Robin Atwood <robin.atwood <at> attglobal.net> writes:


> Another approach is:
> ACCEPT_KEYWORDS="~*" emerge -pv --columns @kde-4.2 | awk '{ print $4 " ~*" }' 
> > kde4

> which worked for me. (You will have to top'n'tail the output a bit.)

OK,

This is an interesting approach.
So if I use a very restricted subset of kde-4.2 and call it @james-kde-4.2
and filter on that, it should work.



Thanks for the suggestion. I get the feeling we're all hacking our own
install semantics here for kde-4.2. With dozens of workstations to eventually
support, I'm looking for something (error free) in my systematic approach.

"Winging it" a little bit different each time brings about risk and 
inhibits my conservative nature, when doing admin work. It just seems like
every thing I read, there are different wrinkles to the various approaches.

So we now have evdev (xorg.conf going on a diet),
kde-4.x gymnastics
and no installation media for '09.
Very smart folks have recommended using different media 
to install (most of which have worked for me) and
things like the kernel/distro function for drivers keeps changing.


Ya just gotta love Gentoo. Just when I was ready to completely
script up my job, I have to relearn how to install and
maintain systems all over again. It's going to be real interesting
to see how the official gentoo docs end up.

"So. We have lots of work to do on the handbooks just for the autobuilds.
Should we have a new directory layout as well?"


I'll keep all of this in mind.

thx,
James

[gentoo-user] Re: @kde-4.2

[Nikos Chantziaras]

James wrote:
> Thanks for the suggestion. I get the feeling we're all hacking our own
> install semantics here for kde-4.2.

I find the -meta packages very helpful.  Instead of pulling in all of 
KDE (with tons of stuff I don't need), I simply emerged those:

   kde-base/ark
   kde-base/kate
   kde-base/kcalc
   kde-base/kdeartwork-meta
   kde-base/kdebase-meta
   kde-base/kdegraphics-meta
   kde-base/kdeplasma-addons
   kde-base/kget

Emerging the *whole* of KDE is, I think, something no one needs :P  Just 
go with the basic stuff, and then emerge additional applications later. 
   You don't even need to make up your own sets or -metas.  Your 
patience will thank you later when the need arises to rebuild everything 
(when KDE 4.2.2 arrives, for example).

[gentoo-user] Re: @kde-4.2

[ABCD]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

James wrote:
> Neil Bothwick writes:
>> cat /etc/portage/sets/kde4.3 >>/etc/portage/package.keywords 
>> Or make package.keywordsa directory and simply put a copy of the sets
>> file in there (or a symlink to the sets file). This is the more
>> manageable option.
> 
> Interesting approach. I usually like to follow the gentoo recommended
> practices. I get the feeling that "sets" via portage 2.2 is very
> much a work in progress. So which of these approaches is likely
> to become the de'facto method?
> 
> Also, I omitted the "~amd64" at the end of all of those manual
> entries into my package.keywords file. It work without them.
> So my question is the "-amd64" entry on every line of my package.keywords
> deprecated now with portage 2.2?
> 
> 
> James
> 

If you are using the kde-testing overlay, there are files that you can
symlink under /etc/portage/package.{keywords,unmask}/ to unmask/keyword
particular versions of KDE. Note also that "any file in [/etc/portage]
that begins with 'package.' can be more than just a flat file. If it is
a directory, then all the files in that directory will be sorted in
ascending alphabetical order by file name and summed together as if it
were a single file" (from portage(5)). To be precise, it can be an
entire directory tree, and still work the same way.

A line in package.keywords without any KEYWORDS implies "~${ARCH}"
(again, see portage(5)).

With the exception of sets and FEATURES=preserved-libs, everything in
portage-2.2 is in portage-2.1.6.*, which is now stable just about
everywhere, so this behavior is at least that old (although I believe it
has been around longer).

- --
ABCD
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkm1awcACgkQOypDUo0oQOpvhgCdEAKRJp1kSFoff++jTn+JQYvp
VZ8An0/7OMDSrfddocWGkJFiArV4D8tZ
=gruJ
-----END PGP SIGNATURE-----

Re: [gentoo-user] Re: @kde-4.2

[Neil Bothwick]

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

On Mon, 9 Mar 2009 14:00:33 +0000 (UTC), James wrote:

> > cat /etc/portage/sets/kde4.3 >>/etc/portage/package.keywords 
> > Or make package.keywordsa directory and simply put a copy of the sets
> > file in there (or a symlink to the sets file). This is the more
> > manageable option.  
 
> Interesting approach. I usually like to follow the gentoo recommended
> practices. I get the feeling that "sets" via portage 2.2 is very
> much a work in progress. So which of these approaches is likely
> to become the de'facto method?

The Gentoo approach has always been to handle package.keywords yourself,
autounmask is an unofficial utility. I hope there will be the facility to
add a set to the file in future.

> Also, I omitted the "~amd64" at the end of all of those manual
> entries into my package.keywords file. It work without them.
> So my question is the "-amd64" entry on every line of my
> package.keywords deprecated now with portage 2.2?

It's always been like that (well, for a very long time, at least). If
you don't specify an arch in the file, it uses the testing variant of
whatever you have in make.conf. 


-- 
Neil Bothwick

Do you steal taglines too?

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

[gentoo-user] Re: @kde-4.2

[James]

Nikos Chantziaras <realnc <at> arcor.de> writes:

> 
> James wrote:
> > Thanks for the suggestion. I get the feeling we're all hacking our own
> > install semantics here for kde-4.2.
> 
> I find the -meta packages very helpful.  Instead of pulling in all of 
> KDE (with tons of stuff I don't need), I simply emerged those:

My understanding is that all the meta packaging is going away 
sooner than later. So either gentoo defined sets or "James" defined
sets are the only option, for the future....

At least that's what others have indicated...


james

[gentoo-user] Re: @kde-4.2

[James]

Neil Bothwick <neil <at> digimed.co.uk> writes:


> The Gentoo approach has always been to handle package.keywords yourself,
> autounmask is an unofficial utility. I hope there will be the facility to
> add a set to the file in future.

good to know.


> It's always been like that (well, for a very long time, at least). If
> you don't specify an arch in the file, it uses the testing variant of
> whatever you have in make.conf. 


I guess being 'late' to the party, is better than missing the whole
event......


thx,

James