IRC Logs

Network: freenode Channel: #gentoo-dev

	Enter your search terms Submit search form
	Web www.irclog.org

[01:25]<mgzfyg>exg: ok now I see what you mean
[01:25]<mgzfyg>exg: any objections to me just removing the -r1s ?
[01:29]<kurrpprrr>Merlin: yes, don't downgrade
[01:29]<kurrpprrr>Merlin: revbump to -r2, then remove -r1
[01:29]<mgzfyg>ok
[01:29]<mgzfyg>will do
[01:30]<mgzfyg>should i repair the originals?
[01:30]<kurrpprrr>wait. -r0 has proper libdir, -r1 hasn't, right?
[01:30]<mgzfyg>correct
[01:30]<kurrpprrr>fix -r1, leave it in tree
[01:30]<mgzfyg>k
[01:30]<kurrpprrr>don't remove it at all, don't revbump
[01:31]<mgzfyg>i like that better
[01:32]<kurrpprrr>yeah, it will work, so no need for revbump
[01:41]<sl2>srcerer: pong
[01:43]<szanznz>spb: I saw some of the thread about paludis, just wanted to throw my 2 cents in
[01:44]<szanznz>spb: This message in particular http://thread.gmane.org/gmane.linux.gentoo.devel/38231/focus=38304
[01:45]<sl2>mmhmm
[01:46]<szanznz>spb: Even though it would be harder in the short term to "fix" profiles to use the virtual, you said yourself this would be better, why not embark on that now, as the more right thing to do
[01:47]<sl2>it's a more intrusive change
[01:48]<szanznz>spb: It's more elegant though?
[01:48]<sl2>it is
[01:49]<szanznz>spb: Less artifacts to maintain going foward?
[01:49]<sl2>unfortunately, we have to deal with people as well as code
[01:49]<szanznz>spb: what's the downside, I mean what's intrusive about it? adding python,etc DEPs to ebuilds?
[01:50]<sl2>editing profiles/base/
[01:51]<szanznz>what breaks when editing profiles/base ?
[01:51]<cxzyswxyvn>srcerer, basically
[01:51]<cxzyswxyvn>srcerer, if you remove python from profiles/base/
[01:51]<cxzyswxyvn>srcerer, every profile (directly or indirectly) inherits base profile
[01:51]<cxzyswxyvn>srcerer, so they'd all have to indicate a python dep at some level
[01:52]<cxzyswxyvn>srcerer, because right now none of them do because python is already in base
[01:52]<szanznz>right, so wouldn't that move out to the individual ebuilds?
[01:52]<cxzyswxyvn>no, it would be a profile change
[01:53]<szanznz>why wouldn't the python DEP be in individual ebuilds?
[01:53]<cxzyswxyvn>because if every profile claims python as a system dep
[01:53]<cxzyswxyvn>then it's guaranteed to be avaliable
[01:53]<przzyrr2>implicit system deps.
[01:54]<przzyrr2>how many ebuilds state they need gcc to compile?
[01:54]<cxzyswxyvn>and if it's not avaliable
[01:54]<cxzyswxyvn>then you've fscked with system and shame on you
[01:56]<szanznz>hmm, that gcc point is interesting, I suppose if the line I was arguing was taken to it's logical conclusion, then gcc would also be removed, but I don't think it's practical, since no possible distribution of gentoo currently exists that doesn't use a kernel written in C
[01:56]<cxzyswxyvn>gcc's not the only c compiler out there
[01:57]<szanznz>but how many individual ebuilds would acutally need to DEP python if it wasn't in the base?
[01:57]<przzyrr2>dunno. scan the tree :P
[01:58]<przzyrr2>rather see the virtual shoved in though. folks who will hit the bugs are the paludis folk trying to ixnay python from their systems
[01:58]<przzyrr2>bootstrap might require a bit o' love, but that's nothing new
[01:58]<szanznz>ChrisWhite: I agree, and the C compiler should be configurable (and therefore not hardcoded in the base profile, but I'm trying to stay within the topic of plugable package managers that all use a common portage tree)
[01:59]<sl2>as things stand at the moment removing python from profiles will do very little since it's pulled in by portage
[01:59]<przzyrr2>hence just shoving the virtual in, and letting y'all sort through it works for me.
[02:03]<szanznz>spb: wouldn't you be changing that by not including portage either?
[02:03]<sl2>the default profiles will still include portage, just via the virtual
[02:04]<przzyrr2>spb: default will specify portage as the default virtual, not necessarily pull it in if the virtual is filled.
[02:04]<szanznz>spb: but the virtual can be redefined right? I mean that was the whole point of your suggestion to move to a virtual right?
[02:04]<przzyrr2>iow, adjustment to your bootstrapping.
[02:05]<sl2>ferringb: well yes
[02:05]<sl2>but for people using portage
[02:05]<sl2>everything will be as it is at the moment
[02:05]<przzyrr2>yep.
[02:05]<szanznz>spb: and that's a further point, a feature
[02:05]<przzyrr2>why the 'but' ? that's groked... :)
[02:06]<szanznz>it makes experimenting with alternate/replacment package managers easier though, and that was the original goal right?
[02:07]<sl2>yup
[02:07]<sl2>which is why, if people are amenable to the idea, i'd like to do it
[02:08]<przzyrr2>moreso used
[02:08]<przzyrr2>offered the thing more times then I care to count :P
[02:08]<przzyrr2>stepping away from the profile format (N parent inheritance), without a way to force portage to explode on it, different stance there ;)
[02:11]<szanznz>My main reason for piping up was that I saw you, spb, had suggested a solution to your own problem. One that is elegant and benefits more than just Paludis. But the suggestion seemed to be getting lost in the volume of posts on the thread.
[02:13]<fu_nnzj>spb let me set a procmail rule to handle it
[02:13]<sl2>haha
[02:13]<fu_nnzj>or prepare the grill and order the meat
[02:14]<przzyrr2>spb: kindly don't send it from the future again ;)
[02:14]<rrrppgnd>heh
[02:14]<sl2>ferringb: you can thank my parents' pc for that
[02:15]<przzyrr2>spb: going to push for python to be added to other profiles btw, or just going to be cleaning up the implicit python deps as y'all go?
[02:16]<szanznz>I don't have any particular bias towards paludis, frankly hadn't heard of it before it came on the GWN radar, but I do like the idea that alternate package managers can be experimented with.
[02:16]<sl2>my default intention is to just remove it from base/, default-linux/ and friends and rely on portage pulling it in
[02:16]<sl2>i'm quite willing to be persuaded otherwise
[02:16]<przzyrr2>works for me.
[02:16]<przzyrr2>spb: mainly don't want to see the python dep propogate, rather see the implicit deps killed off
[02:17]<szanznz>Anything that makes the existing structure more elegant while promoting that kind of experimentation is a good refactoring in my book
[02:17]<przzyrr2>(that's a war of it's own, also)
[02:19]<szanznz>ferringb: not sure what you refering to when you said "force portage to explode on it"
[02:19]<szanznz>ferringb: is gcc not included in base via a virtual now?
[02:21]<mgzfyg>is there a tool to help me see the latest stable versions of an ebuild for all archs?
[02:22]<sl2>earch or eshowkw
[02:22]<kurrpprrr>ferringb: ping?
[02:22]<mgzfyg>spb: what are they part of?
[02:23]<kurrpprrr>ferringb: i got 4 differences to your tree vulnerabilities report
[02:23]<sl2>Merlin: no idea
[02:23]<kurrpprrr>ferringb: app-emulation/wine-0.9 is not vulnerable according to GLSA. wine-0.9 is >= wine-0.9.0
[02:24]<kurrpprrr>ferringb: you're missing dev-perl/Convert-UUlib-1.06. which is < -1.051 and thus vulnerable
[02:24]<kurrpprrr>ferringb: also, glibc-2.3.2-r12 is not vulnerable
[02:25]<kurrpprrr>ferringb: lastly, glibc-2.3.3.20040420-r2 is not vulnerable, either.
[02:26]<kurrpprrr>ferringb: i guess your resolver has problems with version specs
[02:26]<przzyrr2>glsa numbers...
[02:27]<kurrpprrr>ferringb: wine: 200601-09
[02:27]<przzyrr2>win-0.9 is less then win-0.9.0 btw.
[02:27]<kurrpprrr>ferringb: no

Back to #gentoo-dev
Or go to some related logs:
#gentoo
#gentoo
#debian
#php
#ubuntu