Neil Bothwick | 1 Jun 2011 01:05
Picon

Re: Cleaning redundant configuration files

On Tue, 31 May 2011 23:43:59 +0100, David W Noon wrote:

> Remember that I am writing purely about *unmerged* packages.  In the
> case of a rebuild or upgrade, customizations would be preserved just
> as they are now.

Sometimes it is necessary to unmerge a package before emerging a newer
version, either manually or by portage, to resolve blockers. Making
unmerge remove all config files would cause breakage in such a case.

There's a reason why the CONFIG_PROTECT variable is so named.

--

-- 
Neil Bothwick

Dream as if you'll live forever. Live as if you'll die today.
Neil Bothwick | 1 Jun 2011 01:14
Picon

Re: Cleaning redundant configuration files

On Tue, 31 May 2011 17:26:43 +0100, David W Noon wrote:

> >> You have just touched on an annoyance of unmerge, in that it does not
> >> clean up configuration files that have been modified.  It removes
> >> files that are still in the same state as when the package was
> >> emerged, but not those modified by the user.  I don't see how user
> >> changes make the file more important than would be in its vanilla
> >> state.
> >
> >It doesn't remove *any* files that have been modified,
> 
> Erm ... that's what I wrote, above. 

No it's not. You were referring to a special case of the general
statement I made.

> [That is, of course, predicated on
> the assumption that installing Package A will not modify configuration
> files owned by Package B, and vice-versa: all post-installation
> modifications are performed by the user.]

That is valid, provide collision-protect is included in FEATURES.

> >the reasons
> >systems used to get cluttered with orphaned .la files. The logic is
> >quite simple, if it is not the file portage installed with the
> >package, it should not be uninstalled with the package.
> 
> Why should that be so?

(Continue reading)

Alan McKinnon | 1 Jun 2011 01:30
Picon

Re: kde update

Apparently, though unproven, at 00:35 on Wednesday 01 June 2011, Dale did 
opine thusly:

> Alan McKinnon wrote:
> > Apparently, though unproven, at 23:55 on Tuesday 31 May 2011, Dale did
> > opine
> > 
> > thusly:
> >>> It appears I was wrong after all.
> >>> 
> >>> Manners dictates that apologies to Dale are in order.
> >>> 
> >>> Sorry Dale.
> >> 
> >> No need.  I'm more worried about the heat over here.  It's going to be
> >> 100F tomorrow.  My poor garden is starting to cook the food as well as
> >> grow it.  O_O  I just need to explain it better from now on.  ;-)
> > 
> > You live down Louisiana/New Orleans way right? Sticking hot in summer.
> > Fine bourbon though. And blues, don't forget the blues.
> > 
> > Or you could come over to Johannesburg and luxuriate in our wonderful
> > high- altitude winters. Tonight is predicted to be -2 deg C
> 
> I live in Mississippi.  Never been to New Orleans but bet it about the
> same tho.  It's sticky and hot plus the sun cooks you pretty good, like
> being on broil in a oven.  I'm just glad I am not a tomato plant out in
> this.  I got some garden pics on here:
> 
> http://www.facebook.com/profile.php?id=1152574063
(Continue reading)

Peter Humphrey | 1 Jun 2011 01:48

Re: Cleaning redundant configuration files

On Wednesday 01 June 2011 00:14:04 Neil Bothwick wrote:

> It's quite simple logic... If a file is modified, it is no longer the file
> portage installed, so portage does not uninstall it. If anything, the
> problem is that the logic used by portage is too simple.

I don't think it's too simple. It seems exactly right for the task to me: 
clear, predictable and easily understood.

> A customised file contains an investment of the user's time, a generic
> file does not. That investment may be small or great, but it is not
> for portage to determine that value and remove the file without the
> user's consent.

Personally, I'd be livid if portage were to remove my carefully crafted work 
from time immemorial, without so much as a by-your-leave. Anyone who wants 
to delete his own work is free to do so, but the rest of us ought not to be 
required to suffer it.

--

-- 
Rgds
Peter

Peter Humphrey | 1 Jun 2011 01:49

Re: kde update

On Wednesday 01 June 2011 00:30:37 Alan McKinnon wrote:

> And what's that gigantic gate over the river behind you in the profile
> pic? Looks a bit like the sea wall gates on the Thames.

A good deal less elegant though  :)

--

-- 
Rgds
Peter

Dale | 1 Jun 2011 01:55
Picon

Re: Cleaning redundant configuration files

Neil Bothwick wrote:
> On Tue, 31 May 2011 23:43:59 +0100, David W Noon wrote:
>
>    
>> Remember that I am writing purely about *unmerged* packages.  In the
>> case of a rebuild or upgrade, customizations would be preserved just
>> as they are now.
>>      
> Sometimes it is necessary to unmerge a package before emerging a newer
> version, either manually or by portage, to resolve blockers. Making
> unmerge remove all config files would cause breakage in such a case.
>
> There's a reason why the CONFIG_PROTECT variable is so named.
>
>
>    

I had thought of something like that being done manually but didn't 
think of portage doing it itself.  That's a better reason than mine even 
tho it does the same thing.

Dale

:-)  :-)

Dale | 1 Jun 2011 02:11
Picon

Re: kde update

Alan McKinnon wrote:
> So that's what you look like :-)  I had a ... very different ... mental
> picture (also a complete fiction).
>
> There's no public photos on your page though :-(
>
> And what's that gigantic gate over the river behind you in the profile pic?
> Looks a bit like the sea wall gates on the Thames.
>
>    

You thought I was some old geezer with gray hair huh?  lol   Hmmm, I do 
have some of those tho.  It's not as funny now.  :-(  The thing behind 
me is a lock and dam.  The locks are on the other side so you can't see 
those. Tthat is where boats and barges go through to navigate the 
river.  The part behind me is the dam with gates.  It's sort of like 
flood control I guess.  When it rains a lot, they open them up wide.  
There is a large amount of water going through there at times.  
Sometimes it is so much they won't let anyone get close to it.  People 
can fish there tho.  You just loose a lot of bait in those huge rocks.

I made some of the pictures public now.  Try it again and see if you can 
see more.  Mostly me, puter stuff and my garden.  Yea, I live in the 
sticks.  The puter pics are of the new rig I built a while back and am 
currently typing on.  That's my Gentoo rig.  Folks that have been on 
here a while know I just got DSL a year or so ago.  I was on dial-up 
before that.  It took 2 to 3 days just to download the new KDE stuff.  
Let's not talk about downloading the CD's and such.  Awww heck, let's 
do.  That takes about a week to get if it is not to big.  A full CD 
takes about a week and a half at times.  DSL is MUCHO better.  lol
(Continue reading)

Adam Carter | 1 Jun 2011 03:31
Picon

Re: Caching Proxy alternative to Squid?

I've been having problems with my Squid-equipped Gentoo box: For some
sites, Squid just times out. But if I access the sites directly, they
appear in my browser. And doing a direct wget from the Squidbox also
works.

Now I'm not sure whose 'fault' it is, but just in case it's Squid's,
I'll experiment with other web proxies.

No problems with squid here - why not try troubleshooting?
- which version of squid? if arch, have you tried ~arch?
- what does the access and error logs say about the sites that fail?

Allan Gottlieb | 1 Jun 2011 06:00
Picon

unable to find xcb-{aux, event, atom}

I get the following error several times when trying to emerge
gnome-panel on "oldlap", an ~x86 gentoo.

  CCLD   panel-test-applets
/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lxcb-aux
/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lxcb-event
/usr/lib/gcc/i686-pc-linux-gnu/4.5.2/../../../../i686-pc-linux-gnu/bin/ld: cannot find -lxcb-atom
collect2: ld returned 1 exit status

oldlap ~ # locate xcb-aux
/usr/lib/pkgconfig/xcb-aux.pc
oldlap ~ # 

On "ajglap", which is ~amd64, gnome panel is fine and

ajglap gottlieb # locate xcb-aux
/usr/lib64/pkgconfig/xcb-aux.pc
ajglap gottlieb # 

which seems to me to be the same as for "oldlap" except for the 64 vs 32
difference expected for ~amd64 vs ~x86.

Any suggestions would be appreciated.

thanks,
allan

Pandu Poluan | 1 Jun 2011 06:52
Gravatar

Re: Anyone running a gentoo guest on virtualbox?

On Wed, Jun 1, 2011 at 03:35, Mick <michaelkintzios <at> gmail.com> wrote:
> On Tuesday 31 May 2011 21:02:46 Alan McKinnon wrote:
>> Apparently, though unproven, at 21:27 on Tuesday 31 May 2011, Mick did
>> opine
>>
>> thusly:
>> > On Tuesday 31 May 2011 08:07:24 Pandu Poluan wrote:
>> > > On Tue, May 31, 2011 at 13:56, Alan McKinnon <alan.mckinnon <at> gmail.com>

----- 8< ----- massive snippage ----- >8 -----

>> > > When SpanKY's makedev gets stabilized and pushed to baselayout, I'll
>> > > then happily ditch the genkernel cheat for my next VMs :-)
>> >
>> > Are you sure that manually creating /dev/console and /dev/null isn't all
>> > that is required?  The rest of the devices will be created by udev when
>> > it runs at boot time.
>>

Most probably so. But at that point, I was pressed for time. Had the
system need only /dev/{console,null} then all will be well. If not?
Then another cycle of LiveCD-mount-mknod-restart.

Much faster to just `genkernel initramfs` while waiting for the snafus
to be fixed

(Well, that, and I'm lazy)

>> null and console are the absolute irreducible minimum but there's one that
>> can be dispensed with if the correct kernel option is enabled.
>>
>> We don't need everything that makedev traditionally provided (like every
>> block device type known to man, floppys and ancient ptys) but the rest
>> number about ~250 and are useful in single-user mode if udev fails to
>> start.
>>
>> Considering that ~250 devices consumes a teeny-weeny bit of disk space and
>> they are hidden from view normally, I say it's worth it leaving them in.
>> Which is what vapier also says.

Agree.

> I see.  In my head it is as if we're going against the udev principle of
> populating required device nodes.  If udev does not start, isn't it time to
> head for the nearest LiveCD, or must we ensure that every breakage is fixable
> in single-user mode?

There are cases for each, but I personally prefer going single-user.
Especially when working on virtualized servers.

Rgds,
--

-- 
Pandu E Poluan
~ IT Optimizer ~
Visit my Blog: http://pepoluan.posterous.com


Gmane