[21:52:12] Hello [21:52:57] Hey [21:58:45] wired: so you'll run this meeting, right? [21:58:49] yeah [21:59:00] in roughly one minute [21:59:01] :p [21:59:04] wired: if you need I have logs [21:59:05] *** Joins: Betelgeuse (~betelgeus@gentoo/developer/Betelgeuse) [21:59:19] jmbsvicetto: thanks, I log too [21:59:53] jmbsvicetto: i've switched the wave to summary mode (and created a stupid copy as well that i trashed :p) [22:00:00] e'yo. [22:00:07] * ferringb has a meeting at 1pm on a sidenote [22:00:13] aka, hour from now [22:00:21] and its time :) [22:00:22] * scarabeus here [22:00:28] yes [22:00:37] * scarabeus can use only one hand, so he will be really quiet man today :] [22:00:49] here [22:00:52] *** Joins: NeddySeagoon (~NeddySeag@gentoo/developer/NeddySeagoon) [22:01:30] lets wait the standard 5m for halcy0n and chainsaw [22:01:43] agenda: http://archives.gentoo.org/gentoo-council/msg_620cb09e78b4e7d9997c45eb204f7fd7.xml [22:02:42] *** wired changes topic to 'congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting now - agenda: "save" => Array(20100726 19:00.00 UTC - http://dev.gentoo.org/~wired/localtime.php?time=1900 || following 20100809 19:00.00 UTC' [22:02:46] "type" => 9, [22:02:49] "reset" => true [22:02:51] ) [22:02:54] bah [22:02:58] interesting :D [22:03:24] *** wired changes topic to 'congrats to the new council. ferringb, halcy0n, jmbsvicetto, chainsaw, betelgeuse, scarabeus, wired || meeting now - agenda: http://bit.ly/dmARrD || following 20100809 19:00.00 UTC' [22:03:25] anyone got the wave for this time around? [22:03:35] ferringb: sure, want an invite? [22:03:44] its the old agenda one [22:03:45] might as well try the new hawtness [22:03:59] * ferringb only has the summary [22:04:01] ferringb: which mail should i invite? [22:04:06] @gmail [22:04:15] @gentoo just fwds to that account [22:04:23] done [22:04:38] * ferringb only uses @gentoo when needing to sound official while being a pompous ass, rest of the time he just uses @gmail when being a pompous ass [22:04:39] ah your gentoo was already invited :p [22:04:53] wired: if you're using the same, I sent an invite to ferringb [22:05:07] jmbsvicetto: we sent to both mails hehe [22:05:16] is five of you a quorum ? [22:06:15] it should be fine. not optimal, but oh well [22:06:48] NeddySeagoon: iirc, the quorum is 50% + 1 [22:06:50] well we should be, more than 50% of us is around [22:06:54] so... [22:06:58] shall we begin? [22:07:06] yy [22:07:20] jmbsvicetto, tha depends on the rules. if its not in glep-39, its whatever you want [22:07:35] wired: let's go [22:07:43] lets begin with --as-needed [22:07:55] * add --as-needed to default profile's LDFLAGS [22:08:13] NeddySeagoon: GLEP 39: Council decisions are by majority vote of those who show up (or their proxies). [22:08:36] NeddySeagoon: ok, I see two rules: [22:08:37] Council decisions are by majority vote of those who show up (or their proxies). [22:08:40] And at least 50& must be here. [22:08:46] f any meeting has less than 50% attendance by council members, a new election for all places must be held within a month. The 'one year' is then reset from that point. [22:08:47] and if less 50% is around then we are all scrapped [22:08:53] so > 50% [22:08:55] so we are fine [22:09:05] * ferringb notes we might want to look at a different day of the week down the line btw... can take that discussion offline, but monday at noon is proving to be murder for myself (suspect I'm not the only usian hit b that) [22:09:10] Betelgeuse: sorry for repeating you [22:09:13] *by. that said... lets get the show on the road. ;) [22:09:20] ferringb: we can talk about that later [22:09:35] ferringb: I am waiting to get to bed :) [22:09:50] lets begin by voting on adding --as-needed to default profile [22:10:00] * scarabeus says aye captain' [22:10:04] yay to getting to voting, and yay for --as-needed in default profile. [22:10:09] which means, yes for as-needed [22:10:10] I vote yes :) [22:10:48] Betelgeuse / jmbsvicetto ? [22:11:05] wired: let's go [22:11:29] I vote yes for adding --as-needed in default profile [22:11:41] Want me to implent it right now? :) [22:11:44] I don't have anything against adding it. I didn't check if anyone ever did sanity checks with it. [22:11:53] Betelgeuse: we in qa do them :] [22:11:55] Betelgeuse: a lot of people did [22:12:05] Betelgeuse: well mostly ssuominen ;] [22:12:15] ok [22:12:20] its approved [22:12:24] ssuominen: go ahead :) [22:12:44] next item [22:12:48] Should we write a GLEP 42 news item? [22:13:04] yes [22:13:12] Betelgeuse: To match what? ;) [22:13:12] Betelgeuse: good idea [22:13:22] but what should trgger it :] [22:13:27] scarabeus: everything [22:13:28] everything [22:13:29] or everyone [22:13:36] Betelgeuse: I'd say an annoucement through the usual ways, would work [22:13:38] but quite few people have asneeded already [22:13:51] scarabeus: I have [22:13:56] scarabeus: it's not a big burden to read it. [22:14:03] scarabeus: or just skip based on the name [22:14:14] i am not against it [22:14:41] I propose the news item should be approved and in circulation before profiles are changed. [22:14:41] but it can go even after it is enabled in portage, because it does not change anything for the user pov in first time until he does -e :] [22:14:59] Mainly to ensure it gets done. [22:15:09] oh that is good reason [22:15:21] who wants to prepare the news item? [22:15:28] ok sounds sane, its 72 hours right? [22:15:46] ssuominen: i think we will manage to write up something, rite? [22:16:15] he he :D [22:16:23] ok scarabeus it is [22:16:25] scarabeus: yes [22:16:32] i'll help too [22:16:47] you guys really dont track commits huh? :] [22:17:09] ssuominen was too quick [22:17:16] hu... [22:17:18] he got approval [22:17:25] lol [22:17:26] anyway lets implement the message then [22:17:27] I hit commit about when wired said go for it :) [22:17:28] and just add it [22:17:31] thats fine, we'll write the message today [22:17:34] so its cool [22:17:51] so lets move for next topic, i will ensure this will happen ok :] [22:17:54] great [22:18:08] * required-use: http://dev.gentoo.org/~ferringb/required-use.html [22:19:03] ferringb: few already implemented the code for portage, right? [22:19:07] yep [22:19:16] reasonably quick for me to do in pkgcore [22:19:28] dleverton_: Has anyone worked on it for paludis? [22:19:30] paludis should have rough machinery for this already via exheres MYOPTIONS [22:19:37] * scarabeus likes the idea [22:19:44] it loosk good [22:19:49] and will solve many current problems [22:19:50] jmbsvicetto: don't think so [22:19:53] I like the idea [22:19:55] We would approve final EAPI 4 text any way before it goes official. [22:20:02] so I guess we are voting on the idea any way. [22:20:08] pretty much. [22:20:11] Betelgeuse: yeah [22:20:22] ok, +1 from me on using it [22:20:23] note between now and eapi 4 final, if someone has a better name... might be worth considering. [22:20:29] that caveat stated, +1 from me obviously. [22:20:30] ferringb: yes [22:20:44] +1 [22:21:02] ferringb: also the exact cache slot is not there yet but not a problem [22:21:03] yes [22:21:13] or +1 [22:21:29] great [22:21:48] anyone want to say something else on this before we move on? [22:22:05] * ferringb cracks the whip; got 40 minutes left before I'm locked in a meeting ;) [22:22:11] moving on then [22:22:21] eclass removal policy [22:22:31] currently devs have to wait for 2 years before removing an eclass [22:22:57] this is not needed anymore since portage-2.1.4.4 [22:23:30] for eclass added after 2.1.4.4 got stable they can be purged [22:23:40] i think a 30day lastrite would be enough [22:23:45] for old eclasses i would keep the way [22:23:56] it does not hurt us to have empty files there [22:24:01] wired: 60 is my vote, although this number should be worked out w/ overlay consumers... [22:24:16] I would vote on a devmanual patch. [22:24:22] scarabeus: there is no reason to do that offhand [22:24:28] That's been discussed on gentoo-dev. [22:24:37] scarabeus: the env saving/restoration machinery works from the stored env dump, regardless of which version of PM that generated it [22:24:57] ferringb: and old portage did store the env dump? [22:25:01] ferringb: that i didnt know :] [22:25:05] scarabeus: always has [22:25:10] that's what environment.bz2 is [22:25:27] i know what file it was, i just thought it wasnt stored before [22:25:39] Betelgeuse: +1 on the devmanual patch, this needs to be documented [22:25:40] in that case it can be nuked and prepared as devmanual patch and discussed on -dev [22:26:27] +1 from me, although I'd rather the council not set the time frame instead leaving it to QA to find the best value [22:26:47] ferringb: agreed, 30/60 days are just recommendations [22:27:13] who'll take care of the devmanual patch? [22:27:21] I think they should be an enforced minimum. [22:27:24] +1 for me with the devmanual patch [22:27:30] Or we will always have people who find it oke to nuke without delay. [22:27:45] Betelgeuse: i meant recommendations for the QA team [22:28:09] wired: sure [22:28:49] so QA will write the patch? [22:28:56] since they have to decide on the timeframe [22:28:56] wired: we can [22:29:13] [22:29:21] ok [22:29:46] so, next point? [22:29:49] 1sec [22:29:51] (summary) [22:29:59] eclass api change policy [22:30:23] ok [22:30:29] *** Quits: Cardoe (~Cardoe@gentoo/developer/Cardoe) (Remote host closed the connection) [22:30:35] I don't think we need to create one [22:30:44] * ferringb notes that this particular point is trying to legislate common sense in effect [22:31:13] jmbsvicetto: Ass in don't allow it? [22:31:29] i don't see why we should prevent eclass api changes [22:31:33] no, as in let it at the discretion of the developers [22:31:43] as long as the teams ensure the tree doesn't break [22:31:47] I'd frankly punt it back to dev/QA and vote on specific requirements, rather than an open ended question like this. thus a -1 from me in the current form. [22:32:03] jmbsvicetto: If we decide to not care about overlays. [22:32:08] and they update everyone else, we are not needed [22:32:48] Betelgeuse: I think we should care about overlays [22:33:23] Betelgeuse: My only "requirement" is that any major changes are announced with some advanced warning [22:33:37] i think the api should not be changed the much like python does for example [22:33:47] it is better to roll out new eclass with additional stuff/functions [22:33:48] Betelgeuse: so that maintainers of overlays get a warning before the change is implemented [22:33:50] and then migrate the things [22:34:08] i just dont like packages in stable imploding to my face [22:34:13] any way devmanual patch again [22:34:37] Betelgeuse: but instead of having a new policy just for this, I think we can address abuses here with the regular policies from QA and devrel [22:35:01] DevRel should not deal with this. [22:35:10] Unless it has to do with bans. [22:35:11] we may just make it mandatory the warning email [22:35:28] let's move on if we want to handle more points [22:35:39] We can come back to the discussion if there's time left. [22:35:41] This is mostly QA, until it become a repetitive and abusive behaviour of a developer [22:35:52] we're doing good [22:35:58] Betelgeuse: let's move the discussion back to the mls [22:36:20] scarabeus: agree: re: python, although that's realistically QA's role to crack the whip [22:36:57] wired: next point? [22:36:58] how about we don't enforce any policy, but allow QA to restrain teams when they go... too far? [22:37:30] Don't like letting systems break and then picking up the peaces. [22:37:51] wired: such a policy is already in place [22:38:08] win 23 [22:38:11] QA can already deal with developers that break the tree [22:38:11] merde. :) [22:38:22] jmbsvicetto: but is it enforced? [22:38:40] i would say we look pretty undecided, so go for not-decided this time [22:38:43] QA has expressed a desire to enforce such policy [22:38:56] i will try to sent some mailies [22:38:57] ok this is not going anywhere, so lets put it back to the MLs [22:39:09] agreed. [22:39:12] moving on: [22:39:19] - use of invalid DEPEND atom "EAPI_TOO_OLD" instead of calling die in global scope on eclasses [22:39:23] *** Joins: nirbheek (~nirbheek@gentoo/developer/nirbheek) [22:39:30] * ferringb twitches [22:39:39] ferringb: go ahead :p [22:39:41] +1 on die, -infinity on EAPI_TOO_OLD [22:39:41] dleverton_: Does ciaranm recall any reason for using it? [22:39:54] that die works better [22:39:58] from ebuild writter [22:40:02] die will not stop anything [22:40:04] if he uses repoman it gets caught [22:40:08] EAPI_TOO_OLD does [22:40:17] at least used to be that way [22:40:18] I like the idea of the depend [22:40:18] with depend it gets broken in emerge [22:40:28] i showed you guys the test [22:40:30] Betelgeuse: die will stop it from being used (and/or cached) in at least 2 out of the 3 managers [22:40:31] with depend it dies on emerge [22:40:34] I wouldn't mind using a propper dep, though [22:40:38] with die it dies on creating manifest [22:40:51] ferringb: I remember Portage allowing emerge to continue [22:40:54] up until a recent paludis merge, it would also make paludis go rather cranky too during metadata [22:40:56] ferringb: Might have changed since [22:41:11] so first you catch if you emerge the thing, second cant be manifested and commited [22:41:15] + we have --nodeps [22:41:16] virtual/invalid or something similar [22:41:22] Betelgeuse: equivalent to EAPI masking; it will roll past it but not use it last I'd tried it. [22:41:36] then yell that somethings went boom while it was trying to do it's thing. [22:41:37] which technically should allow emerging stuff with forbidden eapi [22:42:14] If we go the die route I would like to see a PMS patch specifying what it does in global scope. [22:42:16] 20:41 < ciaranm> die in global scope used to be considered utterly illegal [22:42:19] 20:41 < ciaranm> unfortunately it got left out of pms by accident, along with the ban on global scope output... [22:42:29] * ferringb notes that's opinion, not fact [22:42:38] die'ing at the repoman level sounds much better, this is something that should be caught by the dev [22:42:57] dleverton_: My understanding was that was the reason we moved from the die to the depend [22:43:24] jmbsvicetto: i never seen reason with portage implementation [22:43:26] about repoman, why? [22:43:44] basically... die can be very ugly, but it blocks any potential invalid usages. The con of such protection is that it reinforces that devs need to do checking of consuming ebuilds when doing changes of this sort (which quite frankly they should be double checking anyways) [22:44:51] the flaws with depend level is that the rest of the metadata is treated as valid, including the cache validation that goes with it [22:44:59] ferringb: Were do we expect the issue with the old EAPI showing up? I assume it's with the overlays [22:45:30] and probably a reasonable number of them don't run repoman [22:45:39] jmbsvicetto: we speak about manifest [22:45:44] repoman manifest does not work [22:45:48] if it has the die [22:45:54] the must create manifests :D [22:45:55] yes, but does it also fail on emerge manifest ? [22:46:04] emerge digest* [22:46:05] grr. crappy connection. [22:46:25] jmbsvicetto: rephrase the question please [22:46:28] scarabeus: Are you sure people are using repoman manifest? [22:46:41] perhaps they're using ebuild digest [22:46:53] http://paste.pocoo.org/show/241953/ [22:47:03] scarab@ugly-elf: ~/gentoo-x86/kde-base/ark $ ebuild ark-4.4.5.ebuild manifest [22:47:09] repoman and ebuild do the same [22:47:10] it bails out [22:47:21] nothing else is really supported for creating manifests [22:47:23] so tadada [22:47:28] scarabeus: ok [22:47:46] Do we want to vote on this? [22:47:48] so, shall we vote on this? [22:47:56] frankly, even if current tools didn't quite get it perfect... this is the route that should be taken, since injecting special values into DEPEND like that screws up the cache validation logic pretty heavily (and isn't friendly towards existing cache validation bits) [22:48:03] +1 on die as said, -infinity on depend. [22:48:15] i would like to go with die [22:48:19] im with die as well [22:48:20] cleaner [22:48:43] ok 4 for vote, so lets vote [22:48:46] aye by me [22:49:04] I would like it written down what die does in global scope. [22:49:32] I can live with both, although I don't like the concept of dieing on eclasses [22:49:59] I'd prefer us to find a way to "raise an exception" [22:50:08] jmbsvicetto: die is "raise an exception" [22:50:22] if you want literal raise/try/catch semantics... well. you patch bash :P [22:50:23] I see it more as an call to exit [22:50:35] the manager supplies die [22:50:41] it's up to the manager what to do in that case [22:50:50] ferringb: The depend to me sounded a "softer approach" [22:50:51] dieing for this specific issue seems ok to me - not saying we should allow general die'ing in eclasses [22:51:12] so its over 10 minutes [22:51:17] on this topic [22:51:21] jmbsvicetto: the problem is that if the eclass cannot work with that eapi, the metadata it generates during that mismatch just isn't usable, period. [22:51:37] I agree with Betelgeuse that we should clear the consequences of the call to die on global scope [22:51:41] *** Joins: ABCD (~abcd@gentoo/developer/abcd) [22:52:02] fine by me. I'd prefer it's usage be heavily limited to instances such as this also [22:52:08] ferringb: it's the manager tha generates the metadata, not the eclass [22:52:19] jmbsvicetto: both. eclass sets the raw values [22:52:34] ok, I'll defer to you on this subject [22:52:36] jmbsvicetto: manager just grabs those values and records them (not arguable, recall I've written this sort of code twice now :P) [22:53:05] can we vote on this and move on? or do you want to look into it more? [22:53:30] * ferringb listens to the crickets [22:54:03] wired: If you count the votes you already got a majority. [22:54:12] But I don't know if ferringb changed since then. [22:54:34] lets clear this out then. who's in favor of die'ing? [22:54:39] yes [22:54:44] documentation first [22:55:22] I'll accept with propper documentation [22:55:33] +it [22:55:40] *** Joins: billie80 (~billie@gentoo/developer/billie) [22:56:12] Betelgeuse: "changed since then" ? [22:56:15] * wired is favor [22:56:31] so patch to pms it is :] [22:56:33] ferringb: I mean is it a yes without documentation [22:56:47] *** Quits: billie (~billie@gentoo/developer/billie) (Read error: Operation timed out) [22:57:25] ok, passed then, 3 to 2. [22:57:42] * ferringb stretches [22:57:47] sorry, meeting time. [22:57:53] Do we require the documentation or not? [22:57:55] will see if I can do both, but no gurantees [22:58:01] ferringb: we're almost done [22:58:01] devmanual should be updated for this [22:58:13] so 3 for documentation and 2 without [22:58:14] wired: its still over 50% :] [22:58:15] ok, then we have 4 votes for documentation? [22:58:23] jmbsvicetto: we do need documentation [22:59:01] * ferringb will do the devmanul patch if no one else does [22:59:05] ferringb: great, thanks [22:59:09] sorry, have to bail. they pay my bills and such ;) [22:59:20] hehe, ok [22:59:21] see you later [22:59:23] cya [22:59:23] ferringb: thanks, c ya [22:59:27] PMS too if we wan't consistency. [22:59:28] may be back in about a bit, but we'll see [22:59:45] next point [22:59:47] mailing lists [22:59:48] wired: We can try seeing if we get a majority on the rest of the points without ferringb [22:59:59] Betelgeuse: yeah [23:00:05] we only have mailing lists left anyway [23:00:21] the cross posting is evil :] [23:00:23] so [23:00:25] first of all [23:00:34] petteri suggested punting -council [23:00:46] i personally think it has its place, so I don't agree :) [23:00:55] I'd like to have it around [23:01:16] and would like council topics being discussed there to make it easier to find previous discussions [23:01:38] How do you know what is a council topic? [23:01:54] Before being brought for council they should be discussed generically. [23:02:01] jmbsvicetto: So you are in fact making it hard to find stuff. [23:02:21] I agree issues should be discussed before being brought to the council [23:02:32] *** Quits: Zorry (~zorry@gentoo/developer/zorry) (Read error: Connection reset by peer) [23:02:33] Betelgeuse: council agendas and discussion on the agendas fit in -council. issues themselves should have their own -dev threads [23:02:40] i would be ok with having it on -project [23:02:49] I meant the agenda emails and any discussions about topics in an agenda [23:02:52] what for we need quiet list [23:03:26] If we want to avoid fragmentation we should only discuss the contents of the agenda not the issues themselves. [23:03:40] Both -project and -council are low traffic. [23:03:48] I don't see why we want to fragment like that. [23:04:11] Betelgeuse: is that bad? having seperate lists makes them easier to filter [23:04:38] i tend to agree with peteri [23:04:46] having stuff on one place is quite convinient [23:05:10] hmm, 2 vs 2 ? [23:05:14] I don't value being able to easily filter council agendas (the only frequent traffic to -council) over less lists. [23:05:21] so scarabeus you think we should move -council to -project? or to -dev? [23:05:32] just project [23:05:49] That also makes it clearer not to discuss technical issues. [23:06:02] *** Joins: Zorry (~zorry@gentoo/developer/zorry) [23:06:55] hmm [23:07:28] what about crossposting to -dev (that was requested by a few devs?) [23:08:05] wired: Betelgeuse already mailed project about that and opened a bug to infra to add a note forbidding it [23:08:05] wired: http://archives.gentoo.org/gentoo-project/msg_4584599e3f2a5e8ebc590ae3c623e7eb.xml [23:08:28] will be announced on gentoo-dev once we get documentation in place [23:08:41] ok [23:09:07] Do you think we can reach any decision here? [23:09:25] We can put it on the table again next time if we still have 2-2 [23:09:27] I don't think so, so would suggest sending this back to the mls again [23:10:16] *** Joins: c1pher|home (~smitdane@resnet75-219.resnet.buffalo.edu) [23:10:22] I can see all threads on gentoo-council at once on my screen now btw [23:10:29] from 2010 [23:10:49] I just noticed there are 3 bugs assigned to council [23:11:01] give the area a little more space and it extends over a year [23:12:20] shall we move this back to the mls and quickly go over the open bugs? [23:12:22] lets move the ml talk to ml [23:12:25] yeah [23:12:35] ok, 3 bugs: [23:12:37] bug 234706 [23:12:39] jmbsvicetto: https://bugs.gentoo.org/234706 "Slacker arches"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:council@g.o [23:12:52] bug 256451 [23:12:54] jmbsvicetto: https://bugs.gentoo.org/256451 "Council meeting notes appear to be missing"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o [23:13:02] bug 256453 [23:13:04] wired: https://bugs.gentoo.org/256453 "Documentation on Gentoo Council meeting processes, particularly regarding agenda items"; Doc Other, Other; NEW; gentoo-bugs@allenjb.me.uk:council@g.o [23:13:30] i see one more [23:13:37] bug 234713 [23:13:38] I suggest we ask Halcy0n if we wants to resume work on the first bug [23:13:39] scarabeus: https://bugs.gentoo.org/234713 "GLEP 55: Use EAPI-suffixed ebuilds (.ebuild-EAPI)"; Gentoo Linux, Unspecified; RESO, LATE; dberkholz@g.o:council@g.o [23:13:47] but it should just be remarked proprely i guess :] [23:14:33] about 2nd bug, we can ask ferringb if still wants to do it [23:14:49] i can take 256453 [23:15:07] ok [23:15:18] that was fast [23:15:41] we should reassign bug 237381 back to us and I propose to take care of it [23:15:43] jmbsvicetto: https://bugs.gentoo.org/237381 "Document appeals process"; Gentoo Linux, Unspecified; NEW; dberkholz@g.o:dberkholz@g.o [23:15:54] great [23:15:58] * wired updates summary [23:16:20] For the record, the complete list of bugs we need to check is https://bugs.gentoo.org/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=&long_desc_type=substring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emailassigned_to1=1&emailcc1=1&emailtype1 [23:16:40] jmbsvicetto: i also check for resolved later status ;] [23:16:54] also i think maybe mark will be interested in 234706 :] [23:16:54] scarabeus: yeah, let me check those as well [23:16:58] i certainly am [23:17:09] because we nowdays again see quite few archies lacking manpower [23:17:59] So, anything else? [23:18:17] I'm a bit tired and would like to get some dinner [23:18:17] jmbsvicetto: your link gives 5000 bugs? [23:18:25] it got stripped :P [23:18:29] wired: [23:18:32] explains it [23:18:39] ok [23:18:52]