20070308

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

MeetingLogs/UbuntuDev/20070308 (last edited 2008-08-06 16:19:49 by localhost)