[gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Mark Haney]

Well, I decided to take the plunge and install KDE4 based on the 
directions at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.

The installation went well (with a re-install of qt4 due to a missing 
use flag) and it was on to restarting the system so I could start 
mucking with the new interface.  And that's where I hit a snag.

In the URL above, the directions say to change /etc/conf.d/xdm, the 
DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just 
xdm instead as a login screen and then, after log in, got my same KDE3.5 
desktop.  There are no other directions on this page, so now I don't 
know where to go from here.

What now?

-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of. [UPDATE]

[Mark Haney]

Mark Haney wrote:
> Well, I decided to take the plunge and install KDE4 based on the 
> directions at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.
> 
> The installation went well (with a re-install of qt4 due to a missing 
> use flag) and it was on to restarting the system so I could start 
> mucking with the new interface.  And that's where I hit a snag.
> 
> In the URL above, the directions say to change /etc/conf.d/xdm, the 
> DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just 
> xdm instead as a login screen and then, after log in, got my same KDE3.5 
> desktop.  There are no other directions on this page, so now I don't 
> know where to go from here.
> 
> What now?
> 

I've done more testing and still no KDE4 running.  I realized I had 
/etc/rc.conf edited to start kde3.5 as well, so I changed it, but 
there's a catch to this.  If I edit DISPLAYMANAGER to 'KDE-4.0' I can't 
set it that way in rc.conf, which looks at /etc/X11/Sessions for it's 
info (apparently).  An ls of that directory doesn't show 'kde-4.0' it 
only has 'kde-4'.  So, when I edited rc.conf for 'kde-4', I still got 
the old school XDM session, but I got an error about the ~/.kde symlink 
being wrong.  I assume that's progress, but I don't know.  I still don't 
get KDE4 on my system, so I'm stuck.  Anyone got any ideas?



-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Mittwoch, 28. Mai 2008, Mark Haney wrote:
> Well, I decided to take the plunge and install KDE4 based on the
> directions at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.
>
> The installation went well (with a re-install of qt4 due to a missing
> use flag) and it was on to restarting the system so I could start
> mucking with the new interface.  And that's where I hit a snag.
>
> In the URL above, the directions say to change /etc/conf.d/xdm, the
> DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just
> xdm instead as a login screen and then, after log in, got my same KDE3.5
> desktop.  There are no other directions on this page, so now I don't
> know where to go from here.
>
> What now?
>

use kdm 3.5 for login. It really does not matter which one you use.

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Mark Haney]

Hemmann, Volker Armin wrote:
> On Mittwoch, 28. Mai 2008, Mark Haney wrote:
>   
>> Well, I decided to take the plunge and install KDE4 based on the
>> directions at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.
>>
>> The installation went well (with a re-install of qt4 due to a missing
>> use flag) and it was on to restarting the system so I could start
>> mucking with the new interface.  And that's where I hit a snag.
>>
>> In the URL above, the directions say to change /etc/conf.d/xdm, the
>> DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just
>> xdm instead as a login screen and then, after log in, got my same KDE3.5
>> desktop.  There are no other directions on this page, so now I don't
>> know where to go from here.
>>
>> What now?
>>
>>     
>
> use kdm 3.5 for login. It really does not matter which one you use.
>
>   
I'm afraid I don't understand what you mean?


-- 
"Beware the leader who bangs the drums of war in order to whip the citizenry into a patriotic fervor, for patriotism is indeed a double-edged sword. It emboldens the blood, just as it narrows the mind. And when the drums of war have reached a fever pitch and the blood boils with hate and the mind has closed, the leader will have no need in seizing the rights of the citizenry. Rather the citizenry, infused with fear and blinded by patriotism, will offer up all of their rights unto the leader and gladly so. How do I know? For this is what I have done. And I am Caesar."

-Julius Caesar

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Mittwoch, 28. Mai 2008, Mark Haney wrote:
> Hemmann, Volker Armin wrote:
> > On Mittwoch, 28. Mai 2008, Mark Haney wrote:
> >> Well, I decided to take the plunge and install KDE4 based on the
> >> directions at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.
> >>
> >> The installation went well (with a re-install of qt4 due to a missing
> >> use flag) and it was on to restarting the system so I could start
> >> mucking with the new interface.  And that's where I hit a snag.
> >>
> >> In the URL above, the directions say to change /etc/conf.d/xdm, the
> >> DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just
> >> xdm instead as a login screen and then, after log in, got my same KDE3.5
> >> desktop.  There are no other directions on this page, so now I don't
> >> know where to go from here.
> >>
> >> What now?
> >
> > use kdm 3.5 for login. It really does not matter which one you use.
>
> I'm afraid I don't understand what you mean

you have kde3.5 installed. use the old kdm and just log in.

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/28 Mark Haney <mhaney@ercbroadband.org>:

> Well, I decided to take the plunge and install KDE4 based on the directions
> at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.
>
> The installation went well (with a re-install of qt4 due to a missing use
> flag) and it was on to restarting the system so I could start mucking with
> the new interface.  And that's where I hit a snag.
>
> In the URL above, the directions say to change /etc/conf.d/xdm, the
> DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just xdm
> instead as a login screen and then, after log in, got my same KDE3.5
> desktop.  There are no other directions on this page, so now I don't know
> where to go from here.
>
> What now?
>
> --
> Libenter homines id quod volunt credunt -- Caius Julius Caesar
>
>
> Mark Haney
> Sr. Systems Administrator
> ERC Broadband
> (828) 350-2415
>
> Call (866) ERC-7110 for after hours support
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>

you have to add the DYSPLAYMANAGER=kdm-4.0 to a file in /etc/env.d/ better
the local environment file, then BE SURE to have installed the following:
kdebase-startkde-4.0.x and kdebase-meta-4.0.x. after that remember to do an
etc-update (or dispatch-conf or whatever utility you use for updating the
/etc) and then do an env-update and a /etc/init.d/xdm restart. also you
should look if xdm has been overwritten (it has to be since)  and if i
remember well also /etc/conf.d/xdm.conf also has changed. then at kdm login
screen select the session type and login. it should work. but e aware that
if you're on xorg-server from git kde4 will most likely don't work.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Mark Haney]

Beso wrote:
> 2008/5/28 Mark Haney <mhaney@ercbroadband.org>:
> 
>> Well, I decided to take the plunge and install KDE4 based on the directions
>> at http://www.gentoo.org/proj/en/desktop/kde/kde4.xml.
>>
>> The installation went well (with a re-install of qt4 due to a missing use
>> flag) and it was on to restarting the system so I could start mucking with
>> the new interface.  And that's where I hit a snag.
>>
>> In the URL above, the directions say to change /etc/conf.d/xdm, the
>> DISPLAYMANAGER variable to kdm-4.0.  Every time I tried that, I got just xdm
>> instead as a login screen and then, after log in, got my same KDE3.5
>> desktop.  There are no other directions on this page, so now I don't know
>> where to go from here.
>>
>> What now?
>>
>> --
>> Libenter homines id quod volunt credunt -- Caius Julius Caesar
>>
>>
>> Mark Haney
>> Sr. Systems Administrator
>> ERC Broadband
>> (828) 350-2415
>>
>> Call (866) ERC-7110 for after hours support
>> --
>> gentoo-amd64@lists.gentoo.org mailing list
>>
>>
> 
> you have to add the DYSPLAYMANAGER=kdm-4.0 to a file in /etc/env.d/ better
> the local environment file, then BE SURE to have installed the following:
> kdebase-startkde-4.0.x and kdebase-meta-4.0.x. after that remember to do an
> etc-update (or dispatch-conf or whatever utility you use for updating the
> /etc) and then do an env-update and a /etc/init.d/xdm restart. also you
> should look if xdm has been overwritten (it has to be since)  and if i
> remember well also /etc/conf.d/xdm.conf also has changed. then at kdm login
> screen select the session type and login. it should work. but e aware that
> if you're on xorg-server from git kde4 will most likely don't work.
> 

Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd prefer 
to have a chance to fall back on to 3.5.9 if I need to.

And what file in /etc/env.d do I need to add that to?  I'm not sure 
which one I should edit.


-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Donnerstag, 29. Mai 2008, Mark Haney wrote:

> Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd prefer
> to have a chance to fall back on to 3.5.9 if I need to.

you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time. I do...
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/29 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:

> On Donnerstag, 29. Mai 2008, Mark Haney wrote:
>
> > Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd prefer
> > to have a chance to fall back on to 3.5.9 if I need to.
>
> you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time. I
> do...
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
you aren't forced to have it installed but since the deps aren't fully ok
nowadays the kdebase-meta-4.0.4 is good to be installed. and since it's a
slotted install (as almost all gentoo major bump versions or even minor in
some cases as python, gcc, java, autotools and autoconf for example) they
are likely to not interfere with each others. you'll just have to make a
copy of your .kde folder. the first time you'll login the system will create
a .kde3.5, a .kde4 and a .kde symlink in your home directory. the first is
the config for the 3.5 enviroment, the second for the kde4 one and the
symlink points to the last environment you've used and after login is
pointing to the in use environment. if you haven't started yet kde4 and find
a .kde4 folder in your home directory then move it elsewhere and retry a
login after installing the kdebase-meta-4.0.4. this is the minimum required
package along with kdebase-startkde-4.0.4 to be able to use kde4. if you
don't like it then just remove the kde4 slot packages and you'll stay with
kde3.5. just remember that a qt rebuild needs a kdelibs rebuild: the qt4
needs  also the kdelibs-3.5.x rebuild to have the qt4 apps still working in
the correct way (lastfm would display only broken stuff without kdelibs
rebuild after a qt4 upgrade/rebuild), while the qt3 doesn't need a
kdelibs-4.0.4 rebuild, but only a kdelibs-3.5.x one. i'd also advice you to
leave the 4.0.4 branch and test the 4.1 beta one (seems to be better in
terms of quality and usability than 4.0.4 one).

-- 
dott. ing. beso

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

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Mark Haney]

Beso wrote:
> 2008/5/29 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:
> 
>> On Donnerstag, 29. Mai 2008, Mark Haney wrote:
>>
>>> Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd prefer
>>> to have a chance to fall back on to 3.5.9 if I need to.
>> you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time. I
>> do...
>> --
>> gentoo-amd64@lists.gentoo.org mailing list
>>
>>
> you aren't forced to have it installed but since the deps aren't fully ok
> nowadays the kdebase-meta-4.0.4 is good to be installed. and since it's a
> slotted install (as almost all gentoo major bump versions or even minor in
> some cases as python, gcc, java, autotools and autoconf for example) they
> are likely to not interfere with each others. you'll just have to make a
> copy of your .kde folder. the first time you'll login the system will create
> a .kde3.5, a .kde4 and a .kde symlink in your home directory. the first is
> the config for the 3.5 enviroment, the second for the kde4 one and the
> symlink points to the last environment you've used and after login is
> pointing to the in use environment. if you haven't started yet kde4 and find
> a .kde4 folder in your home directory then move it elsewhere and retry a
> login after installing the kdebase-meta-4.0.4. this is the minimum required
> package along with kdebase-startkde-4.0.4 to be able to use kde4. if you
> don't like it then just remove the kde4 slot packages and you'll stay with
> kde3.5. just remember that a qt rebuild needs a kdelibs rebuild: the qt4
> needs  also the kdelibs-3.5.x rebuild to have the qt4 apps still working in
> the correct way (lastfm would display only broken stuff without kdelibs
> rebuild after a qt4 upgrade/rebuild), while the qt3 doesn't need a
> kdelibs-4.0.4 rebuild, but only a kdelibs-3.5.x one. i'd also advice you to
> leave the 4.0.4 branch and test the 4.1 beta one (seems to be better in
> terms of quality and usability than 4.0.4 one).
> 

Hey, I'll all for testing 4.1, but how do I get it?  I don't see it in 
portage?



-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 Mark Haney <mhaney@ercbroadband.org>:

> Beso wrote:
>
>> 2008/5/29 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:
>>
>>  On Donnerstag, 29. Mai 2008, Mark Haney wrote:
>>>
>>>  Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd prefer
>>>> to have a chance to fall back on to 3.5.9 if I need to.
>>>>
>>> you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time. I
>>> do...
>>> --
>>> gentoo-amd64@lists.gentoo.org mailing list
>>>
>>>
>>>  you aren't forced to have it installed but since the deps aren't fully
>> ok
>> nowadays the kdebase-meta-4.0.4 is good to be installed. and since it's a
>> slotted install (as almost all gentoo major bump versions or even minor in
>> some cases as python, gcc, java, autotools and autoconf for example) they
>> are likely to not interfere with each others. you'll just have to make a
>> copy of your .kde folder. the first time you'll login the system will
>> create
>> a .kde3.5, a .kde4 and a .kde symlink in your home directory. the first is
>> the config for the 3.5 enviroment, the second for the kde4 one and the
>> symlink points to the last environment you've used and after login is
>> pointing to the in use environment. if you haven't started yet kde4 and
>> find
>> a .kde4 folder in your home directory then move it elsewhere and retry a
>> login after installing the kdebase-meta-4.0.4. this is the minimum
>> required
>> package along with kdebase-startkde-4.0.4 to be able to use kde4. if you
>> don't like it then just remove the kde4 slot packages and you'll stay with
>> kde3.5. just remember that a qt rebuild needs a kdelibs rebuild: the qt4
>> needs  also the kdelibs-3.5.x rebuild to have the qt4 apps still working
>> in
>> the correct way (lastfm would display only broken stuff without kdelibs
>> rebuild after a qt4 upgrade/rebuild), while the qt3 doesn't need a
>> kdelibs-4.0.4 rebuild, but only a kdelibs-3.5.x one. i'd also advice you
>> to
>> leave the 4.0.4 branch and test the 4.1 beta one (seems to be better in
>> terms of quality and usability than 4.0.4 one).
>>
>>
> Hey, I'll all for testing 4.1, but how do I get it?  I don't see it in
> portage?
>

there's a thread on the forum about installing the 4.1 beta 1 on gentoo. i
think that in the next weeks the rc might hit portage in the second half of
june.



-- 
dott. ing. beso

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

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 Beso <givemesugarr@gmail.com>:

> 2008/5/30 Mark Haney <mhaney@ercbroadband.org>:
>
>> Beso wrote:
>>
>>> 2008/5/29 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:
>>>
>>>  On Donnerstag, 29. Mai 2008, Mark Haney wrote:
>>>>
>>>>  Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd
>>>>> prefer
>>>>> to have a chance to fall back on to 3.5.9 if I need to.
>>>>>
>>>> you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time. I
>>>> do...
>>>> --
>>>> gentoo-amd64@lists.gentoo.org mailing list
>>>>
>>>>
>>>>  you aren't forced to have it installed but since the deps aren't fully
>>> ok
>>> nowadays the kdebase-meta-4.0.4 is good to be installed. and since it's a
>>> slotted install (as almost all gentoo major bump versions or even minor
>>> in
>>> some cases as python, gcc, java, autotools and autoconf for example) they
>>> are likely to not interfere with each others. you'll just have to make a
>>> copy of your .kde folder. the first time you'll login the system will
>>> create
>>> a .kde3.5, a .kde4 and a .kde symlink in your home directory. the first
>>> is
>>> the config for the 3.5 enviroment, the second for the kde4 one and the
>>> symlink points to the last environment you've used and after login is
>>> pointing to the in use environment. if you haven't started yet kde4 and
>>> find
>>> a .kde4 folder in your home directory then move it elsewhere and retry a
>>> login after installing the kdebase-meta-4.0.4. this is the minimum
>>> required
>>> package along with kdebase-startkde-4.0.4 to be able to use kde4. if you
>>> don't like it then just remove the kde4 slot packages and you'll stay
>>> with
>>> kde3.5. just remember that a qt rebuild needs a kdelibs rebuild: the qt4
>>> needs  also the kdelibs-3.5.x rebuild to have the qt4 apps still working
>>> in
>>> the correct way (lastfm would display only broken stuff without kdelibs
>>> rebuild after a qt4 upgrade/rebuild), while the qt3 doesn't need a
>>> kdelibs-4.0.4 rebuild, but only a kdelibs-3.5.x one. i'd also advice you
>>> to
>>> leave the 4.0.4 branch and test the 4.1 beta one (seems to be better in
>>> terms of quality and usability than 4.0.4 one).
>>>
>>>
>> Hey, I'll all for testing 4.1, but how do I get it?  I don't see it in
>> portage?
>>
>
> there's a thread on the forum about installing the 4.1 beta 1 on gentoo. i
> think that in the next weeks the rc might hit portage in the second half of
> june.
>
>
forgotten the thread link:

http://forums.gentoo.org/viewtopic-p-5106540.html#5106540




-- 
dott. ing. beso

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

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Mark Haney]

Beso wrote:
> 2008/5/30 Beso <givemesugarr@gmail.com>:
> 
>> 2008/5/30 Mark Haney <mhaney@ercbroadband.org>:
>>
>>> Beso wrote:
>>>
>>>> 2008/5/29 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:
>>>>
>>>>  On Donnerstag, 29. Mai 2008, Mark Haney wrote:
>>>>>  Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd
>>>>>> prefer
>>>>>> to have a chance to fall back on to 3.5.9 if I need to.
>>>>>>
>>>>> you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time. I
>>>>> do...
>>>>> --
>>>>> gentoo-amd64@lists.gentoo.org mailing list
>>>>>
>>>>>
>>>>>  you aren't forced to have it installed but since the deps aren't fully
>>>> ok
>>>> nowadays the kdebase-meta-4.0.4 is good to be installed. and since it's a
>>>> slotted install (as almost all gentoo major bump versions or even minor
>>>> in
>>>> some cases as python, gcc, java, autotools and autoconf for example) they
>>>> are likely to not interfere with each others. you'll just have to make a
>>>> copy of your .kde folder. the first time you'll login the system will
>>>> create
>>>> a .kde3.5, a .kde4 and a .kde symlink in your home directory. the first
>>>> is
>>>> the config for the 3.5 enviroment, the second for the kde4 one and the
>>>> symlink points to the last environment you've used and after login is
>>>> pointing to the in use environment. if you haven't started yet kde4 and
>>>> find
>>>> a .kde4 folder in your home directory then move it elsewhere and retry a
>>>> login after installing the kdebase-meta-4.0.4. this is the minimum
>>>> required
>>>> package along with kdebase-startkde-4.0.4 to be able to use kde4. if you
>>>> don't like it then just remove the kde4 slot packages and you'll stay
>>>> with
>>>> kde3.5. just remember that a qt rebuild needs a kdelibs rebuild: the qt4
>>>> needs  also the kdelibs-3.5.x rebuild to have the qt4 apps still working
>>>> in
>>>> the correct way (lastfm would display only broken stuff without kdelibs
>>>> rebuild after a qt4 upgrade/rebuild), while the qt3 doesn't need a
>>>> kdelibs-4.0.4 rebuild, but only a kdelibs-3.5.x one. i'd also advice you
>>>> to
>>>> leave the 4.0.4 branch and test the 4.1 beta one (seems to be better in
>>>> terms of quality and usability than 4.0.4 one).
>>>>
>>>>
>>> Hey, I'll all for testing 4.1, but how do I get it?  I don't see it in
>>> portage?
>>>
>> there's a thread on the forum about installing the 4.1 beta 1 on gentoo. i
>> think that in the next weeks the rc might hit portage in the second half of
>> june.
>>
>>
> forgotten the thread link:
> 
> http://forums.gentoo.org/viewtopic-p-5106540.html#5106540
> 
> 
> 
> 
Thanks for the URL. I've never dealt with overlays before, but I"m open 
to it.  My question is, if I use the kde4.1 overlay how do I get rid of 
it, when the time comes that 4.1 is in portage?  If I delete the overlay 
does that delete the packages that were installed with it?  I read the 
UG on it, but it wasn't very clear.


-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 Mark Haney <mhaney@ercbroadband.org>:

> Beso wrote:
>
>> 2008/5/30 Beso <givemesugarr@gmail.com>:
>>
>>  2008/5/30 Mark Haney <mhaney@ercbroadband.org>:
>>>
>>>  Beso wrote:
>>>>
>>>>  2008/5/29 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de
>>>>> >:
>>>>>
>>>>>  On Donnerstag, 29. Mai 2008, Mark Haney wrote:
>>>>>
>>>>>>  Do I NEED kde-meta-4.0 installed?  The HOWTO says otherwise.  I'd
>>>>>>
>>>>>>> prefer
>>>>>>> to have a chance to fall back on to 3.5.9 if I need to.
>>>>>>>
>>>>>>>  you can have kde-meta-4.0.4 and kde3.5.9 installed at the same time.
>>>>>> I
>>>>>> do...
>>>>>> --
>>>>>> gentoo-amd64@lists.gentoo.org mailing list
>>>>>>
>>>>>>
>>>>>>  you aren't forced to have it installed but since the deps aren't
>>>>>> fully
>>>>>>
>>>>> ok
>>>>> nowadays the kdebase-meta-4.0.4 is good to be installed. and since it's
>>>>> a
>>>>> slotted install (as almost all gentoo major bump versions or even minor
>>>>> in
>>>>> some cases as python, gcc, java, autotools and autoconf for example)
>>>>> they
>>>>> are likely to not interfere with each others. you'll just have to make
>>>>> a
>>>>> copy of your .kde folder. the first time you'll login the system will
>>>>> create
>>>>> a .kde3.5, a .kde4 and a .kde symlink in your home directory. the first
>>>>> is
>>>>> the config for the 3.5 enviroment, the second for the kde4 one and the
>>>>> symlink points to the last environment you've used and after login is
>>>>> pointing to the in use environment. if you haven't started yet kde4 and
>>>>> find
>>>>> a .kde4 folder in your home directory then move it elsewhere and retry
>>>>> a
>>>>> login after installing the kdebase-meta-4.0.4. this is the minimum
>>>>> required
>>>>> package along with kdebase-startkde-4.0.4 to be able to use kde4. if
>>>>> you
>>>>> don't like it then just remove the kde4 slot packages and you'll stay
>>>>> with
>>>>> kde3.5. just remember that a qt rebuild needs a kdelibs rebuild: the
>>>>> qt4
>>>>> needs  also the kdelibs-3.5.x rebuild to have the qt4 apps still
>>>>> working
>>>>> in
>>>>> the correct way (lastfm would display only broken stuff without kdelibs
>>>>> rebuild after a qt4 upgrade/rebuild), while the qt3 doesn't need a
>>>>> kdelibs-4.0.4 rebuild, but only a kdelibs-3.5.x one. i'd also advice
>>>>> you
>>>>> to
>>>>> leave the 4.0.4 branch and test the 4.1 beta one (seems to be better in
>>>>> terms of quality and usability than 4.0.4 one).
>>>>>
>>>>>
>>>>>  Hey, I'll all for testing 4.1, but how do I get it?  I don't see it in
>>>> portage?
>>>>
>>>>  there's a thread on the forum about installing the 4.1 beta 1 on
>>> gentoo. i
>>> think that in the next weeks the rc might hit portage in the second half
>>> of
>>> june.
>>>
>>>
>>>  forgotten the thread link:
>>
>> http://forums.gentoo.org/viewtopic-p-5106540.html#5106540
>>
>>
>>
>>
>>  Thanks for the URL. I've never dealt with overlays before, but I"m open
> to it.  My question is, if I use the kde4.1 overlay how do I get rid of it,
> when the time comes that 4.1 is in portage?  If I delete the overlay does
> that delete the packages that were installed with it?  I read the UG on it,
> but it wasn't very clear.
>

you unistall it and install the new slot. the kde 4.1 should have the kde4
slot while the kde4.1 beta has the kde4-live slot. you can clearly see that
they're different slots and that removing one doesn't prevent you from using
the other. anyway, in my opinion that overlay will die after the kde4.1 will
hit portage or soon after that.

-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805300619v2631c50exe0dfa95ea11e2c34@mail.gmail.com, excerpted
below, on  Fri, 30 May 2008 13:19:08 +0000:

> you unistall it and install the new slot. the kde 4.1 should have the
> kde4 slot while the kde4.1 beta has the kde4-live slot. you can clearly
> see that they're different slots and that removing one doesn't prevent
> you from using the other. anyway, in my opinion that overlay will die
> after the kde4.1 will hit portage or soon after that.

Do the KDE-live builds require paludis?  I recall reading that they were 
headed that way, because it could support an EAPI with needed features 
while portage couldn't yet.  Those builds were live only and were to stay 
in the overlay since packages in the main tree must support portage.  It 
was the non-live snapshot versions that were the portage ebuilds, to 
eventually be targeted at the tree, after they became release ebuilds, of 
course.

I've not done paludis due to its lack of binary package support.  Even 
tho I'm running only a single computer, I use binary packages for 
installation backups and handy lookup reference since I can just dig in 
the appropriate package tarball to see what an old version of a file 
looked like, so lack of binary package support is as far as I'm concerned 
a blocker, here.  But I guess it hasn't been a priority (sort of like 
proxy support in KDE4, from what I read).  <shrug>  If it works for 
them... but it's not going to work for me without it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 Duncan <1i5t5.duncan@cox.net>:

> Beso <givemesugarr@gmail.com> posted
> d257c3560805300619v2631c50exe0dfa95ea11e2c34@mail.gmail.com, excerpted
> below, on  Fri, 30 May 2008 13:19:08 +0000:
>
> > you unistall it and install the new slot. the kde 4.1 should have the
> > kde4 slot while the kde4.1 beta has the kde4-live slot. you can clearly
> > see that they're different slots and that removing one doesn't prevent
> > you from using the other. anyway, in my opinion that overlay will die
> > after the kde4.1 will hit portage or soon after that.
>
> Do the KDE-live builds require paludis?  I recall reading that they were
> headed that way, because it could support an EAPI with needed features
> while portage couldn't yet.  Those builds were live only and were to stay
> in the overlay since packages in the main tree must support portage.  It
> was the non-live snapshot versions that were the portage ebuilds, to
> eventually be targeted at the tree, after they became release ebuilds, of
> course.
>

the kde svn overlay yes, but from what i've read there's a new overlay which
includes the 4.0.80 version (the 4.1 beta) which is usable with portage. the
other overlay is the real development trunk so there quite a huge movement
in it. also it doesn't really make sense to use binpkg for a svn or git
ebuild that continues to change. it would mean a real huge amount of hd
space.  this tree instead is the official 4.1 branch and should have some
sort of borders in which development would stay.


> I've not done paludis due to its lack of binary package support.  Even
> tho I'm running only a single computer, I use binary packages for
> installation backups and handy lookup reference since I can just dig in
> the appropriate package tarball to see what an old version of a file
> looked like, so lack of binary package support is as far as I'm concerned
> a blocker, here.  But I guess it hasn't been a priority (sort of like
> proxy support in KDE4, from what I read).  <shrug>  If it works for
> them... but it's not going to work for me without it.
>

proxy support is working very well in kde4 (i'm actually using it without
any issues). the problem is konqueror that isn't much compatible with sites
designed for firefox and it isn't yet able to play well with flash. the
binpkg in paludis isn't present as far as i know.


-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805301217q5af4d9c3rc3ea014a012fe04f@mail.gmail.com, excerpted
below, on  Fri, 30 May 2008 19:17:59 +0000:

> 2008/5/30 Duncan <1i5t5.duncan@cox.net>:

>> Do the KDE-live builds require paludis?  I recall reading that they
>> were headed that way, because it could support an EAPI with needed
>> features while portage couldn't yet.  Those builds were live only and
>> were to stay in the overlay since packages in the main tree must
>> support portage.

> the kde svn overlay yes, but from what i've read there's a new overlay
> which includes the 4.0.80 version (the 4.1 beta) which is usable with
> portage. the other overlay is the real development trunk so there quite
> a huge movement in it.

OK, thanks.  I wasn't aware of the other overlay, so that's news to me.  
The split does make sense, however, given that something semi-stable will 
eventually need to find its way to the tree, and by definition, the tree 
version would need to work with portage.

> also it doesn't really make sense to use binpkg
> for a svn or git ebuild that continues to change. it would mean a real
> huge amount of hd space.

I did it for awhile and didn't find space to be anything like an issue.  
Of course, "huge" would be relative to today's even "huger" disks, which 
could be considered the reason I didn't find it an issue.

As currently auto-handled, you have a bit of a point in that binpkgs 
don't make a lot of sense in the live-vcs environment, since it's the 
same "version" changed and remerged, thus overwriting the binpkg.  With 
normal versioning that's of course not an issue, since the versions 
change, so the binpkg filenames change and are not overwritten.  Thus 
it's possible to use the previous binpkgs to rollback to previous 
versions, or for reference, to peak inside them and see how say a config 
file changed between versions.  That's exactly the sorts of things I do 
with binpkgs, and you are correct, an overwritten binpkg isn't much help 
in that regard.

However, before I decided I was a bit too early in following the KDE4 
process for my needs and thus gave it up for the time being, I had 
decided to create a script that would have gathered up all the KDE4 
tarballs and saved them off to a dated subdir somewhere so they wouldn't 
have been overwritten each time I updated.  I could have then used 
logrotate or cron to setup a scheduled thinning down of the backups 
(keeping say the three last rollback versions, then one from each week 
for a month, addressing the accumulating space issue).  That would have 
effectively given me date-versioned fallbacks, thus filling the purpose 
binpkgs normally fill for me.

The reason I wasn't doing it before is that while I had had a chance to 
get the builds merging successfully and was in general keeping up with 
that (thanks to a nicely powerful machine), until then I hadn't really 
had a good chance to actually test it operationally.  Thus, if there were 
any regressions, I'd have (1) likely not even known it, and (2) wasn't 
actually depending on anything anyway.  I realized, however, that if I 
were to find it workable and try to start using it, since it was live-SVN 
I was running, I'd need a way to revert if something broke.  (Actually, 
there /was/ some big breakage at a few points, from what I read, as they 
merged some stuff before the other stuff needed to regain the former 
functionality.  So the case for keeping rollbacks around was a very good 
one!).  Thus the scripts I intended to write, to give me binary rollback 
capabilities even in the case of live version builds that would 
ordinarily overwrite each other.

As it happened, once I had a chance to actually test it, enough 
functionality I depended on was still missing, that I scrapped the entire 
testing process... which was all good anyway, since a couple weeks later 
was when the discussion on the dev list about them now requiring paludis 
took place.

> this tree instead is the official 4.1 branch
> and should have some sort of borders in which development would stay.

Makes sense and follows the plan they were in the process of developing 
when I split, tho I didn't know about the paludis angle at that time.

>> But I guess it hasn't been a priority (sort of like proxy support in
>> KDE4, from what I read).  <shrug>  If it works for them... but it's
>> not going to work for me without it.
>>
>>
> proxy support is working very well in kde4 (i'm actually using it
> without any issues). the problem is konqueror that isn't much compatible
> with sites designed for firefox and it isn't yet able to play well with
> flash. the binpkg in paludis isn't present as far as i know.

??

The flash and etc. stuff isn't a big deal, certainly for those used to 
dealing with KDE3 konqueror where the slaveryware Adobe Flash plugin 
might have worked, but where I never /did/ get either gnash or swfdec-
mozilla working, tho they worked in IceWeasel.  

Actually, for flash (read youtube since that's about all the flash I care 
about), I used iceweasel/firefox with swfdec for awhile, but couldn't 
keep it working reliably, apparently due to dependency merge order issues 
such that it worked if things had been upgraded in the right order, but 
failed as soon as an update came to one of the several, that killed the 
order again.   Then I used iceweasel with a download plugin to download 
the *.flv and played it in kaffeine, better player environment anyway, 
but it was a hassle downloading, playing, and deleting all those files 
manually.  I scrapped swfdec and depends, tho, since I never did figure 
out what magic order they needed to be merged in to reliably work.

Just recently, I found and merged the kde-misc/youtube-servicemenu 
package.  This is what I had been looking for, as it allowed me to 
download youtube videos from konqueror, even without a working plugin to 
view them in konqueror.  It integrated with the desktop better too 
(unsurprising, being KDE), so manually dealing with all those downloaded 
and mostly played and deleted files was much easier.  I continue to 
actually play them in kaffeine, which works much better than trying to 
play them in a tiny segment of the browser window did back on iceweasel 
even when it did work.  

So, hoping/assuming the same youtube-servicemenu package will continue to 
work or they will update it and that'll work, I don't anticipate a whole 
lot of problems there.  (It shouldn't be a major problem, and even if the 
service menu mechanism is changed a bit, I expect I could do the 
necessary fixes here if needed, since it's basically just a MIME-type 
association and a couple scripts.)

However, the proxy stuff I'm now confused on, as you say it works, but 
the comments on the KDE 4.1 beta announcement on the dot say otherwise, 
several people agreed, and nobody, last I checked, corrected them saying 
it worked.

http://dot.kde.org/1211898836/

Now that I look again, there's a mention of a patch, with a comment that 
it fixes socks5 but breaks std http proxy.  So maybe it's only socks-
proxy support that was broken (apparently in 4.0 as well) and that is 
what all the complaints have been about, but std http-proxy support has 
worked.  If so, that's /some/ better than I had though.  I think the 
privoxy I use here as a personal ad-busting junk-rewriting proxy is std 
http, for instance, so it shouldn't be an issue here.  However, it's 
apparently a blocker for many, those who'd be using it on desktops 
connected thru a socks proxy at work, that they have no control over and 
no choice of direct route to the Internet, for instance.  It's still a 
pretty basic feature.

Not to sound too whiny (probably too late =8^( ), but it also appears 
that while multiple panels and panel configs are now working (that was 
the blocker for me earlier, post 4.0 on the 4.1 trunk but still early in 
it, I tried desktop applets instead but the functionality I needed just 
wasn't there, and couldn't be made to be there), panel-autohide isn't, in 
the beta.  It's apparently still on the 4.1 list, even tho feature freeze 
has hit, so maybe there's hope if it was mostly implemented and it's a 
bug they can fix to get it working again.  I don't use it a lot on my KDE 
3.5.9 desktop; at dual 1600x1200 stacked for 1600x2400, I don't need it 
as much as say 1024x768 folks would, but I do use it for a (600x300) 
popout panel containing a kpager applet.  Since IIRC KDE4 has an applet 
that can be put on the desktop for that, there's a decent chance I won't 
miss it a lot once I get a suitably customized arrangement going, but 
it'd be nice to have the option.

In any case, 4.1 appears to have fixed at least some of the 4.0 blockers, 
including the big one here, the lack of multipanel support and 
configuration, so unless there's something really stupid like that 
missing proxy support (tho it looks like it'll work for me after all), 
there's at least a decent chance I'll find it at least minimally usable, 
now, enough to remerge it and start the task of customizing it to my 
needs and switching my habits to the 4.x methodology, even if I have to 
keep parts of KDE3 around for awhile.  That's what I had intended to do 
with 4.0, but it was just too *broken*, too many now vital but missing in 
4.0 features, to make it work, even for this normally out-in-front 
bleeding edge guy who /loves/ many betas.  That's why I say 4.0 was only 
early tech-preview alpha, not even beta, because betas normally have the 
features all there or at least blocked out even if buggy, and 4.0... 
didn't!  So 4.1's the first real beta, if it even reaches that.  It might 
still be more a late tech preview alpha.  Time will tell.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> Beso <givemesugarr@gmail.com> posted
> d257c3560805301217q5af4d9c3rc3ea014a012fe04f@mail.gmail.com, excerpted
> below, on  Fri, 30 May 2008 19:17:59 +0000:
>
> > 2008/5/30 Duncan <1i5t5.duncan@cox.net>:
>
> In any case, 4.1 appears to have fixed at least some of the 4.0 blockers,
> including the big one here, the lack of multipanel support and
> configuration, so unless there's something really stupid like that
> missing proxy support (tho it looks like it'll work for me after all),
> there's at least a decent chance I'll find it at least minimally usable,
> now, enough to remerge it and start the task of customizing it to my
> needs and switching my habits to the 4.x methodology, even if I have to
> keep parts of KDE3 around for awhile.  That's what I had intended to do
> with 4.0, but it was just too *broken*, too many now vital but missing in
> 4.0 features, to make it work, even for this normally out-in-front
> bleeding edge guy who /loves/ many betas.  That's why I say 4.0 was only
> early tech-preview alpha, not even beta, because betas normally have the
> features all there or at least blocked out even if buggy, and 4.0...
> didn't!  So 4.1's the first real beta, if it even reaches that.  It might
> still be more a late tech preview alpha.  Time will tell.
>

or you could just use the kde4 apps in kde3.5. flameeyes has posted a dirty
hack on his blog on how to use kde4 apps from 3.5 environment natively (ie
calling them directly from command line without the full path). you'll just
need the kdebase-meta package and then you could test them out. just one
warning: after installing solid hal would stop mounting stuff on request and
you'd need to work the mounting through dolphin. the device manager handles
the dolphin calls directly in plasma environment. the thing that is
interesting is the ability in plasma to create new workspaces. i think that
the zoom out feature of plasma desktop is meant for that and it should work
out similar to the leopard workspaces. also the widget exposè i think would
work as the osx one, since there's an option to put the widget on a layer
external to the desktop. the thing is that after getting out of the layer
the widget would stay on the visible desktop. the problems still there are
with phonon which doesn't implements enough features yet to be able to port
kaffeine and amarok only through phonon, so these packages devs are still
doing some extra job on that. still, the desktop has now come to be quite
usable.


-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805310843t605009b7x4ae908a4b1c6d46a@mail.gmail.com, excerpted
below, on  Sat, 31 May 2008 15:43:21 +0000:

> or you could just use the kde4 apps in kde3.5.

When I switch, I'll start using KDE4 for everything I can, so it'd be the 
other way, KDE3 where I have to, KDE4 where it has been ported and 
works.  Until then, I'll probably stick with KDE 3.x entirely.  I don't 
see much advantage in running KDE4 apps on a KDE3 desktop, but there is 
some in the reverse, once the KDE4 stuff gets functional enough to let me 
do so.  Hopefully with 4.1.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> Beso <givemesugarr@gmail.com> posted
> d257c3560805310843t605009b7x4ae908a4b1c6d46a@mail.gmail.com, excerpted
> below, on  Sat, 31 May 2008 15:43:21 +0000:
>
> > or you could just use the kde4 apps in kde3.5.
>
> When I switch, I'll start using KDE4 for everything I can, so it'd be the
> other way, KDE3 where I have to, KDE4 where it has been ported and
> works.  Until then, I'll probably stick with KDE 3.x entirely.  I don't
> see much advantage in running KDE4 apps on a KDE3 desktop, but there is
> some in the reverse, once the KDE4 stuff gets functional enough to let me
> do so.  Hopefully with 4.1.
>


for the moment the kde4 stable apps in my personal experience are:
dolphin, krusader (even if on cvs and still considered unstable by its
devs), kate, konqueror (if you aren't going to see sites optimized for
gecko) and it's a big deal better than old 3.5, okular (which is really
great as unified documents viewer), kopete (no irc and new live! protocol
supported yet, but old ones work well), kwallet, gwenview, dragon player
(kaffeine is still ages forward but is a nice low comsumption media player).
surely there are others, but these are quite good now.

by the way, a short question: what do i have to do to be sure that kernel
compilation uses ccache and is there a way to have it compiling into ram
like the packages that portage or paludis install?!


-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805311112k4c7112fbl645e95d85f65f7cc@mail.gmail.com, excerpted
below, on  Sat, 31 May 2008 18:12:56 +0000:

> by the way, a short question: what do i have to do to be sure that
> kernel compilation uses ccache and is there a way to have it compiling
> into ram like the packages that portage or paludis install?!

With the kernel, I don't worry about it.  It's a short enough compile, 
and only once a week or so even when I'm following the RCs, that it's 
really not that worth it.

I DID set it up with a script so it grabs the CFLAGS out of make.conf 
before it compiles, tho.  I figured I might as well.

If you like, we can start a new thread about that, and I can outline the 
whole scripted kernel setup (and the couple of patches I apply using the 
script), that I've created to pretty much automate the process, here.  
There's only one step that I haven't actually automated, the actual 
sources download, but I was thinking about automating that the other 
day.  Everything else, verifying the signature, moving the kernel and 
signature file to my kernel archive, untarring the sources and applying 
the couple trivial patches, running make old config, running the compile, 
doing the install including mounting and unmounting /boot, even invoking 
the editor on grub.conf, all scripted, invoked with just a couple 
commands.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> Beso <givemesugarr@gmail.com> posted
> d257c3560805311112k4c7112fbl645e95d85f65f7cc@mail.gmail.com, excerpted
> below, on  Sat, 31 May 2008 18:12:56 +0000:
>
> > by the way, a short question: what do i have to do to be sure that
> > kernel compilation uses ccache and is there a way to have it compiling
> > into ram like the packages that portage or paludis install?!
>
> With the kernel, I don't worry about it.  It's a short enough compile,
> and only once a week or so even when I'm following the RCs, that it's
> really not that worth it.
>
> I DID set it up with a script so it grabs the CFLAGS out of make.conf
> before it compiles, tho.  I figured I might as well.
>
> If you like, we can start a new thread about that, and I can outline the
> whole scripted kernel setup (and the couple of patches I apply using the
> script), that I've created to pretty much automate the process, here.
> There's only one step that I haven't actually automated, the actual
> sources download, but I was thinking about automating that the other
> day.  Everything else, verifying the signature, moving the kernel and
> signature file to my kernel archive, untarring the sources and applying
> the couple trivial patches, running make old config, running the compile,
> doing the install including mounting and unmounting /boot, even invoking
> the editor on grub.conf, all scripted, invoked with just a couple
> commands.
>

a new thread about it could be very interesting. i'm quite a little
interested in it. could you please post the steps and the scripts in a
fresh  thread when you'll have some spare time?! thanks very much. it should
be you to start the thread on this argument.

now i've just found out the dvb-t device for watching the european
championships with native linux inkernel support.

and thanks again for your hints. i'm little by little learning more and more
about various things after listening to them. it seems that you're
knowledgeable about a lot of different stuff.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Freitag, 30. Mai 2008, Duncan wrote:

> I've not done paludis due to its lack of binary package support.  Even
> tho I'm running only a single computer

there is another reason not to use paludis:

you can't go back.

At least not easily.

With pkgcore you can switch between pkgcore and portage 'on the fly'. emerge 
app a, pmerge app b, emerge app c.

The config files are not touched.

Paludis on the other hand can only described with 'vendor lock in' 
and 'gratuitous incompatibilty'. And don't forget that it is slow.

That it also requires a shitload of dependencies and installs more crap than 
portage and pkgcore combined doesn't make it better. 

At a last point: don't forget WHO is behind paludis - some of the most abusive 
persons gentoo has ever seen. The same people responsible for most problems.

Abusive, agressive, searching for stuff that is not covered by rules, behave 
like a rabid ape until everything is covered by rules, suffocating gentoo and 
then turn into rule nazis and game the system. Yes, this people are behind 
paludis - and 'exherbo'.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Friday 30 May 2008 21:16:06 Hemmann, Volker Armin wrote:
> On Freitag, 30. Mai 2008, Duncan wrote:
> > I've not done paludis due to its lack of binary package support.  Even
> > tho I'm running only a single computer
>
> there is another reason not to use paludis:
>
> you can't go back.
>
> At least not easily.

That is a vicious, ridiculous lie (and the rest only gets worse).
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Barry Schwartz]

David Leverton <levertond@googlemail.com> skribis:
> On Friday 30 May 2008 21:16:06 Hemmann, Volker Armin wrote:
> > On Freitag, 30. Mai 2008, Duncan wrote:
> > > I've not done paludis due to its lack of binary package support.  Even
> > > tho I'm running only a single computer
> >
> > there is another reason not to use paludis:
> >
> > you can't go back.
> >
> > At least not easily.
> 
> That is a vicious, ridiculous lie (and the rest only gets worse).

This is way off-topic, I suppose, but regarding the rest, I came
across this in the Paludis FAQ:

    But C++ is ...

    No it isn't. Whoever told you that was either trolling or
    ignorant.

I suggest that Paludis delete that from the FAQ if the people
responsible don't want a reputation as bullies, because this is
bullying.

Worry about the beam in your own eye, that sort of thing.

There is also the example above of someone being accused of lying
simply for stating a contrary opinion.

Let's all just agree that opinions differ and anyone's opinion may
help guide us in operating our individual Gentoos.

Flame wars are so 1980s. Been there, done that. :)


-- 
Barry SCHWARTZ   /   Esperanto: Barijo ŜVARCO
chemoelectric ĉe chemoelectric punkto org  http://chemoelectric.org
             Free stuff / Senpagaj varoj:  http://crudfactory.com
   To learn about the Esperanto language:  http://lernu.net
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Friday 30 May 2008 21:48:03 Barry Schwartz wrote:
> I suggest that Paludis delete that from the FAQ if the people
> responsible don't want a reputation as bullies, because this is
> bullying.

No it isn't.

> There is also the example above of someone being accused of lying
> simply for stating a contrary opinion.

No, there is the example above of someone being accused of lying simply for 
telling lies.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Freitag, 30. Mai 2008, David Leverton wrote:
> On Friday 30 May 2008 21:16:06 Hemmann, Volker Armin wrote:
> > On Freitag, 30. Mai 2008, Duncan wrote:
> > > I've not done paludis due to its lack of binary package support.  Even
> > > tho I'm running only a single computer
> >
> > there is another reason not to use paludis:
> >
> > you can't go back.
> >
> > At least not easily.
>
> That is a vicious, ridiculous lie (and the rest only gets worse).

oh really?

I don't think so.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Friday 30 May 2008 22:10:00 Hemmann, Volker Armin wrote:
> On Freitag, 30. Mai 2008, David Leverton wrote:
> oh really?
>
> I don't think so.

You also "think" that
* it's Paludis's fault that the maintainers of some of the overlays I use 
chose to commit eclasses with the same names as those in the tree
* package.mask syntax, that I explicitly stated was supported by Portage when 
I first mentioned it, is invalid

Please forgive me if I don't find your li^W"opinions" very compelling.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Freitag, 30. Mai 2008, David Leverton wrote:
> On Friday 30 May 2008 22:10:00 Hemmann, Volker Armin wrote:
> > On Freitag, 30. Mai 2008, David Leverton wrote:
> > oh really?
> >
> > I don't think so.
>
> You also "think" that
> * it's Paludis's fault that the maintainers of some of the overlays I use
> chose to commit eclasses with the same names as those in the tree
> * package.mask syntax, that I explicitly stated was supported by Portage
> when I first mentioned it, is invalid
>
> Please forgive me if I don't find your li^W"opinions" very compelling.

you just call me liar - but you do nothing to prove that. On the mean time, I 
gave you some links.

So, in my opinion, you are just a pro-paludis troll.

And from what I can see, trolls are the prefered audience and power behind 
paludis.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Friday 30 May 2008 23:17:55 Hemmann, Volker Armin wrote:
> So, in my opinion, you are just a pro-paludis troll.

And in my opinion, you are just an obsessive, delusional, anti-Paludis 
fundamentalist.  Whenever it (or Exherbo) is mentioned, you're right there, 
spewing your retarded lies and hatred.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Samstag, 31. Mai 2008, David Leverton wrote:
> On Friday 30 May 2008 23:17:55 Hemmann, Volker Armin wrote:
> > So, in my opinion, you are just a pro-paludis troll.
>
> And in my opinion, you are just an obsessive, delusional, anti-Paludis
> fundamentalist.  Whenever it (or Exherbo) is mentioned, you're right there,
> spewing your retarded lies and hatred.

really? I only see one paludis related 'thread' so far. So could you tone down 
your personal attacks?
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Saturday 31 May 2008 10:53:40 Hemmann, Volker Armin wrote:
> really? I only see one paludis related 'thread' so far.

Look harder.

> So could you tone down your personal attacks?

It's quite hilarious that you say that after your lies and FUD about the 
entire Paludis team.

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Richard Freeman]

Hemmann, Volker Armin wrote:
> So, in my opinion, you are just a pro-paludis troll.
> 
> And from what I can see, trolls are the prefered audience and power behind 
> paludis.

Guys - let's try to keep this civil!

There are lots of folks who use and like paludis who aren't trolls.  I'm 
among them.  The main thing I like is that the dependency management 
tends to work better than portage (or at least better than how portage 
used to work).  It also has better native support for overlays, and it 
is a bit more actively developed.  It also seems much faster to me - or 
at least it used to be (actually - I use portage so infrequently these 
days that it seems to take forever just to regenerate its various caches 
when I do use it - perhaps if I used emerge --sync that might behave 
differently).

On the other hand, I do understand the attitude issues associated with 
some of the key developers and as pointed out in the FAQ quote it tends 
to show.  I'm not sure I'd actively evangelize for its use as a result.

The main thing I had feared with paludis is that at some point a need 
for a particular feature will come along and it will be determined that 
real men don't need that feature and I'll be stuck (while every other 
package manager out there ends up supporting it).  While this still 
concerns me it generally hasn't happened to date, and I'm less concerned 
about it.  However, if it does happen getting my keywords migrated back 
to portage format will end up being a minor headache...

My recommendation is to look into paludis - and feel free to try it out. 
  Be aware of its advantages and limitations.  Then make the appropriate 
decision.  As Duncan pointed out it isn't an ideal package manager if 
you use binary packages frequently.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Avuton Olrich]

On Fri, May 30, 2008 at 7:15 PM, Richard Freeman <rich0@gentoo.org> wrote:
> Hemmann, Volker Armin wrote:
>>
>> So, in my opinion, you are just a pro-paludis troll.
>>
>> And from what I can see, trolls are the prefered audience and power behind
>> paludis.
>
> Guys - let's try to keep this civil!
>
> There are lots of folks who use and like paludis who aren't trolls.  I'm
> among them.  The main thing I like is that the dependency management tends
> to work better than portage (or at least better than how portage used to
> work).  It also has better native support for overlays, and it is a bit more
> actively developed.  It also seems much faster to me - or at least it used
> to be (actually - I use portage so infrequently these days that it seems to
> take forever just to regenerate its various caches when I do use it -
> perhaps if I used emerge --sync that might behave differently).
>
> On the other hand, I do understand the attitude issues associated with some
> of the key developers and as pointed out in the FAQ quote it tends to show.
>  I'm not sure I'd actively evangelize for its use as a result.
>
..
>
> My recommendation is to look into paludis - and feel free to try it out.  Be
> aware of its advantages and limitations.  Then make the appropriate
> decision.  As Duncan pointed out it isn't an ideal package manager if you
> use binary packages frequently.

Couldn't have said it more elegantly myself. ++
-- 
avuton
--
 "I've got a fever. And the only prescription is more cowbell." --
Christopher Walken
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Richard Freeman <rich0@gentoo.org>:

> Hemmann, Volker Armin wrote:
>
>> So, in my opinion, you are just a pro-paludis troll.
>>
>> And from what I can see, trolls are the prefered audience and power behind
>> paludis.
>>
>
> Guys - let's try to keep this civil!
>
> There are lots of folks who use and like paludis who aren't trolls.  I'm
> among them.  The main thing I like is that the dependency management tends
> to work better than portage (or at least better than how portage used to
> work).  It also has better native support for overlays, and it is a bit more
> actively developed.  It also seems much faster to me - or at least it used
> to be (actually - I use portage so infrequently these days that it seems to
> take forever just to regenerate its various caches when I do use it -
> perhaps if I used emerge --sync that might behave differently).
>

that's exactly the point. as i've already said on new system portage is
quite flawly, while paludis is less flawly with deps. and the overlays
handling and the possibility to continue builds if packages fails on various
conditions is not a bad addition. if you emerge sync and update portage
repository you'll just need a paludis --regenerate-installable-cache and
you're ok. also you'll just have to remember to regenerate the installed
cache whenever you install something with portage.


> On the other hand, I do understand the attitude issues associated with some
> of the key developers and as pointed out in the FAQ quote it tends to show.
>  I'm not sure I'd actively evangelize for its use as a result.
>

sometimes they have somem technical points out there but have an impulsive
character. well, if they were in a development company they could have not
been scolded since their work as devs isn't bad.

The main thing I had feared with paludis is that at some point a need for a
> particular feature will come along and it will be determined that real men
> don't need that feature and I'll be stuck (while every other package manager
> out there ends up supporting it).  While this still concerns me it generally
> hasn't happened to date, and I'm less concerned about it.  However, if it
> does happen getting my keywords migrated back to portage format will end up
> being a minor headache...
>
> My recommendation is to look into paludis - and feel free to try it out.
>  Be aware of its advantages and limitations.  Then make the appropriate
> decision.  As Duncan pointed out it isn't an ideal package manager if you
> use binary packages frequently.


i could say that for users as duncan, with need of binpkg and with a minor
number of overlays paludis is not very good and in fact is indicated for
people who reboot oftenly (like ati notebooks users which don't have a
really good standby or suspend) and update world frequently and people who
have a big deal of repos usually more than 2 repos should be good to go with
paludis



-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[ionut cucu]

On Sat, 31 May 2008 00:17:55 +0200
"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> wrote:

> On Freitag, 30. Mai 2008, David Leverton wrote:
> > On Friday 30 May 2008 22:10:00 Hemmann, Volker Armin wrote:
> > > On Freitag, 30. Mai 2008, David Leverton wrote:
> > > oh really?
> > >
> > > I don't think so.
> >
> > You also "think" that
> > * it's Paludis's fault that the maintainers of some of the overlays
> > I use chose to commit eclasses with the same names as those in the
> > tree
> > * package.mask syntax, that I explicitly stated was supported by
> > Portage when I first mentioned it, is invalid
> >
> > Please forgive me if I don't find your li^W"opinions" very
> > compelling.
> 
> you just call me liar - but you do nothing to prove that. On the mean
> time, I gave you some links.
> 
> So, in my opinion, you are just a pro-paludis troll.
> 
> And from what I can see, trolls are the prefered audience and power
> behind paludis.
Here you're doing it again. Dude you're personal, stop offending
people, should you wanna make a point you're doing it all wrong:
give numbers, links, ideas, benchamrks, facts and stop offending
people!!
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 David Leverton <levertond@googlemail.com>:

> On Friday 30 May 2008 22:10:00 Hemmann, Volker Armin wrote:
> > On Freitag, 30. Mai 2008, David Leverton wrote:
> > oh really?
> >
> > I don't think so.
>
> You also "think" that
> * it's Paludis's fault that the maintainers of some of the overlays I use
> chose to commit eclasses with the same names as those in the tree
> * package.mask syntax, that I explicitly stated was supported by Portage
> when
> I first mentioned it, is invalid
>

is portage would admit commiting of changes to its eclasses that would be
avoided. if someone needs a big eclass like the kde4-base for example, but
would need to change a little thing in it what should he do?! this
overriding is good and is done in much places in programming and also in
this case should not be a bother since would just be read for the specific
overlay that ovverrides it. but if portage is so dumb to not be able to
understand that maybe portage mantainers should do it. portage also has the
faculty of mantaining overlays and thus this behavior should be normal.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Freitag, 30. Mai 2008, David Leverton wrote:
> On Friday 30 May 2008 21:16:06 Hemmann, Volker Armin wrote:
> > On Freitag, 30. Mai 2008, Duncan wrote:
> > > I've not done paludis due to its lack of binary package support.  Even
> > > tho I'm running only a single computer
> >
> > there is another reason not to use paludis:
> >
> > you can't go back.
> >
> > At least not easily.
>
> That is a vicious, ridiculous lie (and the rest only gets worse).

http://www.gentooexperimental.org/not-the-gwn/not-the-gwn-current.html

for some numbers.

typical paludis-supporter behaviour:
http://r0bertz.blogspot.com/2007/01/be-careful-when-you-are-on-paludis.html

ciaranm, known to game the system. Abusive against users.
rbrown&spb, just removed because of their abusive behaviour.

And think about that: why is there a whole bunch of paludis support threads in 
f.g.o?

And why is there not one for pkgcore? (hint, because it is so easy to use)
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Friday 30 May 2008 22:18:18 Hemmann, Volker Armin wrote:
> http://www.gentooexperimental.org/not-the-gwn/not-the-gwn-current.html
>
> for some numbers.

Lies, damned lies, and what was that other thing?

> typical paludis-supporter behaviour:
> http://r0bertz.blogspot.com/2007/01/be-careful-when-you-are-on-paludis.html
>
> ciaranm, known to game the system. Abusive against users.
> rbrown&spb, just removed because of their abusive behaviour.

Slander and personal attacks.

> And think about that: why is there a whole bunch of paludis support threads
> in f.g.o?

Because people use it... same reason there are a bunch of threads about 
Portage, KDE, Firefox, etc, etc, etc.

> And why is there not one for pkgcore?

Because hardly anyone uses it (otherwise they'd have found a few of the more 
hilariously obvious bugs by now).  That said, there have been a few questions 
about pkgcore on the forums.  Maybe you were confused by the lack of the 
words "support thread"?

> (hint, because it is so easy to use) 

Yeah, those error messages are so easy to understand....
http://forums.gentoo.org/viewtopic-p-4832873.html?sid=60d1dd0183eccf814e9e393b3756cdc8#4832873
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Samstag, 31. Mai 2008, David Leverton wrote:

> > typical paludis-supporter behaviour:
> > http://r0bertz.blogspot.com/2007/01/be-careful-when-you-are-on-paludis.ht
> >ml
> >
> > ciaranm, known to game the system. Abusive against users.
> > rbrown&spb, just removed because of their abusive behaviour.
>
> Slander and personal attacks.

oh really?

You must have missed the forced retirement of spb and rbrown exactly because 
of their behaviour. Do I need to find the bugzilla link for you?

what the hell, here, for your leisure:
http://bugs.gentoo.org/show_bug.cgi?id=64840

scroll down a bit. Comment 21 is the first that led to the forced retirement. 
But as you can see, spb was a real 'improvement' to gentoo before.

or this nice example of spb behaving abusive (and eroyf. No surprise, the mips 
team was for a long time the host of most trouble makers. Luckily that 
changed.

http://bugs.gentoo.org/show_bug.cgi?id=175558

rbrown, who has a long history of abusive behaviour got retired because of 
that in this bug:
http://bugs.gentoo.org/show_bug.cgi?id=161368

a blog post by flameeyes about that:

http://blog.flameeyes.eu/articles/2008/04/28/get-the-thorn-out


> > (hint, because it is so easy to use)
>
> Yeah, those error messages are so easy to understand....

easier than paludis'.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Saturday 31 May 2008 00:41:25 Hemmann, Volker Armin wrote:
> You must have missed the forced retirement of spb and rbrown exactly
> because of their behaviour. Do I need to find the bugzilla link for you?

There's nothing on any of those bugs that would come even close to justifying 
retirement, just normal IRC banter.  As for the real reason they were 
retired?  I don't know, but I have a suspicion....
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Barry Schwartz]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> skribis:
> On Samstag, 31. Mai 2008, David Leverton wrote:
> 
> > > typical paludis-supporter behaviour:
> > > http://r0bertz.blogspot.com/2007/01/be-careful-when-you-are-on-paludis.ht
> > >ml
> > >
> > > ciaranm, known to game the system. Abusive against users.
> > > rbrown&spb, just removed because of their abusive behaviour.
> >
> > Slander and personal attacks.
> 
> oh really?
> 
> You must have missed the forced retirement of spb and rbrown exactly because 
> of their behaviour. Do I need to find the bugzilla link for you?
....

And then some very interesting links.

Holy moly! Thanks. I'm going to avoid Paludis like the plague.

Which is appropriate, because I looked up "paludis" and found
Anopheles paludis, an important malaria vector, and my Esperanto
dictionary defines "paludismo" as a synonym for "malario",
malaria. Maybe everybody but I already knew this, but it does seem
appropriate.

-- 
Barry SCHWARTZ   /   Esperanto: Barijo ŜVARCO
chemoelectric ĉe chemoelectric punkto org  http://chemoelectric.org
             Free stuff / Senpagaj varoj:  http://crudfactory.com
   To learn about the Esperanto language:  http://lernu.net
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Barry Schwartz]

woops, my bad, I didn't mean to send that to the list.

(Much embarassment)
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:

> On Freitag, 30. Mai 2008, David Leverton wrote:
> > On Friday 30 May 2008 21:16:06 Hemmann, Volker Armin wrote:
> > > On Freitag, 30. Mai 2008, Duncan wrote:
> > > > I've not done paludis due to its lack of binary package support.
>  Even
> > > > tho I'm running only a single computer
> > >
> > > there is another reason not to use paludis:
> > >
> > > you can't go back.
> > >
> > > At least not easily.
> >
> > That is a vicious, ridiculous lie (and the rest only gets worse).
>
> http://www.gentooexperimental.org/not-the-gwn/not-the-gwn-current.html
>
> for some numbers.
>
> typical paludis-supporter behaviour:
> http://r0bertz.blogspot.com/2007/01/be-careful-when-you-are-on-paludis.html
>
> ciaranm, known to game the system. Abusive against users.
> rbrown&spb, just removed because of their abusive behaviour.
>
> And think about that: why is there a whole bunch of paludis support threads
> in
> f.g.o?
>
> And why is there not one for pkgcore? (hint, because it is so easy to use)
> --
> gentoo-amd64@lists.gentoo.org mailing list
>
>
as i've said before: it's not fair to judge the quality of the software by
its producers. i don't agree on how they behave, but that doesn't imply that
if they behave in that way their software is by default bad.


-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[ionut cucu]

On Fri, 30 May 2008 22:16:06 +0200
"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> wrote:

> On Freitag, 30. Mai 2008, Duncan wrote:
> 
> > I've not done paludis due to its lack of binary package support.
> > Even tho I'm running only a single computer
> 
> there is another reason not to use paludis:
> 
> you can't go back.
> 
> At least not easily.
> 
> With pkgcore you can switch between pkgcore and portage 'on the fly'.
> emerge app a, pmerge app b, emerge app c.
> 
> The config files are not touched.
> 
> Paludis on the other hand can only described with 'vendor lock in' 
> and 'gratuitous incompatibilty'. And don't forget that it is slow.
> 
> That it also requires a shitload of dependencies and installs more
> crap than portage and pkgcore combined doesn't make it better. 
> 
> At a last point: don't forget WHO is behind paludis - some of the
> most abusive persons gentoo has ever seen. The same people
> responsible for most problems.
> 
> Abusive, agressive, searching for stuff that is not covered by rules,
> behave like a rabid ape until everything is covered by rules,
> suffocating gentoo and then turn into rule nazis and game the system.
> Yes, this people are behind paludis - and 'exherbo'.
1.You can go back to portage after paludis, please read before post,
and you can do it easy.
2.when it comes to speed paludis is much faster...man do a simple test,
stop talking if you don't know what you're talking about
3."The same people responsible for most problems."....WHAT? where did
that came from? what's the developer's personality has to do with
anything?Paludis has great support from it's developers(they've been
very helpful and pacient with me) and that is all I need to know about
the developer, if he is beating his wife it's not a matter of your
concern.
The last phrase deserves no comment. It's neither nice nor productive,
nor in any way positive, and might be regarded as an insult
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Samstag, 31. Mai 2008, ionut cucu wrote:

> 2.when it comes to speed paludis is much faster

i use pkgcore. It can't go faster than 'instantly'
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200805302216.07276.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Fri, 30 May 2008 22:16:06 +0200:

> On Freitag, 30. Mai 2008, Duncan wrote:
> 
>> I've not done paludis due to its lack of binary package support.  Even
>> tho I'm running only a single computer
> 
> there is another reason not to use paludis:
> 
> you can't go back.
> 
> At least not easily.

Holey moley!  I didn't think I was opening up such a can of worms as the 
subthread indicates! =8^(

FWIW and FWIR (from what I've read) paludis does have a portage 
compatibility mode.  Ciaranm was originally against it (didn't see the 
need), but after it became clear that any ultimate claimant to the status 
off official Gentoo package manager would at least during the transition 
need to maintain compatibility, so people could switch if they needed to, 
compatibility mode was added.

Now, I'm not sure how well it works in practice and I'm really not 
interested at this point because without binary package support, it's 
nothing I'm interested in anyway, but the support is officially there, 
and if it doesn't work, that would be a bug.

Of course, merging out-of-tree packages that portage doesn't support does 
sort of leave you high and dry in terms of switching back, but then, that 
would be part of the deal, rather a feature than a bug.  However, that 
doesn't lessen it as a concern for people who do consider the ability to 
switch back important.  

So when I read that the KDE-SVN overlay was going EAPI=kde1, which only 
paludis supported, I thought to myself just as well, then, that I had 
finally found time to test it before that and had made the decision that 
KDE4 trunk simply wasn't going to fit my needs for awhile.

> With pkgcore you can switch between pkgcore and portage 'on the fly'.
> emerge app a, pmerge app b, emerge app c.
> 
> The config files are not touched.

It's obvious which side of the fence you stand on, but that's not such a 
bad thing. =8^)  As I said, I hadn't intended for this thread to go where 
it went -- I thought I was asking a rather innocent question -- but be 
that as it may, I had been somewhat curious about pkgcore since paludis 
seems to have the more active (combative at times, but ehh) following, so 
there's more info out (some good, some not so good) about paludis than 
about pkgcore.

So seeing someone that's actually using pkgcore is helpful. =8^)

> Paludis on the other hand can only described with 'vendor lock in' and
> 'gratuitous incompatibilty'. And don't forget that it is slow.

Now this... well, let's just say it's uncalled-for.

As explained above, it does have a compatibility mode.  Further, from all 
the remarks I've seen about paludis, from users, supporters, detractors, 
Gentoo and paludis devs and non-devs alike, this is the first time I've 
seen paludis referred to as "slow".  Rather, everyone (else), including 
detractors who severely criticise it for other reasons, seems to agree 
that speed is not one of its failings -- certainly not as opposed to 
portage.  

(I've run into fewer direct comparisons between paludis and pkgcore, 
simply due to the fact that pkgcore devs and users seem to be much more 
inclined to just get on with their business and less apt to be raving 
about how good it is wherever they go.  While the resulting lack of 
widely visible info on pkgcore can be frustrating at times, this less 
combative attitude is certainly appreciated by some.  But then you come 
in with this subthread and change all that...)

> That it also requires a shitload of dependencies and installs more crap
> than portage and pkgcore combined doesn't make it better.

That'd certainly be in the eye of the beholder.  While I'm a KDE person, 
I can empathize with the GNOME folks who hesitate to install what might 
otherwise be a better KDE app solution (such as k3b), because of all the 
KDE "crap dependencies" it brings with it.  Why?  Because I take the same 
position in regard to GNOME apps.  However, a more mature way to express 
the same dependency issues when discussing an app is to mention that it's 
a KDE (or GNOME) app, with the requisite dependencies (note, nothing 
about shit or crap), so people who use the other desktop may have 
legitimate concerns about dependencies if they don't already use other 
apps requiring this desktop.

Same here.  Doing an emerge --pretend paludis, it doesn't have /that/ 
unreasonable a list of new merges, and a good share of the ones it /does/ 
have are simply null-package virtuals, already filled by newer gcc 
versions, but with further dependencies if you are still stuck on older 
gcc (3.x, 4.0, even 4.1).  That doesn't make them "crap dependencies", it 
just means the developers are making the most of tools already available 
to them in newer gcc/g++/libstdc++, that users of older gcc versions have 
to merge separately.  This isn't even as bad as the GNOME/KDE thing 
above, because eventually, everyone using gcc/g++ will already have the 
functionality built in, and unlike the GNOME/KDE thing, that's going to 
be pretty much everyone in the open source community.

> At a last point: don't forget WHO is behind paludis - some of the most
> abusive persons gentoo has ever seen. The same people responsible for
> most problems.
> 
> Abusive, agressive, searching for stuff that is not covered by rules,
> behave like a rabid ape until everything is covered by rules,
> suffocating gentoo and then turn into rule nazis and game the system.
> Yes, this people are behind paludis - and 'exherbo'.

Umm... the pot calling the kettle black?  I might agree with some of what 
you say, but this wasn't and isn't the time and the place to debate all 
that or to bring it up.  Doing so simply makes you (and what you are 
attempting to defend by running everything else down, pkgcore in this 
case) look as bad as you say they are.

Until this subthread, I had a bit of respect for pkgcore, because as I 
mentioned above, its developers and users seem to be more concerned with 
just having something that works, rather than being all aggressive about 
it.  I'm glad I finally found someone to talk about it.  I'm rather less 
enthused about the way chosen to do so.  Hopefully, that's an exception 
rather than the rule, as so far it has seemed to be.

So... um... let's try to keep this civil, shall we?  I pointed out a 
possible issue in the form of asking a question, and... it does seem I 
did get one response, from Beso (thanks Beso =8^), directly on point.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> "Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
> 200805302216.07276.volker.armin.hemmann@tu-clausthal.de, excerpted below,
> on  Fri, 30 May 2008 22:16:06 +0200:
>
> > On Freitag, 30. Mai 2008, Duncan wrote:
> >
> >> I've not done paludis due to its lack of binary package support.  Even
> >> tho I'm running only a single computer
> >
> > there is another reason not to use paludis:
> >
> > you can't go back.
> >
> > At least not easily.
>
> Holey moley!  I didn't think I was opening up such a can of worms as the
> subthread indicates! =8^(
>
> FWIW and FWIR (from what I've read) paludis does have a portage
> compatibility mode.  Ciaranm was originally against it (didn't see the
> need), but after it became clear that any ultimate claimant to the status
> off official Gentoo package manager would at least during the transition
> need to maintain compatibility, so people could switch if they needed to,
> compatibility mode was added.
>
> Now, I'm not sure how well it works in practice and I'm really not
> interested at this point because without binary package support, it's
> nothing I'm interested in anyway, but the support is officially there,
> and if it doesn't work, that would be a bug.
>
> Of course, merging out-of-tree packages that portage doesn't support does
> sort of leave you high and dry in terms of switching back, but then, that
> would be part of the deal, rather a feature than a bug.  However, that
> doesn't lessen it as a concern for people who do consider the ability to
> switch back important.
>
> So when I read that the KDE-SVN overlay was going EAPI=kde1, which only
> paludis supported, I thought to myself just as well, then, that I had
> finally found time to test it before that and had made the decision that
> KDE4 trunk simply wasn't going to fit my needs for awhile.


that was some time ago and portage got the EAPI=1 supported in less than a
month of when it got out. but maybe because pkgcore has been already
supporting it, if i'm remembering well. the out-of-tree packages (like the
scm ones) could be removed before switching back. if you have them in world
and run portage on world you'd only get a bunch of warnings of invalid atoms
in world and portage ignoring these atoms. so even with them the
intercompatibility is good. the kde-overlay mantained by bernyh and others
if based on the kdebuild-1 build system which moves everything from the
ebuilds to the eclasses and to the package manager which search the world,
search the package and its linkage and tries to suggest a list of deps as
core and suggested deps. the core deps are the required ones while the non
core could be ignored. for example kdiff would a be suggested dep for the
package krusader. another good thing of paludis is the use of sets that
include a list of packages. i've actually been using them to update live
packages without putting them all hand by hand everytime.

> emerge app a, pmerge app b, emerge app c.
> >
> > The config files are not touched.
>
> > With pkgcore you can switch between pkgcore and portage 'on the fly'.
>
> It's obvious which side of the fence you stand on, but that's not such a
> bad thing. =8^)  As I said, I hadn't intended for this thread to go where
> it went -- I thought I was asking a rather innocent question -- but be
> that as it may, I had been somewhat curious about pkgcore since paludis
> seems to have the more active (combative at times, but ehh) following, so
> there's more info out (some good, some not so good) about paludis than
> about pkgcore.
>
> So seeing someone that's actually using pkgcore is helpful. =8^)
>

does pkgcore has more features than portage?! i seem to remember trying it
about one year ago and it had the same portage features and almost the same
drawbacks, so i've decided to stay with portage that time. (this is just a
question from an ignorant about pkgcore and doesn't want in any way to start
another flame).


> > Paludis on the other hand can only described with 'vendor lock in' and
> > 'gratuitous incompatibilty'. And don't forget that it is slow.
>
> Now this... well, let's just say it's uncalled-for.
>
> As explained above, it does have a compatibility mode.  Further, from all
> the remarks I've seen about paludis, from users, supporters, detractors,
> Gentoo and paludis devs and non-devs alike, this is the first time I've
> seen paludis referred to as "slow".  Rather, everyone (else), including
> detractors who severely criticise it for other reasons, seems to agree
> that speed is not one of its failings -- certainly not as opposed to
> portage.
>
> (I've run into fewer direct comparisons between paludis and pkgcore,
> simply due to the fact that pkgcore devs and users seem to be much more
> inclined to just get on with their business and less apt to be raving
> about how good it is wherever they go.  While the resulting lack of
> widely visible info on pkgcore can be frustrating at times, this less
> combative attitude is certainly appreciated by some.  But then you come
> in with this subthread and change all that...)
>
> > That it also requires a shitload of dependencies and installs more crap
> > than portage and pkgcore combined doesn't make it better.
>
> That'd certainly be in the eye of the beholder.  While I'm a KDE person,
> I can empathize with the GNOME folks who hesitate to install what might
> otherwise be a better KDE app solution (such as k3b), because of all the
> KDE "crap dependencies" it brings with it.  Why?  Because I take the same
> position in regard to GNOME apps.  However, a more mature way to express
> the same dependency issues when discussing an app is to mention that it's
> a KDE (or GNOME) app, with the requisite dependencies (note, nothing
> about shit or crap), so people who use the other desktop may have
> legitimate concerns about dependencies if they don't already use other
> apps requiring this desktop.


the same goes for me, a kde user. i really need some gnome apps like pan or
firefox and just for it i need a big deal of gnome deps. and you should
understand what i'm saying, since you're also an experienced pan users.
about the db issue with klibido, getting back to db-4.5 fixed it. and no,
klibido doesn't support posting. i'll try to look into it after i understand
well the package, and if noone takes it i'll take on to port it to qt4 and
cmake build system. i'm now starting to work on qt4 and this could be an
interesting challenge and could help me improve my skills with it.

Same here.  Doing an emerge --pretend paludis, it doesn't have /that/
> unreasonable a list of new merges, and a good share of the ones it /does/
> have are simply null-package virtuals, already filled by newer gcc
> versions, but with further dependencies if you are still stuck on older
> gcc (3.x, 4.0, even 4.1).  That doesn't make them "crap dependencies", it
> just means the developers are making the most of tools already available
> to them in newer gcc/g++/libstdc++, that users of older gcc versions have
> to merge separately.  This isn't even as bad as the GNOME/KDE thing
> above, because eventually, everyone using gcc/g++ will already have the
> functionality built in, and unlike the GNOME/KDE thing, that's going to
> be pretty much everyone in the open source community.


and that some tools like pcre (always needed by paludis) is now not needed
only by it. as i've said before, mainly xorg has pushed in these deps (of
course the use flags also helped a lot)

> At a last point: don't forget WHO is behind paludis - some of the most
> > abusive persons gentoo has ever seen. The same people responsible for
> > most problems.
> >
> > Abusive, agressive, searching for stuff that is not covered by rules,
> > behave like a rabid ape until everything is covered by rules,
> > suffocating gentoo and then turn into rule nazis and game the system.
> > Yes, this people are behind paludis - and 'exherbo'.
>
>
> Umm... the pot calling the kettle black?  I might agree with some of what
> you say, but this wasn't and isn't the time and the place to debate all
> that or to bring it up.  Doing so simply makes you (and what you are
> attempting to defend by running everything else down, pkgcore in this
> case) look as bad as you say they are.
>
> Until this subthread, I had a bit of respect for pkgcore, because as I
> mentioned above, its developers and users seem to be more concerned with
> just having something that works, rather than being all aggressive about
> it.  I'm glad I finally found someone to talk about it.  I'm rather less
> enthused about the way chosen to do so.  Hopefully, that's an exception
> rather than the rule, as so far it has seemed to be.
>
> So... um... let's try to keep this civil, shall we?  I pointed out a
> possible issue in the form of asking a question, and... it does seem I
> did get one response, from Beso (thanks Beso =8^), directly on point.
>

well, i'm glad that at least it was useful as an answer. also, i'm now
trying to do as you've said with pan and the cached articles, but i find it
somehow long to do. maybe it's because i'm not used to it. so for the moment
being i've gone back with klibido.

-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805310208o5e6df42as66e855ae009f937c@mail.gmail.com, excerpted
below, on  Sat, 31 May 2008 09:08:38 +0000:

> 2008/5/31 Duncan <1i5t5.duncan@cox.net>:

>> So seeing someone that's actually using pkgcore is helpful. =8^)

> does pkgcore has more features than portage?! i seem to remember trying
> it about one year ago and it had the same portage features and almost
> the same drawbacks, so i've decided to stay with portage that time.
> (this is just a question from an ignorant about pkgcore and doesn't want
> in any way to start another flame).

Good question.  I'd love to see a decent discussion of pkgcore, but 
please start a new thread for it.  A link to a forums thread on the 
subject, or maybe a users-list thread (web archive, gmane or gentoo, 
probably), may be useful to get it started and avoid a bunch of repeat 
questions and answers.

> the same goes for me, a kde user. i really need some gnome apps like pan
> or firefox and just for it i need a big deal of gnome deps. and you
> should understand what i'm saying, since you're also an experienced pan
> users.

Well, to be fair, pan and firefox/iceweasel only require GTK+ and perhaps 
a couple misc dependencies that GNOME also needs.  They certainly don't 
require all of GNOME or even most of its core.  I know, as I have both of 
them merged here, but don't have GNOME merged.  That's like saying 
anything depending on qt depends on KDE.

Every so often I've toyed with the idea of switching to klibido, maybe 
knode or something else for text (thus my excitement when I read 
something implying klibido was a whole substitute for pan, now, seems 
not, unfortunately), unmerging pan, hoping to be able to kill GTK+ with 
it.  However, if iceweasel/firefox needs it as I think it does now that 
you mention it, that's not likely to work unless I decide I can also live 
without iceweasel... which actually might be reasonable once again if 
webkit continues to grow in popularity.  The only thing I've /really/ 
needed it for the last few years is doing taxes, and if khtml/webkit 
eventually works properly for that...

> about the db issue with klibido, getting back to db-4.5 fixed it.
> and no, klibido doesn't support posting.

Too bad. =8^)  I had my hopes up there for a bit.

> i'll try to look into it after
> i understand well the package, and if noone takes it i'll take on to
> port it to qt4 and cmake build system. i'm now starting to work on qt4
> and this could be an interesting challenge and could help me improve my
> skills with it.

Hopefully klibido follows to KDE4.  It'd be a shame to see it stuck on 
KDE3, after all the work that has gone into it and as sparse on the 
ground as real binary news harvesters seem to be.

>> Doing an emerge --pretend paludis, it doesn't have /that/
>> unreasonable a list of new merges, and a good share of the ones it
>> /does/ have are simply null-package virtuals, already filled by newer
>> gcc versions[.]

> and that some tools like pcre (always needed by paludis) is now not
> needed only by it. as i've said before, mainly xorg has pushed in these
> deps (of course the use flags also helped a lot).

For pcre, certain other packages have been using it for awhile.  pan 
does, and I it, so it didn't show up on my dependency list.  (You 
mentioned xorg, it depends on it too now? I guess it really /is/ getting 
around!  I wouldn't have known since I have it merged for pan.)  Point 
about eye of the beholder...  But based on a post (yours I think) I see 
since I posted the grandparent, it seems the newer gcc does indeed take 
care of what might have been quite a stack of deps.

> also, i'm now trying to do as you've said with pan and the cached
> articles, but i find it somehow long to do. maybe it's because i'm not
> used to it. so for the moment being i've gone back with klibido.

Well, it's not that it's longer... it takes that time to download the 
posts either way... but it does seem to take longer since you download 
them all before starting to work on them.

There's to it tho that make it not seem so bad.

First, depending on what you are downloading and from where (groups), it 
may be possible to train yourself to setup a smaller group download 
first, then the larger group, scheduled after the small group.  For some 
things (mainly single part binaries), that works reasonably well, as the 
shorter group may be mostly downloaded by the time you get thru sorting 
thru and deleting the stuff you do NOT need to download on the larger 
group, then scheduling the rest of it for download.  That way you can 
switch to the shorter group, and with it mostly or all downloaded, go 
right to work sorting and saving what downloaded.  If it works out right, 
by the time you finish that, the larger group (or some portions thereof, 
see below) will be done.

Second, you can download text groups first, then binaries, then read and 
reply to the text groups giving the binaries a chance to get partly done 
before you switch back to them.

Third, there's nothing saying you have to download the whole group at 
once.  In the first round (with only headers), at least on some groups, 
you can download samples, preview stills or clips, then decide if you 
want to download the whole series.  If not, delete the series right there 
and go on.  If you want to download it, setup the download to cache right 
then and there, and go on.  By the time you've worked thru the group and 
setup the last of the downloads, the first will hopefully be done or 
close to it.  As the downloads to cache complete, the icon will change 
from download to in-cache, so you can see what messages were in jobs that 
have already completed downloading.  Thus, you can go thru and process 
the downloaded series while others are still downloading.  Of course, you 
may have to flip the sort order between subject/author/date/scored a bit 
to get the series together and make it easy to go thru them, but a binary 
news junkie will probably be accustomed to doing some of that already.

Fourth, while it can be hard to discipline yourself to do so, at least 
initially, you can also train yourself to setup the new downloads at the 
END of your working session, before you go to work or to bed or do family 
or friend stuff or whatever.  Then it downloads while you are doing 
something else, and you come back and have everything nicely ready for 
your NEXT session.  Do your sorting and saving and whatever (without 
checking for new messages yet), delete the now garbage headers and 
cache, /then/ grab new headers, select what you want to download deleting 
the rest, set it downloading, and your session is finished.  Again, when 
you get thru sleeping or working or whatever, you'll have another fresh 
batch of downloads already stored locally.  No waiting for the downloads 
to finish, as you let the computer do that while you're away doing other 
things!  Of course, this works better on a desktop you leave where it is, 
than on a laptop you disconnect to take with you when you are finished.  
Still, even with a laptop that's normally on the go with you, you gotta 
sleep sometime, and you might as well let it be downloading while you do.
Admittedly, tho, this takes discipline, as once you decide you want the 
files, it's hard to wait until the next session to actually go thru them.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> Beso <givemesugarr@gmail.com> posted
> d257c3560805310208o5e6df42as66e855ae009f937c@mail.gmail.com, excerpted
> below, on  Sat, 31 May 2008 09:08:38 +0000:
> > the same goes for me, a kde user. i really need some gnome apps like pan
> > or firefox and just for it i need a big deal of gnome deps. and you
> > should understand what i'm saying, since you're also an experienced pan
> > users.
>
> Well, to be fair, pan and firefox/iceweasel only require GTK+ and perhaps
> a couple misc dependencies that GNOME also needs.  They certainly don't
> require all of GNOME or even most of its core.  I know, as I have both of
> them merged here, but don't have GNOME merged.  That's like saying
> anything depending on qt depends on KDE.
>
> Every so often I've toyed with the idea of switching to klibido, maybe
> knode or something else for text (thus my excitement when I read
> something implying klibido was a whole substitute for pan, now, seems
> not, unfortunately), unmerging pan, hoping to be able to kill GTK+ with
> it.  However, if iceweasel/firefox needs it as I think it does now that
> you mention it, that's not likely to work unless I decide I can also live
> without iceweasel... which actually might be reasonable once again if
> webkit continues to grow in popularity.  The only thing I've /really/
> needed it for the last few years is doing taxes, and if khtml/webkit
> eventually works properly for that...
>

well, firefox 4 would go with webkit and qt4. there's an announce from the
firefox project director. gecko is unmantainable and veryyyy slow, so the
only one who will continue to use it would be iexploder. also the new qt4
utils and the ability to build an app that runs cross platform with much
less work would be quite interesting. and now maybe also openoffice would
think about switching to it.


> > i'll try to look into it after
> > i understand well the package, and if noone takes it i'll take on to
> > port it to qt4 and cmake build system. i'm now starting to work on qt4
> > and this could be an interesting challenge and could help me improve my
> > skills with it.
>
> Hopefully klibido follows to KDE4.  It'd be a shame to see it stuck on
> KDE3, after all the work that has gone into it and as sparse on the
> ground as real binary news harvesters seem to be.
>

i really hope so. it's good to have it around.


> >> Doing an emerge --pretend paludis, it doesn't have /that/
> >> unreasonable a list of new merges, and a good share of the ones it
> >> /does/ have are simply null-package virtuals, already filled by newer
> >> gcc versions[.]
>
> > and that some tools like pcre (always needed by paludis) is now not
> > needed only by it. as i've said before, mainly xorg has pushed in these
> > deps (of course the use flags also helped a lot).
>
> For pcre, certain other packages have been using it for awhile.  pan
> does, and I it, so it didn't show up on my dependency list.  (You
> mentioned xorg, it depends on it too now? I guess it really /is/ getting
> around!  I wouldn't have known since I have it merged for pan.)  Point
> about eye of the beholder...  But based on a post (yours I think) I see
> since I posted the grandparent, it seems the newer gcc does indeed take
> care of what might have been quite a stack of deps.


yep, gcc or xorg. i don't remember which of them, but the 4.2.x branch
surely pushes quite some deps needed by paludis. i'm not sure if xorg do
pushes some too, since i've done the emerge paludis after the 2 emerge -e
system and the xorg emerge.


> > also, i'm now trying to do as you've said with pan and the cached
> > articles, but i find it somehow long to do. maybe it's because i'm not
> > used to it. so for the moment being i've gone back with klibido.
>
>
> Well, it's not that it's longer... it takes that time to download the
> posts either way... but it does seem to take longer since you download
> them all before starting to work on them.
>
> There's to it tho that make it not seem so bad.
>
> First, depending on what you are downloading and from where (groups), it
> may be possible to train yourself to setup a smaller group download
> first, then the larger group, scheduled after the small group.  For some
> things (mainly single part binaries), that works reasonably well, as the
> shorter group may be mostly downloaded by the time you get thru sorting
> thru and deleting the stuff you do NOT need to download on the larger
> group, then scheduling the rest of it for download.  That way you can
> switch to the shorter group, and with it mostly or all downloaded, go
> right to work sorting and saving what downloaded.  If it works out right,
> by the time you finish that, the larger group (or some portions thereof,
> see below) will be done.
>
> Second, you can download text groups first, then binaries, then read and
> reply to the text groups giving the binaries a chance to get partly done
> before you switch back to them.
>
> Third, there's nothing saying you have to download the whole group at
> once.  In the first round (with only headers), at least on some groups,
> you can download samples, preview stills or clips, then decide if you
> want to download the whole series.  If not, delete the series right there
> and go on.  If you want to download it, setup the download to cache right
> then and there, and go on.  By the time you've worked thru the group and
> setup the last of the downloads, the first will hopefully be done or
> close to it.  As the downloads to cache complete, the icon will change
> from download to in-cache, so you can see what messages were in jobs that
> have already completed downloading.  Thus, you can go thru and process
> the downloaded series while others are still downloading.  Of course, you
> may have to flip the sort order between subject/author/date/scored a bit
> to get the series together and make it easy to go thru them, but a binary
> news junkie will probably be accustomed to doing some of that already.
>
> Fourth, while it can be hard to discipline yourself to do so, at least
> initially, you can also train yourself to setup the new downloads at the
> END of your working session, before you go to work or to bed or do family
> or friend stuff or whatever.  Then it downloads while you are doing
> something else, and you come back and have everything nicely ready for
> your NEXT session.  Do your sorting and saving and whatever (without
> checking for new messages yet), delete the now garbage headers and
> cache, /then/ grab new headers, select what you want to download deleting
> the rest, set it downloading, and your session is finished.  Again, when
> you get thru sleeping or working or whatever, you'll have another fresh
> batch of downloads already stored locally.  No waiting for the downloads
> to finish, as you let the computer do that while you're away doing other
> things!  Of course, this works better on a desktop you leave where it is,
> than on a laptop you disconnect to take with you when you are finished.
> Still, even with a laptop that's normally on the go with you, you gotta
> sleep sometime, and you might as well let it be downloading while you do.
> Admittedly, tho, this takes discipline, as once you decide you want the
> files, it's hard to wait until the next session to actually go thru them.
>

it's a little too complicated to me. i'm usually using pan just for browsing
the newsgroups and read some text articles. what i'd like to download i'd
take the nzb and use klibido. the problems with klibido stopping to work
sometimes, drives me mad and continues to bind me to pan, since it's the
only other nzb capable around with a decent interface, else i'd have already
switched fully to knode+klibido.


-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805310853j7bd01489pa5b74f1d69ae0383@mail.gmail.com, excerpted
below, on  Sat, 31 May 2008 15:53:37 +0000:

> well, firefox 4 would go with webkit and qt4. there's an announce from
> the firefox project director. gecko is unmantainable and veryyyy slow,
> so the only one who will continue to use it would be iexploder. also the
> new qt4 utils and the ability to build an app that runs cross platform
> with much less work would be quite interesting. and now maybe also
> openoffice would think about switching to it.

That'd be interesting.  Safari/Konqueror/Firefox/Qt/Qtopia all using the 
same webkit core.  That'd pressure MS even more effectively.  I wonder 
what the chances of getting Opera online with it too, might be?  They've 
stayed proprietary, but with that sort of open source union going on, I 
could see them taking advantage of the LGPL renderer if it might have 
some chance of turning the tables on MS.  They could still keep 
everything else proprietary.

>> Hopefully klibido follows to KDE4.  It'd be a shame to see it stuck on
>> KDE3, after all the work that has gone into it and as sparse on the
>> ground as real binary news harvesters seem to be.
>>
> i really hope so. it's good to have it around.

I don't know if you've been to the site recently.  I just checked.  
Nothing since 2006.  It may be worth joining the user list if you haven't 
already and dropping and inquiry.  If that doesn't work, contact him 
directly and see.  That assumes the question hasn't been asked and 
answered and is in a list archive on gmane or something, already.  (Just 
checked gmane, don't see it there.)

> it's a little too complicated to me. i'm usually using pan just for
> browsing the newsgroups and read some text articles.

So you're not too serious about the downloading thing, like every day or 
whatever, only maybe once a week or so, when you get time?  I can see 
that, and in fact don't do a lot of binary downloading here, either, tho 
when I do, I tend to get REALLY serious about it for awhile.  Sort of 
like Charles with developing pan, I guess.  I'll go awhile without, then 
get REALLY serious and go to town on it for awhile, before I get too busy 
again...

Yeah, in that case, for simple browsing and pick and choose here and 
there downloading, most of the techniques I mentioned aren't particularly 
useful.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> Beso <givemesugarr@gmail.com> posted
> d257c3560805310853j7bd01489pa5b74f1d69ae0383@mail.gmail.com, excerpted
> below, on  Sat, 31 May 2008 15:53:37 +0000:
>
> > well, firefox 4 would go with webkit and qt4. there's an announce from
> > the firefox project director. gecko is unmantainable and veryyyy slow,
> > so the only one who will continue to use it would be iexploder. also the
> > new qt4 utils and the ability to build an app that runs cross platform
> > with much less work would be quite interesting. and now maybe also
> > openoffice would think about switching to it.
>
> That'd be interesting.  Safari/Konqueror/Firefox/Qt/Qtopia all using the
> same webkit core.  That'd pressure MS even more effectively.  I wonder
> what the chances of getting Opera online with it too, might be?  They've
> stayed proprietary, but with that sort of open source union going on, I
> could see them taking advantage of the LGPL renderer if it might have
> some chance of turning the tables on MS.  They could still keep
> everything else proprietary.
>

well, qt and qtopia are on webkit, safari was the forewarder on it, opera
too maybe will emulate it, as it does now, since its motor is quite good
now, but has less compatibility with sites that don't follow the web
standards... damn that devs that still create sites not following
standards!!!!


> >> Hopefully klibido follows to KDE4.  It'd be a shame to see it stuck on
> >> KDE3, after all the work that has gone into it and as sparse on the
> >> ground as real binary news harvesters seem to be.
> >>
> > i really hope so. it's good to have it around.
>
>
> I don't know if you've been to the site recently.  I just checked.
> Nothing since 2006.  It may be worth joining the user list if you haven't
> already and dropping and inquiry.  If that doesn't work, contact him
> directly and see.  That assumes the question hasn't been asked and
> answered and is in a list archive on gmane or something, already.  (Just
> checked gmane, don't see it there.)


on the klibido site?! maybe its devs have gone with gtk+ and pan.... :-(


> > it's a little too complicated to me. i'm usually using pan just for
> > browsing the newsgroups and read some text articles.
>
>
> So you're not too serious about the downloading thing, like every day or
> whatever, only maybe once a week or so, when you get time?  I can see
> that, and in fact don't do a lot of binary downloading here, either, tho
> when I do, I tend to get REALLY serious about it for awhile.  Sort of
> like Charles with developing pan, I guess.  I'll go awhile without, then
> get REALLY serious and go to town on it for awhile, before I get too busy
> again...
>
> Yeah, in that case, for simple browsing and pick and choose here and
> there downloading, most of the techniques I mentioned aren't particularly
> useful.


yep, that was quite the point. it could be useful if i would have to put
some cron jobs over big serious downloads, but for that i'd chose a terminal
nzb capable and do some scripts on it and cron.


-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Beso <givemesugarr@gmail.com> posted
d257c3560805311124i5244a139h99f88a9510e9d20b@mail.gmail.com, excerpted
below, on  Sat, 31 May 2008 18:24:08 +0000:

> on the klibido site?! maybe its devs have gone with gtk+ and pan.... :-(

Dev, singular.  At least from all indications and he said it was just 
him, at one point.  Of course, pan isn't much more than one main dev 
either, and a fits and starts one that goes great guns for awhile then 
ignores it for awhile, at that.  But pan does seem to have a relatively 
active user base (including me, probably the senior regular on the pan 
lists) and several devs that submit patches from time to time, as well as 
i18n and HIG support and bug and svn infrastructure from the GNOME guys.  
The klibido dev mentioned getting I think one patch from someone else, 
and it's a relatively new project (tho it's been a few years now), so 
it's likely much more a single-man operation.

But your point is well taken.  It was 2006 and the last release was, he 
said, an "intermediate" release as he worked on a couple db changes... 
but the newer version or for that matter any other further changes... 
never came.  Who knows?  It could have simply been something he did in 
college, then he graduated, maybe got married and had a kid, and hasn't 
thought much about it since.

If I ever decided to get back into it, I'd certainly join the user list 
and see what was up, if anything.  Of course now, I may not, since 
there's little reason to if he's not going to port it to KDE4, and 
there's no sign of any recent life, so who knows?

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Samstag, 31. Mai 2008, Beso wrote:
another good thing of paludis is the use of sets that
> include a list of packages. i've actually been using them to update live
> packages without putting them all hand by hand everytime.

http://www.pkgcore.org/trac/pkgcore/wiki/Features

http://www.pkgcore.org/trac/pkgcore/doc/doc/getting-started.rst
--->
Sets
Available sets are dependent upon your configuration. The majority of users 
still use /etc/make.conf configuration, which has five default sets:
system, world, installed, version-installed, glsa
system, world:
 These two are the same as in portage.
version-installed:
versioned-installed is a set of all CPVs from the vdb. This is useful 
for --emptytree.
Example:
If you have app/foo-1 and bar/dar-2 installed (and just those), 
versioned-installed would be a set containing -app/foo-1 and -bar/dar-2.
installed:
installed is an unversioned set, but is slotted. Unlike version-installed, 
installed can be used for "system update". Using pmerge -us installed over 
pmerge -u -s system -s world also has the advantage that dependency-orphaned 
packages are updated.
Example:
If you had app/foo-1 slot 1, app/foo-2 slot 2, installed would be a set 
containing app/foo:1 app/foo:2.
glsa:
 Packages that are vulnerable to security bugs, as specified in their 
appropriate Gentoo Linux Security Advisory (GLSA).
Custom Sets
Doing this for a make.conf configuration is pretty simple. Just add a file 
to /etc/portage/sets, containing a list of atoms. The set name is the 
filename.
Example: Making a kde set:
pquery 'kde-*/*' --no-version > /etc/portage/sets/kde-set
pmerge -uDs kde-set
<-----

---->

New in pkgcore:
--ignore-failures:
Ignore resolution/build failures, skipping to the next step. Think of it as 
the equivalent of --skipfirst, just without the commandline interruption.
It goes without saying that this feature should be used with care. It is 
primarily useful for a long chain of non-critical updates, where a failure is 
not an issue.
A good example of usage is if you want to build mozilla-firefox and openoffice 
overnight: both take a long while to build (including their dependencies), 
and the user is after getting as many packages built for the targets as 
possible, rather then having the 5th build out of 80 bail out without even 
attempting the other 75.
Long term, this feature will likely be replaced with a more finely tuned 
option.

<-----

people who asked for a similar functionality in paludis were called stupid.
(asking for skipfirst equivalent)
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
> New in pkgcore:
> --ignore-failures:
> [snip]
>
> people who asked for a similar functionality in paludis were called stupid.
> (asking for skipfirst equivalent)

[dleverton@shiny-one ~] $ paludis --help
[snip]
  --continue-on-failure  Whether to continue after a fetch or install error
      if-fetch-only        If fetching only (default)
      never                Never
      if-satisfied         If remaining packages' dependencies are satisfied
      if-independent       If independent of failed and skipped packages
      always               Always (UNSAFE)

-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

David Leverton <levertond@googlemail.com> posted
200805312034.51915.levertond@googlemail.com, excerpted below, on  Sat, 31
May 2008 20:34:51 +0100:

> On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
>> New in pkgcore:
>> --ignore-failures:
>> [snip]
>>
>> people who asked for a similar functionality in paludis were called
>> stupid. (asking for skipfirst equivalent)
> 
> [dleverton@shiny-one ~] $ paludis --help [snip]
>   --continue-on-failure  Whether to continue after a fetch or install
>   error
>       if-fetch-only   If fetching only (default)
>	never           Never
>       if-satisfied    If remaining packages' dependencies are satisfied
>	if-independent  If independent of failed and skipped packages
>       always          Always (UNSAFE)

I don't have a particular dog in this fight, but that's not the same 
thing.  --skip-first allows the admin to react to whatever when wrong, 
try to fix it, and use the skip option only if he decides it's 
warranted.  IOW, it's sort of interactive, tho over time.  It appears 
this option must be added at the beginning, before one knows there'll be 
an error, and independent of what that error might be.  

(I'm assuming paludis creates a log of what failed, so one can try them 
again later, after fixing the problem or getting a package update or 
whatever.  If not, that's another difference, as the --skipfirst option 
allows one to (manually) create such a list, and in fact that's what I 
use it for when doing an emerge --emptytree after upgrading gcc, for 
instance.  The old packages often still work fine so don't /have/ to be 
upgraded, but with a list, as they are fixed to work with the new 
version, they can be retried and if successful, stricken from the list, 
thus gradually shrinking the number of packages not compatible with the 
new gcc version.)

I did see the log where the --skipfirst functionality request was called 
stupid.  I never quite understood why.  If the above was already there 
and considered equivalent, I can see why the request might be called 
stupid, but nobody bothered to explain that if it was indeed the case, so 
both the requester and all the others that ended up seeing that IRC log 
missed out on the real answer.  Unfortunately, that sort of "missing out" 
has become somewhat of a pattern, altho if/when the explanation /does/ 
come, it's usually very well reasoned out.  It's just worse than pulling 
teeth to get it, sometimes, even on the devel list after being asked 
repeatedly by multiple devs, which is where I see the pattern repeated 
most often, since as a good admin, I lurk there to see what's coming down 
the road before I hit it.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[David Leverton]

On Sunday 01 June 2008 00:54:19 Duncan wrote:
> I don't have a particular dog in this fight, but that's not the same
> thing.

The point is that our little friend was gloating about how pkgcore has such a 
cool feature and paludis has nothing like it, when in fact paludis has 
something far better.

> I did see the log where the --skipfirst functionality request was called
> stupid.  I never quite understood why.

Assuming you mean the log that I think you mean, that person was called stupid 
due to

(zhllg) mlangc, actually i use this script to update the system: "sudo 
emerge -tauvDN world || until sudo emerge --resume --skipfirst; do sudo 
emerge --resume --skipfirst; done

I hope you understand what's wrong with that.
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

David Leverton <levertond@googlemail.com> posted
200806010117.27540.levertond@googlemail.com, excerpted below, on  Sun, 01
Jun 2008 01:17:26 +0100:

> Assuming you mean the log that I think you mean, that person was called
> stupid due to
> 
> (zhllg) mlangc, actually i use this script to update the system: "sudo
> emerge -tauvDN world || until sudo emerge --resume --skipfirst; do sudo
> emerge --resume --skipfirst; done
> 
> I hope you understand what's wrong with that.

Well, yes, if that's /all/ he does, but that isn't necessarily the case, 
and if it is, that's a serious user educational opportunity missed when 
one just says he's stupid and kicks him, refusing to explain why or how 
he's stupid or what the better approach might be and why.  The problem, 
regardless of whether it was a user who hadn't thought things thru or a 
problem with the software, didn't get solved.  It still exists, in fact 
worse now, because there's now a frustrated user even /more/ convinced 
he's dumb and can't hope to understand how to do it right.  That's 
another user now well on the way to being a dumb malware host and 
propagator, because everybody treats them as too stupid to understand how 
to act responsibly, and eventually, they give in and start to act like it 
and ultimately, believe it themselves.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Richard Freeman]

Duncan wrote:
> I don't have a particular dog in this fight, but that's not the same 
> thing.  --skip-first allows the admin to react to whatever when wrong, 
> try to fix it, and use the skip option only if he decides it's 
> warranted.  IOW, it's sort of interactive, tho over time.  It appears 
> this option must be added at the beginning, before one knows there'll be 
> an error, and independent of what that error might be.  
> 
> (I'm assuming paludis creates a log of what failed, so one can try them 
> again later, after fixing the problem or getting a package update or 
> whatever.  

Sure it does - but you can go one better.  When paludis dies it can be 
asked to create a resume script - a command line that will resume where 
it left off.  This will include all the packages that it hadn't yet 
installed.  You can edit this command line as you please and execute it.

It isn't exactly --skipfirst, but it is better in some regards and maybe 
worse in others.

Oh, even if you don't want to use paludis as your package manager you 
might want to look at adjutrix.  There are scripts that do the same 
sorts of things with portage, but adjutrix can do reverse deps in 
seconds, or a comparison of amd64 to x86 for keywording purposes.

Also - paludis's support for GLSAs is nice - paludis -i security will 
install all security updates, and paludis --report will catch any 
unfixed GLSAs.

Again - the best package manager is situation-dependent.  I'm 
occasionally disappointed by some of paludis's developers (and some of 
its detractors), but it is a very capable piece of software.
-- 
gentoo-amd64@lists.gentoo.org mailing list

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

Richard Freeman <rich0@gentoo.org> posted 4842013B.7090101@gentoo.org,
excerpted below, on  Sat, 31 May 2008 21:54:03 -0400:

> but you can go one better.  When paludis dies it can be asked to create
> a resume script - a command line that will resume where it left off. 
> This will include all the packages that it hadn't yet installed.  You
> can edit this command line as you please and execute it.
> 
> It isn't exactly --skipfirst, but it is better in some regards and maybe
> worse in others.

That's a very nice feature, indeed! I'm impressed! =8^)

[snipped discussion of a feature I've no comment on]

> Also - paludis's support for GLSAs is nice - paludis -i security will
> install all security updates, and paludis --report will catch any
> unfixed GLSAs.

That's nice for folks running what to me might as well be 20th century 
software, stable folks who are running servers and the like and thus 
don't update very often.  There's certainly a place for such.  However, 
here I run all ~amd64, normally synced and updated (deep newuse world) 
weekly or better, and by the time the GLSAs come out, I've often been 
running the fixed versions for weeks already!  I do still keep track of 
the announcements, and check versions occasionally, but only maybe once 
or twice a year does the GLSA come out close enough to the release of the 
fix that I actually have to do an upgrade based on it.

Therefore, automated GLSA processing might be nice for some, just as the 
terrible quakes in China were literally the end of the world for some, 
but neither one really affects me where I live.

> Again - the best package manager is situation-dependent.  I'm
> occasionally disappointed by some of paludis's developers (and some of
> its detractors), but it is a very capable piece of software.

Absolutely agreed, the best PM *IS* situation dependent.  I'm also very 
glad Gentoo's got a wealth of three entirely different choices to choose 
from.  Definitely following the Open Source and standardisation spirit! 
=8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/31 Duncan <1i5t5.duncan@cox.net>:

> David Leverton <levertond@googlemail.com> posted
> 200805312034.51915.levertond@googlemail.com, excerpted below, on  Sat, 31
> May 2008 20:34:51 +0100:
>
> > On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
> >> New in pkgcore:
> >> --ignore-failures:
> >> [snip]
> >>
> >> people who asked for a similar functionality in paludis were called
> >> stupid. (asking for skipfirst equivalent)
> >
> > [dleverton@shiny-one ~] $ paludis --help [snip]
> >   --continue-on-failure  Whether to continue after a fetch or install
> >   error
> >       if-fetch-only   If fetching only (default)
> >       never           Never
> >       if-satisfied    If remaining packages' dependencies are satisfied
> >       if-independent  If independent of failed and skipped packages
> >       always          Always (UNSAFE)
>
> I don't have a particular dog in this fight, but that's not the same
> thing.  --skip-first allows the admin to react to whatever when wrong,
> try to fix it, and use the skip option only if he decides it's
> warranted.  IOW, it's sort of interactive, tho over time.  It appears
> this option must be added at the beginning, before one knows there'll be
> an error, and independent of what that error might be.
>
> (I'm assuming paludis creates a log of what failed, so one can try them
> again later, after fixing the problem or getting a package update or
> whatever.  If not, that's another difference, as the --skipfirst option
> allows one to (manually) create such a list, and in fact that's what I
> use it for when doing an emerge --emptytree after upgrading gcc, for
> instance.  The old packages often still work fine so don't /have/ to be
> upgraded, but with a list, as they are fixed to work with the new
> version, they can be retried and if successful, stricken from the list,
> thus gradually shrinking the number of packages not compatible with the
> new gcc version.)
>

paludis always creates logs, even if everything goes fine. you could disable
them but it's unsafe.


> I did see the log where the --skipfirst functionality request was called
> stupid.  I never quite understood why.  If the above was already there
> and considered equivalent, I can see why the request might be called
> stupid, but nobody bothered to explain that if it was indeed the case, so
> both the requester and all the others that ended up seeing that IRC log
> missed out on the real answer.  Unfortunately, that sort of "missing out"
> has become somewhat of a pattern, altho if/when the explanation /does/
> come, it's usually very well reasoned out.  It's just worse than pulling
> teeth to get it, sometimes, even on the devel list after being asked
> repeatedly by multiple devs, which is where I see the pattern repeated
> most often, since as a good admin, I lurk there to see what's coming down
> the road before I hit it.
>

the --skipfirst is stupid. it just skips the first package that failed. the
problem is  the following: if a package has failed and the following is
dependant on it the skipfirst just resumes portage and then issues an error
of deps not met and stops. this would stop your emerge and you would need to
do the emerge again, since a --resume doesn't find anything to resume. the
continue-on-failure is a little more intelligent:
normally, if a package has a dependance on a package that failed (even if
not strictly on the version that failed to install) the package would have
been skipped. the other option is to skip a package if the deps installed
are satisfied (so if you have a dep on >=openldap-2.3.x and openldap-2.4.1
fails to install the packages that with the first option would have been
skipped would now install, since openldap-2.3.5 is present). the other
continue options are stupid and most likely to do some real harm so i don't
tend to consider them useful. at the end of the emerge process paludis
prints the packages that have failed and gives a command line to resume the
emerge operation, including the various logs of failure and the messages
from the packages that have been succefully merged.
this option doesn't prevent errors, but tells paludis to continue the work
if possible and let the eventual errors to be controlled at the admin
return. pkgcore seems to do something similar, by looping the --skipfirst
option, but that is more like the continue-on-failure always with the skip
of the first package on the resume. it's a bit stupid, but still more useful
than the --skipfirst of portage.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Hemmann, Volker Armin]

On Samstag, 31. Mai 2008, David Leverton wrote:
> On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
> > New in pkgcore:
> > --ignore-failures:
> > [snip]
> >
> > people who asked for a similar functionality in paludis were called
> > stupid. (asking for skipfirst equivalent)
>
> [dleverton@shiny-one ~] $ paludis --help
> [snip]
>   --continue-on-failure  Whether to continue after a fetch or install error
>       if-fetch-only        If fetching only (default)
>       never                Never
>       if-satisfied         If remaining packages' dependencies are
> satisfied if-independent       If independent of failed and skipped
> packages always               Always (UNSAFE)

oh, cool. After calling everybody stupid and retarded who asked for something 
like that, they finally implemented it. That is what I call adult behaviour.
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/6/1 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:

> On Samstag, 31. Mai 2008, David Leverton wrote:
> > On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
> > > New in pkgcore:
> > > --ignore-failures:
> > > [snip]
> > >
> > > people who asked for a similar functionality in paludis were called
> > > stupid. (asking for skipfirst equivalent)
> >
> > [dleverton@shiny-one ~] $ paludis --help
> > [snip]
> >   --continue-on-failure  Whether to continue after a fetch or install
> error
> >       if-fetch-only        If fetching only (default)
> >       never                Never
> >       if-satisfied         If remaining packages' dependencies are
> > satisfied if-independent       If independent of failed and skipped
> > packages always               Always (UNSAFE)
>
> oh, cool. After calling everybody stupid and retarded who asked for
> something
> like that, they finally implemented it. That is what I call adult
> behaviour.



well, yours is equal.... it seems that the explanation of how the
continue-on-failure works and on what differences (noticeable ones) are
between the 2 flags hasn't reached your mind. you who continue to just flame
against a piece of software just because it has been done by someone you
don't like, without even considering its good and bad sides are no less than
the ones you just look down on. it was you who has brought out the flame
when it wasn't necessary and when i was replying to a duncan's question
which had nothing to do with flames and shouldn't bother package installers
behaviour. and everytime the things would have taken the road to calm down
you would just get out with other flames. it seems that you like a lot
flaming... well, maybe it's time to settle down a little and if you want to
flame post another thread with flame paludis vs other world as subject and
flame there. whoever reads the subject of the thread would not think to see
a flame between paludis and portage.
thanks.

-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[ionut cucu]

On Sun, 1 Jun 2008 20:59:02 +0200
"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> wrote:

> On Samstag, 31. Mai 2008, David Leverton wrote:
> > On Saturday 31 May 2008 20:25:42 Hemmann, Volker Armin wrote:
> > > New in pkgcore:
> > > --ignore-failures:
> > > [snip]
> > >
> > > people who asked for a similar functionality in paludis were
> > > called stupid. (asking for skipfirst equivalent)
> >
> > [dleverton@shiny-one ~] $ paludis --help
> > [snip]
> >   --continue-on-failure  Whether to continue after a fetch or
> > install error if-fetch-only        If fetching only (default)
> >       never                Never
> >       if-satisfied         If remaining packages' dependencies are
> > satisfied if-independent       If independent of failed and skipped
> > packages always               Always (UNSAFE)
> 
> oh, cool. After calling everybody stupid and retarded who asked for
> something like that, they finally implemented it. That is what I call
> adult behaviour.
<LOUD>Dude!</LOUD>
What's wrong with you? Firstly nobody compels you to use it, secondly
you're sooooo missing the difference between --skip-first and
--continue-on-failure, thirdly I use what I like, stop spitting on it!
There is one thing a "constructive criticism" but just offending,
without ever using it, or knowing what you're talking about is just
wrong! So please mind you're language, provide a well documented
opinion,and so on....
[OT]: I really like the idea of having several package managers to
choose from because: Gentoo is about choice!
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Mark Haney]

ionut cucu wrote:
> On Sun, 1 Jun 2008 20:59:02 +0200

Man, I've opened up a HUGE can o'worms here.  I didn't mean to.  But 
back to the reason for the post, I cannot find the correct KDE4.1 
overlay.  I read that it was kdesvn-portage, but it's not that I can 
tell.  So, if it's not there, where is it.  I'm all for testing the crap 
out of it and reporting bugs at this point.



-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/6/2 Mark Haney <mhaney@ercbroadband.org>:

> ionut cucu wrote:
>
>> On Sun, 1 Jun 2008 20:59:02 +0200
>>
>
> Man, I've opened up a HUGE can o'worms here.  I didn't mean to.  But back
> to the reason for the post, I cannot find the correct KDE4.1 overlay.  I
> read that it was kdesvn-portage, but it's not that I can tell.  So, if it's
> not there, where is it.  I'm all for testing the crap out of it and
> reporting bugs at this point.
>

the 4.1 beta should be at least 4.0.80 version. that overlay should be the
one of the 4.1 support thread and should have the old ebuild system. 4.1
shouldn't hit portage until official release (about 1 or 2 week after
release). the last i've checked that overlay had the old 4.1 alpha 1,
already surpassed in quality and stability by the paludis-kde4 scm overlay.
you'll just still have to check how does that overlay (the one mentioned in
the 4.1 support thread) evolve and hope it works. i haven't tried it myself,
but i know 2 things:
1. kde 4.1 should be much more stable than kde 4.0.x or kde4-scm versions
available in portage and kde4-experimental overlay
2. i've tried it on a livecd and works fine for me, so if it doesn't really
work well then maybe it's due to the overlay mantainers not doing a good
work.


-- 
dott. ing. beso

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

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Mark Haney]

Beso wrote:
> 2008/6/2 Mark Haney <mhaney@ercbroadband.org>:
> 
>> ionut cucu wrote:
>>
>>> On Sun, 1 Jun 2008 20:59:02 +0200
>>>
>> Man, I've opened up a HUGE can o'worms here.  I didn't mean to.  But back
>> to the reason for the post, I cannot find the correct KDE4.1 overlay.  I
>> read that it was kdesvn-portage, but it's not that I can tell.  So, if it's
>> not there, where is it.  I'm all for testing the crap out of it and
>> reporting bugs at this point.
>>
> 
> the 4.1 beta should be at least 4.0.80 version. that overlay should be the
> one of the 4.1 support thread and should have the old ebuild system. 4.1
> shouldn't hit portage until official release (about 1 or 2 week after
> release). the last i've checked that overlay had the old 4.1 alpha 1,
> already surpassed in quality and stability by the paludis-kde4 scm overlay.
> you'll just still have to check how does that overlay (the one mentioned in
> the 4.1 support thread) evolve and hope it works. i haven't tried it myself,
> but i know 2 things:
> 1. kde 4.1 should be much more stable than kde 4.0.x or kde4-scm versions
> available in portage and kde4-experimental overlay
> 2. i've tried it on a livecd and works fine for me, so if it doesn't really
> work well then maybe it's due to the overlay mantainers not doing a good
> work.
> 
> 

Beso, I tried to get the kde4-live overlay and layman sys it doesn't 
exist.  Even when I pulled in the xml file via the URL it didn't come 
up.  Ah well, maybe I'll just wait for 4.1 to be released.


-- 
Libenter homines id quod volunt credunt -- Caius Julius Caesar


Mark Haney
Sr. Systems Administrator
ERC Broadband
(828) 350-2415

Call (866) ERC-7110 for after hours support
-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/6/2 Mark Haney <mhaney@ercbroadband.org>:

> Beso wrote:
>
>> 2008/6/2 Mark Haney <mhaney@ercbroadband.org>:
>>
>>  ionut cucu wrote:
>>>
>>>  On Sun, 1 Jun 2008 20:59:02 +0200
>>>>
>>>>  Man, I've opened up a HUGE can o'worms here.  I didn't mean to.  But
>>> back
>>> to the reason for the post, I cannot find the correct KDE4.1 overlay.  I
>>> read that it was kdesvn-portage, but it's not that I can tell.  So, if
>>> it's
>>> not there, where is it.  I'm all for testing the crap out of it and
>>> reporting bugs at this point.
>>>
>>>
>> the 4.1 beta should be at least 4.0.80 version. that overlay should be the
>> one of the 4.1 support thread and should have the old ebuild system. 4.1
>> shouldn't hit portage until official release (about 1 or 2 week after
>> release). the last i've checked that overlay had the old 4.1 alpha 1,
>> already surpassed in quality and stability by the paludis-kde4 scm
>> overlay.
>> you'll just still have to check how does that overlay (the one mentioned
>> in
>> the 4.1 support thread) evolve and hope it works. i haven't tried it
>> myself,
>> but i know 2 things:
>> 1. kde 4.1 should be much more stable than kde 4.0.x or kde4-scm versions
>> available in portage and kde4-experimental overlay
>> 2. i've tried it on a livecd and works fine for me, so if it doesn't
>> really
>> work well then maybe it's due to the overlay mantainers not doing a good
>> work.
>>
>>
>>
> Beso, I tried to get the kde4-live overlay and layman sys it doesn't exist.
>  Even when I pulled in the xml file via the URL it didn't come up.  Ah well,
> maybe I'll just wait for 4.1 to be released.
>
>
as i've said i've not tried it out myself, but they posted an xml which
should be added to layman and then he should find and add the overlay.
alternatively you could just manually do a git clone or svn co of the
repository and then add the main directory to make.conf in the overlay dirs.


-- 
dott. ing. beso

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

[gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Duncan]

"Hemmann, Volker Armin" <volker.armin.hemmann@tu-clausthal.de> posted
200805312125.42938.volker.armin.hemmann@tu-clausthal.de, excerpted below,
on  Sat, 31 May 2008 21:25:42 +0200:

> http://www.pkgcore.org/trac/pkgcore/wiki/Features
> 
> http://www.pkgcore.org/trac/pkgcore/doc/doc/getting-started.rst

Thanks. =8^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

-- 
gentoo-amd64@lists.gentoo.org mailing list

Re: [gentoo-amd64] Re: KDE 4.0.4 upgrade, sort of.

[Beso]

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

2008/5/30 Hemmann, Volker Armin <volker.armin.hemmann@tu-clausthal.de>:

> On Freitag, 30. Mai 2008, Duncan wrote:
>
> > I've not done paludis due to its lack of binary package support.  Even
> > tho I'm running only a single computer
>
> there is another reason not to use paludis:
>
> you can't go back.
>
> At least not easily.
>
> With pkgcore you can switch between pkgcore and portage 'on the fly'.
> emerge
> app a, pmerge app b, emerge app c.
>
> The config files are not touched.


with paludis the portage config files are not touched. paludis has its own
config dir where to install its personal config files. i use portage
regulary to compile with ABI=x86 which paludis has some problems with and
sometimes goes a little mad.

>
> Paludis on the other hand can only described with 'vendor lock in'
> and 'gratuitous incompatibilty'. And don't forget that it is slow.
>

on what base you say it's slow?! i'm using it because on my system is tons
of times faster; i really assure you that is faster in discovering deps and
it finds them in the right way at least. i'm now rebuilding a new clean
system and with portage i've got problems building it since portage quite
some time has not selected the right dependency and thus builds fail. with
paludis for now this hasn't yet happened. to not speak of the continue
option: with portage after a package compile/install fail portage stops and
doesn't continue. after you do a --resume skipfirst most of the times the
build will completely fail because of deps not met and then there would be
no way to resume the actual build. paludis has the continue-on-errors option
with cases like if package is independent of the one failed (useful in new
sytem builds), if requirements not met (useful in world updates) and also it
gives a list of packages. you could edit the list and set S instead of P
whenever you'd like to skip a specific package.


That it also requires a shitload of dependencies and installs more crap than
> portage and pkgcore combined doesn't make it better.
>

on this i can agree with you. i'd just want to show one thig, though: on the
new system i've installed the weekly stages from funtoo, rebuild the system
with emerge -e system, rebuild again the system with emerge -e system and my
personal use flags and then build xorg-server with portage. after that,
since i wanted kde4-svn i installed paludis and, miracle, the only real dep
needed for me there was boost. it seems that now the deps aren't so huge
anymore. anyway that it takes a big deal of time every update is right (2,5
hours with inram compilation).

At a last point: don't forget WHO is behind paludis - some of the most
> abusive
> persons gentoo has ever seen. The same people responsible for most
> problems.
>
> Abusive, agressive, searching for stuff that is not covered by rules,
> behave
> like a rabid ape until everything is covered by rules, suffocating gentoo
> and
> then turn into rule nazis and game the system. Yes, this people are behind
> paludis - and 'exherbo'.


a software is not to be judged by its creators, but on what it does. as i've
said paludis has some flaws (is written in c++, it takes ages to update, it
doesn't behave very well with x86 abi on multilib profiles, lacks binpkg
support) but also has some better issues (a big deal of hooks that improve
it very much, it can handle very external overlays and update them without
passing through another package and this is i think the best thing of
paludis, is can handle per package or per overlay, keyword and unmask
configs, it can use eix through the eix hook, it can show new packages in
the tree after update and show a report of your system, is fast on first run
world update - on 400+ package world the time of resolving deps and
everything is less than 30 secs, while portage on first run goes for some
minutes, it has reconcilio that is faster and cleaner than revedep-rebuild
and it handles the new scm build system which is really nice. the problem
with that build system is its test. portage won't adopt it for the moment
because it still has to be tested but that a package can suggestother
packages and the user would be able to accept suggestions or not is a big
step towards usability.

-- 
dott. ing. beso

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