TZ UTC+6
05:05 mdz ok, we're already behind, let's get started 05:06 cjwatson BenC and rtg are still travelling so are excused 05:06 mdz cjwatson: they're both still traveling 05:06 cjwatson I'd forgotten that extended to today 05:06 mdz (Riddell) Are the changes needed for abbatoir's oem installer going to get in? If not should we try for a basic qt 4 port? 05:06 cjwatson I've been working on that today 05:06 Riddell question to cjwatson 05:06 Riddell ooh? 05:07 cjwatson should be done RSN; I'd like that to get in 05:07 mdz what is abbatoir's oem installer? 05:07 Riddell ok, excellent, we'll wait for that then 05:07 cjwatson oem doesn't see much testing until beta anyway, realistically 05:07 cjwatson mdz: it's a rework of the oem-config kde ui 05:08 mdz Riddell: is that all? 05:08 Riddell yes thanks 05:08 mdz (iwj) Is anyone doing regular rebuild testing ? autopkgtest could do this quite easily - atm I've explicitly disabled that by telling it to test the binaries from the archive rather than doing a build. Should I turn this on ? If I do it's not likely to go through the alphabet very fast but it will give us a chance to argue about what to do with the notifications. 05:09 mdz iwj: this is supposed to be provided by Canonical IS on a periodic basis; there's a rough outline of a process in the wiki 05:09 iwj There's also the question of whether we want to test the binaries actually in the archive, or ones built specially. 05:09 pitti would it be possible to do it the other way round? 05:09 mdz iwj: they set up a katie/wanna-build instance and use that === mvo does semi-automatic install tests 05:09 pitti i. e. add autopkgtest to our already existing rebuild tests 05:09 pitti ? 05:09 mdz potentially, yes 05:09 iwj mdz: https://wiki.canonical.com/RebuildTestProcess ? 05:09 tfheen_ there has been some recent trouble with the last couple rounds of rebuild testing, and it should ideally happen in a fairly tight timeframe. 05:09 iwj Sounds a bit ad-hoc. 05:10 mdz iwj: cf. "rough outline" above 05:10 iwj mdz: Right. 05:10 iwj pitti: That's a definite possibility, yes. 05:10 mdz I saw in #-devel that there is some doubt about whether the testing has begun? 05:10 tfheen_ also, that process is just the interface, it's not how it's implemented. 05:10 iwj NB that autopkgtest tends to do it one package at a time; that wiki page seems to suggest a from-ground up rebuild of everything (from some known bootstrap?) 05:10 iwj mdz: I haven't been reading #-devel much today. 05:11 mdz tfheen_: right, that part needs to be provided by IS 05:11 mdz tfheen_: there was to have been a rebuild test on 8 Feb. 05:11 mdz did that happen? 05:11 iwj My cron job ran for the first time last night but basically no packages have tests so it's just makework. 05:11 iwj AFAIAA only dovecot and mawk have tests so far. 05:11 tfheen_ mdz: last time I spoke with Adam (which admittedly is some time ago) the last round of rebuild testing happened, but I haven't actually gotten the results anywhere. 05:11 mdz iwj: how so? is it not installing and uninstalling the packages and checking the results? 05:12 mdz tfheen_: it seems unlikely that nothing failed 05:12 tfheen_ mdz: something is bound to have failed, I have just failed to get in touch with Adam. I'll try again, this time cc-ing elmo. 05:12 mdz tfheen_: CC me as well 05:12 tfheen_ sure 05:12 iwj mdz: Well, atm it has optimised out the install the package step since there aren't any tests. 05:13 mdz iwj: it should not do that 05:13 iwj I could change the command-line arguments to make it install the packages unconditionally. 05:13 tfheen_ ACTION: tfheen to get rebuild test results, To: \infty; Cc: mdz, elmo 05:13 mdz installing the package is one of the most valuable tests of all, intrinsically 05:13 iwj mdz: Right. 05:13 mvo iwj: what scope do you currently test? main only? 05:13 iwj I think I should perhaps talk to the IS people about what these rebuild tests consist of ? 05:13 mdz and removal, too, since that isn't tested as often in the field 05:13 iwj mvo: Yes. 05:13 tfheen_ basically having something like piuparts would be useful. 05:13 iwj mdz: Right. 05:14 iwj tfheen_: I haven't yet looked seriously at cannibalising piuparts (or indeed reimplementing it if that's quicker). 05:14 iwj But it would be a nice fit. 05:14 mdz someone ran piuparts over the archive a little while ago, and found a stack of failures 05:14 mdz the output was a bit difficult to work with though 05:15 tfheen_ piuparts doesn't pay attention to dependencies, so cascading can easily give false positives. 05:15 mdz hrm 05:15 tfheen_ (say x11-common isn't clean, anything depending on x11-common would be marked as unclean) 05:15 mdz oh, I see 05:15 dholbach http://www.nabble.com/FTBFS-and-piuparts-failures-lists-for-feisty-t3159699.html 05:15 iwj tfheen_: Ah. I do have some tracking of what things might be responsible but it's probably not quite strong enough to avoid all consequetial false positives. 05:15 ogra_ it also needs proper blacklisting ... 05:16 mvo I have some code as part of the auto-upgradetester that tests installability of large amounts of packages (basily testing a feisty->feisty upgrade) 05:16 ogra_ ltsp-client isnt installable outside a chroot ... but puiparts tries it anyway ... 05:16 mdz mvo: oh, that's useful 05:16 mdz mvo: is that running in the DC yet? 05:17 mvo mdz: this one is pretty new, it runs on my machine currently 05:17 mdz mvo: but the regular upgrade test is in the DC now? 05:17 mvo mdz: but i plan to move it over soon 05:17 mvo mdz: yes, it runs regularly with hicups sometimes 05:17 mvo it was e.g. bitten by the xorg priority bug 05:17 iwj I haven't had a reply to my RT ticket about autopkgtest in the DC (not that surprising, since it was long and will involve some decisions). 05:17 mdz that's good 05:18 mvo endless loops in maintainer scripts currently need resolving by hand === mvo needs to write some watchdog code for this 05:18 Keybuk iwj: what is the RT# ? 05:18 mdz I need to have a look through what's in RT 05:18 mdz ACTION: mdz to review RT queue 05:18 iwj Keybuk: 26993 05:18 iwj It's been err about a week. 05:18 iwj No, two. 05:19 iwj endless loops> kill the Xen VM :-). 05:19 tfheen_ yeah, xen makes that a lot easier. 05:19 mvo iwj: I need to "borrow" the xen bits from you 05:19 mdz ok, so tollef is going to follow up regarding the rebuild test. ready to move on? 05:20 iwj mvo: Sure, they don't need borrowing - there're two interfaces. 05:20 mdz cjwatson/bdmurray: outstanding actions? 05:20 iwj mdz: So the answer to my Q is no, I shouldn't do rebuild tests. But I should do installs. 05:20 cjwatson mailed the list earlier regarding those 05:20 mvo iwj: lets talk about this offline :) 05:20 iwj mvo: Right. 05:21 mdz iwj: the answer is that they're supposed to happen by other means, but we need to reconfirm. we may find that we need to do them ourselves somehow 05:21 mdz Riddell,tfheen_: KDE 4 in NEW? 05:21 iwj mdz: OK. I'll not start doing them until someone tells me otherwise. 05:21 mdz Ubugtu: thanks 05:21 iwj ACTION: iwj to tell autopkgtest to install things even if they have no tests to run. 05:21 cjwatson bugsquad docs in UbuntuDevelopment are written (though still a bit rough; bdmurray had comments), I investigated 63175 a bit, talked with scott, and then scott asked mvo to do the rest 05:22 mdz Riddell: is that blocking anything for beta? 05:22 Riddell mdz: no, although libkexiv2 will (blocks new digikam) 05:22 tfheen_ iwj: if we don't have better control of the rebuild tests for feisty+1, I would like us to do it internally. 05:22 iwj tfheen_: Right. 05:23 mvo cjwatson: I have no news on 63175 yet, sorry 05:23 mdz Riddell: and the new upgrader definitely needs to be in and tested for beta 05:23 Riddell I agree 05:23 cjwatson mvo: it was about an hour or two ago, that's fine ;-) 05:23 pitti (FYI, new KDE dist-upgrader is in edgy-proposed now) 05:23 mvo :) 05:24 mdz mvo: do you (have cycles to) test Kubuntu upgrades? 05:24 tfheen_ there was a licence question about libkexiv2, but that has been resolved to my satisfaction now, so it just needs to be waved through. 05:24 mvo mdz: its on my list for sru-verification, I will do it this week 05:25 Riddell tfheen_: I didn't hear about that, looking forward to having it waved through 05:25 pitti mvo: NB that one 'works for me' is not enough for me in the KDE dist-upgrader case; I want at least ten different success reports 05:25 tfheen_ Riddell: or rather, digikam, the jasper / jpeg2k patent issue. 05:26 mvo pitti: I have read that, I plan to be one of the ten :) 05:26 Riddell we have people in #kubuntu-testers eager to help testing it 05:26 Riddell tfheen_: oh, right yes 05:26 mdz should be straightforward to arrange testing now that it's in -proposed 05:26 mdz cjwatson: what's the final outcome on the ubiquity advanced partitioner for feisty? 05:27 cjwatson it's in, disk bar will have to wait 'til next time 05:27 cjwatson it's reasonably usable without, and certainly better than the old partitioner 05:27 cjwatson if necessary I'll work around problems with explanatory text 05:28 mdz doko/pitti: will the maintainer field changes be completed for beta? 05:28 cjwatson there's one bit of validation I need to add for beta, and some issues with formatting swap and such, but it's largely ok 05:28 doko mdz: yes 05:28 pitti mdz: yes, as long as doko finishes his rebuilds soon 05:28 pitti doko: what's your ETA? 05:28 mdz ok, good 05:28 doko pitti: doday 05:28 doko bah 05:28 pitti I need to do ~ 40 rebuilds 05:28 mdz pitti: is your livefs change request in RT? 05:29 pitti mdz: no, it's not 05:29 pitti I was going to ask who else can access this script 05:29 mdz pitti: I think it ought to be 05:29 pitti ok 05:29 mdz pitti: I expect that anyone with root can 05:29 pitti it started out with a simple 'yes, I'll do it later' change, sorry 05:29 mdz what we want for that is for the scripts to be in bzr 05:29 mdz so we can just ask for merges 05:29 doko door bell ... 05:30 mdz I need to put that in RT myself; didn't hear back the last time I emailed 05:30 mdz ACTION: mdz to file livefs->bzr issue in RT 05:30 pitti TBH I didn't make too much good experiences with RTing stuff 05:30 mdz kwwii: what are these new ooo icons? something which fits better with everything else I hope? 05:30 pitti but I'll do it to get a number anyway 05:31 kwwii mdz: yeah, they are human on top of tango 05:31 heno the new ooo icons are sweet 05:31 kwwii mdz: really cool because we are the first ones to release them 05:31 dholbach mdz: they should be in the archive now - just start oowriter 05:31 mdz pitti: is restricted-manager on track for beta? that's when it will see the most testing 05:31 mdz dholbach: I've had oowriter running for weeks ;-) 05:31 pitti mdz: today I got it to configure nvidia with a single click 05:32 pitti but I need someone with ATI to tell me the necessary steps 05:32 mdz very nice, I like the splash too 05:32 tfheen_ mdz: iirc, the livefs.sh script is in baz. 05:32 cjwatson it is 05:32 Keybuk pitti: ATI shouldn't be hooked into the desktop effects button 05:32 pitti r-m itself works reasonably so far, but it needs desktop-effects integrations 05:32 mdz pitti: that's excellent 05:32 pitti Keybuk: but certainly r-m should be able to configure the fglrx driver? 05:32 Keybuk pitti: yup, definitely 05:33 mdz pitti: I'll be among the first to test that once it's in the archive; my desktop is now nvidia 05:33 Keybuk mdz: ouch, you have my sympathy 05:33 pitti Keybuk: I thought about sth. like a generric 'restricted-manager --check-for-better-driver' 05:33 ogra_ poor boy 05:33 mdz pitti: this meeting would be a good place to ask for an ATI tester 05:33 bdmurray I have an ATI card 05:33 mdz I have an ATI chipset in my laptop, but it doesn't require fglrx 05:33 mdz I suppose I could still test though 05:33 mvo I have one in my laptop 05:33 mdz pitti: does it also support undoing its changes? === ogra_ could only test with an r200 which si supported poorly by both drivers 05:33 pitti mvo: you are voluntold :) 05:34 seb128 I can do testing on my desktop 05:34 pitti mdz: yes, if you disable the driver, you'll get back to the previous one 05:34 asac iirc i have ati in my laptop as welll ... i could use that for testing as it needs to be wiped anyway at some point. 05:34 pitti mdz: well, right now it's s/previous/nv for nvidia/ 05:34 ogra_ pitti, that also handles the fglrx mesa breakage ? 05:34 pitti ogra_: as I said, ATM it does not do *anything* to configure fglrx 05:34 cjwatson livefs> lamont DOT jones AT canonical DOT com--2005-master/livecd-rootfs--mainline--0.27 in /home/warthogs/archives/lamont DOT jones AT canonical DOT com--2005-master, AFAIK 05:35 Keybuk ogra appears to be volunteering to help :p 05:35 mdz pitti: I seem to recall the script for fglrx going missing or never quite being written 05:35 ogra_ Keybuk, i'm willing to help testing :) === pitti wonders where restricted-manager 0.3 went to -- I uploaded it hours ago 05:35 tfheen_ cjwatson: the current one on the buildds should be extracted for comparison. 05:35 mdz cjwatson: that's obsolete; there are changes in production which aren't in revision control 05:35 cjwatson plausible 05:35 mdz that's what I heard from infinity 05:35 Keybuk pitti: it's published 05:36 pitti oh, indeed; ah, I only have the de. mirror for universe 05:36 pitti mdz: happy testing then 05:36 mdz pitti: it should be almost identical to nvidia 05:36 mdz swap drivers, install the GL libraries 05:36 mdz afaik, I've never used it 05:37 mvo IIRC there is some option that needs to be set for fglrx to make it work 05:37 pitti mdz: no magic driver options and such? anyway, I'll figure it out, plenty of testers above :) 05:37 Keybuk mdz: then curse about once a week when your X server dies at the worst possible moment :-/ 05:37 ogra_ mdz, ati doesnt work anymore as long as fglrx is installed ... 05:37 mvo Option "Composite" "false" 05:37 ogra_ fglrx replaces the GL lobs and hogs them 05:37 ogra_ *libs 05:37 pitti mvo: that doesn't sound quite right for compiz OOTB :/ 05:37 ogra_ so you cant easily switch back and forth without uninstalling fglrx 05:38 Keybuk pitti: compiz doesn't work with fglrx 05:38 pitti ogra_: same with nvidia; r-m now installs the required packages 05:38 pitti and removes them again 05:38 ogra_ ah, cool 05:38 mdz ogra_: nvidia is the same 05:38 seb128 I'll likely use the no-tfp patch for compiz to make it work with fglrx 05:38 bdmurray Is there any good pretty desktop documentation? 05:38 tfheen_ or we could rework the modules so r-m does the alternatives handling rather than nvidia-glx itself 05:38 pitti Keybuk: ah, that's why you only want nvidia integration into desktop-effects? 05:38 mvo pitti: the recipt I send you worked for install/remove? 05:38 Keybuk pitti: exactly 05:38 pitti Keybuk: good to know 05:39 pitti mvo: yup, works fine 05:39 pitti mvo: (recipe, btw) 05:39 Keybuk fglrx doesn't support the necessary bits to make composite and compositors work 05:39 mdz seb128: oh? interesting 05:39 mdz seb128: is that the same patch used in beryl? 05:39 Keybuk if your card is supported by the ati driver, it's always better than fglrx 05:40 mdz tfheen_: yes, in feisty+1 we're likely to want to have the drivers all preinstalled, but this is a good incremental step 05:40 seb128 mdz: yes 05:40 pitti Keybuk: anyway, I think we should bundle this special knowledge into r-m and make the --check-for-composite-driver-whatever DTRT 05:40 pitti Keybuk: and just call this in d-e 05:40 Keybuk *nods* 05:40 mdz pitti: so I should wait for restricted-manager 0.3 and test that with desktop-effects? 05:41 pitti mdz: r-m 0.3 is in feisty, and as I said, it's not yet intertwined with desktop-effects; you have to start it from the menu so far 05:41 mdz pitti: oh, I thought you said you uploaded it but didn't see it enter the archive 05:41 pitti mdz: that was wrong, I looked at the German mirror 05:41 mdz ah 05:41 pitti I usually don't need universe crack of the minute 05:42 mdz heh 05:42 mdz ok, is there any other business for the meeting? 05:42 ogra_ yes 05:42 heno iso testing 05:42 ogra_ any word about SoC from our management or CTO ? 05:42 ogra_ :) 05:42 Riddell doko said he was doing it 05:42 cjwatson I have something as well re launchpad downtime from kiko 05:43 cjwatson doko and Keybuk are handling SoC jointly 05:43 doko ogra_: doing that ... 05:43 Keybuk ogra: we're participating as usual; doko and I will be jointly managing it 05:43 ogra_ Keybuk, doko thanks for taking it ! :) 05:43 doko Keybuk: let's schedule a phone call for tomorrow please 05:43 mdz they'll send out announcements when there is something to announce 05:43 ogra_ i didnt know if we do it at all this time 05:43 Keybuk doko: jinx, just /msg'd you the same thing 05:43 ogra_ there was no talking about it anywhere, thats why i asked 05:43 mdz (heno) We should do a round of ISO testing before beta freeze to flush out some bugs early. (see Testing/Matrix) 05:44 Keybuk ogra: it's only just been announced by Google 05:44 heno from my email to the distro list: We've decided to start beta testing early this cycle! The idea is to get 05:44 heno some ISO testing done before the beta freeze to flush out some bugs 05:44 heno before the release crunch. 05:44 heno ... 05:44 heno For the first (pre-beta-freeze) test cycle, please download daily images 05:44 heno in the period Friday-Monday, and test as you normally would with the 05:44 heno milestone candidates. 05:44 ogra_ Keybuk, well, leslie is already pretty busy on the SoC list ;) 05:44 mdz it seems like a good idea to do a quick validation test before we freeze, so that we can chase out obvious bugs before we enter the beta release crunch 05:44 Keybuk ogra: really? she's supposed to be away this week <g> 05:44 mdz the idea is that we do this just like we do for beta/RC/final, with everyone doing a few test cases 05:45 ogra_ haha 05:45 mdz so that the round of testing during the freeze goes more smoothly 05:45 mdz heno: so will you match people up with a set of test cases based on their hardware? 05:46 heno I've made a start here https://wiki.ubuntu.com/Testing/Matrix 05:46 mdz oh, good 05:46 heno but it needs some feedback 05:46 mdz ACTION: everyone to confirm their test cases on Testing/Matrix 05:47 mdz heno: I don't think I'll be able to test WinFOSS this time around, since I'm not in the office (no windows at home) 05:47 heno That was one of my questions: who has windows? :) 05:47 tfheen I do, I guess I could do winfoss 05:47 Riddell I do 05:48 ogra_ i have winfoss ... but no windows :) 05:48 heno and should I be testing all my own winfoss work? (is that good policy?) 05:48 mdz heno: if needed, we can certainly buy a couple of copies 05:48 heno ok, I can of course test, but should not be the only one 05:49 heno thanks Riddell, tfheen 05:49 iwj heno: You seem to have me down for amd64 but I don't have one. 05:49 mdz is everyone clear on the testing plan? you should look at the matrix and make sure that you're capable of doing your test cases 05:49 ogra_ i'll find people in the community for edubuntu winfoss ... 05:49 heno I'll shuffle things around a bit more 05:49 mdz heno: will you send out a pointer to the test candidate once it's in place? 05:49 heno yes 05:50 mdz ok, sounds good 05:50 Keybuk note: I've hassled mdy again about our vmware licences, 05:50 Keybuk no luck though 05:50 heno except this time there is no specific candidate iso 05:50 heno (but for beta, etc there will be) 05:50 mdz heno: hmm, I guess it's not strictly necessary 05:50 heno just 'a recent daily' 05:51 mdz to serve as a dry run for the testing process itself and distribution of test cases, and to chase out the obvious bugs 05:51 tfheen_ noting down which version you're testing is still useful, though. 05:51 mdz Keybuk: who's lacking? 05:51 asac i am not really sure about all test cases ... erase disk for instance :/ 05:52 mdz asac: as it's a rather popular one with real users, it does need to be thoroughly tested 05:52 heno https://wiki.ubuntu.com/Testing/InstallMethods 05:52 mdz if hardware is the issue, we can discuss that 05:52 heno That needs fleshing out too 05:52 asac probably should get an extra disk i guess 05:52 ogra_ hmm, heno whats the DVD winfoss testcase for the edubuntu add-on CD ? 05:52 heno with more detailed instructions for each test 05:53 mdz heno: should probably refer to Testing/Short 05:53 ogra_ cjwatson, do we build a DVD from the add-on stuff ? 05:53 heno ogra_: don't know, is there no such thing? 05:53 ogra_ not afaik 05:53 Keybuk mdz: everyone, but you who bought one yourself 05:53 heno mdz: right, I'll merge and clean up 05:53 cjwatson ogra_: add-on should be included in the regular DVD; no pointt building a separate one 05:53 iwj asac: Get one of those removeable caddy drive tray things. 05:53 ogra_ but i might be wrong, thats why i ask cjwatson 05:53 iwj Or just open the box :-). 05:53 cjwatson Keybuk: I have my own as well 05:53 asac iwj: yeah :) 05:54 Keybuk mdz: the ones on the ISVLicences page have all expired, as they were issued incorrectly by vmware 05:54 heno ACTION: heno to improve ISO testing documentation 05:54 ogra_ cjwatson, so i assume there is no winfoss on the DVD, is there ? 05:54 mdz Keybuk: I need to talk to mdy about something else, will ask him about that as well 05:54 cjwatson ogra_: hmm, probably not at the moment but that's actually a bug 05:54 ogra_ oh, ok 05:54 mdz ACTION: mdz to ask mdy about vmware licenses 05:54 cjwatson ogra_: feel free to check and file it 05:54 pitti asac: having two HDs in the computer is nice anyway for distributing access etc. 05:54 ogra_ so itws a valid testcase then, thanks 05:54 cjwatson door, brb 05:55 heno ogra_: I was in doubt about the new edubuntu images, please make corrections 05:55 asac pitti: I alrady have two :) ... still need to sort things out and maybe get a third 05:55 mdz ok, it sounds like we're fairly clear on the pre-testing procedure 05:55 ogra_ heno, will do, to be honest i havent tested any DVD yet 05:55 mdz any other business for the meeting? 05:55 cjwatson yes 05:55 bdmurray I was curious about bug 75681 05:55 cjwatson kiko asks whether they can take lp down early tomorrow morning 05:56 bdmurray cjwatson: is that UTC? 05:56 tfheen_ I'm fine with that, given that I'm on vac tomorrow. 05:56 mdz I get a server error on https://launchpad.net/bugs/75681 === mvo gets it too 05:56 bdmurray whoops, all of lp seems to be down now 05:56 iwj It seems broken. 05:56 cjwatson launchpad is falling over and they think postgresql 8.2 will improve things 05:56 bdmurray it is about a boot-time race condition with mdadm === dholbach starts hacking bughelper--LP-timeout--support 05:56 mdz bdmurray: email the list about it instead I guess 05:56 seb128 <kiko> *** We're doing some online maintenence work on Launchpad -- the site will be slow and unstable for a few minutes *** 05:57 iwj bdmurray: I'm probably the person to talk to about that. 05:57 mdz bdmurray: ubuntu-devel, even 05:57 cjwatson they say the downtime will be 7:30-9:30 UTC; if it's not then, then the next window would be 4:30 UTC on Saturday, but they don't want to hold off until then if they can avoid it 05:57 iwj I'd be quite keen to chat real-time with a user who has the symptoms. 05:57 cjwatson I asked if it could be earlier in the morning tomorrow, but apparently not 05:57 bdmurray iwj: The submitter is kees and I have the symptoms too 05:57 mdz that time is OK with me 05:57 cjwatson so I said I'd bring it up here as it affects most of us in Europe 05:57 iwj bdmurray: Excellent :-). (err) 05:57 iwj bdmurray: Talk after the meeting ? 05:58 bdmurray iwj: sounds good 05:58 mdz it sounds like an urgent situation 05:58 cjwatson any objections, speak now or forever hold your peace 05:58 heno == LP meeting report == 05:58 heno There was some discussion about the recent performance issues and oopses. They are investigating oopsec reports and system logs. No conclusions yet. One theory is the translation timeouts are hogging server CPU, in which case that will pass. 05:58 Keybuk cjwatson: do they have to wait until then? :p 05:58 cjwatson hah 05:58 heno just though I'd post that 05:58 heno seemed relevant 05:58 cjwatson 16:32 <kiko> well, we could do it at 4:30 UTC saturday, BUT, it means that a) launchpad will still be slow until at least then and b) the poimport script, required to opening feisty translations, will not run until then. 05:58 cjwatson 16:32 <kiko> I would much prefer doing it tomorrow 05:58 cjwatson 16:35 <cjwatson> I'll ask in the meeting 05:59 mdz heno: thanks 05:59 cjwatson ok, I'm hearing no objections, so I'll tell kiko yes 05:59 mdz right 05:59 mdz cjwatson: please mark the distro-team calendar as well 05:59 mdz ...and that's our time 06:00 mdz thanks, everyone 06:00 mdz adjourned