highvoltagegood morning13:10
highvoltagewendar: so all new apps that are submitted now are assumed to be for precise, right?13:10
dholbachI'd appreciate if you all could have a look at https://wiki.ubuntu.com/OptRequirement and tell me what you think :)13:18
dholbachajmitch, dpm, highvoltage, lfaraone, mhall119, stgraber, wendar: ^ :)13:21
mhall119dholbach: regarding the FHS, IMHO the fact that *we* are shipping the packages makes them less "third party"13:27
highvoltagedholbach: I've always been a big supporter of the "dev release + backports" idea, I think that's preferred to "Expiring apps".13:27
mhall119highvoltage: the problem with that is you have to work with the dev release13:27
mhall119so in order to get a Unity 4 lens into Oneiric, it would have to work on Unity 5 in Precise first, which isn't backwards compatible13:28
highvoltagemhall119: the problem with not doing that is that you to do the work with the dev release when it becomes stable anyway13:28
highvoltage(and the next one, and the next one, and the next one)13:28
mhall119thats not really so much a "problem" as it is an annoyance13:29
highvoltagemhall119: yes, where compatibility becomes problematic, it would certainly be an exception. I think there's more than one right way to approach it, and using a combination of things might be the best way13:29
highvoltagemhall119: it's a problem when it takes up time that could be better used otherwise.13:29
mhall119that's up to the app developer to decide how to best spend their time13:29
highvoltageah ok. Well if we could just blame everything on the app developers then we have absolutely no problems currently.13:30
highvoltage(sorry I'm still waking up... coffee time)13:30
mhall119I'm not blaming, I saying we shouldn't try and enforce optimal time-management skills on developers13:31
* highvoltage isn't saying that either13:31
mhall119what we should be doing is reducing the barrier to getting apps in13:31
highvoltageI'm saying that if we can get it into the archives and backport it, then we should.13:31
dholbachmhall119, I mentioned the lens example indirectly13:31
mhall119and, IMO, targetting a development release in order to deploy to a stable release is an unnecessary barrier13:32
highvoltagemhall119: in some ways it would reduce the barrier, because doing it otherwise just won't scale13:32
mhall119it would reduce future barriers, yes, but by increasing the initial ones13:33
highvoltagemhall119: re-reviewing hundreds of apps (or even thousands) will be a huge amount of work compared to doing it properly once13:33
dholbachmhall119, I wasn't suggesting that we tell app developers to target the dev release - but it'd be just implemented that way13:33
dholbachmhall119, so the ARB would do a test-build, etc13:33
mhall119and if it didn't build on the development release?13:34
highvoltagemhall119: ah yes, I guess it's worth mentioning (after reading what dholbach said), that I wouldn't expect app developers to do it themselves13:34
dholbachthen that'd be a problem we'd need to solve13:34
mhall119okay, so I have an app, hello-unity, I want to submit to Precise, how would that work *today* if we had the backports method13:35
highvoltageI guess in that case it's fine if we do it like it works currently, and then in that case an app developer would have to re-submit on the next release13:35
highvoltagemhall119: it sounds logical that for *today*, it would go through the extras ppa like all the current arb apps.13:36
dholbachmhall119, look, I'm trying to solve the problem - I don't want things to be harder - I don't have it all figured out yet, but I'm trying to think of using processes and tools we already have, because I feel there will be less objections because problems on those paths are things we know about already13:36
dholbachmhall119, I would expect the submission process to be the same13:36
mhall119highvoltage: yes, I'd be all for making app developers re-submit for each release, it's not that much more work for an actively developed app13:36
dholbachupload source package to ppa, state which release you want it in, the rest is taken care of13:37
mhall119dholbach: I'm not criticizing, I know we're all trying to make things better, just offering real examples to see how the proposed processes would support them13:37
* dholbach nods13:37
mhall119these are my "user stories", so to speak13:38
dholbachmaybe we need some kind of mixture of the processes to accomodate your use case - like the package would be just uploaded to -backports13:39
dholbachI'll flesh out the dev-release incompatibility bit again13:39
dholbachand state that we want the submission process to be the same13:39
dholbachmhall119, I know you've been bitten by other "simple upload processes" before :)13:40
highvoltagemhall119: I'm not always sure what the goal is for add-on apps in Ubuntu. Apple has half a million *apps* in its app store, (Debian has somewhat over 35 000 packages (not even apps), I'm sure you'd want something that can at least scale *somewhat*, and for that we'd have to cut out repetitive work, even if it's just 5 minutes per package per release. at some point, when it's appropriate to do so, we'll have to encourage, help or insist13:40
highvoltagemhall119: as for the use cases, yes it would be appreciated if you could put some together13:40
mhall119dholbach: do you want me to put these user stories on the wiki page you linked to?13:41
dholbachyeah, why not13:41
dholbachhighvoltage, I hope that at some stage we will just use PPAs where we see if things build and then put work into lint tools to check for all the stuff we know might be broken13:42
dholbachthen we could automate lots of the work and spend time on the truly important stuff13:43
highvoltagedholbach: just read through AppArmorEasyprof, sounds nice13:43
dholbachhighvoltage, did you find anything missing on the page? or unclear?13:43
highvoltagedholbach: I think it sums things up (regarding the opt requirement) nicely13:45
dholbachok cool13:45
dholbachhighvoltage, is there any different solution you could see?13:45
highvoltagedholbach: well, I'm still a bit concerned about files that may overwrite each other if there won't be dedicated namespaces for apps, but there's probably a solution for that13:46
dholbachhighvoltage, it's a general problem we have and we don't do much about it - it's a bit unfair that we let app developers (and the ARB) pay for it :-/13:47
highvoltagedholbach: perhaps myapps could warn when a file in a package is already installed via another package already (not that I want to pile more work on myapps developers :) )13:47
highvoltage(and sorry for the general unparsability of that sentence)13:48
dholbachI mean we could at least add some functionality to an arb-lint tool to check against a current Contents.gz13:48
highvoltageah right, yes13:48
dholbachand we could check the list of installed files for "general purpose names"13:48
dholbachbut the ideal solution would be for package management to deal with issues like that13:49
dholbachor some clever confinement technique13:49
dholbachbut now I feel we sacrifice the success of apps in Ubuntu because we choose to selectively deal with the problems just in new apps and not in general13:50
highvoltagewhat do you mean?13:51
dholbachwe generally don't do much about file overwrites13:51
dholbachwe choose to just enforce such a special rule on apps13:51
highvoltageah right13:51
dholbachand the apps submitters and arb people suffer because of that :)13:52
dholbachbut I tried to keep fiery rhetoric out of the document, I hope I succeeded with that ;-)13:52
highvoltageI'm a bit too scared to talk to them but I'd actually like some opinions from dpkg/apt developers13:52
dholbachmvo largely agrees :)13:53
highvoltagespecifically, if there's any plans (or objection) on changing/adding functionality when a file is about to be overwritten13:53
dholbachhe suggested moving to backports completely :)13:53
highvoltagelike, it could ask "Do you want to divert this file to the newly installed package or use the file from the existing package?" or I don't know, just something better than "NO!!! I REFUSE TO DO ANYTHINIG FURTHER YOU MORON!!!!111cos(0)!!"13:54
dholbachyes, it'd be nice if apt/dpkg/software-center understood what was happening and would tell you "package A and B clash, B is just Prio:extra, shall I remove it or do you want to rollback the upgrade"?13:55
dholbachbut I assume that's mountains of work13:55
mhall119dholbach: highvoltage: added 4 use cases that concern me13:58
dholbachcool, I'll have a look in a bit13:58
mhall119please add any that concern you guys (obviously my concerns were all about backports)14:01
highvoltagemhall119: the user stories themselves are good but it seems to try to build an arguement against backports (we acknowledge that backports isn't the answer for everything)14:01
mhall119highvoltage: it points out the problems that would need to be address if we go with backports14:02
highvoltagemhall119: backports would be /one/ possible solution for packages. so it's not a case of "going with backports or not"14:02
mhall119right, so whatever we decide to do, we will need to make sure each of these use cases is addressed14:03
mhall119even if we go with multiple paths to accomplish that14:04
highvoltagemhall119: I recomment you take out the "backports" sub-bullets then and just keep them as use cases14:04
highvoltage(because those arguments against backports are all irrelevant)14:04
mhall119highvoltage: my idea was that we would have a bullet for each option, pointing out whether it would support the use case or not14:05
highvoltagemhall119: ok.14:06
mhall119that way, as long as each use case had a "supported" bullet, we know they're all covered14:06
ajmitchdholbach: I'm about +100 on not requiring /opt, and using backports more14:50
dholbachajmitch, anything the page is missing?14:50
ajmitchin some cases we've been encouraging people to use backports instead14:51
* ajmitch has only quickly read it so far14:51
ajmitchlifeless had a file conflicts checker, fwiw14:51
ajmitch& this is timely, as one of the submissions in the last couple of days is for a nautilus extension14:52
ajmitchopening backports prior to release helps with some of the issues mentioned in the user stories - afaik it was requiring a LP change14:53
ajmitchdholbach: I also know this'd reduce some of the friction around extras.ubuntu.com being considered not part of ubuntu :)14:54
dholbachajmitch, so as part of opening Q+1 we'll open backports earlier on?14:54
dholbachajmitch, will we allow uploads to only -backports?14:55
ajmitchdholbach: right, precise-backports was originally going to open at feature freeze, the TB signed off on it14:55
ajmitchhttps://blueprints.launchpad.net/ubuntu/+spec/foundations-o-backports-bof is light on details but has the general plan14:56
dholbachhum, I'm wondering where in the wiki doc we could plug this14:57
ajmitchmaybe the session at UDS about hacking launchpad could be used to help make sure quantal-backports can be opened at feature freeze14:58
dholbachok, we have another session at UDS called "unblocking developer" which will be all about bottlenecks14:59
dholbachmaybe that'd be a good place14:59
ajmitchdo you have a blueprint link so I can subscribe?14:59
dholbachI just think we should mention it in OptRequirement somewhere too14:59
dholbachas it will mitigate some of the concerns14:59
* ajmitch hasn't liked /opt for a long time15:00
dholbachcan you plug it into the wiki while I look for the blueprint link? ;-)15:00
ajmitchI think the others know my feelings on this :)15:00
ajmitchhttp://conflictchecker.ubuntu.com/possible-conflicts/ doesn't look like it's been run for awhile, but I can ask lifeless about it15:01
dholbachok team call - brb15:02
ajmitchmm, uds update, I suppose I should find a US power adaptor for my laptop :)15:31
wendardholbach: I wouldn't say we spend the vast majority of our time on the /opt requirement, certainly not 90%15:43
wendardholbach: we spend the vast majority of our time educating developers, that's true, but only a tiny part of that has anything to do with /opt15:43
wendardholbach: more of the education is really basic stuff like how to package in the first place15:44
wendardholbach: or, how to even create a tarball/layout that can be packaged.15:44
dholbachis that for the old packages or the newer ones as well?15:45
wendardholbach: I'd estimate the cost of /opt at closer to 10% of total effort15:45
dholbachand with requiring ppa submissions, how much do you think it'd be?15:46
wendarno change with ppa submission, the same work has to be done15:47
wendaron backports, I'm generally in favor15:48
wendarthe resistance in the past was more from the backporters15:48
wendarit won't work for everything15:48
wendarlike, lenses and scopes15:48
wendar(where the code is completely different on Oneiric and Precise)15:48
wendarand, note that it would still block us at feature freeze15:48
wendarwhile this cycle we were still launching apps on Oneiric right up to a week before the Precise release15:49
wendarand, would expect that to continue15:49
wendarso, we might need a special exception that says we can backport some apps that aren't in the current development release, but  are expected to be in the *next* development release15:50
wendare.g. last week we might have backported an app to Oneiric that wasn't in Precise, but plan to submit it to the  Q dev release15:51
wendarthe backporters might consider that a lesser evil than continuing to operate extras.ubuntu.com, hard to tell15:51
dholbachright mhall119 mentioned the lens case as well15:52
dholbachmaybe we can have a chat about your time estimation generally15:52
wendarmaybe for Q we could do both extras and backports? and do some apps in each?15:52
dholbachI assumed that the opt requirement took the majority of time15:52
wendarbasically just add backports as another publishing channel15:52
dholbachI'm happy with that - we should talk to the TB or whoever else could make a decision15:52
* dholbach nods15:53
wendarthen dev release + backports would not use /opt15:53
wendarand extras would keep using /opt15:53
wendarand we could compare time to review, time to launch, etc15:53
wendarand review burden on backports team, and on MOTU, reviewing the new apps15:54
wendarWe've mostly got the /opt install down to a set of formulas now15:54
dholbachright, that's all relevant15:54
* ajmitch thinks that could be good15:54
ajmitch /opt works if it's a very standard installation, like distutils or automake15:55
wendarEspecially for python apps, it's a pretty straightforward set of tweaks15:55
dholbachhum, I'm still a bit surprised that the /opt requirement accounts for so little of your time - I thought it was the major blocker15:55
ajmitchwhen apps have paths hardcoded, it takes a bit more work15:55
wendaraye, the stranger toolsets are undiscovered country15:55
ajmitchI don't know if it's only 10% as you said, since it generally can involve adding patches15:56
wendardholbach: nah, most of the time is spent communicating with developers, especially about buggy code15:56
ajmitchlike the fun with harmonyseq I need to resolve15:56
dholbachok, buggy code we will need to discuss in any case - so that can't be optimised away15:57
wendarit'd be nice to chat with new developers, and ask how much time they spend digesting the /opt requirement15:57
dholbachor let's say... easily optimised away15:57
wendarbecause now that we've pushed the PPA requirement, the effort of /opt is more on the developer15:57
ajmitchstill plenty of work in the actal reviewing what the app does15:57
* ajmitch doesn't know if the PPA requirement is very clear to people submitting still15:58
wendarAFAICT, no one gets it right on first submission15:58
wendarbut then, it hasn't been well documented until a couple weeks ago15:59
wendarand, that documentation still isn't linked from developer.ubuntu.com15:59
wendarso, they probably never see it15:59
ajmitchI'd rather see the submission form require picking a PPA & a package from that PPA, but that probably takes a bit of work16:00
dholbachajmitch, yes, that'd be ideal in my mind too16:00
wendarbut, at least we can respond to the first submission with links to the docs, that helps16:00
wendarand yes, if all apps with "no cost" and "FLOSS license" required a valid PPA link, that would help enormously16:01
wendar(and blocked uploading any files)16:01
ajmitchI think one I looked at today just had a .dsc16:01
wendarI've seen a lot of those16:02
wendaror just .deb16:02
ajmitchjust .deb is very common16:02
dholbachso looking ahead, fixing glitches in MyApps, using&improving automatic tools (once we have stuff in PPAs) and the /opt requirement would speed things up16:02
dholbachI'm somehow trying to estimate how big a problem /opt really is16:03
dholbachas I said above, I assumed that it was one of the biggest stumbling blocks16:03
dholbach(and sources of frustration)16:03
ajmitchI can understand why it's there, but it still does feel like a bit of work for anything remotely non-standard16:03
wendarI was concerned ahead of time, but in actual practice pushing apps through, it hasn't been a huge time-suck16:04
ajmitch& it means that I should reject submissions like forgetbox, since I don't think a nautilus extension can live outside /usr16:04
wendarand, the more apps I do, the easier it gets, because I've worked out the tricks, and can reuse them16:05
wendarajmitch: I'd say a nautilus extension should be main archive and backports anyway16:05
wendarajmitch: so, that's probably a good thing16:05
wendardholbach: the current approval/publishing process is very fast16:06
wendarwe can stage an app, vote on it, and get it live in the current release in a single day16:06
wendardholbach: we often take ~3 days to vote, but it could go faster16:07
dholbachsure, I can't see how that could be much more efficient16:07
wendardholbach: I don't see anyway we could get archive admin approval, publish in dev release, backport approval, and publish in backports in a single day16:07
ajmitchif it's the same person doing backport & archive admin duties, that's not too hard, but I don't know if that's allowed16:08
ajmitchit'd mostly depend on time of day & availability of source/binary NEW reviews16:08
dholbachright, archive admin approval might be the biggest blocker16:08
dholbachfor 1 or 2 members of the ARB to join the backports team to do their work might mitigate the concern a bit16:09
ajmitchhelpign out backports has been one of those "I'll get around to it soon" things for me :)16:09
wendaryes, I think that would be essential, but I imagine the backporters would want new members to build up some experience before they start launching apps on their own16:10
wendarI think they have their own voting/approval process?16:10
dholbachI'm not sure - usually the requirement to get something backported are quite low16:11
dholbachI could imagine that every additional hand on deck would be appreciated16:11
wendarbuild, install, run is their mantra16:12
ajmitchbecause they're working from a known good starting point16:12
wendaryup, it allows for some simplifications16:13
wendaranother issue is that backports isn't visible by default16:13
wendarpeople have to take a manual step to enable it for specific packages16:13
mhall119wendar: can you give me the link to whatever documentation we should point to from developer.u.c?16:14
mhall11912:06 < wendar> but then, it hasn't been well documented until a couple weeks ago16:14
mhall11912:06 < wendar> and, that documentation still isn't linked from developer.ubuntu.co16:14
wendarso, it would be nice to have a feature that allows us to set certain packages as always visible in backports (for a specific release)16:14
wendarmhall119: https://wiki.ubuntu.com/AppReviewBoard/Submissions16:14
wendarmhall119: that has a nice overview, and links to all the other detailed help we offer16:15
mhall119wendar: thanks16:15
mhall119I'll get that added16:15
wendardholbach: expiring apps isn't a big deal, as long as the dev release has a higher version number than the backports release16:16
wendardholbach: does backports do archive copies to new dev releases like the main archives do?16:16
dholbachwendar, I'm not quite sure16:17
wendardholbach: with extras it's just a natural side-effect of starting each release with an empty archive16:17
dholbachwendar, "expiring apps" was about removing apps from the next release, so they don't get copied over and over again (and we have bitrot in the archive, which was one concern)16:17
ajmitchnot currently, because they're always copied from the dev release16:17
wendardholbach: right, that's why extras doesn't copy16:18
ajmitchso if an app is currently in oneiric-backports, it's because it's available in precise16:18
wendarajmitch: yes, that's the current backports policy16:18
ajmitchthe suggested change for opening it pre-release, I think it was going to be a semi-automated copy into that development release16:19
dholbachwendar, yes, I just mentioned it in the doc that we could emulate something like the "expiring apps" if deemed necessary16:19
ajmitchso a new source package could go into precise-backports, then when quantal opened it would have been copied in (with a different version number)16:19
wendarcopied from backports->dev release?16:20
wendarI thought they only allowed the other way16:20
wendardev release->backports16:20
ajmitchwendar: afaik, yes, because this is a special case16:20
ajmitchI don't know where that part is documented, I'll need to look it up16:21
ajmitchhttps://lists.ubuntu.com/archives/technical-board/2011-November/001122.html has the proposal to the TB16:22
wendarah, yes16:23
ajmitchhttps://lists.ubuntu.com/archives/technical-board/2012-March/001224.html has followups from march16:23
wendarso, what they're talking about is opening P-backports at P-feature freeze16:23
wendarwe'd need an extra allowance16:23
wendarallowing O-backports to accept packages that are only in P-backports, and not in P-main archive yet16:23
ajmitchI'm guessing that we'd probably still have this dual-track of extras.ubuntu.com & backports, since using backports runs counter to having the myapps process for apps that aren't included as part of ubuntu itself16:26
ajmitchmore of a definition problem of what it's meant to be16:26
wendarthere's also the fact that the recommended path for totally new packages in Ubuntu is generally to go through Debian16:27
wendarwe have redirected some submissions to Debian already16:27
dholbachalright, for me it's time to call it a day16:30
dholbachif you want to make changes to the wiki page, please do :)16:30
wendarthanks dholbach!16:30
dholbachhave a great weekend everyone16:30
* ajmitch doesn't want to look at the clock16:30
dholbachbig hugs!16:31
dholbachugh, nuts16:31
wendarajmitch: go to bed!16:31
* dholbach hugs ajmitch16:31
* ajmitch hugs back16:31
ajmitchI'll be up for the meeting in a few hours :)16:31
ajmitchanyway, 'night' :)16:32
wendarajmitch: night!16:34
wendarajmitch, highvoltage, lfaraone, stgraber: anything to meet about this month? I figure we'll have a more detailed catchup at UDS.20:09
highvoltagewendar: there's a lot we could talk about, but indeed, UDS is around the corner :)20:14
wendarhighvoltage: the big thing is "how many UDS sessions do we want?"20:15
wendarI'm thinking of scheduling just one on Monday, and adding more later in the week if needed20:15
highvoltagewendar: for me personally... as few as possible, but not less than that.20:15
highvoltagewendar: that sounds good20:16
wendarI'm thinking of scheduling just one on Monday, and adding more later in the week if neededarb20:17
wendarblurg, shift and up arrow are right next to each other on this tiny netbook keyboard20:17
wendarmeant to type: agreed, I don't want to go in with sessions scheduled for ARB every day20:18
wendarone or two (if some piece needs more followup) will probably be plenty20:19
ajmitchwendar: happy to meet at UDS rather than on irc20:51
ajmitchthough I did just manage to wake up for this one ;)20:53
wendarand after so little sleep too!20:57
wendarajmitch: I'm here if you want to go ahead and run20:57
wendarajmitch: or want me to20:57
wendarwe can at least get the blueprint in20:57
ajmitchin terms of stuff to talk about, I think we can just leave it for UDS20:58
ajmitchsorry for not writing up the meeting minutes from last time20:58
ajmitchI was going to check up on some bugs, which I did, and had positive progress on all of them20:59
ajmitchthe python-distutils-extra bug was fixed in debian & subsequently in precise20:59
wendarthat's great!21:00
wendarI need to go back and summarize a few months of minutes21:01
ajmitchyep, it made me happy to be to close it21:01
ajmitchs/to be/to be able/21:01
ajmitchyou'll be at UDS for the week?21:01
wendaryes, arrive on sunday, leave on saturday21:02
ajmitchgreat, seems like we'll have a few of us there21:02
wendarmaybe we should do a BOF night21:02
wendaror, head out for pizza :)21:03
ajmitchI like that idea21:03
* highvoltage too21:03
ajmitchjust looking at the blueprints registered so far, I hope we can get the ARB discussions out of the way in a session or two21:07
wendarup to 118 blueprints already, that's great!21:08
ajmitchhttps://blueprints.launchpad.net/ubuntu/+spec/community-q-upstream-myapps is mostly relevant to us, do we need to register another?21:08
* ajmitch isn't sure if the discussion is meant to be around process on the upstream developer side, or reviewing21:09
wendarThat's more apps in general, though the ARB is part of it21:12
wendarit'd be worth having our own session, where we plan out the next cycle21:12
wendarfor us, that's mostly clearing old submissions, and building up volunteer reviewers21:13
wendarit might be a good chance to invite the MyApps developers in to talk through the bug list21:16
ajmitchthat could be good, then we can explain what we'd like in terms of requiring a PPA for submissions21:17
wendarThis one may be interesting to attend: https://blueprints.launchpad.net/ubuntu/+spec/community-q-app-promotion21:19
ajmitchI think I've signed up for most of the 3rd party app sessions now21:19
wendarI'll be traveling tomorrow, but will be back on after that21:31
wendardo you want to put in the first rough cut of the blueprint?21:31
ajmitchit'll need to be after I wake up properly21:31
wendarmonday will fill up fast21:31
wendaroh, yeah21:31
wendargetting it in Sunday or Monday would probably even be fine.21:32
* ajmitch isn't looking forward to the travelling21:32
wendarheh, yeah, you've got a *long* trip21:32
wendarmine is only one direct 9-hour flight21:32
ajmitchnot quite as long as your trip for LCA21:32
wendarcheesecake compared to yours :)21:32
ajmitch~12 hours from auckland21:32
wendarthat's pretty good21:33
wendarstill long and boring, of course21:33
ajmitchI need to find a local pub in dunedin so we can have a last minute release party tonight, too :)21:33
wendarah, sweet!21:33
ajmitchsince a couple of the others here are going to oakland prior to UDS21:34
wendarUbuntu Oregon is doing one on Sunday, so I'll be back in time for it21:34
wendarhopefully they'll visit around, Oakland isn't the most exciting part of the San Francisco Bay Area :)21:34
ajmitchI think it's up to 3 canonical people in dunedin now21:35
wendarI should go get some sleep before the flight21:43
ajmitchok, I'll try & write up a quick blueprint & submit it21:43
wendarleds for precise is building, and will hopeful get copied from the PPA to live tonight21:43
wendarcool, thanks!21:43
ajmitchI'm guessing it'll be 'community-q-app-review-board'?21:44
wendaryeah, that sounds good21:44
ajmitchok then21:44
ajmitchenjoy your flight :)21:44
ajmitch(if that's possible)21:44
wendarwill do21:44
wendarIt is pretty much the only time I watch movies, so that's a pluss21:45
* wendar waves off21:45
highvoltagebye wendar22:07

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!