[03:42] <somerville32> @schedule atlantic
[03:42] <Ubugtu> Schedule for Canada/Atlantic: 08 Mar 12:00: Ubuntu Development Team | 11 Mar 07:00: LoCo Team | 12 Mar 15:00: Derivative Team | 13 Mar 13:00: Forum Council | 13 Mar 17:00: Technical Board | 14 Mar 17:00: Edubuntu
[04:38] <mvo> @schedule berlin
[04:38] <Ubugtu> Schedule for Europe/Berlin: 08 Mar 17:00: Ubuntu Development Team | 11 Mar 11:00: LoCo Team | 12 Mar 19:00: Derivative Team | 13 Mar 17:00: Forum Council | 13 Mar 21:00: Technical Board | 14 Mar 21:00: Edubuntu
[04:43] <mooey> @schedule london
[04:43] <Ubugtu> Schedule for Europe/London: 08 Mar 16:00: Ubuntu Development Team | 11 Mar 10:00: LoCo Team | 12 Mar 18:00: Derivative Team | 13 Mar 16:00: Forum Council | 13 Mar 20:00: Technical Board | 14 Mar 20:00: Edubuntu
[04:43] <mooey> heh
[04:54] <mdz> morning
[04:55] <dholbach> hiya
[04:56] <ogra> meh, i forgot my report ... but i'm here
[04:56] <mdz> Keybuk,cjwatson: ping
[04:58] <Keybuk> mdz: I'm missing two atm
[04:58] <Riddell> hi
[04:59] <Keybuk> missing one
[04:59] <iwj> Oh here I am.
[04:59] <Keybuk> no, not you :p
[04:59] <kwwii> I am here
[05:00] <Keybuk> pitti - haven't seen anything from him all afternoon
[05:00] <mdz> seen cjwatson?
[05:01] <Keybuk> yeah, he just ping'd out
[05:03] <pitti> hi, sorry for being late
[05:03] <heno> mdz: I just posted to the distro list about testing. I'd like to add that as an item to the meeting
[05:03] <mdz> heno: ok, go ahead and edit the wiki page
[05:03] <tkamppeter> hi
[05:03] <heno> pre-beta-freeze ISO testing
[05:04] <cjwatson_> hi, sorry about that, n-m decided to hate me
[05:04] <mdz> cjwatson_: ok, everyone here on your side?
[05:05] <cjwatson> missing BenC, rtg
[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
[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
[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?
[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.jones@canonical.com--2005-master/livecd-rootfs--mainline--0.27 in /home/warthogs/archives/lamont.jones@canonical.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 :)
[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
[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
[05:56] <mdz> bdmurray: email the list about it instead I guess
 *** 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
[06:00] <pitti> thanks everyone
[06:00] <asac> thanks
[06:00] <cjwatson> mdz: done
[06:00] <dholbach> thanks
[06:00] <kwwii> thanks
[06:01] <ogra> thanks
[06:01] <seb128> thank you