path: root/meeting-logs/20070208.txt

Feb 08 12:00:36 kingtaco|work	>>>>> BEGIN LOGGING
Feb 08 12:00:41 kingtaco|work	ok, rollcall
Feb 08 12:00:48 *	kingtaco|work here
Feb 08 12:01:27 *	Flameeyes here (dining)
Feb 08 12:01:36 kloeri	hi all
Feb 08 12:01:39 vapier	poop
Feb 08 12:01:46 kingtaco|work	robbat2|na, ?
Feb 08 12:01:55 kingtaco|work	spb
Feb 08 12:02:04 wolf31o2|mobile	present
Feb 08 12:02:24 kingtaco|work	spb is making food, I guess he'll be here in a minute
Feb 08 12:02:46 kingtaco|work	anyone have items that I didn't just list?
Feb 08 12:02:57 Flameeyes	glep44 status
Feb 08 12:03:02 kingtaco|work	ok
Feb 08 12:03:10 kloeri	genone wanted us to reconfirm glep 23
Feb 08 12:03:16 kingtaco|work	got that on the list
Feb 08 12:03:21 *	amne (n=amne@gentoo/developer/amne) has joined #gentoo-council
Feb 08 12:03:36 kingtaco|work	Flameeyes, you want to start with 44?
Feb 08 12:04:18 spb	back
Feb 08 12:04:47 Flameeyes	kingtaco|work, I'd rather be silent while dining, but if you want to start with 44, fine
Feb 08 12:05:01 kingtaco|work	ok
Feb 08 12:05:11 kingtaco|work	lets start with the council member thing then
Feb 08 12:05:40 kingtaco|work	so, the council glep doesn't say anything about what happens when a dev leaves of his own will
Feb 08 12:06:06 kingtaco|work	I think we should take the next place in the orig election and then have the council confirm it.
Feb 08 12:06:07 Flameeyes	nor if it gets removed by devrel
Feb 08 12:06:17 vapier	s/of his own will/
Feb 08 12:06:20 kingtaco|work	what I'm not sure of is if majority vote or unanmous vote
Feb 08 12:06:38 Flameeyes	I would be for unanymous
Feb 08 12:07:22 kingtaco|work	regardless of how we decide to vote, if the vote fails, it'd be a new election for that one member for a reduced term
Feb 08 12:07:26 spb	on the other hand, for consistency it makes sense to do the same thing if a dev leaves that is done when the slacker boot is applied
Feb 08 12:07:58 vapier	http://thread.gmane.org/gmane.linux.gentoo.devel/45517
Feb 08 12:08:23 kloeri	devrel won't retire council members btw unless they're completely inactive (just like other devs) in which case they'd be marked slackers before that happened
Feb 08 12:09:02 kingtaco|work	yeah
Feb 08 12:09:14 Flameeyes	kloeri, what happens in case of complaints?
Feb 08 12:09:18 spb	kloeri: technically it takes three months for a council member to be booted for slacking, where the activity timeout is two months
Feb 08 12:09:29 vapier	from the few responses on -dev (mine included), simply taking the next person "in line" until exhausted seems easiest route to get things up and going again
Feb 08 12:09:29 *	welp (n=welp@gentoo/developer/welp) has joined #gentoo-council
Feb 08 12:09:46 spb	though i suppose it'll take a bit longer to actually retire inactive people
Feb 08 12:09:50 kingtaco|work	as long as it's approved by the remaining members
Feb 08 12:09:53 kingtaco|work	I concur
Feb 08 12:09:54 vapier	how the council member comes to be no longer a gentoo developer is irrelevant to the topic i think
Feb 08 12:10:09 kloeri	spb: well, technically I'll probably never get close to two months and there's at least two weeks to file notice against retirement so it should work out I think
Feb 08 12:10:16 Flameeyes	vapier, agreed
Feb 08 12:10:24 *	avenj (n=avenj@gentoo/developer/avenj) has joined #gentoo-council
Feb 08 12:10:49 kloeri	next person in line is fine imo
Feb 08 12:10:54 spb	i have a slight preference for option 2 in that mail, but taking the next in line works too
Feb 08 12:11:26 spb	i just don't see why a dev leaving the council and getting booted from the council should have different methods to replace them
Feb 08 12:11:29 Flameeyes	kloeri, by the way, if the activty is counted on cvs, it's possible that someone is presenting to the council meeting just fine but resulting inactive
Feb 08 12:11:58 kingtaco|work	ok, lets vote: when a council member leaves his position will be filled by the next candidate in the origional election, subject to unanmious approval of the existing council members
Feb 08 12:12:00 kloeri	Flameeyes: I check all kinds of development related activities, not just cvs
Feb 08 12:12:10 kingtaco|work	failing that it's a general election for a reduced term for that spot
Feb 08 12:12:12 Flameeyes	kloeri, council counting too?
Feb 08 12:12:17 g2boojum	spb: Would you be happier if the GLEP were amended to permit taking the next on the list (plus confirmation) a possibility for slacker boots, as well?
Feb 08 12:12:24 kloeri	Flameeyes: of course
Feb 08 12:12:29 Flameeyes	kingtaco|work, I vote yes
Feb 08 12:12:31 Flameeyes	kloeri, okay
Feb 08 12:12:38 spb	g2boojum: either way works for me; i'd just prefer they were consistent
Feb 08 12:12:52 wolf31o2|mobile	yes
Feb 08 12:12:53 vapier	i'd just say 'leaving the council'
Feb 08 12:12:54 kloeri	I vote yes
Feb 08 12:13:03 kingtaco|work	ok, add "for any reason" to "council member leaves"
Feb 08 12:13:10 kingtaco|work	I vote yes
Feb 08 12:13:13 spb	yes
Feb 08 12:13:39 kingtaco|work	vapier, robbat2|na ?
Feb 08 12:13:42 wolf31o2|mobile	I'd agree with vapier, etc.  I don't see the need for a new election if the council agrees to have the next person in line take the position unanimously
Feb 08 12:13:58 vapier	why does the council need to agree
Feb 08 12:14:15 wolf31o2|mobile	uhh... because that's what we're being asked to vote on
Feb 08 12:14:15 *	The_Paya (i=the_paya@gentoo/developer/thepaya) has joined #gentoo-council
Feb 08 12:14:19 wolf31o2|mobile	;]
Feb 08 12:14:31 kingtaco|work	vapier, you mean agree to the Nth spot?
Feb 08 12:14:45 vapier	a council member leaves, the next spot is filled by the next person in the list]
Feb 08 12:14:55 vapier	doesnt matter if the existing council members like that next person
Feb 08 12:15:06 Flameeyes	vapier, if it happens to be the least preferred member for the council, it would make sense to veto him from joining
Feb 08 12:15:13 vapier	why
Feb 08 12:15:17 vapier	it's an elected position
Feb 08 12:15:18 kingtaco|work	vapier, well, think about it this way
Feb 08 12:15:43 spb	the alternative to having the council members agree on the replacement is to include 'reopen nominations' on the council ballot and not accept anyone below it
Feb 08 12:15:46 kingtaco|work	that person that was voted for months ago may not be in the same position when we would put him in the council
Feb 08 12:15:55 *	rbrown` (n=mynamewa@paludis/contributor/rbrown) has joined #gentoo-council
Feb 08 12:15:57 kingtaco|work	also note that that person has the right to decline
Feb 08 12:16:24 wolf31o2|mobile	no they don't
Feb 08 12:16:27 wolf31o2|mobile	:P
Feb 08 12:16:29 kingtaco|work	I think having the vote is just a safty clause
Feb 08 12:16:43 vapier	then it's either we take the next person or we re-open elections
Feb 08 12:16:49 *	NeddySeagoon (n=NeddySea@gentoo/developer/NeddySeagoon) has joined #gentoo-council
Feb 08 12:16:51 kingtaco|work	oh yres
Feb 08 12:16:53 vapier	we cant selectively skip
Feb 08 12:16:56 kingtaco|work	that's what I'm saying
Feb 08 12:17:21 kingtaco|work	if we decline the next person it would be a election for that position for a reduced term
Feb 08 12:17:31 wolf31o2|mobile	right
Feb 08 12:17:31 kingtaco|work	we as in the current council
Feb 08 12:17:46 vapier	i'll sign off on that
Feb 08 12:17:52 kingtaco|work	ok
Feb 08 12:18:01 kingtaco|work	6 yes, 1 abstain(robbat2)
Feb 08 12:18:05 kingtaco|work	all good?
Feb 08 12:18:12 spb	looks it
Feb 08 12:18:19 kingtaco|work	ok, next item
Feb 08 12:18:20 Flameeyes	yah
Feb 08 12:18:21 wolf31o2|mobile	WFM
Feb 08 12:18:30 kingtaco|work	glep 23 or 44 first?
Feb 08 12:18:34 kingtaco|work	Flameeyes, you pick
Feb 08 12:18:44 *	Flameeyes sets modes [#gentoo-council +v solar]
Feb 08 12:18:49 Flameeyes	solar, you around for the status on 44?
Feb 08 12:18:55 kingtaco|work	I take it it's 44 then :)
Feb 08 12:19:10 Flameeyes	kingtaco|work, if he's around :) if he's not, let's go with 23 :)
Feb 08 12:19:14 kingtaco|work	Flameeyes, it's 12:20 here, he's probably on lunch
Feb 08 12:19:21 kingtaco|work	ok
Feb 08 12:19:22 Flameeyes	then 23 would do
Feb 08 12:19:36 kingtaco|work	so genone wants us to re afferm glep 23 because things have changed
Feb 08 12:19:40 kingtaco|work	anyone want to talk about it?
Feb 08 12:19:48 spb	what's changed, specifically?
Feb 08 12:19:48 vapier	changed how
Feb 08 12:19:53 kingtaco|work	good question
Feb 08 12:20:35 kingtaco|work	does sources.g.o track glep repo?
Feb 08 12:20:36 Flameeyes	for context, and people who have no clue about what 23 is, it's "Handling of ACCEPT_LICENSE"
Feb 08 12:20:38 *	drac (i=drac@gentoo/developer/drac) has joined #gentoo-council
Feb 08 12:20:39 kingtaco|work	g2boojum, ^^?
Feb 08 12:21:01 spb	they're in gentoo/xml/htdocs/
Feb 08 12:21:05 vapier	well genone isnt on and all i see is http://article.gmane.org/gmane.linux.gentoo.devel/45750
Feb 08 12:21:37 g2boojum	kingtaco|work: I had assumed you folks knew what the issues were.  I haven't talked to genone about it.
Feb 08 12:21:38 vapier	http://sources.gentoo.org/viewcvs.py/gentoo/xml/htdocs/proj/en/glep/
Feb 08 12:21:39 kingtaco|work	bump it to next month so he can tell us what's changed?
Feb 08 12:21:40 Flameeyes	I think it's the old discussion of a month or two ago
Feb 08 12:21:55 wolf31o2|mobile	http://bugs.gentoo.org/show_bug.cgi?id=152593
Feb 08 12:22:01 Flameeyes	but I admit I didn't really follow it
Feb 08 12:22:13 wolf31o2|mobile	likely it's the solution to that bug that he wants discussed
Feb 08 12:22:18 g2boojum	spb: paludis folks have any complaints w/ what genone's doing?
Feb 08 12:22:33 g2boojum	?
Feb 08 12:22:46 spb	we already have license filtering, so the only issue is with group syntax and how they're defined
Feb 08 12:23:10 g2boojum	spb: Think you folks, genone, and pkgcore can come to an agreement?
Feb 08 12:23:30 wolf31o2|mobile	there's also http://bugs.gentoo.org/show_bug.cgi?id=17367
Feb 08 12:23:37 vapier	what do other package managers have to do with this ?
Feb 08 12:23:51 kingtaco|pda	shouldnt this be part ogpkg manager spec?
Feb 08 12:24:14 wolf31o2|mobile	nothing... as I understand it, he simply wants us to re-approve it, since the ideas have changed a bit since the original GLEP was approved
Feb 08 12:24:35 spb	kingtaco|pda: it should
Feb 08 12:24:55 vapier	well we can scratch our heads some more or just ask genone for more info
Feb 08 12:25:06 vapier	and make sure we tag all topics for relevant info before the meeting so we dont do this
Feb 08 12:25:07 Flameeyes	afk 1 minute
Feb 08 12:25:14 kingtaco|pda	ok, bump it
Feb 08 12:25:14 g2boojum	vapier: My view was that if there's a reasonable consensus on how to implement it, then the council probably doesn't really need to get involved except to approve it after the fact.
Feb 08 12:25:18 wolf31o2|mobile	looks like our best option is to defer
Feb 08 12:25:29 spb	the only comments i have on the glep as it is are (1) NON-MUST-HAVE-READ is a stupid name, and (2) is it legal to negate a license group?
Feb 08 12:25:34 solar	Flameeyes: pong
Feb 08 12:25:48 kingtaco|pda	solar glep 44
Feb 08 12:25:51 wolf31o2|mobile	but I would recommend everyone check out those two bugs
Feb 08 12:25:59 vapier	spb: something to post to the list
Feb 08 12:26:03 Flameeyes	back
Feb 08 12:26:06 vapier	wolf31o2: you already know my position on * :p
Feb 08 12:26:07 kloeri	deferring seems to be the best option now I agree
Feb 08 12:26:17 Flameeyes	yeah deferring is a good idea
Feb 08 12:26:27 spb	vapier: yeah, hence i say defer
Feb 08 12:26:40 kingtaco|work	ok, defered
Feb 08 12:26:50 kingtaco|work	Flameeyes, solar: glep44 time
Feb 08 12:27:01 solar	KingTaco: it seems to be progressing well. Flameeyes has been really on top of things. In the last few days he took the tree from 10% not ready to 7%. Maybe in a few weeks we will be able to make that cut over
Feb 08 12:27:17 wolf31o2|mobile	spb: I agree that #1 is stupid... and #2, as I remember it, was that a group could only include licenses, not negate them, but it would be legal syntax to allow a negated group in ACCEPT_LICENSE... so you can --@OSI-APPROVED, but @OSI-APPROVED couldn't have -VMWARE (or something like that)
Feb 08 12:27:18 Flameeyes	there is one problem though
Feb 08 12:27:29 kingtaco|work	solar, tbh, I'm not sure what flameeyes wants to talk about so I'll defer to him
Feb 08 12:28:02 Flameeyes	there are a few packages that are currently unmaintained (officially, or simply because the herd they belong to does not exist anymore)
Feb 08 12:28:13 Flameeyes	and of those, there are quite a few that misses an upstream package
Feb 08 12:28:28 Flameeyes	what are we up to do with them?
Feb 08 12:28:34 wolf31o2|mobile	are they not on our mirrors?
Feb 08 12:28:38 solar	when you say upstream you are saying they are on the mirrors but the SRC_URI has expired
Feb 08 12:28:41 Flameeyes	do we consider glep44 an high enough priority to mess with them?
Feb 08 12:28:47 Flameeyes	solar, yes
Feb 08 12:29:05 Flameeyes	the quick and dirty solution is to use mirror://gentoo/ for those files
Feb 08 12:29:07 wolf31o2|mobile	if they're on the mirrors, I would say leave them alone, if they're neither in SRC_URI or the mirrors, they need to be axed
Feb 08 12:29:16 solar	Well the timeframe was about 1 year. That glep comes from 04-Dec-2005
Feb 08 12:29:24 kingtaco|work	mess with them how?  isn't it simply regenerating the digests?
Feb 08 12:29:29 spb	my comment on this is that PMS in its current state only describes Manifest2 and not the old-style digest/manifest
Feb 08 12:29:45 Flameeyes	kingtaco|work, see the missing SRC_URI url
Feb 08 12:29:47 wolf31o2|mobile	PMS?
Feb 08 12:29:50 spb	so it'd be nice to have the tree completely converted by the time that gets implemented
Feb 08 12:29:54 spb	wolf31o2|mobile: package manager spec
Feb 08 12:29:57 wolf31o2|mobile	k
Feb 08 12:29:59 kloeri	just change them to mirror://gentoo/ where possible
Feb 08 12:30:04 kingtaco|work	if there is no upstream URI then change to mirror://gentoo and if it's not on our mirrors, pull the shit from the tree
Feb 08 12:30:13 wolf31o2|mobile	agreed
Feb 08 12:30:41 wolf31o2|mobile	Flameeyes: I'm willing to help you with this if you need it to try to get this done quicker... I'd *love* to be able to make the cut for 2007.0
Feb 08 12:30:41 *	genstef (n=genstef@gentoo/developer/genstef) has left #gentoo-council
Feb 08 12:30:56 Flameeyes	if we all agree on that, I'll see to fix the pacakges updating SRC_URI when needed (and opening a reference bug for safety)
Feb 08 12:31:45 Flameeyes	vapier, there are a few of your packages and base-system packages too
Feb 08 12:31:59 vapier	when arent there
Feb 08 12:32:04 kingtaco|work	ok, so we seem to agree on the course of action for these packages, is there anything we need to vote on or discuss more?
Feb 08 12:32:40 Flameeyes	well, I would ask if I can just go on and fix the tree at once or if I need to clear it up with all the maintainers
Feb 08 12:32:59 spb	if you're not making substantive changes then i don't see the problem
Feb 08 12:32:59 *	christel (i=christel@freenode/staff/gentoo.christel) has joined #gentoo-council
Feb 08 12:33:00 Flameeyes	[considering that the list of packages fixed by me is generated and easily found, as I'm using a standard commit message
Feb 08 12:33:02 solar	So target deadline is before 2007.0 snapshots begin? Can you give us a rough idea when that is planned for?
Feb 08 12:33:26 Flameeyes	solar, maybe too soon
Feb 08 12:33:34 wolf31o2|mobile	it very well might be... the plan in Monday
Feb 08 12:33:35 kingtaco|work	Flameeyes, can you generate a list of ebuilds that need fixing?
Feb 08 12:33:42 Flameeyes	kingtaco|work, I have it already
Feb 08 12:33:55 solar	can you post it for everybody else?
Feb 08 12:33:57 Flameeyes	http://rafb.net/p/s2xMEr38.html
Feb 08 12:34:02 Flameeyes	solar, was nopasting it already :)
Feb 08 12:34:07 kingtaco|work	Flameeyes, lets script emails to the maintainers and give them a week or 2 to fix then fix them ourselves
Feb 08 12:34:19 Flameeyes	kingtaco|work, that would miss the snapshot
Feb 08 12:34:30 kingtaco|work	hrm
Feb 08 12:34:37 wolf31o2|mobile	if that's the consensus, I'm fine with that
Feb 08 12:34:47 wolf31o2|mobile	but we're not pushing the snapshot >= 2 weeks
Feb 08 12:34:54 spb	i'm in favour of just doing it
Feb 08 12:34:58 Flameeyes	me too
Feb 08 12:34:58 wolf31o2|mobile	as am I
Feb 08 12:35:06 wolf31o2|mobile	it's just Manifest generation
Feb 08 12:35:10 kingtaco|work	ok, I'll ride the wagon
Feb 08 12:35:16 kloeri	yeah, just do it
Feb 08 12:35:20 spb	it shouldn't involve any substantive ebuild changes
Feb 08 12:35:27 kingtaco|work	vapier, you game?
Feb 08 12:35:33 spb	just regenerating stuff that's regenerated on every commit
Feb 08 12:35:34 wolf31o2|mobile	right
Feb 08 12:35:36 kloeri	and let ebuild maintainers worry about real bugs
Feb 08 12:35:51 wolf31o2|mobile	so who's planning on doing this work? us?
Feb 08 12:36:00 Flameeyes	I can do it overnight
Feb 08 12:36:02 kingtaco|work	sounds like flameeyes is
Feb 08 12:36:03 vapier	considering all you're doing is rebuilding digests, just do it now ;p
Feb 08 12:36:06 wolf31o2|mobile	I volunteer
Feb 08 12:36:14 wolf31o2|mobile	Flameeyes: I'll do games-*
Feb 08 12:36:19 kingtaco|work	were I not at scale this weekend I'd help
Feb 08 12:36:19 wolf31o2|mobile	Flameeyes: I see there's a bunch of them
Feb 08 12:36:31 vapier	it isnt like you're changing the ebuild
Feb 08 12:36:38 wolf31o2|mobile	right
Feb 08 12:36:45 Flameeyes	wolf31o2|mobile, okay, that's really good to hear as there are a few that aren't fetchable to begin with iirc
Feb 08 12:36:45 kingtaco|work	ok
Feb 08 12:36:56 kingtaco|work	next topic
Feb 08 12:37:00 kingtaco|work	if we have them
Feb 08 12:37:01 wolf31o2|mobile	the only concern I have is there's a possible bug in pycrypto... it hasn't been confirmed yet, though
Feb 08 12:37:06 kloeri	Flameeyes: I can do dev-python if you like
Feb 08 12:37:29 wolf31o2|mobile	http://bugs.gentoo.org/show_bug.cgi?id=164462 <---
Feb 08 12:37:50 kingtaco|work	nothing else on the list, anyone got anything else before the floor opens?
Feb 08 12:37:58 Flameeyes	wolf31o2|mobile, not the same as last time?
Feb 08 12:37:59 wolf31o2|mobile	I don't think that should stop us, but if we find it is a bug, it might keep us from doing the switch for 2007.0
Feb 08 12:38:12 wolf31o2|mobile	Flameeyes: dunno... I haven't verified it just yet
Feb 08 12:38:23 g2boojum	tr1?
Feb 08 12:38:25 kingtaco|work	ah
Feb 08 12:38:39 kingtaco|work	g2boojum, iirc you wanted us to talk about it, but what is there to talk about?
Feb 08 12:39:03 g2boojum	kingtaco|work: It'd be nice to have an executive decision on how to handle tr1 support in portage.
Feb 08 12:39:07 Flameeyes	ah, for a note, don't use ebuild .. digest if possible, or it would override the digest check of FEATURES=strict
Feb 08 12:39:24 Flameeyes	just run echangelog and repoman commit
Feb 08 12:39:32 g2boojum	There's general agreement that none of the current ideas are fabulous, but something is going to have to be chosen relatively soon.
Feb 08 12:39:36 kingtaco|work	g2boojum, I don't think most of us have an oppinion as it is
Feb 08 12:39:41 kingtaco|work	portage doesn't use it
Feb 08 12:39:42 g2boojum	s/ideas/solutions/
Feb 08 12:39:49 Flameeyes	I've used "Regenerate digest in Manifest2 format." for all the commits, so that the list is regenerated by grepping for the string
Feb 08 12:39:58 kloeri	g2boojum: I think the best proposal so far is ciaranms many virtuals
Feb 08 12:40:10 g2boojum	kingtaco|work: Um, true only because portage is python, and C.
Feb 08 12:40:22 kingtaco|work	indeed
Feb 08 12:40:30 kingtaco|work	so it'
Feb 08 12:40:37 g2boojum	kingtaco|work: It will still affect the portage tree, once people start writing packages that rely on tr1 support in g++.
Feb 08 12:40:38 spb	kloeri: unfortunately true. which is a pity, because that solution is a pain in the arse
Feb 08 12:40:48 kloeri	spb: completely agree
Feb 08 12:40:56 kingtaco|work	so as I see it, tr1 support is a dep of some packages where they can either dep on boost or gcc4
Feb 08 12:41:05 wolf31o2|mobile	Flameeyes: k
Feb 08 12:41:22 kingtaco|work	can't we have a simple virtual of boost || gcc-4.1 ?
Feb 08 12:41:28 Flameeyes	[reason for regenerating the list is that those packages are good candidates for new maintainers and/or removal]
Feb 08 12:41:30 kloeri	kingtaco|work: gcc-4.1 or boost, yes
Feb 08 12:41:32 spb	kingtaco|work: the problem is that right now nothing implements all of tr1, and the bits that various things implement are all different
Feb 08 12:41:37 kingtaco|work	maybe a tr1.eclass that does some sanity checks
Feb 08 12:42:11 vapier	if we simply forced people to stop being lazy and get their arches onto gcc-4.1, then we'd be set ;)
Feb 08 12:42:16 kingtaco|work	so upstream is using broken libraries
Feb 08 12:42:20 spb	vapier: not quite
Feb 08 12:42:24 g2boojum	kingtaco|work: Not really, because in time there's an expectation that people will remove boost tr1 support in favor of support built-into g++, but removing a c++ lib will break compiled packages.
Feb 08 12:42:29 *	iluxa (n=anonymou@gentoo/developer/iluxa) has joined #gentoo-council
Feb 08 12:42:30 spb	if something starts using tr1 regexes you have problems again
Feb 08 12:42:42 vapier	if it isnt in the compiler then dont use it
Feb 08 12:42:43 g2boojum	kingtaco|work: So || won't really work well.
Feb 08 12:42:48 vapier	boost sucks
Feb 08 12:42:48 *	Flameeyes sets modes [#gentoo-council +v Betelgeuse]
Feb 08 12:42:51 kingtaco|work	fyi, jokey likes the tr1.eclass idea
Feb 08 12:42:54 kingtaco|work	(from pm)
Feb 08 12:42:59 Flameeyes	Betelgeuse has another proposal too
Feb 08 12:43:16 Betelgeuse	This can be solved by || ( ) deps that lock to the version at compile time
Feb 08 12:43:18 spb	vapier: 4.2 and 4.3 have bits of tr1 that 4.1 doesn't, as do boost and stlport iirc
Feb 08 12:43:24 Betelgeuse	But that would be EAPI=1 most likely
Feb 08 12:43:38 spb	Betelgeuse: it's also a pain in the arse
Feb 08 12:43:58 spb	what if i use a feature of tr1 that at present is only implemented by boost, but gets support for it in, say, gcc-4.3?
Feb 08 12:43:59 kingtaco|work	so there is no full implementation of tr1 yet
Feb 08 12:44:22 Betelgeuse	spb: you would use boost:: any way
Feb 08 12:44:25 kingtaco|work	I'd say packages that use tr1 type features should hard dep on whatever provides those features
Feb 08 12:44:28 vapier	how many packages actually leverage tr1
Feb 08 12:44:28 g2boojum	kingtaco|work: There is, but it's boost, which, as vapier points out, "sucks".
Feb 08 12:44:29 spb	then with the || ( ) dep thing you'd have to go through and update every ebuild using it for the new dep
Feb 08 12:44:32 kingtaco|work	I'd still use an eclass for sanity checks
Feb 08 12:44:40 Betelgeuse	spb: The sources having the wrapper would need mos any way.
Feb 08 12:45:00 vapier	"every ebuild" isnt a big deal if we're talking a handful of packages
Feb 08 12:45:00 kingtaco|work	we could hard dep on boost until gcc gets full tr1 support
Feb 08 12:45:08 Betelgeuse	spb: nothing is saying that we could not have the binding in the virtual
Feb 08 12:45:22 Flameeyes	how many packages are we talking about?
Feb 08 12:45:34 Flameeyes	I wouldn't go to something like 10 virtuals if the packages using them are 3 or 4
Feb 08 12:46:01 spb	Flameeyes: if we go the virtuals route i'd add them one at a time as needed
Feb 08 12:46:04 kingtaco|work	g2boojum, it might suck today, that doesn't mean it'll suck tomorrow
Feb 08 12:46:19 Flameeyes	spb, that doesn't stop them from being 10 virtuals even if they are 3 packages
Feb 08 12:46:21 spb	kingtaco|work: it's sucked for the last five years; no reason to suppose it'll change
Feb 08 12:46:30 Flameeyes	because they might be using 10 different features of tr1
Feb 08 12:46:36 spb	at the moment the issue is mainly with tr1-memory
Feb 08 12:46:47 g2boojum	kingtaco|work: Oh, the code in boost is excellent.  The problem is that you need almost all of it, and it's huge, for tr1.
Feb 08 12:46:48 spb	which means right now it'll be one or two virtuals
Feb 08 12:47:12 kingtaco|work	I guess I don't see what the big deal is that an ebuild deps on what it needs, perhaps a eclass to do sanity checks
Feb 08 12:47:15 Flameeyes	nobody has a figure of how many packages are using tr1?
Feb 08 12:47:26 spb	kingtaco|work: 11M of source is a hell of a lot for a single shared pointer class
Feb 08 12:47:35 kingtaco|work	if it only needs gcc tr1 support then it should dep on the minimum gcc
Feb 08 12:48:06 spb	except that not all archs have that gcc available
Feb 08 12:48:21 kingtaco|work	spb, I'd argue that the whole concept is crap, and that none of it is ever needed with proper programming, but it's not something that we need to go into now
Feb 08 12:48:33 kloeri	Flameeyes: don't have any figures on that but grepping the tree for boost deps should give you some idea I guess
Feb 08 12:48:38 spb	define 'proper programming'
Feb 08 12:48:43 *	Flameeyes sets modes [#gentoo-council +v jeeves]
Feb 08 12:48:46 Flameeyes	!ddep boost
Feb 08 12:48:47 jeeves	yikes 44 pkgs reverse depend on boost! Try digging around here instead. http://tinderbox.dev.gentoo.org/misc/dindex/
Feb 08 12:48:49 vapier	assuming the boost requirement is for TR1
Feb 08 12:48:58 kingtaco|work	spb, not difficult to manage your own pointers
Feb 08 12:48:58 g2boojum	Flameeyes: Probably not.  The worry isn't so much the current number of packages, but there's evidence that a lot of folks are planning to jump on the tr1 bandwagon quite soon.
Feb 08 12:49:01 vapier	and not just for one of the bajillion other things boost provides
Feb 08 12:49:04 spb	kingtaco|work: hah
Feb 08 12:49:10 kloeri	it's going to expand in the future as well
Feb 08 12:49:16 kingtaco|work	anyway
Feb 08 12:49:28 kingtaco|work	it doesn't matter what you or I think about those that use this library
Feb 08 12:49:39 Flameeyes	g2boojum, there are often a lot of evidences that a lot of folks are jumping on a lot of bandwagons.... I don't like to get decisions over those evidences
Feb 08 12:49:42 kingtaco|work	people are using it so we have to support it
Feb 08 12:49:57 kingtaco|work	but I still don't know why it has to be treated differently than any other dep
Feb 08 12:50:01 kloeri	vapier: yes, only a vague idea as some packages might just require >=gcc-4.1 instead of boost etc.
Feb 08 12:50:06 Flameeyes	vapier, let's say that 1/4 of those packages need tr1 right now? would that make any sense?
Feb 08 12:50:28 spb	kingtaco|work: if we had a complete implementation of tr1 anywhere then it would be simple
Feb 08 12:50:59 kingtaco|work	spb, surely upstreams that use tr1 would say "use gcc" or "use boost" or "use libtr1"
Feb 08 12:51:29 spb	kingtaco|work: most of them will use tr1::shared_ptr and have configure.ac check whether gcc has it and include wrapper code for boost's implementation if it doesn't
Feb 08 12:51:57 kingtaco|work	ok
Feb 08 12:52:12 spb	except that if you happen to be using a different STL implementation then the configure check will see it in the standard library and use that version instead of boost or gcc
Feb 08 12:53:03 kingtaco|work	so, follow me here for a sec
Feb 08 12:53:14 kingtaco|work	say we made all tr1 ebuilds dep on boost
Feb 08 12:53:17 *	diox (n=diox@gentoo/developer/diox) has joined #gentoo-council
Feb 08 12:53:36 kingtaco|work	most of them at compile time would detect that gcc has what they need from tr1 and ignore boost
Feb 08 12:53:38 kingtaco|work	right?
Feb 08 12:53:46 spb	but boost is still pulled into the depgraph
Feb 08 12:53:51 spb	and boost is fucking huge
Feb 08 12:53:56 kingtaco|work	right
Feb 08 12:54:05 kingtaco|work	but you only have to compile it once
Feb 08 12:54:18 spb	except that in most cases you don't have to compile it at all
Feb 08 12:54:43 kingtaco|work	then why can't the ebuilds for these packages dep on the proper thing?
Feb 08 12:54:44 spb	it's kinda like saying that vim should always build gvim as well because you only have to compile X once
Feb 08 12:54:47 Flameeyes	sincerely, I'd just use || ( ) deps until the size of the involved tree is assessed
Feb 08 12:54:51 kingtaco|work	if it works with gcc 4.1, then dep on it
Feb 08 12:54:59 kingtaco|work	if it doesn't dep on boost
Feb 08 12:55:05 Flameeyes	if the packages needing tr1 grew a lot, go with virtuals
Feb 08 12:55:07 spb	depping on 4.1 doesn't work on platforms that don't have it yet
Feb 08 12:55:14 kingtaco|work	from what you tell me, noone in their right mind would use boost where gcc is available
Feb 08 12:55:21 Flameeyes	I wouldn't go with virtuals right away, because we don't know the size
Feb 08 12:55:56 kingtaco|work	spb, which brings us back to virtual/tr1
Feb 08 12:56:11 spb	kingtaco|work: except that there is nothing that provides all of tr1
Feb 08 12:56:17 kingtaco|work	indeed
Feb 08 12:56:22 kingtaco|work	so there isn't a good solution
Feb 08 12:56:41 kingtaco|work	other than messy mips?(boost):(gcc-4) type stuff
Feb 08 12:56:41 Flameeyes	and we have no figure of what's needed, which makes it difficult to get the pro/cons of the various options
Feb 08 12:56:47 Flameeyes	as none of them is "pro only"
Feb 08 12:56:48 g2boojum	Which was why ciaranm suggested virtual/tr1-memory, virtual/tr1-...
Feb 08 12:57:02 spb	g2boojum: which kinda sucks, but is the best option anyone's suggested yet
Feb 08 12:57:22 Flameeyes	g2boojum, which wouldn't really be good if you had 10 virtuals and 4 packages using them ...
Feb 08 12:57:40 vapier	so just create virtuals as packages need them
Feb 08 12:58:00 vapier	whether it be virtuals or a tr1.eclass, it's going to be chunky
Feb 08 12:58:06 kingtaco|work	Flameeyes, the assumption is that more packages will use tr1 as time goes on
Feb 08 12:58:13 kingtaco|work	I'm not sure I buy it, but meh
Feb 08 12:58:18 kingtaco|work	I simply don't know
Feb 08 12:58:24 Flameeyes	kingtaco|work, and as time goes on, _if_ they are going to do it, we can change the solution
Feb 08 12:58:32 Flameeyes	it's not like we need to write it in stone once and forever
Feb 08 12:58:33 spb	they are going to
Feb 08 12:58:35 kingtaco|work	what's the solution now then?
Feb 08 12:58:38 spb	it's far too useful not to
Feb 08 12:58:40 Flameeyes	spb, you a time traveler?
Feb 08 12:58:57 kingtaco|pda	anyway
Feb 08 12:58:59 spb	Flameeyes: no; i just know that a lot of people writing C++ code have a vague degree of common sense
Feb 08 12:59:06 Flameeyes	there are a lot of things that are far too useful not to do, but still not many people do that
Feb 08 12:59:21 Flameeyes	spb, so? you can still not be sure of what happens
Feb 08 12:59:28 kingtaco|pda	ahm
Feb 08 12:59:56 kloeri	tr1 is definitely going to be used much more as it's (an upcoming) part of the standard library
Feb 08 12:59:59 Flameeyes	you can't _guarantee_ that anybody is going to use it more than now, at least not grow to a size that would make us good to go with virtuals
Feb 08 12:59:59 spb	i can make an educated guess with reasonable certainty
Feb 08 13:00:07 kloeri	it's not some random library we're talking about
Feb 08 13:00:19 kingtaco|pda	flame what do you propose as a immediate replacement for virtuals?
Feb 08 13:00:45 Flameeyes	kingtaco|pda, well, I would be for first assessing the number of packages that requires the virtuals
Feb 08 13:00:50 Flameeyes	and the number of required virtuals
Feb 08 13:00:54 kingtaco|pda	until more stuff starts using tr1
Feb 08 13:01:16 kingtaco|pda	assume the num doesnt justify virts
Feb 08 13:01:17 Flameeyes	if you get more virtuals, or a size of virtuals that is more or less the same of the packages, I would just use || ( ) rather than virtuals
Feb 08 13:01:21 *	djay-il|work (n=alex@bzq-88-152-191-182.red.bezeqint.net) has joined #gentoo-council
Feb 08 13:01:43 Flameeyes	[which with new-style virtuals is more or less equivalent, just requires peripheral maintainership rather than central]
Feb 08 13:01:55 Flameeyes	if the size justify the use of virtuals, go for it
Feb 08 13:02:01 Flameeyes	adding new-style virtuals has a cost on the tree
Feb 08 13:02:33 spb	if very few packages pick up on tr1 then virtuals have a slight disadvantage
Feb 08 13:02:46 spb	if lots of packages pick up on tr1 then not doing virtuals now has a big disadvantage
Feb 08 13:02:51 Flameeyes	right
Feb 08 13:02:56 spb	the latter is more likely than the former
Feb 08 13:03:07 spb	which brings it down to a question of expected effort, and virtuals win
Feb 08 13:03:14 Flameeyes	I wouldn't asses the likelyness on this, as it's quite debatable
Feb 08 13:03:24 kloeri	out of all the proposed solutions I still prefer the virtuals tbh
Feb 08 13:03:29 spb	ok, assume they're equally likely if you want
Feb 08 13:03:39 spb	the virtuals still win on expected effort
Feb 08 13:03:51 Flameeyes	not for 10 or 20 new virtuals, imho
Feb 08 13:04:06 spb	noone's asking you to create them
Feb 08 13:04:18 kingtaco|work	Flameeyes, working on your assumption that it's not useful, whats the disadvantage(other than a few more files in the tree) to using virtuals?
Feb 08 13:04:47 Flameeyes	spb, I beg you not to get it personal, the council's opinion was asked, I'm saying what I think
Feb 08 13:05:01 g2boojum	Flameeyes: If I may ask, why do you feel that it's debatable?  I'm finding it hard to believe that people won't use new libraries that will be in the C++ standard, but you may well know something I don't.
Feb 08 13:05:12 kingtaco|work	spb, and given that different arches will implement tr1 differently(boost vs gcc) how will virtuals help ?
Feb 08 13:05:32 spb	kingtaco|work: far far easier to put arch? ( ) deps in a virtual than in twelve packages
Feb 08 13:06:06 kingtaco|work	why not a eclass then?
Feb 08 13:06:17 spb	what would the eclass do?
Feb 08 13:06:20 Flameeyes	kingtaco|work, there's at least one bug with virtuals handling right now if you get naming collision, so I wouldn't abuse virtuals too much; the size of the tree is indeed also a concern to me, and more packages you got installed locally more time it takes to create the depgraph
Feb 08 13:06:40 kingtaco|work	the same thing as virtuals but with more control
Feb 08 13:06:51 kingtaco|work	you can add to DEPEND in an eclass
Feb 08 13:06:59 spb	ten virtuals will have zero noticeable impact on the size of the tree
Feb 08 13:07:02 kloeri	well, name collisions shouldn't be an issue as we already know about that
Feb 08 13:07:22 kloeri	just avoid silly name collisions
Feb 08 13:07:23 spb	the chances of someone creating a package named tr1-memory in another category are minimal
Feb 08 13:07:33 Flameeyes	ten virtuals without need every two weeks will kill us most likely
Feb 08 13:07:48 kingtaco|work	every 2 weeks?
Feb 08 13:07:50 kingtaco|work	explain
Feb 08 13:07:52 spb	ten virtuals once with good justification won't
Feb 08 13:07:53 kloeri	ehh, we're not talking about every two weeks at all
Feb 08 13:08:01 Flameeyes	kingtaco|work, just figurative
Feb 08 13:08:04 kingtaco|work	ok
Feb 08 13:08:05 kloeri	this is a fairly rare occasion
Feb 08 13:08:24 Flameeyes	spb, I still have to see the assessment for their justification, I'm not turning them down entirely from the start
Feb 08 13:08:34 spb	Flameeyes: i gave it above
Feb 08 13:08:35 kingtaco|work	Flameeyes, also, if a pkg deps on virtual/tr1-foo then where is the collision?
Feb 08 13:08:44 Flameeyes	I would just assess the number of required packages to be changed before
Feb 08 13:08:49 Flameeyes	kingtaco|work, binpkg generation
Feb 08 13:08:50 kingtaco|work	I'm not aware of this bug
Feb 08 13:08:53 kingtaco|work	ah
Feb 08 13:09:19 Flameeyes	spb, where? I don't see any number in my backlog?
Feb 08 13:09:28 spb	Flameeyes: expected effort
Feb 08 13:09:41 spb	the justification is probabilistic
Feb 08 13:10:01 Flameeyes	I don't really buy it myself, personal though
Feb 08 13:10:48 wolf31o2|mobile	how about we let democracy take over and just vote it out?
Feb 08 13:11:03 spb	i don't see a better option than virtuals
Feb 08 13:11:03 wolf31o2|mobile	(this meeting is kinda dragging on time-wise)
Feb 08 13:11:03 Flameeyes	note: you won't make me change idea repeating the same reasoning, like I'm not considering changing your ideas repeating my opinion
Feb 08 13:11:05 kingtaco|work	I think a TR1_USES="memory pointer"; inherit tr1 would be better than virtuals
Feb 08 13:11:16 Flameeyes	I said what I thought, and then we can vote
Feb 08 13:11:24 kingtaco|work	wolf31o2|mobile, da, I'll get there shortly
Feb 08 13:11:29 kingtaco|work	ok
Feb 08 13:11:32 spb	kingtaco|work: then you've turned a set of virtuals into a great big select-case statement
Feb 08 13:11:35 Flameeyes	kingtaco|work, uhm, there's a problem with useflags though
Feb 08 13:11:51 kingtaco|work	Flameeyes, ?
Feb 08 13:11:56 kingtaco|work	pick a different env var
Feb 08 13:12:07 kingtaco|work	or is there something else?
Feb 08 13:12:14 spb	kingtaco|work: what happens if a package only needs tr1::regex if a given useflag is set?
Feb 08 13:12:16 Flameeyes	kingtaco|work, I mean, if it needs memory or pointer _only_ if an useflag is enabled or disabled
Feb 08 13:12:25 Flameeyes	how would you handle that with variables before inherit?
Feb 08 13:12:31 kingtaco|work	spb, Flameeyes I get ya
Feb 08 13:12:36 Flameeyes	Maybe a bit better would be having inherit tr1
Feb 08 13:12:45 Flameeyes	and then set foo? ( ${TR1_MEMORY_DEPS} )
Feb 08 13:12:57 kingtaco|work	ohh, that looks promising
Feb 08 13:13:02 kingtaco|work	spb, thoughts?
Feb 08 13:13:06 spb	except that that's what virtuals were designed to do
Feb 08 13:13:13 spb	you've just reimplemented the same thing in a different place
Feb 08 13:13:27 kingtaco|work	with more control and less bugs
Feb 08 13:13:31 Flameeyes	spb, yes, that's what I said before too anyway, reimplementing through || () the same thing
Feb 08 13:13:32 spb	not really
Feb 08 13:13:38 Flameeyes	kingtaco|work, it has one problem anyway
Feb 08 13:13:54 spb	i don't see how it gives any more control
Feb 08 13:14:03 Flameeyes	_if_ the packages using tr1 will actually increase, it would become way less performant than new-style virtuals
Feb 08 13:14:25 spb	that is a point
Feb 08 13:14:35 spb	changing the eclass invalidates cache for everything using it
Feb 08 13:14:41 spb	changing a virtual invalidates one cache entry
Feb 08 13:14:46 kingtaco|work	ok, I guess we vote
Feb 08 13:14:50 wolf31o2|mobile	I dislike the eclass idea for one simple reason, we have to leave that crap in the tree forever
Feb 08 13:14:51 Flameeyes	that's why I think we should first get some figures at least on the current tree and maybe maintainer-wanted
Feb 08 13:14:57 spb	plus what wolf31o2|mobile said
Feb 08 13:15:12 spb	ok, Flameeyes votes to do nothing for now and look at numbers
Feb 08 13:15:28 Flameeyes	no.
Feb 08 13:15:33 Flameeyes	I vote to get the figures, and then decide
Feb 08 13:15:39 kingtaco|work	we have 3 possible solutions: 1) each ebuild does it all on it's own 2) a dozen virtuals 3) a eclass
Feb 08 13:15:41 spb	hence do nothing for now
Feb 08 13:15:51 kingtaco|work	or bump it to next month
Feb 08 13:15:57 spb	2
Feb 08 13:16:12 kloeri	my vote is on 2
Feb 08 13:16:17 kingtaco|work	I wouldn't mind bumping it to next month, seems we have more to discuss
Feb 08 13:16:40 wolf31o2|mobile	I'm voting 2... we can always remove virtuals easy enough later, where eclasses we can't
Feb 08 13:16:53 Flameeyes	spb, semantically different, "doing nothing" would also mean not getting the figures
Feb 08 13:16:57 vapier	i vote 2 and vote spb do the work
Feb 08 13:16:58 kloeri	wolf31o2|mobile: agreed
Feb 08 13:17:02 *	hparker has quit (Remote closed the connection)
Feb 08 13:18:02 kingtaco|work	gah, the eclass is so much more powerful, but the problems around the eclasses in general makes it not attractive
Feb 08 13:18:29 wolf31o2|mobile	right
Feb 08 13:18:53 Flameeyes	indeed
Feb 08 13:19:13 kingtaco|work	I reluctantly choose #2, but I think we should see if we can make eclasses suck less(maybe part of wolfs idea on small projects)
Feb 08 13:19:56 wolf31o2|mobile	speaking of... we didn't really get a lot of ideas for that... I'll have to query again and try to keep track of everything... seems things kinda got off-track on that
Feb 08 13:20:22 kingtaco|work	Flameeyes, wanna vote?
Feb 08 13:20:29 Flameeyes	kingtaco|work, I did my vote already
Feb 08 13:20:57 Flameeyes	wolf31o2|mobile, maybe you could use bugs.g.o to track the stuff, now that it is usable :)
Feb 08 13:21:16 kingtaco|work	ok, as I understand it Flameeyes wants to bump to next month so we can do more research
Feb 08 13:21:23 kingtaco|work	everyone vote yes/no please
Feb 08 13:21:32 spb	yes/no on bumping it?
Feb 08 13:21:35 kingtaco|work	da
Feb 08 13:21:38 wolf31o2|mobile	heh... yeah, that's possible... first, I think we need a good idea on what we should be doing
Feb 08 13:21:45 wolf31o2|mobile	ok
Feb 08 13:21:46 wolf31o2|mobile	no
Feb 08 13:21:49 spb	no point
Feb 08 13:22:08 kingtaco|work	kloeri, vapier ? (flameeyes I assume is "yes")
Feb 08 13:22:12 kloeri	no need to defer it imo
Feb 08 13:22:42 kloeri	if somebody comes up with a better solution we can always migrate to that instead of the virtuals
Feb 08 13:22:47 vapier	like the one legged man says, bump it
Feb 08 13:23:13 kingtaco|work	so 3 no, 2 yes
Feb 08 13:23:24 kingtaco|work	(I've yet to vote)
Feb 08 13:24:29 kingtaco|work	I'll vote bump too, but note that option #2 is likely to go into effect next month so that's the timeline
Feb 08 13:24:40 Flameeyes	robbat2 is still missing
Feb 08 13:24:45 kingtaco|work	we got a month to come up with something better
Feb 08 13:24:50 kingtaco|work	yes, he's a slacker today
Feb 08 13:25:04 Flameeyes	kingtaco|work, yeah nothing stops anyone into implementing it out of the tree and be ready to commit it
Feb 08 13:25:21 kingtaco|work	we all kosher?
Feb 08 13:25:25 wolf31o2|mobile	ok, I'll say we bump it, too so we don't end up deadlocked
Feb 08 13:25:25 wolf31o2|mobile	heh
Feb 08 13:25:29 wolf31o2|mobile	make it all official-like
Feb 08 13:25:33 kingtaco|work	hehe
Feb 08 13:25:42 *	spb shrugs
Feb 08 13:26:12 kingtaco|work	spb, would you start planning the implementation of virtuals please
Feb 08 13:26:13 kloeri	ok, so is Flameeyes going to come up with some numbers on packages using tr1?
Feb 08 13:26:18 spb	kingtaco|work: nothing much to plan
Feb 08 13:26:34 spb	it's all ready to be implemented
Feb 08 13:26:44 Flameeyes	kloeri, I would have no idea how to extract those numbers, as I don't know what tr1 consists of
Feb 08 13:26:55 spb	Flameeyes: anything in the std::tr1 namespace
Feb 08 13:27:03 kingtaco|work	spb, aight, can you post the list of virtuals and the lists of the packages that use them?
Feb 08 13:27:05 Flameeyes	spb, just that?
Feb 08 13:27:07 spb	anything using boost::shared_ptr
Feb 08 13:27:15 kingtaco|work	or flameeyes
Feb 08 13:27:23 kingtaco|work	if we're going to bump we should make use of it
Feb 08 13:27:26 spb	anything using hashed containers in C++
Feb 08 13:27:40 Flameeyes	although, there's no point in doing the redudant job, whoever is going to try changing to virtuals will also provide the numbers by indirection
Feb 08 13:27:45 kingtaco|work	spb, but how without looking at every source file can we tell what is using it?
Feb 08 13:28:09 kingtaco|work	I think tha'ts what flameeyes is hinting at
Feb 08 13:28:15 spb	kingtaco|work: by looking at upstream's stated deps
Feb 08 13:28:21 kingtaco|work	for every package?
Feb 08 13:28:37 kingtaco|work	we can't just grep for boost?
Feb 08 13:28:46 spb	same way as you'd figure out who's using python-2.4 features
Feb 08 13:29:03 kingtaco|work	for that I'd look at the deps in the ebuild
Feb 08 13:29:05 kloeri	tr1 isn't any different from other deps in that regard
Feb 08 13:29:06 kingtaco|work	scriptable
Feb 08 13:29:14 kingtaco|work	ok, lemme rephrase
Feb 08 13:29:16 kloeri	you have to look at every single package to determine the deps
Feb 08 13:29:28 kingtaco|work	what should we search for in the ebuild to determine if it's using some tr1 stuff?
Feb 08 13:30:32 kingtaco|pda	boost? gcc4?
Feb 08 13:30:44 kloeri	you can grep for std::tr1 and friends but it source might not always use the std:: qualifier
Feb 08 13:30:45 spb	the most likely indicator is a dep on || ( gcc-4.1 boost )
Feb 08 13:31:00 kingtaco|pda	ok
Feb 08 13:31:25 kingtaco|pda	who's doing that list?
Feb 08 13:31:43 spb	the list of packages doing it right at this moment is fairly meaningless
Feb 08 13:32:09 kingtaco|pda	not to some of us
Feb 08 13:32:27 kingtaco|pda	hence the bump
Feb 08 13:32:33 spb	someone to whom it has meaning can find the list then
Feb 08 13:32:49 spb	as far as i'm concerned it's sensible future proofing as much as anything else
Feb 08 13:33:11 spb	especially since i know that at least one package will continue to use more tr1 features as they become available
Feb 08 13:33:47 kingtaco|work	sure
Feb 08 13:33:50 kingtaco|work	we all know this
Feb 08 13:33:54 kingtaco|work	it's no secret
Feb 08 13:34:58 kingtaco|work	however, a dozen virtuals for only paludis makes no sense.  if we're going to do all the virtuals, it needs to be for all the packages that use tr1
Feb 08 13:35:09 spb	right
Feb 08 13:35:11 kingtaco|work	this is not perl
Feb 08 13:35:21 kingtaco|work	no 17 ways to do one thing :)
Feb 08 13:35:30 spb	so implement the virtuals and then as packages are seen to need them they get made to use them
Feb 08 13:36:01 kingtaco|work	right, and what people want to know is what currently will take advantage of it
Feb 08 13:36:33 *	g2boojum dashes; Thanks for the discussion, all.
Feb 08 13:36:59 kingtaco|work	not future intent
Feb 08 13:37:28 spb	so what you're saying is that there's no point implementing something that will be used in the future if it's not going to be used at the time it's written?
Feb 08 13:37:33 kingtaco|work	so someone raise their hand to figure it out
Feb 08 13:37:38 kingtaco|work	I'm not saying that at all
Feb 08 13:37:44 spb	looks that way
Feb 08 13:37:50 kingtaco|work	gah
Feb 08 13:39:22 spb	if it does turn out to be just two or three packages that need it then it'll only be one virtual we need
Feb 08 13:39:30 spb	which makes it little different from any of the other virtuals in tree
Feb 08 13:39:30 kingtaco|work	one last time, some people want to know what would currently take advantage of said virtuals
Feb 08 13:39:45 kingtaco|work	SOMEONE needs to provide a list
Feb 08 13:39:58 kingtaco|work	who is going to do it?
Feb 08 13:40:28 spb	http://www.google.com/codesearch?hl=en&q=+std::tr1+-gcc+-boost&sa=N is a start
Feb 08 13:40:58 Flameeyes	I would just look at the changes needed to implement virtuals, so if spb is going to show a patch to the tree with the changes needed (or even a cvs up list, if he's not going to blatantly cheat), those numbers suffice to me
Feb 08 13:41:00 kingtaco|work	ebuilds in the tree
Feb 08 13:41:26 kingtaco|work	cat/pkg one per line plain ASCII
Feb 08 13:42:08 kingtaco|work	anyway, this shit takes too much time, someone do it in the next 2 weeks, the topic will come up for vote next month
Feb 08 13:42:22 kingtaco|work	anyone else have any other topic before open floor?
Feb 08 13:42:30 Flameeyes	nothing here
Feb 08 13:42:37 wolf31o2|mobile	I have initial reply-to docs, but I need to fix them
Feb 08 13:43:06 *	avenj (n=avenj@gentoo/developer/avenj) has left #gentoo-council
Feb 08 13:43:13 kloeri	should we discuss the maintainer timeout thingy that drizzt and betelgeuse both suggested or is everybody happy with relying on common sense?
Feb 08 13:43:23 kingtaco|work	I prefer common sense
Feb 08 13:43:27 Flameeyes	common sense goes well for me
Feb 08 13:43:33 spb	common sense
Feb 08 13:43:35 Flameeyes	we discussed that on -core not many months ago too
Feb 08 13:43:57 kloeri	I have spf docs at http://dev.gentoo.org/~kloeri/spf.txt that needs to be guidexml'ified and possibly fixed/expanded upon
Feb 08 13:44:03 spb	tree devs have access to the whole tree for a reason
Feb 08 13:44:10 *	kloeri prefers common sense as well
Feb 08 13:44:12 wolf31o2|mobile	common sense
Feb 08 13:44:26 kingtaco|work	I'm sure vapier goes along with common sense
Feb 08 13:44:33 *	Flameeyes sets modes [#gentoo-council -vv Betelgeuse solar]
Feb 08 13:44:38 *	Flameeyes sets modes [#gentoo-council -v jeeves]
Feb 08 13:44:43 kloeri	nod
Feb 08 13:44:46 kingtaco|work	anything else?
Feb 08 13:44:50 *	Flameeyes sets modes [#gentoo-council -v g2boojum]
Feb 08 13:44:57 kloeri	nothing from me
Feb 08 13:45:16 kingtaco|work	ok, open floor time
Feb 08 13:45:19 *	kingtaco|work sets modes [#gentoo-council -m]
Feb 08 13:45:46 spb	http://www.google.com/codesearch?hl=en&lr=&q=boost%3A%3Ashared_ptr+gentoo.osuosl.org&btnG=Search <== sources in our distfiles mirrors using shared_ptr
Feb 08 13:46:00 vapier	nothing from wolf31o2 about reply-to ?
Feb 08 13:46:06 vapier	err nm i see that comment
Feb 08 13:46:12 kingtaco|work	vapier, he said he's got a doc (mostly) ready
Feb 08 13:46:18 *	Flameeyes hands glasses to vapier
Feb 08 13:46:19 vapier	"council managed projects" ?
Feb 08 13:46:27 wolf31o2|mobile	http://dev.gentoo.org/~wolf31o2/reply-to.xml
Feb 08 13:46:41 kingtaco|work	vapier, my suggestion to that is a group of people to fix up eclass suckage
Feb 08 13:46:58 wolf31o2|mobile	I spoke about that... I didn't really get anything that stood out... so I'm going to pose the question again and tally up the responses, then have us vote on one of them next time around
Feb 08 13:47:05 vapier	k
Feb 08 13:47:18 kingtaco|work	maybe define a "persistant" eclass spec, where the eclass would stay in the cache from compile time
Feb 08 13:47:41 agaffney	are you people still going?
Feb 08 13:47:44 kingtaco|work	so we can remove them from the tree
Feb 08 13:47:48 *	agaffney looks at the clock
Feb 08 13:47:49 kingtaco|work	agaffney, open floor atm
Feb 08 13:47:52 agaffney	ah
Feb 08 13:48:00 agaffney	I missed the meeting...anything "interesting"?
Feb 08 13:48:08 vapier	no
Feb 08 13:48:13 kingtaco|work	not really, a bunch on tr1
Feb 08 13:48:28 agaffney	yeah, I completely ignored that thread on -dev, so I have no idea what that even is :P
Feb 08 13:48:28 kingtaco|work	if noone does the logs I'll send them out when I get home
Feb 08 13:48:35 kingtaco|work	>>>>> OPEN FLOOR
Feb 08 13:48:53 agaffney	>>>>> VAPIER'S MOM
Feb 08 13:49:00 Jokey	another idea that came up more often recently. keywording involves touching the ebuild and thus results in refetch of the whole ebuild just for a change of 1-5 chars.. Proposal: signed separate keywords file per package, syntax like with package.keywords
Feb 08 13:49:09 vapier	someone forgot to commit the logs for 20070111
Feb 08 13:49:23 Flameeyes	Jokey, rsync should handle the changes
Feb 08 13:49:25 kingtaco|work	vapier, iirc that was robbat2, I'll try to get him on it
Feb 08 13:49:45 Jokey	Flameeyes: not talking about who handles it but the amount of useless traffic for it
Feb 08 13:49:48 kingtaco|work	Flameeyes, rsync works with blocks, I question if most ebuilds are larger than one block
Feb 08 13:50:09 vapier	err no, links in index.xml are bokren
Feb 08 13:50:11 vapier	i'll fix em
Feb 08 13:50:13 Jokey	Flameeyes: think of a kde stable keywording... how many ebuilds you refetch...
Feb 08 13:50:17 spb	separating keywords is far more effort than it's worth
Feb 08 13:50:31 Jokey	Flameeyes: and how often as we have more than one arch
Feb 08 13:50:31 spb	and i would question whether it's sensible at all
Feb 08 13:50:55 kingtaco|work	Jokey, the other side to that is it's another block rsync has to fetch
Feb 08 13:51:02 Flameeyes	Jokey, I mean that in theory it should refetch just the part that changed... of course as kingtaco|work said, it might be that it actually refetch all of it anyway
Feb 08 13:51:21 kingtaco|work	plus it takes more FS space
Feb 08 13:51:28 kingtaco|work	for most of the users anyway
Feb 08 13:51:54 Jokey	KingTaco: won't take more space
Feb 08 13:52:02 spb	it takes more FS space, you have to transfer the entire keywords file when it changes anyway, the transition would be completely horrible, it makes the package manager's job far harder, ....
Feb 08 13:52:14 spb	Jokey: "block size"
Feb 08 13:52:23 kingtaco|work	Jokey, how so?  not all of us use reiser with tail packing
Feb 08 13:52:25 spb	more files == more inodes and more space
Feb 08 13:52:27 kingtaco|work	I use ext3
Feb 08 13:52:27 kloeri	you also have additional problems with keeping the keyword file in sync with the ebuilds
Feb 08 13:52:36 Flameeyes	what kloeri said
Feb 08 13:52:51 *	Jokey also notes that we have --whole-file in default portage sync options
Feb 08 13:53:13 Flameeyes	right now you are sure that if you change a package and someone changed the keywords in the mean time you get a collision
Feb 08 13:53:38 Flameeyes	if you got keywords and ebuilds split, you cannot guarantee that if you try to change the dependencies, the keywords are fixed
Feb 08 13:54:33 kingtaco|pda	would require atomic commits
Feb 08 13:54:59 kingtaco|pda	which cvs doesnt directly do
Feb 08 13:55:04 Flameeyes	kingtaco|pda, no, won't help
Feb 08 13:55:34 Flameeyes	atomic commits would help only if you had the keywording file beside the ebuilds
Feb 08 13:55:42 Flameeyes	which would mean having to add _a lot_ of extra files
Feb 08 13:55:54 kingtaco|pda	da
Feb 08 13:55:59 Jokey	11063 atm
Feb 08 13:55:59 Flameeyes	[okay, less files than the current digests, but still a lot]
Feb 08 13:56:15 Flameeyes	Jokey, that's at least 11MB then
Feb 08 13:56:25 Jokey	considering that we are at 145k files already < 10%
Feb 08 13:56:35 Flameeyes	I would still like to avoid it
Feb 08 13:56:40 Flameeyes	would probably be slower on rsync anyway
Feb 08 13:56:51 Flameeyes	as it would still need to resync the keywording file every time
Feb 08 13:57:05 kloeri	I don't see the benefits at all and I think there's several cons to that idea
Feb 08 13:57:07 kingtaco|work	jokey, I guess none of us see the advantage
Feb 08 13:57:08 *	|mpagano| (n=kvirc@pool-70-105-167-163.nwrknj.fios.verizon.net) has joined #gentoo-council
Feb 08 13:57:09 Flameeyes	and rarely there are more than one ebuild changed per package during keywording
Feb 08 13:57:15 kingtaco|work	we'd swap transferring one file for another
Feb 08 13:57:25 Jokey	kingtaco|pda: seems so, have to live with it then
Feb 08 13:57:31 kingtaco|work	and add a whole other bunch of headaches
Feb 08 13:57:32 kloeri	a huge amount of additional files, risk of desynchronisation being the primary ones I guess
Feb 08 13:57:35 Jokey	KingTaco: you have too many aliases in here ;)
Feb 08 13:57:37 spb	ok, so everyone agrees it's a stupid idea?
Feb 08 13:57:40 kingtaco|work	but if there are advantages, please say them
Feb 08 13:57:58 kingtaco|work	we're not mind readers
Feb 08 13:58:06 Jokey	kingtaco|pda: a) transfer b) easier to "overlay" ebuilds for keywording on alt projects
Feb 08 13:58:19 kingtaco|work	transfer?
Feb 08 13:58:25 Flameeyes	I can't see any advantage in transfer
Feb 08 13:58:26 Jokey	file size
Feb 08 13:58:26 kingtaco|work	you're swapping one file for another
Feb 08 13:58:32 Flameeyes	you just change the file to tranfer
Feb 08 13:58:36 kingtaco|work	a packet is a packet
Feb 08 13:58:40 Jokey	err no
Feb 08 13:58:43 Flameeyes	Jokey, and file number to sync
Feb 08 13:58:50 Jokey	I transfer one file for 3 keyworded ebuilds
Feb 08 13:58:56 Jokey	(openldap)
Feb 08 13:59:02 kingtaco|work	so you want one file per pkg
Feb 08 13:59:07 kingtaco|work	for all the keywords
Feb 08 13:59:12 Flameeyes	Jokey, how often would you keyword more than one ebuild for package?
Feb 08 13:59:12 Jokey	being one file with about 2k instead of 3 files each 14k
Feb 08 13:59:15 spb	and when you roll out the change you have to transfer every ebuild and a keywords file for every package
Feb 08 13:59:18 kingtaco|work	all versions of that ebuild in one file
Feb 08 13:59:22 spb	which more than outweighs the saving you'll make
Feb 08 13:59:25 Jokey	Flameeyes: all slotted packages come to mind
Feb 08 13:59:32 Flameeyes	Jokey, how many there are?
Feb 08 13:59:46 kloeri	adding new versions and cleaning out old versions would be a lot more painful that way
Feb 08 13:59:48 Jokey	kde, gnome, ldap, mysql,.....
Feb 08 13:59:50 Flameeyes	and that would only work if you keyword them _at the same time_
Feb 08 14:00:03 ---	robbat2|na is now known as robbat2
Feb 08 14:00:05 robbat2	argh
Feb 08 14:00:05 Flameeyes	Jokey, you never keyword more than one kde slot per time
Feb 08 14:00:06 Jokey	kloeri: if repoman helps on that one
Feb 08 14:00:08 robbat2	overslept :-(
Feb 08 14:00:20 kingtaco|work	robbat2, :(
Feb 08 14:00:28 Flameeyes	robbat2, you didn't lose much
Feb 08 14:00:32 kingtaco|work	robbat2, btw, you need to upload the last meeting minutes
Feb 08 14:00:33 *	solar does not think you are a slacker
Feb 08 14:00:42 *	mpagano has quit (Client Quit)
Feb 08 14:01:08 Jokey	Flameeyes: would even more speak for it as you still only have to transfer the keyword file and not the ebuild and manifest over and over again
Feb 08 14:01:16 robbat2	kingtaco|work, huh, the previous ones should be up? I emailed them as well
Feb 08 14:01:23 Flameeyes	Jokey, you should transfer the manifest too
Feb 08 14:01:27 kingtaco|work	robbat2, vapier pointed it out
Feb 08 14:01:30 kloeri	Jokey: so now you need to cvs rm some ebuild and then run repoman fixmess before committing? :)
Feb 08 14:01:32 Flameeyes	and no it speaks against it
Feb 08 14:01:32 kingtaco|work	I haven't confirmed
Feb 08 14:01:48 Jokey	kloeri: you need to do that currently anyway
Feb 08 14:01:53 Jokey	for redigesting
Feb 08 14:01:57 Jokey	so no difference
Feb 08 14:02:01 vapier	robbat2: the link was broken, i fixed it
Feb 08 14:02:02 Flameeyes	Jokey, repoman commit regenerates manifest, if you didn't know
Feb 08 14:02:08 vapier	it had two 1's instead of three
Feb 08 14:02:10 Jokey	Flameeyes: I know
Feb 08 14:02:19 Flameeyes	then you shouldn't run repoman fix during removal of old ebuilds
Feb 08 14:02:26 kloeri	no, keeping keywords and ebuilds in sync and managing digests is different problems
Feb 08 14:03:01 *	kingtaco|pda has quit (Read error: 104 (Connection reset by peer))
Feb 08 14:03:24 Jokey	well really, I personally don't care as of today I'm on 100 mbit natively at home... but sanchan f.ex is on 56k and he does care about every single byte to transfer as he has to pay for it
Feb 08 14:04:17 Flameeyes	I think that adding more files is just making the situation worse, as we said you end up swapping one file sent to another
Feb 08 14:04:39 Flameeyes	plus two files when you're adding a new ebuild
Feb 08 14:04:40 kingtaco|work	not to sound crass, but I dont think adding this sort of complexity to maybe save a couple bytes is worth it
Feb 08 14:04:52 Flameeyes	I'd consider more sensible to move toward Manifest2 asap
Feb 08 14:04:58 kingtaco|work	indeed
Feb 08 14:05:06 Flameeyes	[and I'm still committing]
Feb 08 14:05:39 Flameeyes	or maybe someone should see what happens for who are under limited network environments to disable --whole-file
Feb 08 14:05:40 Jokey	can't recall it atm, does manifest2 force gpg signed files?
Feb 08 14:05:55 Flameeyes	Jokey, Manifest2 will remove the digest-* files
Feb 08 14:05:58 kloeri	no
Feb 08 14:06:19 kloeri	manifest signing and manifest 2 are separate issues
Feb 08 14:06:29 kingtaco|work	ohh
Feb 08 14:06:31 Jokey	does manifest signing have a glep?
Feb 08 14:06:34 kingtaco|work	a topic for next month
Feb 08 14:06:41 kloeri	not yet
Feb 08 14:06:41 kingtaco|work	manifest signing
Feb 08 14:06:49 Jokey	k'
Feb 08 14:06:51 kloeri	robbat2 needs to finish his tree signing stuff
Feb 08 14:06:52 robbat2	if I finish the stuff on it before then
Feb 08 14:07:08 kingtaco|work	last I heard people didn't want to do it because of lack of gpg-agent
Feb 08 14:07:13 kingtaco|work	but that's no longer the case
Feb 08 14:07:27 kloeri	looked fairly good the stuff I saw a few weeks ago though
Feb 08 14:07:27 Jokey	gpg-agent/keychain ++
Feb 08 14:07:36 Flameeyes	fwiw, zmedico also told me how to increase the timeout of gpg-agent, making its use even more practical
Feb 08 14:07:41 kingtaco|work	I'm using gpg-agent with my own "keychain"
Feb 08 14:07:52 Flameeyes	[not that I wasn't using signing before too]
Feb 08 14:08:15 kingtaco|work	ok, a topic for next month then
Feb 08 14:08:20 kingtaco|work	anything else?
Feb 08 14:08:57 kingtaco|work	speak now or wait 28 days ...
Feb 08 14:09:01 Flameeyes	a second
Feb 08 14:09:12 Flameeyes	I would like to get rid of the glep about the 4-tuple keywords
Feb 08 14:09:23 Flameeyes	that's glep22
Feb 08 14:09:29 Flameeyes	[had to look up the number]
Feb 08 14:10:40 Flameeyes	last council asked for a new glep to obsolete it, but considering that it has been difficult to address this through a replacement glep (that glep was _never_ put in action as it is written), and that the current status of the tree is already good enough, it might be worth just retire that glep
Feb 08 14:10:48 kingtaco|work	Flameeyes, I don't think anyone has implemented it
Feb 08 14:10:54 kingtaco|work	but lets vote on it next month
Feb 08 14:10:57 Flameeyes	agreed
Feb 08 14:11:02 kloeri	that will have to wait for next month
Feb 08 14:11:11 kloeri	we need a little time to consider it I guess
Feb 08 14:11:13 Flameeyes	kloeri, yes, just saying that I want to bring up that topic :)
Feb 08 14:11:21 Flameeyes	for next month, that is
Feb 08 14:11:21 kloeri	nod
Feb 08 14:11:23 kingtaco|work	ok
Feb 08 14:11:26 kingtaco|work	anything else?
Feb 08 14:11:29 kingtaco|work	3
Feb 08 14:11:32 kingtaco|work	2
Feb 08 14:11:35 kingtaco|work	1
Feb 08 14:11:35 kloeri	we'll probably be happy to dump it though :)
Feb 08 14:11:44 kingtaco|work	>>>>>END MEETING