Re: [gentoo-user] Re: KDE (mono to meta) migration
On Sat, 24 Jun 2006 18:28:39 +0200, Bo Ørsted Andresen wrote: You seem to have been more confused than enlightened by the tricks I posted. If you want to nuke kde completely you should just do: # cd /var/db/pkg emerge -Cva kde-base/* You should also rm -fr /usr/kde or rm -fr /usr/kde/3.[0-4] if you want to keep 3.5. This removes files that were not deleted by the unmerge. This includes anything that had changed during installation, such as config files and any library files that fix_libtools_files.sh may have changed. -- Neil Bothwick Everything's back to normal. Damn. signature.asc Description: PGP signature
[gentoo-user] Re: KDE (mono to meta) migration
Bo Ørsted Andresen bo.andresen at zlin.dk writes: The revdep-rebuild is good *after* emerging kde-meta. It will recompile third party applications such as amarok against the new version of kde-meta. I posted the simple steps at the bottom of my previous mail. Assuming you really do want to nuke kde completely (on your other computers): # cd /var/db/pkg emerge -Cva kde-base/* # emerge -uva kde-meta # revdep-rebuild -p # revdep-rebuild Yep these 4 lines do the trick. Multiple applications of revdep-rebuild thx. James -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: KDE (mono to meta) migration
Bo Ørsted Andresen bo.andresen at zlin.dk writes: On Thursday 22 June 2006 22:12, James wrote: Ok I'll do this after emerging kde-meta completes. I hope I was not suppose to do this before 'emerge -uavDN kde-meta' You weren't. Blocks are only within the same slot. In fact the split packages blocks only the monolithic package they belong to. OK Unmerge what you don't need or remerge (after emerging kde 3.5) what you still need. When you are done with that the above command should give no output and any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong to no package. Pay attention to what you do though. A revdep-rebuild before this step will probably take care of most of this. Before or after the emerge -uavDN kde-meta? If you are removing stuff it doesn't matter. If you are remerging stuff it should be after. If you do it before it will be built against the old version again which is pretty pointless. Well, something is messed up. I still get many many blocks: =kde-base/kdepim-3.5* (is blocking kde-base/libkpgp-3.5.0-r1) [blocks B ] =kde-base/kdepim-3.5* (is blocking kde-base/libkdenetwork-3.5.0) [blocks B ] =kde-base/kdepim-3.5* (is blocking kde-base/libkpimidentities-3.5.2) [blocks B ] =kde-base/kdepim-3.5* (is blocking kde-base/libkdepim-3.5.2-r1) [blocks B ] =kde-base/kdepim-3.5* (is blocking kde-base/libkcal-3.5.2-r1) snip [blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kamera-3.5.2) [blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kghostview-3.5.2) [blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kcoloredit-3.5.2) snip I after deleting everything. I unmerge everthing (KDE) I thought: 467emerge --unmerge kde-base/kdewebdev 468emerge --unmerge kde-base/kdeadmin 470emerge --unmerge kde-base/kdemultimedia 471emerge --unmerge kde-base/kdepim 472emerge --unmerge kde-base/kdeutils 475emerge --unmerge kde-base/kdetoys 477 emerge --unmerge kde-base/kdegraphics 480 emerge --unmerge kde-base/kdenetwork snip but they are still blocking? I tried revdep-rebuild emerge --rsync and env-update source /etc/profile etc-update update-eix eupdatedb Yet the system think they are gone, for example: emerge --unmerge kde-base/kdegraphics --- Couldn't find 'kde-base/kdegraphics' to unmerge. Yet is still one of the blocking packages? [blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kuickshow-3.5.2) .[blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kgamma-3.5.2) .[blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kmrml-3.5.2) snip What did I miss? James -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: KDE (mono to meta) migration
Your quoting style is terrible...! On Saturday 24 June 2006 17:25, James wrote: Unmerge what you don't need or remerge (after emerging kde 3.5) what you still need. When you are done with that the above command should give no output and any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong to no package. Pay attention to what you do though. A revdep-rebuild before this step will probably take care of most of this. Here I was talking about cleaning out the cruft that third party applications that do not belong to KDE may leave behind after you have removed KDE from an old slot. This has nothing to do with the problems below. It is relevant when you are done upgrading kde and not before. [SNIP] Well, something is messed up. I still get many many blocks: [blocks B ] =kde-base/kdepim-3.5* (is blocking kde-base/libkpgp-3.5.0-r1) [SNIP] [blocks B ] =kde-base/kdegraphics-3.5* (is blocking kde-base/kamera-3.5.2) I after deleting everything. I unmerge everthing (KDE) I thought: 467emerge --unmerge kde-base/kdewebdev 468emerge --unmerge kde-base/kdeadmin 470emerge --unmerge kde-base/kdemultimedia 471emerge --unmerge kde-base/kdepim 472emerge --unmerge kde-base/kdeutils 475emerge --unmerge kde-base/kdetoys 477 emerge --unmerge kde-base/kdegraphics 480 emerge --unmerge kde-base/kdenetwork snip but they are still blocking? Did you unmerge kde? It depends on the monolithic packages above. # emerge --unmerge kde I tried revdep-rebuild emerge --rsync and env-update source /etc/profile etc-update update-eix eupdatedb That's pretty pointless at the moment. When you don't know what is pulling something in you should add --tree to the emerge command. -- Bo Andresen pgp7OfNZMicfr.pgp Description: PGP signature
[gentoo-user] Re: KDE (mono to meta) migration
Bo Ørsted Andresen bo.andresen at zlin.dk writes:
You weren't. Blocks are only within the same slot. In fact the split packages
blocks only the monolithic package they belong to.
Sorry, my last response got butchered. Gmane get's rediculous somethings
borderline upsurd on it's request to make lines shorter and other response
formating issues.
I have gotten ride of all of the blocking, by unmerging everthing kde I could
find:
525 emerge --unmerge kde-base/kdegraphics
526 emerge --unmerge kde-base/kdemultimedia
snip
Before or after the emerge -uavDN kde-meta?
If you are removing stuff it doesn't matter. If you are remerging stuff it
should be after. If you do it before it will be built against the old version
again which is pretty pointless.
another pair of 'revdep-rebuild' seemed to have worked?
However, the last time I did this I got a ton of blocking isses.
One more retry. I post again if this does not work.
One of the KDE devs should put out a tool or script to completely
nuke kde, then let folks run
emerge -uavDN kde-meta' and be done with it. Disk space is cheap
and I do not have time to 'hack' at kde across 7 workstations.
Re compiling everything from from scratch is no bid deal. Waisting
lots of timer, per machine to migrate from monolithic to meta
has wasted quite a lot of time, and I still have 6 more machines to go.
So on the next machine, here's my steps to completely nuke kde
install kde-meta:
First:
# emerge --unmerge kde-base/kdeartwork
# emerge --unmerge kde-base/kdegames
# emerge --unmerge kde-base/kdeaddons
# emerge --unmerge kde-base/kdewebdev
# emerge --unmerge kde-base/kdeadmin
# emerge --unmerge kde-base/kdegraphics
# emerge --unmerge kde-base/kdemultimedia
# emerge --unmerge kde-base/kdepim
# emerge --unmerge kde-base/kdeutils
# emerge --unmerge kde-base/kdeedu
# emerge --unmerge kde-base/kdebase
# emerge --unmerge kde-base/kdetoys
Second:
Now remove all old kde 3.2, 3.3, and 3.4 kruft
# cd /var/db/pkg emerge -Cva kde-base/*-3.{2,3,4}*
# env-update source /etc/profile etc-update update-eix eupdatedb
Third:
clean up broken links
# revdep-rebuild -p
# revdep-rebuild
# emerge --sync
# env-update source /etc/profile etc-update
Fourth:
install kde-meta
emerge -uavDNp kde-meta
if blocking occurs, unmerge clocking packages and return to Second
emerge -uavDN kde-meta
Did I miss anything? Did I get anything out of order?
Please edit to make this a mechanical process, or add in
options at the right place to go the selection of
individual kde packages after installing kdebase-meta?
PS I sure hope this helps other avoid this time-sync.
sincerely,
James
James
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: KDE (mono to meta) migration
On Saturday 24 June 2006 18:05, James wrote:
One of the KDE devs should put out a tool or script to completely
nuke kde, then let folks run
emerge -uavDN kde-meta' and be done with it. Disk space is cheap
and I do not have time to 'hack' at kde across 7 workstations.
Re compiling everything from from scratch is no bid deal. Waisting
lots of timer, per machine to migrate from monolithic to meta
has wasted quite a lot of time, and I still have 6 more machines to go.
You seem to have been more confused than enlightened by the tricks I posted.
If you want to nuke kde completely you should just do:
# cd /var/db/pkg emerge -Cva kde-base/*
It's as simple as that. Both Neil and I told you that a long time ago. This
nukes both new and old slots. Both split and monolithic. And allows you to
start with kde from scratch.
So on the next machine, here's my steps to completely nuke kde
install kde-meta:
First:
[SNIP]
There is no reason call emerge 12 times. Just use one command:
# emerge --unmerge
kde-base/kde{,artwork,games,addons,webdev,admin,graphics,multimedia,pim,utils,edu,base,toys}
That changes nothing though (except you forgot to unmerge kde-base/kde - the
above command includes that too). And this is unnecessary if you nuked kde
completely.
Second:
Now remove all old kde 3.2, 3.3, and 3.4 kruft
# cd /var/db/pkg emerge -Cva kde-base/*-3.{2,3,4}*
That also is only necessary if you did not nuke kde completely.
# env-update source /etc/profile etc-update update-eix eupdatedb
This is completely pointless after unmerging something.
Third:
clean up broken links
# revdep-rebuild -p
# revdep-rebuild
You can do that after emerging kde-meta-3.5. No reason to do it before.
# emerge --sync
# env-update source /etc/profile etc-update
Again this is completely pointless at this time.
Fourth:
install kde-meta
emerge -uavDNp kde-meta
if blocking occurs, unmerge clocking packages and return to Second
emerge -uavDN kde-meta
Blocking won't occur if you already removed the monolithic packages.
Did I miss anything? Did I get anything out of order?
Please edit to make this a mechanical process, or add in
options at the right place to go the selection of
individual kde packages after installing kdebase-meta?
Now you should run revdep-rebuild. You need to make up your mind if you want
to nuke everything or not. You keep saying you want to nuke kde completely
and yet follow advice that avoids nuking it completely. Assuming you really
do want to nuke kde completely (on your other computers):
# cd /var/db/pkg emerge -Cva kde-base/*
# emerge -uva kde-meta
# revdep-rebuild -p
# revdep-rebuild
--
Bo Andresen
pgpRNucQwdQLY.pgp
Description: PGP signature
[gentoo-user] Re: KDE (mono to meta) migration
Bo Ørsted Andresen bo.andresen at zlin.dk writes:
You seem to have been more confused than enlightened by the tricks I posted.
If you want to nuke kde completely you should just do:
# cd /var/db/pkg emerge -Cva kde-base/*
It's as simple as that. Both Neil and I told you that a long time ago. This
nukes both new and old slots. Both split and monolithic. And allows you to
start with kde from scratch.
OK my bad/stupid/ineptness. OK?
Are these simple steps going to work?
If not please edit. I do not care about
extra compile time. I need a simple straightforward method
to nuke(unistall all of KDE) and install via kde-meta
First:#
nuke all occurances of kde
cd /var/db/pkg emerge -Cva kde-base/*
Second:
Ensure all the old kde kruft is gone 3.2, 3.3, and 3.4
# cd /var/db/pkg emerge -Cva kde-base/*-3.{2,3,4}*
# env-update source /etc/profile etc-update update-eix
# eupdatedb
Third:
clean up broken links
# revdep-rebuild -p
# revdep-rebuild
# emerge --sync
# env-update source /etc/profile etc-update
Fourth:
install kde-meta
# emerge -uavDNp kde-meta
if blocking occurs, unmerge blocking packages and return to First
# emerge -uavDN kde-meta
Did I miss anything? Did I get anything out of order?
Everyting went well, I just had lots of blocking packages when
I did not expect too?
(sorry about being a grouch lack of sleep...
James
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: KDE (mono to meta) migration
On Saturday 24 June 2006 19:21, James wrote:
Are these simple steps going to work?
If not please edit. I do not care about
extra compile time. I need a simple straightforward method
to nuke(unistall all of KDE) and install via kde-meta
First:#
nuke all occurances of kde
cd /var/db/pkg emerge -Cva kde-base/*
Good.
Second:
Ensure all the old kde kruft is gone 3.2, 3.3, and 3.4
# cd /var/db/pkg emerge -Cva kde-base/*-3.{2,3,4}*
This removes *nothing* that the first step didn't already remove.
# env-update source /etc/profile etc-update update-eix
# eupdatedb
This is still pointless. It does no harm and it changes nothing.
Third:
clean up broken links
# revdep-rebuild -p
# revdep-rebuild
# emerge --sync
# env-update source /etc/profile etc-update
Still pointless at this time.
Fourth:
install kde-meta
# emerge -uavDNp kde-meta
Good.
if blocking occurs, unmerge blocking packages and return to First
# emerge -uavDN kde-meta
Nothing will block if you followed the first step.
Did I miss anything? Did I get anything out of order?
Everyting went well, I just had lots of blocking packages when
I did not expect too?
The revdep-rebuild is good *after* emerging kde-meta. It will recompile third
party applications such as amarok against the new version of kde-meta. I
posted the simple steps at the bottom of my previous mail.
--
Bo Andresen
pgpsnn7iirJLP.pgp
Description: PGP signature
[gentoo-user] Re: KDE (mono to meta) migration
Bo Ørsted Andresen bo.andresen at zlin.dk writes: On Thursday 22 June 2006 18:28, James wrote: have looked at threads on this issue from 12jun06 and 2jun06 and http://www.gentoo.org/doc/en/kde-split-ebuilds.xml. By the way, this doc is good for explaining the issues, but does not explain a clear method to perform the migration form mono to meta.. Did you look at [1] too? Yes, That solves how to install a new kde (mono, meta, split) but does not really address cleanzing the sytem of all the old kde kruft. I have stuff from kde 3.2, 3.3., 3.4 on some of my older systems. Beside, my thoughts are to remove everthing and start from fresh, as I seem to be tracking down a multitude of kde related trivial issues on a variety of kde/gentoo systems I manage. Is there an easy way to remove all of the kde packages before migration to kde-meta? Sure. But it would remove packages that the meta packages depend on too. kde-base/kdelibs takes a long time to compile and hence shouldn't be removed as you still need it. Unless of course you need to upgrade it anyway. This might be feasible: #cd /var/db/pkg emerge -Cva `ls -d kde-base/* | grep -v -r 'kdelibs\|arts'` It will remove everything in the kde-base category except kdelibs and arts. Make sure to check what it removes before doing it. It shouldn't be more than 13 packages. [SNIP] But if meta is going away, like the monolithic kde packaging (eventually) I'd rather go straight to the split kde package system. Comments and Recommendations on kde-meta's future? Why would you think the kde-meta aka the split packages would be going away? They certainly won't. xfree_vs_xorg, dev_vs_udev, and now kde seem to need major surgery Historical experiences with Gentoo. Gentoo is great for the current new stuff, but often, I'm learning and dealing with minutia, I would prefer to avoid. When I do avoid the gentoo minutia, I get burned, like now having to move to meta or split. Granted, in the long run, these migrations have been good, but it's still painful (time consuming) to walk the gentoo path, at times Actually there aren't a lot of monolithic packages. [1] lists them all in a box in section 2. If you have all of them you still need to remove only 13 packages. Well, but, on some systems, I have kde files from 3.2, 3.3 and 3.4 and 3.5.2 now installed. I have a mess across 7 differnet gentoo workstations. These are the packages that would be merged, in reverse order: Calculating dependencies... done! .[blocks B ] =kde-base/kdemultimedia-3.5* (is blocking kde-base/kaboodle-3.5.2) .[blocks B ] =kde-base/kdemultimedia-3.5* (is blocking kde-base/kdemultimedia-kappfinder-data-3.5.2) This tells you that kde-base/kdemultimedia blocks both kaboodle and kdemultimedia-kappfinder-data. You only need to remove the one package kdemultimedia. It just blocks a lot of packages that are pulled in by kde-meta. [SNIP] From mono to split? Some gentoo/kde systems I manage will want to go to the split system or a few kde-meta packages and the rest of the kde(split) apps individually installed. Do what I said above or just remove the few packages manually when they block something. There really aren't that many. emerging any split package will work just as well as the meta packages. You should only use the meta packages if you wan't everything. [1] http://www.gentoo.org/doc/en/kde-config.xml I'll give it a whirl.. thx, James -- gentoo-user@gentoo.org mailing list
[gentoo-user] Re: KDE (mono to meta) migration
Neil Bothwick neil at digimed.co.uk writes: Is there an easy way to remove all of the kde packages before migration to kde-meta? See the thread form a couple of hours ago, Awe, yes, Gmane runs very slow during the day (EST), I see this recent discussion. I think you have misunderstood the purpose of the meta packages. They are simply empty packages that depend on various other packages. The old kde package was a meta-package that depended on the various monolithic builds, now there is a meta-package to replace each of the monolithic builds that depends on the split packages. kde-meta depend on all the split ebuilds. Yep, this explains quite a lot. Comments and Recommendations on kde-meta's future? The meta-packages won't be going away, they are even more important with the split ebuilds. they aren't exclusive to KDE either; gnome, gnome-light and xorg-x11-7* are all meta packages. Thanks for the information, this clears things up for me James -- gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: KDE (mono to meta) migration
Just showing a couple of tricks.
On Thursday 22 June 2006 20:15, James wrote:
Yes, That solves how to install a new kde (mono, meta, split) but
does not really address cleanzing the sytem of all the old kde kruft.
I have stuff from kde 3.2, 3.3., 3.4 on some of my older systems.
This removes everything in kde-base that is version 3.2, 3.3 or 3.4 (and
installed of course):
# cd /var/db/pkg emerge -Cva kde-base/*-3.{2,3,4}*
#cd /var/db/pkg emerge -Cva `ls -d kde-base/* | grep -v -r \
'kdelibs\|arts'`
One could add a version too so that only the newest version of kdelibs and
arts is kept since it is still required. Like this:
# cd /var/db/pkg emerge -Cva `ls kde-base | grep -v -r
'kdelibs-3\.5\.3\|arts-3\.5\.3'`
Beside, my thoughts are to remove everthing and start from fresh, as
I seem to be tracking down a multitude of kde related trivial issues
on a variety of kde/gentoo systems I manage.
This removes everything in kde-base. It's equivalent to Neils suggestion.
# cd /var/db/pkg emerge -Cva kde-base/*
Also after removing old slots there may still be third party apps left that has
been compiled against the old versions. They need to be remerged after the new
version of kde has been emerged to compile them against the new version and
remove the old cruft in /usr/kde/3.4 etc.
This will show you what packages still have cruft in /usr/kde/3.2 - 3.4:
# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
Unmerge what you don't need or remerge (after emerging kde 3.5) what you still
need. When you are done with that the above command should give no output and
any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong
to no package. Pay attention to what you do though. A revdep-rebuild before
this step will probably take care of most of this.
xfree_vs_xorg, dev_vs_udev, and now kde seem to need major surgery
Historical experiences with Gentoo. Gentoo is great for the current
new stuff, but often, I'm learning and dealing with minutia, I would
prefer to avoid. When I do avoid the gentoo minutia, I get burned,
like now having to move to meta or split. Granted, in the long run,
these migrations have been good, but it's still painful (time consuming)
to walk the gentoo path, at times
The split packages are replacing the monolithic. Not the other way around. And
KDE 4.x will get out next spring.
--
Bo Andresen
pgpCpEJCc04DU.pgp
Description: PGP signature
[gentoo-user] Re: KDE (mono to meta) migration
Bo Ørsted Andresen bo.andresen at zlin.dk writes:
This removes everything in kde-base that is version 3.2, 3.3 or 3.4 (and
installed of course):
# cd /var/db/pkg emerge -Cva kde-base/*-3.{2,3,4}*
Used this one. I'd rather clean it all out (KDE) and start over.
This removes everything in kde-base. It's equivalent to Neils suggestion.
# cd /var/db/pkg emerge -Cva kde-base/*
I then removed the monolithci packages by hand that are blocking
This is the command I used to see what is(was) blocking kde-meta:
emerge -uavDN kde-meta
Also after removing old slots there may still be third party apps left that
has
been compiled against the old versions. They need to be remerged after the new
version of kde has been emerged to compile them against the new version and
remove the old cruft in /usr/kde/3.4 etc.
This will show you what packages still have cruft in /usr/kde/3.2 - 3.4:
# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
Ok I'll do this after emerging kde-meta completes. I hope I was not suppose
to do this before 'emerge -uavDN kde-meta'
Right now the (test) workstation is compiling kde-meta. When that is done,
I'll report back my results. This way, maybe other folks can have a
concise method to clean out the old kde kruft and get fresh kde-meta
or kde-split(dealer's choice...)
Unmerge what you don't need or remerge (after emerging kde 3.5) what you still
need. When you are done with that the above command should give no output and
any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong
to no package. Pay attention to what you do though. A revdep-rebuild before
this step will probably take care of most of this.
Before or after the emerge -uavDN kde-meta?
James
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: KDE (mono to meta) migration
On Thursday 22 June 2006 22:12, James wrote: Ok I'll do this after emerging kde-meta completes. I hope I was not suppose to do this before 'emerge -uavDN kde-meta' You weren't. Blocks are only within the same slot. In fact the split packages blocks only the monolithic package they belong to. [SNIP] Unmerge what you don't need or remerge (after emerging kde 3.5) what you still need. When you are done with that the above command should give no output and any files still in /usr/kde/3.2 - 3.4 can be safely deleted since they belong to no package. Pay attention to what you do though. A revdep-rebuild before this step will probably take care of most of this. Before or after the emerge -uavDN kde-meta? If you are removing stuff it doesn't matter. If you are remerging stuff it should be after. If you do it before it will be built against the old version again which is pretty pointless. -- Bo Andresen pgplhWMuJSLMA.pgp Description: PGP signature
Re: [gentoo-user] Re: KDE (mono to meta) migration
On 22/06/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote:
This will show you what packages still have cruft in /usr/kde/3.2 - 3.4:
# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
It aborts on mine:
==
# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
find: /usr/kde/3.2: No such file or directory
find: /usr/kde/3.3: No such file or directory
find: /usr/kde/3.4: No such file or directory
List all packages owning a particular set of files
Note: Normally, only one package will own a file. If multiple packages
own the same file, it usually consitutes a problem, and should be
reported.
Syntax:
belongs local-opts filename
local-opts is either of:
-c, --category cat - only search in category cat
-f, --full-regex - supplied query is a regex
-e, --earlyout - stop when first match is found
-n, --name-only- don't print the version.
xargs: equery: exited with status 255; aborting
==
What gives?
--
Regards,
Mick
--
gentoo-user@gentoo.org mailing list
Re: [gentoo-user] Re: KDE (mono to meta) migration
On Thursday 22 June 2006 23:48, Mick wrote:
It aborts on mine:
==
# find /usr/kde/3.{2,3,4} | xargs equery belongs | cat
find: /usr/kde/3.2: No such file or directory
find: /usr/kde/3.3: No such file or directory
find: /usr/kde/3.4: No such file or directory
List all packages owning a particular set of files
Obviously you don't have any cruft from 3.2, 3.3 or 3.4 on that system. So all
is good.
--
Bo Andresen
pgpz24S9aTaQM.pgp
Description: PGP signature
Re: [gentoo-user] Re: KDE (mono to meta) migration
On 22/06/06, Bo Ørsted Andresen [EMAIL PROTECTED] wrote: Obviously you don't have any cruft from 3.2, 3.3 or 3.4 on that system. So all is good. Phew! :-)) Thanks for the nice tips! I have bookmarked it. -- Regards, Mick -- gentoo-user@gentoo.org mailing list
