how to contribute to use/slot deps: was Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

On Sat, Dec 24, 2005 at 12:40:35PM +0900, Jason Stubbs wrote:
> On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote:
> > On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
> > > On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> > > > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > > > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> > > > >
> > > > > | Do those already work then? I'd like to be able to use them.
> > > > >
> > > > > Not in anything end users should be using. The syntax is pretty much
> > > > > decided upon though...
> > > >
> > > > Glad that they are comming though. Even though I'd probably not hold my
> > > > breath.
> > >
> > > Trolling?
> >
> > Erm..  No, I don't think he is. We've been asking / waiting for the
> > [use] syntax to appear since before you joined the project. It's been on
> > "the list" for so long that many of us have given up... ; )
> 
> Yep, bug 2272.

(still was trolling).

> > I don't think its trolling when we've been let down on it in the past,
> > had it postponed to "the great redesign"  ( project baghira,  I think,
> > too)   And so on.
> 
> "Even though I'd probably not hold my breath"? It's something that many 
> people 
> want but most are not evening willing to attempt implementing it. What was 
> the purpose of that comment?

Expanding on this since jason's email is quite a bit nicer then my 
original response.  Frankly... the potshot at portage is mild 
bullshit, but at this point I'm getting accustomed to it- bit easier 
to take a swipe at portage rather then to do actual work 
improving things (low blow potentially, but it sure as hell seems to 
be the case).

If folks are looking to get this feature, here's how you scratch that 
itch.

1) design and implement your own stable based patch that is 
maintainable.
2) help complete the saviour branch which holds a massive 
refactoring (including use/slot required refactoring).  Use/Slot is 
already sitting in that branch btw, although the resolver handling of 
it (ability to dig itself out of use cycles) isn't there yet.
3) help with the day to day bug mangling, regression fixes, and 
general maintenance.  Or work on the small features that need to be 
dealt with; either way, help reduce the load so existing portage devs 
can implement the beast.

Note that nowhere in that list, is nagging/snarky comments/general 
asshattery on public ml's listed as a means to get what you want.  

That's actually something of a negative contribution, since time is 
spent sending pissy emails such as this, or just results in 
people saying "screw portage work".  Devs making noise, you know what 
the scenario is, you're on the receiving end of it too for your area 
of work.  Portage is no different.

It's really pretty simple- get off your butt and chip in if you want 
it, else you're on _our_ timeline (eg, we implement it when we deem it 
sane/ready to go).  It's been 3 years for the bug- more then ample 
time to have contributed for some of the devs complaining in this 
thread.

Chip in, or bite your tongue essentially.
~harring


pgp8Y001vliBX.pgp
Description: PGP signature

Re: [gentoo-dev] Stepping aside...

[Curtis Napier]

Sven Vermeulen wrote:

Hi all

It is with deep regret that I want to inform you about my decision to step
down from the position of Gentoo Documentation lead. 


I can't believe this. I am very sad. Swift is my mentor and one of a few 
people whos work inspired me to donate my time to Gentoo to begin with. 
Swift, your leadership of the GDP will be missed.



Neysx, congrats on the promotion, I look forward to working with you. I 
know the GDP will flourish under your leadership just like it did under 
swifts.

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

On Sat, 24 Dec 2005 12:50:33 +0900 Jason Stubbs <[EMAIL PROTECTED]>
wrote:
| SLOT is currently an arbitrary string (without spaces) so general
| matching of "*" might be useful. Of course, there's no restriction of
| not using "*" in SLOTs at the moment either...

*shrug* SLOT will have to be tightened up anyway. Otherwise
SLOT="[foo]" will cause terrible confusion.

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

On Saturday 24 December 2005 10:25, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]>
>
> wrote:
> | kde-libs/kde:3
> | ^^^ need any kde, with slotting enabled.
> |
> | kde-libs/kde:3,4
> | ^^^ need any kde, slotting 3 or 4.

I'd prefer to not have this last one. It can be done as "|| ( kde-libs/kde:3 
kde-libs/kde:4 )" whereas all other atom constructs are already at their most 
minimalistic form.

> Will foo-bar/baz:3* or foo-bar/baz:3.* work?

SLOT is currently an arbitrary string (without spaces) so general matching of 
"*" might be useful. Of course, there's no restriction of not using "*" in 
SLOTs at the moment either...

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] X.Org 7.0 Release

[John Myers]

On Friday 23 December 2005 16:29, Donnie Berkholz wrote:
> I've been meaning to get it into guidexml and make it a real project doc
> for a while now (and the accompanying porting guide), but haven't had
> time. Anybody who wants to help out by doing this is quite welcome to do
> so.
>
Here's one I smashed together just now:
-- 
# 
# electronerd, the electronerdian from electronerdia
#





Migrating to Modular X HOWTO


  Donnie Berkholz


Joshua Baergen



This guide shows you how to migrate to modular X.Org






?
?


Migrating to Modular X


Introduction



To keep old packages from getting in the way, we're going to clean out all the
old xorg-x11 cruft before installing modular X. This isn't absolutely crucial,
but it will help ensure a smooth migration.





First step: clean out your old X



Before you start, make sure you have a package of the old, monolithic xorg-x11
built with USE=dlloader if the dlloader flag was available in that
version. It's not available in >=6.8.99.15.



# emerge gentoolkit
# quickpkg xorg-x11



Get rid of the monolithic installation:



# emerge -Ca xorg-x11
# rm -rf /usr/lib/opengl/xorg-x11
# rm -rf /usr/lib/libGL*



You definitely want a backup copy of the monolithic xorg-x11 so you can mix and
match parts if desired.



The later steps are helpful in getting rid of symlinks created by 
opengl-update.



If your /usr/X11R6 isn't a symlink to /usr, delete it
and start from scratch. But first, save a list of all the packages installing
there.



# if [[ ! -L /usr/X11R6 ]]; \
	then equery belongs /usr/X11R6 > usr-x11r6-packages \
	&& rm -rf /usr/X11R6; fi






Second step: Installing modular X



First, add the required packages to /etc/portage/package.unmask.
Open /usr/portage/profiles/package.mask in your text editor of
choice, then copy and paste the full modular X mask over to
package.unmask. Do the same with package.keywords if
you're running stable.



For direct rendering, you'll want to activate the dri USE flag.



Now, install the metabuild.  This will install the server and popular
applications, giving you a working desktop implementation of X:



# emerge xorg-x11



Note that this install tries to be rather minimal, so things like xcursor-themes
are not installed by default.



Next, install some drivers. This will vary depending on your input and video
hardware, so take a look in /usr/portage/x11-drivers/. Here's a
sample:



# emerge xf86-input-mouse xf86-input-keyboard xf86-video-ati



With modular installed, external drivers such as nvidia-glx and wacom as well as
some vnc apps may not work if they install things to
/usr/lib/modules instead of /usr/lib/xorg/modules.
Many of these will have modular X detection added to the installation process
and thus will need to be re-merged after modular X install.






Caveats/Common Problems

'emerge -u world' wants to install xorg-x11



This is because the tree isn't fixed for modular dependencies yet. You can help
the porting effort by reading
http://dev.gentoo.org/~spyderous/xorg-x11/porting_to_modular_x_howto.txt
and filing bugs with patches to the individual package maintainers. The 
maintainers will be listed in metadata.xml in the same directory as the package,
and the 'herdstat' package will speed up querying for them.






Driver problems



I've had reports that:



  ati won't start X

  But it works fine on my FireGL 8800
  
Resolved by moving /usr/lib/xorg/modules/multimedia out of
the way
  

  
  vesa locks up box with an mga card
  vga produces a very weird-looking screen, divided into quarters




Getting glxinfo/glxgears



The best way to deal with this is undecided by upstream so far, so there's an
ebuild in my overlay contributed by cardoe. Alternately, you can build them by
hand.



Option 1: 
http://dev.gentoo.org/~spyderous/overlay/x11-misc/glx-utils/



I'm not going to tell you how to use an overlay, so if you don't know and are
too lazy to read the docs, use option 2.



Option 2: Build by hand



# emerge freeglut
# tar zxvf /usr/portage/distfiles/Mesa-6.3.1.1.tar.gz
# cd Mesa-6.3.1.1/configs
# ln -s linux-dri-x86 current
# cd ../progs/xdemos
# make glxinfo
# make glxgears
# cp glxinfo glxgears /usr/bin/



To get some debugging info from glxinfo to help in getting direct rendering
working:



# LIBGL_DEBUG=verbose glxinfo




Mouse protocol autodetection



If you have Protocol "auto" set in xorg.conf for your mouse, it may not
work. You may need to specify Protocol "ExplorerPS/2" or "IMPS/2"
for your wheel to work.





Where are imake/xmkmf?



These are now in the tree. However, gccmakedep is not modularized yet
and thus the imake build system is still broken for some packages.




Everything in /usr/lib/xorg disappeared!



Remerge >=xorg-server-0.99.1-r4. This was a temporary bug in the ebuild that 
resulted in deletion after removal of a package. Instead, 
/usr/lib/xorg should have only been deleted when no xorg-server
rema

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

On Saturday 24 December 2005 05:45, Spider (DmD Lj) wrote:
> On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
> > On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> > > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> > > >
> > > > | Do those already work then? I'd like to be able to use them.
> > > >
> > > > Not in anything end users should be using. The syntax is pretty much
> > > > decided upon though...
> > >
> > > Glad that they are comming though. Even though I'd probably not hold my
> > > breath.
> >
> > Trolling?
>
> Erm..  No, I don't think he is. We've been asking / waiting for the
> [use] syntax to appear since before you joined the project. It's been on
> "the list" for so long that many of us have given up... ; )

Yep, bug 2272.

> I don't think its trolling when we've been let down on it in the past,
> had it postponed to "the great redesign"  ( project baghira,  I think,
> too)   And so on.

"Even though I'd probably not hold my breath"? It's something that many people 
want but most are not evening willing to attempt implementing it. What was 
the purpose of that comment?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Optimizing performance

[John Myers]

On Friday 23 December 2005 15:52, Diego 'Flameeyes' Pettenò wrote:
> On Friday 23 December 2005 18:35, Paul de Vrieze wrote:
> > Just to add. This is not so much related to debugging information in the
> > library files (what gdb can use). That information never makes it from
> > disk so is not that much of a speed issue (esp. if it is split out).
>
> Actually, if the binaries are not stripped, they consume more memory.
> With splitdebug the issue is unseen (I'm happily using it with -g3 for
> everything now..)
But, as pauldv said, you still shouldn't USE=debug if you want speed
-- 
# 
# electronerd, the electronerdian from electronerdia
#


pgp8Ow4AgbSnM.pgp
Description: PGP signature

Re: [gentoo-dev] [RFC] iconv and libintl virtuals

[Diego 'Flameeyes' Pettenò]

On Sunday 11 December 2005 18:02, Diego 'Flameeyes' Pettenò wrote:
> Okay now that virtual/x11 introduced the new generation's virtuals, the
> decision of waiting to have virtuals for iconv and libintl can be
> considered concluded, and we might start adding them, right? :D

I'm still waiting for other answers to this, a part Spider's consideration 
about libiconv (that shown no problems yet, I'll anyway see to mask it on 
default-linux profile and other glibc-based profiles).

If people has no complaints with this, next week I would start adding the 
packages and fixing the ebuilds to use the right deps.

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpAHf4hYIuJ5.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

On Fri, 23 Dec 2005 17:04:32 -0800 Brian Harring <[EMAIL PROTECTED]>
wrote:
| kde-libs/kde:3
| ^^^ need any kde, with slotting enabled.
| 
| kde-libs/kde:3,4
| ^^^ need any kde, slotting 3 or 4.

Will foo-bar/baz:3* or foo-bar/baz:3.* work?

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Brian Harring]

On Fri, Dec 23, 2005 at 10:30:09PM +0100, Carsten Lohrke wrote:
> On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote:
> > Erm..  No, I don't think he is. We've been asking / waiting for the
> > [use] syntax to appear since before you joined the project. It's been on
> > "the list" for so long that many of us have given up... ; )
> 
> He - and I thought I just missed the thread between all those emails in my 
> inbox. I'm interested as well to hear a bit about the proposed enhanced 
> dependency syntax.

dev-lang/python[tcltk]
^^^ need that atom resolved with use flag tcltk enabled

>=sys-apps/portage-2.0[sandbox,!build]
^^^ need >=portage-2.0 merged with sandbox on, build off.

kde-libs/kde:3
^^^ need any kde, with slotting enabled.

kde-libs/kde:3,4
^^^ need any kde, slotting 3 or 4.

Combination?  Not set in stone afaik, the implementation I have 
sitting in saviour doesn't care about the ordering however.


> > (finally we can kill use_with !! )
> 
> Why? There're not only autotooled configure scripts, so I don't see how to 
> replace it in a generic way. I don't see what this would have to do with 
> depending on ( ebuild foo without use flag bar ), either.

assume he meant built_with_use

~harring


pgpvWuwLg77mB.pgp
Description: PGP signature

Re: [gentoo-dev] X.Org 7.0 Release

[Donnie Berkholz]

Joshua Baergen wrote:
As many of you no doubt have noticed, spyderous and I finished bumping 
the modular packages to the newly released 7.0, which includes many 
changes and bug fixes since 6.8.2.  Over the next few weeks we'll be 
finalizing licenses and other necessities.  To whoever has been using 
modular for awhile: please let us know of any issues you currently have, 
or had during upgrading.


What's this mean for everybody who maintains X-using applications? Well, 
7.0 will probably come out of package.mask in a month at most, so that's 
how long you have to either get your apps ported or suffer with them 
being broken on ~arch systems.


That's the stick end of this; I provided the carrot a while back and 
didn't get many takers.


Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] X.Org 7.0 Release

[Donnie Berkholz]

Greg KH wrote:

For those of us who want to try modular now, where's the pointer to how
to do this (I can't seem to find it in the archives, sorry...)


I've been meaning to get it into guidexml and make it a real project doc 
for a while now (and the accompanying porting guide), but haven't had 
time. Anybody who wants to help out by doing this is quite welcome to do so.


I'm taking off for a week, so Josh will be taking care of your X.

Thanks,
Donnie
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stepping aside...

[Dale]

Roy Marples wrote:


On Friday 23 December 2005 20:17, Paul de Vrieze wrote:
 


On Friday 23 December 2005 16:44, Sven Vermeulen wrote:
   


It is with deep regret that I want to inform you about my decision to
step down from the position of Gentoo Documentation lead.
 


May I with this email thank you for the marvelous job you inspired the docs
team to during your leadership. And of course the hope to see more
contributions from you.
   



I'd like to echo that - the documentation available at the time was one of my 
attractions to Gentoo as it was good :)


Glad to see you aren't leaving us though!

Roy
 

Ditto, big time.  Docs are great with Gentoo. 


Dale
:-)

--
To err is human, I'm most certainly human.

I have four rigs:

1:  Home built; Abit NF7 ver 2.0 w/ AMD 2500+ CPU, 1GB of ram and right now two 
80GB hard drives.
2:  Home built; Iwill KK266-R w/ AMD 1GHz CPU, 256MBs of ram and a 4GB drive.
3:  Home built; Gigabyte GA-71XE4 w/ 800MHz CPU, 128MBs of ram and a 2.5GB 
drive.
4:  Compaq Proliant 6000 Server w/ Quad 200MHz CPUs, 128MBs of ram and a 4.3GB 
SCSI drive.

All run Gentoo Linux, all run folding. #1 is my desktop, 2, 3, and 4 are set up as servers.  


--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Optimizing performance

[Diego 'Flameeyes' Pettenò]

On Friday 23 December 2005 18:35, Paul de Vrieze wrote:
> Just to add. This is not so much related to debugging information in the
> library files (what gdb can use). That information never makes it from disk
> so is not that much of a speed issue (esp. if it is split out).
Actually, if the binaries are not stripped, they consume more memory.
With splitdebug the issue is unseen (I'm happily using it with -g3 for 
everything now..)

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgp9kmRUvN7r7.pgp
Description: PGP signature

Re: [gentoo-dev] X.Org 7.0 Release

[Diego 'Flameeyes' Pettenò]

On Friday 23 December 2005 23:50, Greg KH wrote:
> For those of us who want to try modular now, where's the pointer to how
> to do this (I can't seem to find it in the archives, sorry...)
google for <> :)

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpH9bqK3ieCW.pgp
Description: PGP signature

Re: [gentoo-dev] X.Org 7.0 Release

[Dan Meltzer]

http://dev.gentoo.org/~spyderous/xorg-x11/migrating_to_modular_x_howto.txt

followed it this morning :)
On 12/23/05, Greg KH <[EMAIL PROTECTED]> wrote:
> On Fri, Dec 23, 2005 at 03:40:57PM -0700, Joshua Baergen wrote:
> > As many of you no doubt have noticed, spyderous and I finished bumping
> > the modular packages to the newly released 7.0, which includes many
> > changes and bug fixes since 6.8.2.  Over the next few weeks we'll be
> > finalizing licenses and other necessities.  To whoever has been using
> > modular for awhile: please let us know of any issues you currently have,
> > or had during upgrading.
>
> For those of us who want to try modular now, where's the pointer to how
> to do this (I can't seem to find it in the archives, sorry...)
>
> thanks,
>
> greg k-h
> --
> gentoo-dev@gentoo.org mailing list
>
>

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stepping aside...

[Michiel de Bruijne]

On Friday 23 December 2005 16:44, Sven Vermeulen wrote:
> Hi all
>
> It is with deep regret that I want to inform you about my decision to step
> down from the position of Gentoo Documentation lead.

I just want to say thank you very much for the outstanding work you (and the 
rest of the GDP-team) have done. I think that the quality and quantity of the 
things done by the GDP-team is something that a lot of projects can only 
dream about. (open en closed source software)

Bedankt!

> I will remain a member of the Gentoo Documentation Project, hacking away at
> guides such as that bootstrapping one and the Gentoo Handbook, but I hand
> the coördination over to Xavier Neys who was virtually leading the GDP
> anyway and does seem to find a good balance between real-life and
> Gentoo-life :)

I wish Xavier good luck and a lot of fun with the (formalization of) new role 
within the GDP.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] X.Org 7.0 Release

[Greg KH]

On Fri, Dec 23, 2005 at 03:40:57PM -0700, Joshua Baergen wrote:
> As many of you no doubt have noticed, spyderous and I finished bumping 
> the modular packages to the newly released 7.0, which includes many 
> changes and bug fixes since 6.8.2.  Over the next few weeks we'll be 
> finalizing licenses and other necessities.  To whoever has been using 
> modular for awhile: please let us know of any issues you currently have, 
> or had during upgrading.

For those of us who want to try modular now, where's the pointer to how
to do this (I can't seem to find it in the archives, sorry...)

thanks,

greg k-h
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] X.Org 7.0 Release

[Joshua Baergen]

As many of you no doubt have noticed, spyderous and I finished bumping 
the modular packages to the newly released 7.0, which includes many 
changes and bug fixes since 6.8.2.  Over the next few weeks we'll be 
finalizing licenses and other necessities.  To whoever has been using 
modular for awhile: please let us know of any issues you currently have, 
or had during upgrading.


A couple people have also asked if 6.9 will be added to the tree.  There 
are currently no plans for this, and so 6.8.2-r4/6 (depending on 
platform) will be the last monolithic version barring any major security 
issues.  I've already noted in a bug that bumping to 6.9 will not be as 
easy as just changing the package version, and we see no reason to 
provide it if 7.0 will be here anyway and upstream will not release any 
further monolithic versions.


Merry Christmas,
Joshua Baergen
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's

[Ciaran McCreesh]

On Fri, 23 Dec 2005 20:33:13 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| - Checkout time of a full new tree (no load, and with load)

Do we really care about this? SVN will do really really badly here, but
does it matter?

| - Concurrency performance (how do multiple simultaneous commits and
| updates perform)

With this one, you've got to bear in mind that SVN will correctly
handle transaction commits, whereas CVS will quite happily let you crap
all over half of someone else's transaction.

Performance comparisons are only one part of it...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Carsten Lohrke]

On Friday 23 December 2005 21:45, Spider (DmD Lj) wrote:
> Erm..  No, I don't think he is. We've been asking / waiting for the
> [use] syntax to appear since before you joined the project. It's been on
> "the list" for so long that many of us have given up... ; )

He - and I thought I just missed the thread between all those emails in my 
inbox. I'm interested as well to hear a bit about the proposed enhanced 
dependency syntax.

> (finally we can kill use_with !! )

Why? There're not only autotooled configure scripts, so I don't see how to 
replace it in a generic way. I don't see what this would have to do with 
depending on ( ebuild foo without use flag bar ), either.


Carsten





pgpivOsQ6nOV0.pgp
Description: PGP signature

[gentoo-dev] Re: Re: pkg_{pre,post}inst misusage

[Duncan]

Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted
below,  on Sat, 24 Dec 2005 04:06:05 +0900:

>> You are /sure/ the new code won't screw anything of that sort up, right?
>> Maybe that's the reason nobody seems to have been around to know about.
>> It just sounds like it /could/ be dangerous to me.  For some reason, I
>> don't like the idea of something that could hose a system that badly!  =8^\
> 
> *Please* don't tell me you run ~arch.

Well, I do, plus some stuff from package.mask like gcc-4.x and the
associated binutils and glibc stuff.

OTOH, I have long run a working and a backup snapshot version of the
system portions of my system (everything that packages normally touch),
for this very reason -- I'm running unstable, so I should be prepared to
boot to the backup if the main system gets hosed, either by my
fat-fingering or that of someone else.

Still, the last glibc upgrade was more "exciting" than I had anticipated,
even if DO say if I wanted boring and reliable, I'd be doing household
appliances, not computers.   (I'm proud to say I handled it without
having to resort to a reboot or the backups, tho... if only because I
happened to have an mc instance running  in another vt at the time, and I
was able to use it to restore enough symlinks manually, to read the
documentation, figure out what happened, and restore the others by copying
them out of the binpkg.)

-- 
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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] New Developer: Peter Volkov

[sanchan]

Mike Doty wrote:

Please take a moment to welcome our newest developer, pva.  Peter is
joining to help out with netmon.


Welcome Peter!
--
Sandro (Sanchan) - Gentoo Developer

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Stepping aside...

[Roy Marples]

On Friday 23 December 2005 20:17, Paul de Vrieze wrote:
> On Friday 23 December 2005 16:44, Sven Vermeulen wrote:
> > It is with deep regret that I want to inform you about my decision to
> > step down from the position of Gentoo Documentation lead.
>
> May I with this email thank you for the marvelous job you inspired the docs
> team to during your leadership. And of course the hope to see more
> contributions from you.

I'd like to echo that - the documentation available at the time was one of my 
attractions to Gentoo as it was good :)

Glad to see you aren't leaving us though!

Roy
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Diego 'Flameeyes' Pettenò]

On Friday 23 December 2005 18:41, Peter wrote:
> We would like your help in evaluating, testing, and
> commenting on this approach. Please locate the latest
> nvidia ebuild at:
I thought that we (gentoo devs) were trying to split the modules from ebuilds, 
so that people don't need to waste time with userland when rebuilding modules 
after kernel update.

Also, I'd really like to have nvidia-glx split from nvidia-kernel because of 
fbsd support, adding all on one ebuild would make it difficult to handle the 
fbsd case...

-- 
Diego "Flameeyes" Pettenò - http://dev.gentoo.org/~flameeyes/
Gentoo/ALT lead, Gentoo/FreeBSD, Video, AMD64, Sound, PAM, KDE


pgpdX142l70xE.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Spider (DmD Lj)]

On Sat, 2005-12-24 at 03:37 +0900, Jason Stubbs wrote:
> On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> > On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> > > | Do those already work then? I'd like to be able to use them.
> > >
> > > Not in anything end users should be using. The syntax is pretty much
> > > decided upon though...
> >
> > Glad that they are comming though. Even though I'd probably not hold my
> > breath.
> 
> Trolling?


Erm..  No, I don't think he is. We've been asking / waiting for the
[use] syntax to appear since before you joined the project. It's been on
"the list" for so long that many of us have given up... ; ) 

I don't think its trolling when we've been let down on it in the past,
had it postponed to "the great redesign"  ( project baghira,  I think,
too)   And so on.


Suffice to say, we're still waiting, but more content to hack around and
break the build process theese days.

(finally we can kill use_with !! ) 


//Spider


> --
> Jason Stubbs
-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end



signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Fri, 23 Dec 2005 20:13:45 +, Stuart Herbert wrote:

> Hi Peter,
> 
> On Fri, 2005-12-23 at 14:05 -0500, Peter wrote:
>> in any case. By unifying the ebuilds, we are merely duplicating what
>> nvidia provides in its install packages. We're not doing anything they
>> aren't.
> 
> Who is "we" please?  
augustus, spyderous, azarah, me and testers.

> As you're a non-dev, it would be polite to
> introduce yourself at the top of emails like this for the benefit of
> those who don't want to wade through that bug.  You probably didn't
> intend it this way, but your lack of introduction has distracted from
> the work you're trying to do here.

I was just doing as I was asked. Post an invitation for testing and
comments. I did not think I had to do anything more other than document
what this project is about. As for my lack of etiquette, I apologize.

I'm peter, a user. I contribute ebuilds. Rox primarily, avfs, nvidia,
libtrash, fuse, python-alsa plus I've commented on many more
(enlightenment, eterm, etc,). I also rewrote the rox.eclass. In
addition, I have made small contributions to several OS projects over the
last seven years. I enjoy participating.

This particular project _was_ my idea. I posted the bug with a first stab at
the unified ebuild. augustus took it up and is now in charge. I truly felt
there were two problems that this corrected. 

1) the existing ebuild code was a bit messy and outdated. Unifying the
ebuilds forced a cleanup long overdue
2) the concept of splitting a product seemed overly complex and
unnecessary.

The whole purpose of opening a bug on it was to have the concept reviewed,
improved, or disregarded.

I did _not_ do this project in order to defend it or try and justify it.
If it fills a need, then it will be ported. If not, it won't. But just
because something has always been done a certain way does not mean that
it is the right way or it can't change. The ati drivers come as one
package so why can't nvidia. The "extra" package ati has are far larger
and far more complex than the TWO nvidia extra programs. The idea of
having an nvidia kernel ebuild and a separate nvidia glx ebuild is not
logical. glx depends on kernel, but not the other way around? Good luck
running a glx app withing it! nvidia-settings and xconfig are so small
they are insignificant in terms of compile time. 1' 10".

And, consider from the user's pov. Wouldn't it be simpler and easier to
say "emerge nvidia-drivers" and be done with it?

So, that's it. Sorry for the non-intro, but I wasn't asked to do that.


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's

[Spider (DmD Lj)]

On Fri, 2005-12-23 at 20:34 +0100, Paul de Vrieze wrote:
> On Thursday 22 December 2005 08:13, Bret Towe wrote:
> > On 12/21/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> > > Donnie Berkholz wrote:
> > > > I know some of you have done research on how gentoo-x86 converts over
> > > > to other systems besides CVS such as SVN, arch, etc. But I can't find
> > > > the info anywhere in my archives.
> > > >
> > > > Could whoever's got it, post it?
> > > >
> > > > I'm particularly interested in hearing about CVS, SVN, mercurial,
> > > > bazaar, darcs.
> > >
> > > I've downloaded a copy of the gentoo-x86 repo and will run tests myself.
> > > Please advise me as to exactly which tests you would like to see, beyond
> > > whatever I feel like doing.
> >
> 
> Also look at usability of the system. From my perspective, arch/tla is not 
> that easy to use. Cvs and subversion are better. 

Add to this that tla is constantly misreporting and has a tendency to
mess up repositories.

For example, " I screwed up, rm file, checkout"  doesn't work with
arch...  You get a friendly "your repository is pristine"  . 

Right.


After screwing around with tla and tlx, their hideously annoying tag and
branch names (sheesh) their overabundance of {}  and the braindeadness
of being unable to verify that my tree is really exactly the same as any
other person is seeing,   I cannot speak strongly enough against this.

Git, seems useful, but a bit hard to track ( I really dislike having to
fibble around with long random characterstrings just to check out a
certain version. I can deal, but still)

Mercurial,  last I checked, was still rather fragile. Fast, decent, but
fragile. :(

svn I haven't tried, actually. Although in current terms, it seems to be
a good replacement from how we work and what we do with things.

//Spider

-- 
begin  .signature
Tortured users / Laughing in pain
See Microsoft KB Article Q265230 for more information.
end



signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Stepping aside...

[Paul de Vrieze]

On Friday 23 December 2005 16:44, Sven Vermeulen wrote:
> It is with deep regret that I want to inform you about my decision to step
> down from the position of Gentoo Documentation lead.

May I with this email thank you for the marvelous job you inspired the docs 
team to during your leadership. And of course the hope to see more 
contributions from you.

Bedankt,

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp8nwW0GF6ua.pgp
Description: PGP signature

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Stephen P. Becker]

Sigh...The point was to take 3, potentially 4, ebuilds and make 1.


Well, nvidia-xconfig should probably be part of hte nvidia-settings 
ebuild, but I really don't think the drivers and kernel module should be 
included.  Why not create a meta-ebuild which pulls all of these ebuilds 
in, so that it is easy to install everything, yet you don't break the 
ability to re-install the kernel module everytime somebody compiled a 
new kernel.




BTW, please post these comments to the bug report.


Bug reports are not a forum for discussion.



We hope you will find this approach a more streamlined and easy
implementation for nVidia.


I don't particularly see how it is easier.



But many do. This mirrors the approach nvidia takes.


Why should we care what approach nvidia takes?  I'm looking for reasons 
here.




No, nVidia devs are Kris and the x11-driver group.
BTW, I don't want to get into a multi-threaded debate about the
merits or drawbacks to this in this forum. Bug reports or comments are
encouraged since that way everyone involved will see it. I was just asked
to post the invite.


See my comment above.  Mailing lists are for discussion, and bugzilla is 
for fixing bugs.


-Steve

--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Stuart Herbert]

Hi Peter,

On Fri, 2005-12-23 at 14:05 -0500, Peter wrote:
> in any case. By unifying the ebuilds, we are merely duplicating what
> nvidia provides in its install packages. We're not doing anything they
> aren't.

Who is "we" please?  As you're a non-dev, it would be polite to
introduce yourself at the top of emails like this for the benefit of
those who don't want to wade through that bug.  You probably didn't
intend it this way, but your lack of introduction has distracted from
the work you're trying to do here.

Best regards,
Stu
-- 
Stuart Herbert [EMAIL PROTECTED]
Gentoo Developer  http://www.gentoo.org/
  http://stu.gnqs.org/diary/

GnuGP key id# F9AFC57C available from http://pgp.mit.edu
Key fingerprint = 31FB 50D4 1F88 E227 F319  C549 0C2F 80BA F9AF C57C
--


signature.asc
Description: This is a digitally signed message part

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Fri, 23 Dec 2005 14:43:59 -0500, Stephen P. Becker wrote:

> Since nobody else has asked, I will.  What is the point?  What problem 
> are you trying to solve with this ebuild?  As far as I can tell, there 
> is no point, other than trying to sound like you are doing something 
> important.

Sigh...The point was to take 3, potentially 4, ebuilds and make 1. As for
trying to sound anything, that is not true. Why not bring that up with
Kris who has taken up this project.

> 
> I can tell you that I would be disappointed if this replaces the current 
> ebuilds, because I really don't need to reinstall nvidia-settings and 
> nvidia-glx every time I build a new kernel.
> 

That's why we are having this dialog. When I proposed doing a unified
ebuild, the objective always was to get and encourage feedback. If you are
happy keeping up with three ebuilds, then that is feedback we need to
have. BTW, please post these comments to the bug report.

> 
>> We hope you will find this approach a more streamlined and easy
>> implementation for nVidia.
> 
> I don't particularly see how it is easier.

But many do. This mirrors the approach nvidia takes.

> 
> 
>> Thanks for your participation and feedback.
>> 
>> Peter Hyman on behalf of the nVidia devs.
> 
> The nVidia devs?  Is upstream pushing this?  Why?  What is the point?

No, nVidia devs are Kris and the x11-driver group.
> 
> -Steve

BTW, I don't want to get into a multi-threaded debate about the
merits or drawbacks to this in this forum. Bug reports or comments are
encouraged since that way everyone involved will see it. I was just asked
to post the invite.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Stephen P. Becker]

Since nobody else has asked, I will.  What is the point?  What problem 
are you trying to solve with this ebuild?  As far as I can tell, there 
is no point, other than trying to sound like you are doing something 
important.


I can tell you that I would be disappointed if this replaces the current 
ebuilds, because I really don't need to reinstall nvidia-settings and 
nvidia-glx every time I build a new kernel.




We hope you will find this approach a more streamlined and
easy implementation for nVidia.


I don't particularly see how it is easier.



Thanks for your participation and feedback.

Peter Hyman on behalf of the nVidia devs.


The nVidia devs?  Is upstream pushing this?  Why?  What is the point?

-Steve
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's

[Paul de Vrieze]

On Thursday 22 December 2005 08:13, Bret Towe wrote:
> On 12/21/05, Donnie Berkholz <[EMAIL PROTECTED]> wrote:
> > Donnie Berkholz wrote:
> > > I know some of you have done research on how gentoo-x86 converts over
> > > to other systems besides CVS such as SVN, arch, etc. But I can't find
> > > the info anywhere in my archives.
> > >
> > > Could whoever's got it, post it?
> > >
> > > I'm particularly interested in hearing about CVS, SVN, mercurial,
> > > bazaar, darcs.
> >
> > I've downloaded a copy of the gentoo-x86 repo and will run tests myself.
> > Please advise me as to exactly which tests you would like to see, beyond
> > whatever I feel like doing.
>
> might i also suggest testing out git along with the above listed?
> since i dont know git well enuf or what exactly are requirements of
> a gentoo dev ill just point to some documents
> tutorial can be found here:
> http://www.kernel.org/pub/software/scm/git/docs/tutorial.html
> and documention here:
> http://www.kernel.org/pub/software/scm/git/docs/

Also look at usability of the system. From my perspective, arch/tla is not 
that easy to use. Cvs and subversion are better. 

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp5N24IttxBu.pgp
Description: PGP signature

Re: [gentoo-dev] Viability of other SCM/version control systems for big repo's

[Paul de Vrieze]

On Tuesday 20 December 2005 04:07, Chandler Carruth wrote:
> Ciaran McCreesh wrote:
> >On Tue, 20 Dec 2005 09:17:56 +0900 Kalin KOZHUHAROV
> >
> ><[EMAIL PROTECTED]> wrote:
> > | As far as speed is concerned, it is comparable with CVS.
> >
> >Be more specific please. We're looking for benchmarks showing how well
> >it performs in terms of speed, bandwidth and memory usage for actions
> >such as commit and update on a repository with 100k+ small files.
>
> I have hardware on which I would be more than willing to perform this
> type of benchmark. Can you provide/point to a repository of files to
> benchmark, and a set of operations to perform? The obvious being the
> portage tree itself, with some/all of its history (however much is
> necessary for the benchmarks to be meaningful), but would require a set
> of activities to generate a relevant benchmark.
>
> For reference, I have a server that is not yet in production, but
> readying for production in the next few months, running Gentoo, on a
> raid-5 array of SCSI harddrives. I don't remember the precise
> specifications off hand, but I could provide them along with the results.
>
> Would this be useful? Would more/other hardware be necessary useful? (I
> have access to multiple workstations on which I could run simultaneous
> tests, causing transactions to become relevant and important, etc etc,
> and further hardware might be available here.) Hope this can be of some
> use to you in trying to make this evaluation.

In this respect we want to know things like:

- Checkout time of a full new tree (no load, and with load)

- Update time (without load, and with load)

- Concurrency performance (how do multiple simultaneous commits and updates
  perform)

- Is there a difference between checking out and committing parts of the tree
  instead of the full tree.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpBp1EOexMeB.pgp
Description: PGP signature

[gentoo-dev] Stepping aside...

[Sven Vermeulen]

Hi all

It is with deep regret that I want to inform you about my decision to step
down from the position of Gentoo Documentation lead. 

Over the years, the Gentoo Documentation Project has grown, evolved and
matured to what it is today: a well functioning documentation-machine
devoted to the ongoing development and maintenance of Gentoo's
documentation. Many resources are referring to our documentation to show
others how things should be done.

Such appreciation isn't due to a single individual, but because of an entire
team of coördinators, editors, authors, translators and contributors. In my
time as translator (first), editor (second) and lead (until present) I have
always appreciated the friendlyness and helpfulness of this entire
community.

In my position as documentation lead, I tried to keep the project on track,
managing subprojects where possible and help shed some light on obscure or
difficult problems that arose during the documentation development (no,
"editing" isn't all that the GDP does). I hope that I did this well, at
least I have not heard differently.

However, leading a project also requires high availability; e-mails should
be followed-up quickly, conversations with team members must happen (even if
not scheduled), hotfixes must be committed as soon as possible, etc. When I
was a student, free time wasn't scarce (I didn't follow that much lectures -
yes, "bad, bad me") so I could devote much time to Gentoo.

Lately, because my work now doesn't leave me much time (not that the work is
extremely demanding, but it's 2.5h away from home and I don't have Internet
access on the train), I found myself in a position where I wasn't able to
talk to my fellow GDP (and other Gentoo) developers or contribute to the
interesting topics in #gentoo or other Gentoo related chat channels.

This situation won't improve much in the first few months, or perhaps even
year, until I settle somewhere more closely to my job. For this reason, I
have decided not to take on the lead position anymore.

I will remain a member of the Gentoo Documentation Project, hacking away at
guides such as that bootstrapping one and the Gentoo Handbook, but I hand
the coördination over to Xavier Neys who was virtually leading the GDP
anyway and does seem to find a good balance between real-life and
Gentoo-life :)

For those who wonder, this shouldn't affect any other responsibilities I
have within Gentoo, including Foundation and Council, as most of that work
happens off-line anyway or at scheduled IRC meetings. However, I can imagine
that some developers voted for me for my position rather than my person. If
there is a (large) demand for it, I have no problems in attempting to get
re-elected for those positions (or stepping down if I am not).

With kind regards (yes, that's what "Wkr" stands for),

Sven Vermeulen

-- 
  Gentoo Foundation Trustee  |  http://foundation.gentoo.org
  Gentoo Council Member  

  The Gentoo Project   <<< http://www.gentoo.org >>>


pgp3v9YCZaln9.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Saturday 24 December 2005 03:42, Thomas de Grenier de Latour wrote:
> On Sat, 24 Dec 2005 02:22:06 +0900
>
> Jason Stubbs <[EMAIL PROTECTED]> wrote:
> > PackageA is installed, PackageB is installed, PackageB is
> > uninstalled -> PackageA is broken. Does this case exist?
>
> Found two on my system:
>
>  * "/usr/lib/X11/app-defaults -> /etc/X11/app-defaults" is
> installed by several X11 apps (media-gfx/xfig, x11-misc/seyon,
> x11-misc/xvkbd, and i would not be surprised there are others)

This looks like something that a lower level X ebuild should be installing. 
The problem here is that there's also a bit of funny business going on when 
portage encounters a merge of some filetype being blocked by a different 
filetype. In the above case, if some X11 package installs 
the /usr/lib/X11/app-defaults symlink and all other apps install 
to /etc/X11/app-defaults then everything should be fine.

>  * "/usr/share/cups/model/foomatic-ppds -> /usr/share/ppd" is
> installed by both net-print/foomatic-db and net-print/hplip.

Again, given the name of the symlink, net-print/hplip should probably be 
installing directly to /usr/share/ppd.

> Maybe this particular packages could be hacked to avoid need for
> the symlinks (or the symlinks should be installed only by some
> lower level, depended-on, packages?), but anyway it would be hard
> to do a strict sanity check of the whole tree. And letting that to
> "collision-protect" feature doesn't sound really like a short term
> solution neither. So, basically, i don't see how you could safely
> change this portage behavior atm (although i agree it would be a
> good thing once done).

Yep, it seems that changing the behaviour will lead to some breakage. However 
repoman is definately not capable of handling this sort of stuff. Also, none 
of the breakage (that you've revealed here at least) is that bad. Putting the 
relevant collision-protect changes into ~arch and following up with the 
actual unmerge changes should lead to minimal disruption on the user's side.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] Re: Unified nVidia Driver Ebuild ready for testing

[Peter]

On Fri, 23 Dec 2005 18:47:40 +, Mike Frysinger wrote:

> On Fri, Dec 23, 2005 at 12:41:45PM -0500, Peter wrote:
>> We are in the process of developing and testing
>> a unified nVidia driver ebuild. When implemented,
>> it will replace the nvidia-kernel, nvidia-glx, and 
>> nvidia-settings ebuilds. It will also add the utility
>> nvidia-xconfig.
> 
> issues:
>  - people rebuild nvidia-kernel when they upgrade/change their kernel
>version; rebuilding the other packages in this case is pointless
>  - nvidia-kernel/nvidia-glx may be released in parallel, but 
>the nvidia-settings package is not last i checked (never even heard
>of nvidia-xconfig) ... whats the point in unifying things when they
>arent the same version ... you'll hit the same issue as above, if
>a new version of nvidia-settings is put out, people will have to
>pointlessly rebuild the other nvidia packages
> -mike

All noted. nvidia-settings and -xconfig are included in binary form with
the pkg?.run files. -xconfig is married to a particular version of the
driver. Settings too will change rarely, if at all, without a driver
update.

Total compile time, as noted in the bug report, for me was 1' 10" using an
XP 2500 oc'ed to 2800. The glx modules don't compile at all since they're
not open source. Updating only kernel, and not glx is a dangerous business
in any case. By unifying the ebuilds, we are merely duplicating what
nvidia provides in its install packages. We're not doing anything they
aren't.

FWIW, I have already contacted upstream and suggested _strongly_ that they
include the source for settings and xconfig with the pkg?.run files.

Your feedback is appreciated. Please post to the bug report any additional
comments.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage

[Jason Stubbs]

On Saturday 24 December 2005 03:43, Duncan wrote:
> Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted
>
> below,  on Sat, 24 Dec 2005 02:22:06 +0900:
> > A quick patch makes symlinks handled similarly to regular files and
> > solves the issue. I'll put it into testing unless anybody can come up
> > with a reason not to. The case that will be broken by the patch is when
> > two different packages install the same symlink. PackageA is
> > installed, PackageB is installed, PackageB is uninstalled -> PackageA is
> > broken. Does this case exist?
>
> Yikes!  That's not going to remove /lib or /usr/lib or the like, for us on
> amd64, where that's a symlink to lib64, will it?
>
> equery b /lib
> [ Searching for file(s) /lib in *... ]
> net-analyzer/macchanger-1.5.0-r1 (/lib)
> sys-apps/baselayout-1.12.0_pre12 (/lib)
> sys-boot/grub-0.97 (/lib)
> sys-devel/gcc-4.0.2-r1 (/lib)
> sys-devel/gcc-3.4.4-r1 (/lib)
> sys-fs/device-mapper-1.01.05 (/lib)
> sys-fs/lvm2-2.01.14 (/lib)
> sys-fs/udev-078 (/lib)
> sys-libs/glibc-2.3.6 (/lib)
>
> There's a similar, longer list, for  /usr/lib.  Obviously, not all of
> those will own it as a symlink, but it is one, and if removing one happens
> to remove the symlink...

I'm not familiar with equery so I don't know what this output means. By the 
look of it, it is only a list of packages that own stuff in that directory.

> Also consider the effect where a former dir is now a symlink or a former
> symlink is now a dir.  The recent xorg directory moves come to mind.

With the patch I've done, recorded symlinks will continue to be ignored if the 
target is not a symlink.

> You are /sure/ the new code won't screw anything of that sort up, right?
> Maybe that's the reason nobody seems to have been around to know about.
> It just sounds like it /could/ be dangerous to me.  For some reason, I
> don't like the idea of something that could hose a system that badly!  =8^\

*Please* don't tell me you run ~arch.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: pkg_{pre,post}inst misusage

[Simon Stelling]

Duncan wrote:

It just sounds like it /could/ be dangerous to me.  For some reason, I
don't like the idea of something that could hose a system that badly!  =8^\


It won't hose your system badly, since you've got /usr/lib64 listed in 
/etc/ld.so.conf. I agree it wouldn't be very nice though.


--
Simon Stelling
Gentoo/AMD64 Operational Co-Lead
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Mike Frysinger]

On Fri, Dec 23, 2005 at 12:41:45PM -0500, Peter wrote:
> We are in the process of developing and testing
> a unified nVidia driver ebuild. When implemented,
> it will replace the nvidia-kernel, nvidia-glx, and 
> nvidia-settings ebuilds. It will also add the utility
> nvidia-xconfig.

issues:
 - people rebuild nvidia-kernel when they upgrade/change their kernel
   version; rebuilding the other packages in this case is pointless
 - nvidia-kernel/nvidia-glx may be released in parallel, but 
   the nvidia-settings package is not last i checked (never even heard
   of nvidia-xconfig) ... whats the point in unifying things when they
   arent the same version ... you'll hit the same issue as above, if
   a new version of nvidia-settings is put out, people will have to
   pointlessly rebuild the other nvidia packages
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Harald van Dijk]

On Sat, Dec 24, 2005 at 03:09:47AM +0900, Jason Stubbs wrote:
> On Saturday 24 December 2005 02:52, Harald van Dijk wrote:
> > On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
> > > Symlinks are handled within portage differently to regular files. Regular
> > > files get an mtime check and are removed if it matches. Symlinks don't
> > > get an mtime check (even thought the mtime is stored) and are only
> > > removed if the symlink's target doesn't exist. Hence, it seems to be this
> > > way by design. Why it's this way? Who knows. It's been that way for
> > > longer than anyone can remember which is why _it's so important that bugs
> > > get filed_.
> >
> > Honestly, I thought it was supposed to be like that, since
> > collision-protect also doesn't protect against packages overwriting
> > each other's symlinks (package A and package B can both create
> > /dummy -> bin without any problems from portage).
> 
> As far as portage source goes, it is meant to be like that. But as far as 
> portage source goes, installed package information isn't necessary for dep 
> calculation (including depclean)... Most code has been reviewed and the major 
> issues are known by at least one person, but there is still some code that 
> hasn't suffered a close examination (yet alone reworking) such as the code 
> that the above bug hits.
> 
> > Do you want a bug report for that?
> 
> Yes, please.

Okay, reported as bug #116511.


pgpLSR78dHprn.pgp
Description: PGP signature

[gentoo-dev] Re: pkg_{pre,post}inst misusage

[Duncan]

Jason Stubbs posted <[EMAIL PROTECTED]>, excerpted
below,  on Sat, 24 Dec 2005 02:22:06 +0900:

> A quick patch makes symlinks handled similarly to regular files and
> solves the issue. I'll put it into testing unless anybody can come up
> with a reason not to. The case that will be broken by the patch is when
> two different packages install the same symlink. PackageA is
> installed, PackageB is installed, PackageB is uninstalled -> PackageA is
> broken. Does this case exist?

Yikes!  That's not going to remove /lib or /usr/lib or the like, for us on
amd64, where that's a symlink to lib64, will it?

equery b /lib
[ Searching for file(s) /lib in *... ]
net-analyzer/macchanger-1.5.0-r1 (/lib)
sys-apps/baselayout-1.12.0_pre12 (/lib)
sys-boot/grub-0.97 (/lib)
sys-devel/gcc-4.0.2-r1 (/lib)
sys-devel/gcc-3.4.4-r1 (/lib)
sys-fs/device-mapper-1.01.05 (/lib)
sys-fs/lvm2-2.01.14 (/lib)
sys-fs/udev-078 (/lib)
sys-libs/glibc-2.3.6 (/lib)

There's a similar, longer list, for  /usr/lib.  Obviously, not all of
those will own it as a symlink, but it is one, and if removing one happens
to remove the symlink...

Also consider the effect where a former dir is now a symlink or a former
symlink is now a dir.  The recent xorg directory moves come to mind.

You are /sure/ the new code won't screw anything of that sort up, right?
Maybe that's the reason nobody seems to have been around to know about.
It just sounds like it /could/ be dangerous to me.  For some reason, I
don't like the idea of something that could hose a system that badly!  =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 in
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html


-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] glep 42 (news) round six

[Paul de Vrieze]

On Sunday 18 December 2005 05:15, Ciaran McCreesh wrote:
> You are encouraged to reply to this thread saying "I agree with ciaranm
> that repository IDs should not be allowed to contain spaces".

I agree with ciaranm that repository IDs should not be allowed to contain 
spaces.

Paul

ps. Thanks for the perseverence on this glep. 

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpUJvQ16Kley.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Thomas de Grenier de Latour]

On Sat, 24 Dec 2005 02:22:06 +0900
Jason Stubbs <[EMAIL PROTECTED]> wrote:

> PackageA is installed, PackageB is installed, PackageB is
> uninstalled -> PackageA is broken. Does this case exist?

Found two on my system: 

 * "/usr/lib/X11/app-defaults -> /etc/X11/app-defaults" is
installed by several X11 apps (media-gfx/xfig, x11-misc/seyon,
x11-misc/xvkbd, and i would not be surprised there are others)

 * "/usr/share/cups/model/foomatic-ppds -> /usr/share/ppd" is
installed by both net-print/foomatic-db and net-print/hplip.

Maybe this particular packages could be hacked to avoid need for
the symlinks (or the symlinks should be installed only by some
lower level, depended-on, packages?), but anyway it would be hard
to do a strict sanity check of the whole tree. And letting that to
"collision-protect" feature doesn't sound really like a short term
solution neither. So, basically, i don't see how you could safely
change this portage behavior atm (although i agree it would be a
good thing once done).

--
TGL.
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

On Saturday 24 December 2005 03:23, Paul de Vrieze wrote:
> On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> > On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
> >
> > wrote:
> > | > That was my original thought when I started playing with it. I
> > | > switched to postfix to make it more consistent with the way :slot
> > | > and [use] restrictions work. *shrug* I guess it's down to whether
> > | > you consider a
> > |
> > | Do those already work then? I'd like to be able to use them.
> >
> > Not in anything end users should be using. The syntax is pretty much
> > decided upon though...
>
> Glad that they are comming though. Even though I'd probably not hold my
> breath.

Trolling?

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

On Friday 23 December 2005 19:12, Ciaran McCreesh wrote:
> On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
>
> wrote:
> | > That was my original thought when I started playing with it. I
> | > switched to postfix to make it more consistent with the way :slot
> | > and [use] restrictions work. *shrug* I guess it's down to whether
> | > you consider a
> |
> | Do those already work then? I'd like to be able to use them.
>
> Not in anything end users should be using. The syntax is pretty much
> decided upon though...

Glad that they are comming though. Even though I'd probably not hold my 
breath.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpMr255Sg45r.pgp
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Ciaran McCreesh]

On Fri, 23 Dec 2005 18:57:44 +0100 Paul de Vrieze <[EMAIL PROTECTED]>
wrote:
| > That was my original thought when I started playing with it. I
| > switched to postfix to make it more consistent with the way :slot
| > and [use] restrictions work. *shrug* I guess it's down to whether
| > you consider a
| 
| Do those already work then? I'd like to be able to use them.

Not in anything end users should be using. The syntax is pretty much
decided upon though...

-- 
Ciaran McCreesh : Gentoo Developer (I can kill you with my brain)
Mail: ciaranm at gentoo.org
Web : http://dev.gentoo.org/~ciaranm



signature.asc
Description: PGP signature

Re: [gentoo-dev] Multiple Repo Support

[Jason Stubbs]

On Saturday 24 December 2005 02:57, Paul de Vrieze wrote:
> On Friday 16 December 2005 18:54, Ciaran McCreesh wrote:
> > On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]>
> >
> > wrote:
> > | Just one remark: What about making the syntax a bit more familiar to
> > | C++ users:
> > |
> > | ~  DEPENDS="gentoo-foo::foo-bar/baz-2.1"
> >
> > That was my original thought when I started playing with it. I switched
> > to postfix to make it more consistent with the way :slot and [use]
> > restrictions work. *shrug* I guess it's down to whether you consider a
>
> Do those already work then? I'd like to be able to use them.

:slot and [use]? Not yet. I'm sure that once they do the shouts will be 
resounding across the globe such that it would not be possible for you to be 
unaware of it... ;)

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Saturday 24 December 2005 02:52, Harald van Dijk wrote:
> On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
> > Symlinks are handled within portage differently to regular files. Regular
> > files get an mtime check and are removed if it matches. Symlinks don't
> > get an mtime check (even thought the mtime is stored) and are only
> > removed if the symlink's target doesn't exist. Hence, it seems to be this
> > way by design. Why it's this way? Who knows. It's been that way for
> > longer than anyone can remember which is why _it's so important that bugs
> > get filed_.
>
> Honestly, I thought it was supposed to be like that, since
> collision-protect also doesn't protect against packages overwriting
> each other's symlinks (package A and package B can both create
> /dummy -> bin without any problems from portage).

As far as portage source goes, it is meant to be like that. But as far as 
portage source goes, installed package information isn't necessary for dep 
calculation (including depclean)... Most code has been reviewed and the major 
issues are known by at least one person, but there is still some code that 
hasn't suffered a close examination (yet alone reworking) such as the code 
that the above bug hits.

> Do you want a bug report for that?

Yes, please.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] state of ebooks

[Michael Sterrett -Mr. Bones.-]

I'm not at all pleased with the current state of the ebooks.  I guess
I missed the discussion about it on this list before.  I looked at the
archives and I didn't see any response to vapier's question about *why*
ebookmerge was happening.

I don't want to be forced to use the ebookmerge script.  From briefly
looking at it, there are temp file issues, quoting issues, spelling
issues and, worst of all, it seems like it installs a copy of whatever
ebook in the users' home directories.  That all seems not as good as the
individual-package solution that (afaict) was working fine.

The current situation is that all the ebook ebuilds are masked and
ebookmerge is marked unstable.  That's very annoying for those on
stable-only systems.

Michael Sterrett
  -Mr. Bones.-
[EMAIL PROTECTED]
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Optimizing performance

[Lares Moreau]

On Fri, 2005-12-23 at 09:36 -0800, Donnie Berkholz wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
> 
> Paul de Vrieze wrote:
> | On Thursday 15 December 2005 16:50, Donnie Berkholz wrote:
> |>gentoo-performance  Discussions about improving the performance of 
> Gentoo
> |>
> |>Although it was a bit quiet last time I was subscribed to it.
> |
> |
> | I still am. The last message is from last august. And that was about
> someone
> | wanting to unsubscribe the wrong way. The last proper message was from
> July
> | 4th.
> 
> That clearly means everybody thinks Gentoo's performance is great and
> feels no need to discuss it. =)
It is discussed on gentoo-user. although many times with
less-then-practical solutions

-Lares
-- 
Lares Moreau <[EMAIL PROTECTED]>  | LRU: 400755 http://counter.li.org
lares/irc.freenode.net |
Gentoo x86 Arch Tester |   ::0 Alberta, Canada
Public Key: 0D46BB6E @ subkeys.pgp.net |  Encrypted Mail Preferred
Key fingerprint = 0CA3 E40D F897 7709 3628  C5D4 7D94 483E 0D46 BB6E


signature.asc
Description: This is a digitally signed message part

Re: [gentoo-dev] Multiple Repo Support

[Paul de Vrieze]

On Friday 16 December 2005 18:54, Ciaran McCreesh wrote:
> On Fri, 16 Dec 2005 10:00:02 +0100 Danny van Dyk <[EMAIL PROTECTED]>
>
> wrote:
> | Just one remark: What about making the syntax a bit more familiar to
> | C++ users:
> |
> | ~  DEPENDS="gentoo-foo::foo-bar/baz-2.1"
>
> That was my original thought when I started playing with it. I switched
> to postfix to make it more consistent with the way :slot and [use]
> restrictions work. *shrug* I guess it's down to whether you consider a

Do those already work then? I'd like to be able to use them.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpkSyKnESIpi.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Harald van Dijk]

On Sat, Dec 24, 2005 at 02:22:06AM +0900, Jason Stubbs wrote:
> Symlinks are handled within portage differently to regular files. Regular 
> files get an mtime check and are removed if it matches. Symlinks don't get an 
> mtime check (even thought the mtime is stored) and are only removed if the 
> symlink's target doesn't exist. Hence, it seems to be this way by design. Why 
> it's this way? Who knows. It's been that way for longer than anyone can 
> remember which is why _it's so important that bugs get filed_.

Honestly, I thought it was supposed to be like that, since
collision-protect also doesn't protect against packages overwriting
each other's symlinks (package A and package B can both create
/dummy -> bin without any problems from portage). Do you want a bug
report for that?


pgp31VAhJfrqr.pgp
Description: PGP signature

[gentoo-dev] Unified nVidia Driver Ebuild ready for testing

[Peter]

To Gentoo nVidia users:

We are in the process of developing and testing
a unified nVidia driver ebuild. When implemented,
it will replace the nvidia-kernel, nvidia-glx, and 
nvidia-settings ebuilds. It will also add the utility
nvidia-xconfig.

We would like your help in evaluating, testing, and
commenting on this approach. Please locate the latest
nvidia ebuild at: 

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

The download package for the new ebuild is at:
http://bugs.gentoo.org/attachment.cgi?id=75389

This is the very latest nVidia 8178 driver. Please
be sure and review the nVidia changelog and readme.
If your fonts are abnormally small, see Appendix Y
and the nVidia forums for info on DPI. See

http://www.nvnews.net/vbulletin/forumdisplay.php?s=&forumid=14

for specific news and info about the nVidia drivers
for linux.

Since this is a developmental ebuild, it is NOT currently
in portage. If you would like to try it out, please
follow these simple instructions:

1) Untar the file into /usr/local/portage/x11-drivers
(if your portage overlay is in a different location,
adjust accordingly).

2) exit all window managers

3) unmerge nvidia-kernel, nvidia-glx, and nvidia-settings
(emerge -C .) This ebuild will NOT install if any
other nVidia ebuilds are installed.

4) edit /etc/portage/package.keywords and add

x11-drivers/nvidia-drivers   ~x86 (or ~amd64). 
Other arches are not supported. Sorry.

5) emerge nvidia-drivers.

This will load the kernel module, glx support, nvidia-
settings and -xconfig all in one swoop.

NOTE: Modular X support is not yet implemented.

If you have comments, notice a bug, or if you have 
suggestions for improvement, PLEASE post to the existing
bug report:

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

Please DO NOT report bugs about the upstream driver. If the
driver does not work, then see the nVidia news forum.

We hope you will find this approach a more streamlined and
easy implementation for nVidia.

Thanks for your participation and feedback.

Peter Hyman on behalf of the nVidia devs.



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Optimizing performance

[Donnie Berkholz]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Paul de Vrieze wrote:
| On Thursday 15 December 2005 16:50, Donnie Berkholz wrote:
|>gentoo-performance Discussions about improving the performance of 
Gentoo
|>
|>Although it was a bit quiet last time I was subscribed to it.
|
|
| I still am. The last message is from last august. And that was about
someone
| wanting to unsubscribe the wrong way. The last proper message was from
July
| 4th.

That clearly means everybody thinks Gentoo's performance is great and
feels no need to discuss it. =)

Donnie
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDrDWsXVaO67S1rtsRAt/oAKCBfnZ+RN+rit/SIy8PgMxf8fagIACePVaX
km6UtHuIbO3jqm2r4EVmcJA=
=wIaL
-END PGP SIGNATURE-
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Optimizing performance

[Paul de Vrieze]

On Thursday 15 December 2005 19:38, John Myers wrote:
> On Thursday 15 December 2005 04:48, Patrick Lauer wrote:
> > Hi all,
> >
> > I was wondering if there are any sane ways to optimize the performance
> > of a Gentoo system.
> > Overoptimization (the well known "-O9 -fomgomg" CFLAGS etc.) tends to
> > make things unstable, which is of course not what we want. The "easy"
> > way out would be buying faster hardware, but that is usually not an
> > option ;-)
> >
> > So ... what can be done to get the stable maximum out of your hardware?
>
> This should be obvious, but don't USE=debug globally. Last time I did that,
> it made my Athlon64 3400+ with 1G of RAM feel like the 300MHz PII with 192M
> of RAM I have.

Just to add. This is not so much related to debugging information in the 
library files (what gdb can use). That information never makes it from disk 
so is not that much of a speed issue (esp. if it is split out). It is however 
related to the debug use flag enabling various kinds of debugging checks, 
output and whatnot in software. Those tests are useful for debugging, but in 
the case of tests are normally disabled because of the performance hit they 
carry.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgp7qVfWu615u.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Saturday 24 December 2005 02:11, Zac Medico wrote:
> Harald van Dijk wrote:
> > Don't know if it's been reported as a portage bug, but this would show
> > it:
> >
> > KEYWORDS="~x86"
> > src_install() {
> > dodir /test
> > dosym /usr/bin /test
> > }
> >
> > When unmerging, portage won't remove /test/bin because its target still
> > exists.
>
> That is fixed in portage-2.0.53 (latest stable).
>
> http://bugs.gentoo.org/show_bug.cgi?id=59593

Similar characteristics but slightly different.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Re: Optimizing performance

[Paul de Vrieze]

On Thursday 15 December 2005 16:50, Donnie Berkholz wrote:
> Patrick Lauer wrote:
> | On Thu, 2005-12-15 at 07:43 -0700, Duncan wrote:
> |>This really belongs on user, or perhaps on the appropriate purposed list,
> |>desktop or hardened or whatever, not on devel.  That said, some
> |>comments...  (I can't resist. )
> |
> | -user has the risk of many "use teh -fomglol flag, it si teh fast0r" ;-)
> | hardened doesn't have much to do with performance (although I'd be
> | interested what impact - if any - the different security features have!)
>
> ~From http://www.gentoo.org/main/en/lists.xml --
>
> gentoo-performanceDiscussions about improving the performance of Gentoo
>
> Although it was a bit quiet last time I was subscribed to it.

I still am. The last message is from last august. And that was about someone 
wanting to unsubscribe the wrong way. The last proper message was from July 
4th.

Paul

-- 
Paul de Vrieze
Gentoo Developer
Mail: [EMAIL PROTECTED]
Homepage: http://www.devrieze.net


pgpalGqSzBuEG.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Friday 23 December 2005 22:13, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> > > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > > > Well, you should know that those are because of portage bugs or
> > > > > some portage peculiarity, read the corresponding bugs for example
> > > > > for cups to find out more.
> > > >
> > > > Can you point me to a bug? There's no mention in the ChangeLog that I
> > > > can see nor in the ebuilds themselves...
> > >
> > > Bug #99375 is mentioned in the changelog for samba.
> >
> > Okay. It appears to be something related to symlinks. Can you show me the
> > bug assigned to portage that reports this and/or shows how to reproduce
> > it?
>
> Don't know if it's been reported as a portage bug, but this would show
> it:
>
> KEYWORDS="~x86"
> src_install() {
>   dodir /test
>   dosym /usr/bin /test
> }
>
> When unmerging, portage won't remove /test/bin because its target still
> exists.

Seeing that there's no bug filed for this, discussion can go here; that's no 
existance of a portage bug is of itself no reason to put an ugly workaround 
in the ebuilds themselves mind you.

Symlinks are handled within portage differently to regular files. Regular 
files get an mtime check and are removed if it matches. Symlinks don't get an 
mtime check (even thought the mtime is stored) and are only removed if the 
symlink's target doesn't exist. Hence, it seems to be this way by design. Why 
it's this way? Who knows. It's been that way for longer than anyone can 
remember which is why _it's so important that bugs get filed_.

A quick patch makes symlinks handled similarly to regular files and solves the 
issue. I'll put it into testing unless anybody can come up with a reason not 
to. The case that will be broken by the patch is when two different packages 
install the same symlink.　PackageA is installed, PackageB is installed, 
PackageB is uninstalled -> PackageA is broken. Does this case exist?

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Zac Medico]

Harald van Dijk wrote:


Don't know if it's been reported as a portage bug, but this would show
it:

KEYWORDS="~x86"
src_install() {
dodir /test
dosym /usr/bin /test
}

When unmerging, portage won't remove /test/bin because its target still exists.


That is fixed in portage-2.0.53 (latest stable).

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

Zac
--
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] sanity checking libtool versions & portability

[Mike Frysinger]

On Fri, Dec 23, 2005 at 03:52:37PM +0100, [EMAIL PROTECTED] wrote:
> In other words, it breaks portability. And let this be the one thing people
> expect from using GNU's ubiquitous autotools. Our comments follow:

this has been fixed already, you should update to libtool-1.5.20-r1

> c) follow advice on 
> 

i've already chatted with upstream about the version checking idea and
what we're doing now is the best course for Gentoo
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] checdeps.rb for getting deps out of elf files

[Mike Frysinger]

On Fri, Dec 23, 2005 at 01:09:08PM +0200, Petteri R??ty wrote:
> Basically it does ldd on all
> the elf files in a package and then checks to which packages those
> libraries belong.

ldd is garbage for this purpose

use `readelf -d ELF | grep NEEDED` or just `scanelf -n ELF`
-mike
-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] sanity checking libtool versions & portability

[erik . nolf]

Hello,

We recently switched development platform from RedHat/Fedora to Gentoo.
Great you'd say. However, now our users (most notably on Solaris) complain
that our small utility's "./configure" bails out with the dreadful message:

*** [Gentoo] sanity check failed! ***
*** libtool.m4 and ltmain.sh have a version mismatch! ***
*** (libtool.m4 = 1.5.20, ltmain.sh = ) ***

Please run: ...

When in fact there is no mismatch. It seems Solaris regular "grep" or "sed" do
not handle "[[:space:]]" syntax used in libtool.m4's _LT_VERSION_CHECK macro.

gentoo_ltmain_version=`grep '^[[:space:]]*VERSION=' $ltmain | sed -e...

In other words, it breaks portability. And let this be the one thing people
expect from using GNU's ubiquitous autotools. Our comments follow:

a) wouldn't a '^VERSION=' be sufficient?

(strict but portable, at least we patched our libtool.m4 this way)

b) keep syntax, checks needed for proper grep/sed

(too elaborated)

c) follow advice on 

(func_check_version_match sounds neat, don't know how to use yet ;-)

Thanks for reading. If one considers to implement c) we 'll be eager to help.
After all, we appreciate Gentoo very much.

Greetings,

Erik



-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] Changing description for the xml global use flag

[Mike Frysinger]

On Thu, Dec 22, 2005 at 10:58:03PM +, Stuart Herbert wrote:
> On Mon, 2005-12-19 at 23:48 +0200, Petteri R??ty wrote:
> > /usr/portage/profiles/use.desc:xml - Check/Support flag for XML library
> > (version 1)
> > 
> > I think the xml use flag should be more generic. There are after all
> > other alternatives for xml support than dev-libs/libxml. Maybe something
> > like Adds xml support?
> 
> I can see where you're coming from, but I'm not sure it's worth the
> potential disruption that this will cause our users.  
> 
> Unless I'm missing something, won't every user who has any form of
> USE=xml, USE=-xml, USE=xml2, or USE=-xml2 in make.conf and packages.use
> get a nasty surprise the next time they emerge -u world?
> 
> I haven't seen any discussion taking this into account yet.

i dont really see this being an issue ... i dont think anyone really
has 'xml -xml2' or '-xml xml2' ... much more likely they have 'xml 
xml2' or '-xml -xml2'
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] another global use flag...

[Mike Frysinger]

On Fri, Dec 23, 2005 at 02:03:39PM +, Marcus D. Hanwell wrote:
> That is why I don't quite understand why Mozilla based browsers use the 
> mozsvg 
> use flag when there is already a global svg use flag available and if you 
> enable svg you can pretty much guarantee you will want it in mozilla too. 

maybe a bug ?  'mozsvg' has existed for much longer than 'svg' afaik
-mike
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] another global use flag...

[Marcus D. Hanwell]

On Thursday 22 December 2005 21:52, Carsten Lohrke wrote:
> On Thursday 22 December 2005 20:14, Drake Wyrm wrote:
> > Query: Which would be more appropriate in this case? "jasper" for the
> > library it pulls in as a depend, or "jpeg2k" for the functionality that
> > library provides? There's nothing else in the tree (as far as I can
> > tell) which provides JPEG-2000, but there could be.
>
> It is imho a _problem_ when use flags are _unnecessarily_ named after the
> library instead the provided functionality. When there are two libs doing
> the same thing, a single use flag should suffice: Less use flags mean
> reduced complexity for the user, who likely will understand what "jpeg2k"
> means, but not "jasper". Which leads me to the next issue; Often you can
> read:
>
> foo - enables support for $category/foo
>
> Such a description is as good as none. To give a sample how it should be:
>
> jpeg2k - Support for JPEG 2000, a wavelet-based image compression format.
>
I second this sentiment - global use flags are supposed to be defined broadly 
so as to allow fairly generic easily understood terms. I know straight away 
what jpeg2k, but without looking at a description I have no idea what jasper 
is.

That is why I don't quite understand why Mozilla based browsers use the mozsvg 
use flag when there is already a global svg use flag available and if you 
enable svg you can pretty much guarantee you will want it in mozilla too. 
Users don't need to be bothered with the implementation details, if they want 
jpeg2k or svg support generally they are not going to be too concerned about 
which library provides it.

I also think jpeg2k should become a global use flag in answer to the original 
question :)


pgpIPWRJKUbt1.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Harald van Dijk]

On Fri, Dec 23, 2005 at 10:00:20PM +0900, Jason Stubbs wrote:
> On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> > On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > > Well, you should know that those are because of portage bugs or some
> > > > portage peculiarity, read the corresponding bugs for example for cups
> > > > to find out more.
> > >
> > > Can you point me to a bug? There's no mention in the ChangeLog that I can
> > > see nor in the ebuilds themselves...
> >
> > Bug #99375 is mentioned in the changelog for samba.
> 
> Okay. It appears to be something related to symlinks. Can you show me the bug 
> assigned to portage that reports this and/or shows how to reproduce it?

Don't know if it's been reported as a portage bug, but this would show
it:

KEYWORDS="~x86"
src_install() {
dodir /test
dosym /usr/bin /test
}

When unmerging, portage won't remove /test/bin because its target still exists.


pgpTyyBw7DQJN.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > Well, you should know that those are because of portage bugs or some
> > > portage peculiarity, read the corresponding bugs for example for cups
> > > to find out more.
> >
> > Can you point me to a bug? There's no mention in the ChangeLog that I can
> > see nor in the ebuilds themselves...
>
> Bug #99375 is mentioned in the changelog for samba.

Okay. It appears to be something related to symlinks. Can you show me the bug 
assigned to portage that reports this and/or shows how to reproduce it?

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Friday 23 December 2005 21:39, Harald van Dijk wrote:
> On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> > On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > > Well, you should know that those are because of portage bugs or some
> > > portage peculiarity, read the corresponding bugs for example for cups
> > > to find out more.
> >
> > Can you point me to a bug? There's no mention in the ChangeLog that I can
> > see nor in the ebuilds themselves...
>
> Bug #99375 is mentioned in the changelog for samba.

It still doesn't explain why it's necessary.

--
Jason Stubbs

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] checdeps.rb for getting deps out of elf files

[Thomas de Grenier de Latour]

On Fri, 23 Dec 2005 13:09:08 +0200
Petteri Räty <[EMAIL PROTECTED]> wrote:

> Basically it does ldd on all the elf files in a package and then
> checks to which packages those libraries belong. 

I don't think "ldd" alone is the way to go, because it doesn't make
distinction beetween direct and indirect links, and thus real and
deep deps. 
To give you the idea, there's a patch in this thread for Spider's
"depreverse" script, which shows how to filter "ldd" output to keep
only NEEDED libs (using "objdump" here, although it would be doable
with "scanelf" too nowdays):
http://thread.gmane.org/gmane.linux.gentoo.devel/27288

--
TGL.

-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Harald van Dijk]

On Fri, Dec 23, 2005 at 08:31:06PM +0900, Jason Stubbs wrote:
> On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> > Well, you should know that those are because of portage bugs or some
> > portage peculiarity, read the corresponding bugs for example for cups
> > to find out more.
> 
> Can you point me to a bug? There's no mention in the ChangeLog that I can see 
> nor in the ebuilds themselves...

Bug #99375 is mentioned in the changelog for samba.


pgp53gj28DU3s.pgp
Description: PGP signature

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

On Friday 23 December 2005 20:19, Stefan Schweizer wrote:
> Well, you should know that those are because of portage bugs or some
> portage peculiarity, read the corresponding bugs for example for cups
> to find out more.

Can you point me to a bug? There's no mention in the ChangeLog that I can see 
nor in the ebuilds themselves...

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list

Re: [gentoo-dev] pkg_{pre,post}inst misusage

[Stefan Schweizer]

Well, you should know that those are because of portage bugs or some
portage peculiarity, read the corresponding bugs for example for cups
to find out more.

Regards,
Stefan

-- 
gentoo-dev@gentoo.org mailing list

[gentoo-dev] checdeps.rb for getting deps out of elf files

[Petteri Räty]

http://dev.gentoo.org/~betelgeuse/scripts/checkdeps.rb
Some people will probably find this useful. Basically it does ldd on all
the elf files in a package and then checks to which packages those
libraries belong. I think portage people are working on integrating
something like this to portage in the form of verify-rdepend.

Regards,
Petteri


signature.asc
Description: OpenPGP digital signature

Re: [gentoo-dev] Changing description for the xml global use flag

[Petteri Räty]

Stuart Herbert wrote:
> 
> I can see where you're coming from, but I'm not sure it's worth the
> potential disruption that this will cause our users.  
> 
> Unless I'm missing something, won't every user who has any form of
> USE=xml, USE=-xml, USE=xml2, or USE=-xml2 in make.conf and packages.use
> get a nasty surprise the next time they emerge -u world?
> 
> I haven't seen any discussion taking this into account yet.
> 
> Best regards,
> Stu

Most profiles turn on xml2 by default so we can just have the xml global
use flag on by default to avoid most breakage. Then people turning -xml2
will just get xml until they switch to -xml. If you want to run a
minimal ship, you should be doing emerge -pv any way before updates to
check for new use flags.

[EMAIL PROTECTED] /usr/portage/profiles $ grep xml2 -r
/usr/portage/profiles/ -l

package.use is probably something we can't affect atm. It would probably
be useful if Portage checked for unexisting flags in it. This is just
one of those things that have to be properly informated to the user base
until our tools are better in handling these situations.

Regards,
Petteri


signature.asc
Description: OpenPGP digital signature

[gentoo-dev] pkg_{pre,post}inst misusage

[Jason Stubbs]

Here's what we have:

app-office/qhacc/qhacc-3.4.ebuild:  [ -n "${PF}" ] && rm -rf 
/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r2.ebuild:   rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.14a-r3.ebuild:   rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20-r1.ebuild:rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20a.ebuild:  rm -rf 
${ROOT}/usr/share/doc/${PF}
net-fs/samba/samba-3.0.20b.ebuild:  rm -rf 
${ROOT}/usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r3.ebuild:   rm -fR /usr/share/doc/${PF}
net-print/cups/cups-1.1.23-r4.ebuild:   [ -n "${PN}" ] && rm -fR 
/usr/share/doc/${PN}-*
net-print/cups/cups-1.1.23-r5.ebuild:   [ -n "${PN}" ] && rm -fR 
/usr/share/doc/${PN}-*


I'll let others do the yelling.

--
Jason Stubbs
-- 
gentoo-dev@gentoo.org mailing list