| infinity | Alternates re-spun, if someone who knows how the ISO tracker works wants to post them. :P | 00:04 |
|---|---|---|
| stgraber | infinity: all of them or just ubuntu? | 00:06 |
| infinity | stgraber: The whole shebang. | 00:06 |
| infinity | stgraber: live/desktop/preinstall/whatever images are still grinding away, but alternates should all be ready. | 00:07 |
| stgraber | ok, posting them on the tracker | 00:07 |
| slangasek | are none of the live images done yet? | 00:09 |
| stgraber | infinity: I'm guessing that includes server too. What about the omap and omap4 build for server, was that part of it too? | 00:12 |
| stgraber | nevermind, I see them on cdimage | 00:12 |
| stgraber | posting | 00:12 |
| mdeslaur | bug 855171 may be worth mentioning in here | 00:13 |
| ubot4 | Launchpad bug 855171 in nss (Ubuntu) (and 1 other project) "libnss3.so went missing after upgrade (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/855171 | 00:13 |
| stgraber | infinity: ok, I think I got them all, only left disabled on the tracker are the upgrades (not sure why so didn't re-activate), desktop builds and dvd builds | 00:14 |
| slangasek | mdeslaur: can you attach an apt term.log, which is generally more usable than a dpkg.log? | 00:16 |
| slangasek | (/var/log/apt/term.log) | 00:16 |
| slangasek | the file's missing here too, how incredibly rude. | 00:18 |
| slangasek | convenient that I hadn't rebooted yet, I guess | 00:18 |
| mdeslaur | slangasek: attached | 00:19 |
| slangasek | thanks | 00:19 |
| slangasek | mdeslaur: do you know when you last had it | 00:19 |
| slangasek | ? | 00:19 |
| mdeslaur | I had it when I booted the laptop just before doing the dist-upgrade | 00:19 |
| mdeslaur | so, whatever you see that's dated the 20th is when it happened | 00:19 |
| mdeslaur | bbl | 00:20 |
| slangasek | I am going to be annoyed if this turns out to be a knock-on effect of running update-ca-certificates | 00:23 |
| slangasek | which is looking likely | 00:23 |
| slangasek | yep | 00:24 |
| slangasek | arrrgh | 00:24 |
| doko_ | slangasek, is there something wrong with java-ca-certificates update? | 00:33 |
| slangasek | doko_: yes, the do_cleanup() function is nuking the system libnss3 | 00:33 |
| slangasek | doko_: can you have a look at it? | 00:33 |
| doko_ | slangasek, ok, first thing tomorrow morning. not now, just too tired | 00:34 |
| slangasek | tomorrow morning is too late | 00:34 |
| slangasek | if you're not free to do it now, that's fine; but this is eating users' systems in realtime | 00:34 |
| slangasek | no nss3 == no network-manager | 00:34 |
| doko_ | gaah | 00:34 |
| infinity | stgraber: Thanks. | 00:35 |
| * infinity goes to make some food. | 00:36 | |
| doko_ | slangasek, there was a suggestion to drop the libdir setting in nss.cfg. openjdk does have the multiarch path on the default libpath. | 00:42 |
| slangasek | doko_: should we take this to #ubuntu-devel? RAOF is also looking at it there, probably better to not have too many people working on it in parallel | 00:43 |
| doko_ | ok | 00:44 |
| infinity | Failed to fetch http://ftpmaster.internal/ubuntu/pool/main/c/ca-certificates/ca-certificates_20110502+nmu1ubuntu2_all.deb 403 Forbidden | 00:49 |
| * infinity blinks. | 00:49 | |
| infinity | slangasek: Did I miss a memo? | 00:51 |
| slangasek | infinity: yes | 00:51 |
| slangasek | look up | 00:51 |
| infinity | Oh. | 00:51 |
| infinity | Ugh. | 00:51 |
| infinity | So, all these images are useless? :P | 00:51 |
| slangasek | you can use them as virtual coasters | 00:53 |
| infinity | I need a virtual microwave to make them crackly. | 00:54 |
| stgraber | infinity: btw, you should now have admin rights on the tracker | 00:56 |
| infinity | stgraber: Shiny, I suppose that means I'd need to learn how to make it go, then. | 01:00 |
| infinity | Anyhow, with ca-certificates in standard, that invalidates every image except for core. Woo. | 01:00 |
| * infinity kills the builds that were in progress still... | 01:00 | |
| charlie-tca | ooops ;( | 01:02 |
| * GrueMaster weeps for humanity | 01:03 | |
| slangasek | infinity: ca-certificates-java uploaded | 01:06 |
| slangasek | infinity: please to reviewing | 01:06 |
| slangasek | or if you prefer, I'll accept it myself (but then I should probably test it first) | 01:07 |
| infinity | slangasek: I'll review when it lands.. | 01:10 |
| slangasek | so | 01:11 |
| slangasek | ca-certificates-java doesn't affect all the images | 01:11 |
| slangasek | but I think ca-certificates should gain a Breaks: on the old version of ca-certificates-java to enforce the upgrade in tandem | 01:11 |
| slangasek | actually, Conflicts: | 01:12 |
| infinity | Which then affects all images. | 01:12 |
| slangasek | yep | 01:13 |
| slangasek | infinity: you're holding the baton; what do you think? | 01:13 |
| infinity | I think I have a date tonight, but the baton is relocatable. ;) | 01:13 |
| infinity | I do think we should respin for it, though. | 01:14 |
| slangasek | for -java, yes | 01:14 |
| doko_ | hmm, ca-certificates-java should only be on DVD images | 01:16 |
| slangasek | -java tested locally, confirmed that I still have libnss3.so | 01:16 |
| infinity | slangasek: I may be coming into this discussion late, but how is it ever a good idea (even with this lovely guard in place) for a random package to delete libraries? | 01:16 |
| doko_ | infinity, because it did create the link | 01:17 |
| infinity | (The code looks to do what it wants to, though) | 01:17 |
| infinity | doko_: Ahh, it's a symlink (or, it is when we want it dead)? | 01:17 |
| infinity | A -L guard might have made that more obvious too. | 01:17 |
| doko_ | infinity, it's a hard coded value in nss.cfg, but we need it to run the update | 01:18 |
| slangasek | doko_: it's on {kubuntu,ubuntu,edubuntu} DVDs and ubuntu-server, but the question is if we want to update ca-certificates as well for all the users who might have -java installed locally and be affected | 01:18 |
| * infinity nods. | 01:18 | |
| slangasek | infinity: right, it's meant to only be cleaning up symlinks created in this same script | 01:18 |
| slangasek | but it, ah, missed | 01:18 |
| infinity | slangasek: Check. | 01:18 |
| doko_ | slangasek, if it's safer this way, fine | 01:19 |
| slangasek | the damn thing is, I *saw* the ca-certificates-java error backtrace when I was preparing the ca-certificates update, and assumed it was an innocuous pre-existing problem... I should have followed up on that error earlier :/ | 01:19 |
| infinity | slangasek: I'm just going to go on record as saying that's one hell of an ugly and opaque shell script for something that appears to accidentally nuke files, but it looks like it should do what it says on the tin, so accepted. | 01:21 |
| infinity | (Well, until the next time something weird happens) | 01:21 |
| slangasek | infinity: thanks. so, you still hold the baton, what would you like to do? I can prep a ca-certificates upload with the Conflicts quickly enough... | 01:21 |
| infinity | slangasek: Well, the conflict is sane anyway, I think. | 01:21 |
| slangasek | and if you need to pass the baton off to me, I can take it | 01:21 |
| infinity | slangasek: Personally, I think that warrants a rebuild. | 01:21 |
| * slangasek nods | 01:21 | |
| slangasek | done then | 01:22 |
| slangasek | since the breakage was introduced in a narrow range of versions in oneiric, I'll probably make it an == conflict to not complicate natty->oneiric upgrades | 01:24 |
| infinity | slangasek: I already killed the arm builds, which take longer than everything else combined, so it's not like this makes things worse. | 01:26 |
| slangasek | yep | 01:30 |
| slangasek | ca-certificates uploaded | 01:30 |
| infinity | slangasek: There was only one broken -java version? | 01:30 |
| slangasek | infinity: in Ubuntu, yes | 01:30 |
| infinity | Handy. | 01:30 |
| slangasek | :) | 01:30 |
| slangasek | publisher running | 01:52 |
| slangasek | (or jogging in place) | 01:52 |
| micahg | ^^ that can wait until after beta 2, it's an FTBFS fix, but part of the ubuntustudio packageset | 02:24 |
| micahg | any objections from the release team for me to use the buildds for mozilla updates (all short ATM, will ask again before the long Firefox 7 ones) | 03:13 |
| infinity | micahg: Any chance you can do them serially? | 03:20 |
| infinity | I don't really feel like putting buildds on manual, not when I'm not sure how long I'll be up. | 03:21 |
| micahg | infinity: the buildd manager will max out at 60% for the PPA | 03:21 |
| micahg | so that's 1 for the 2 arch ones, 3 for i386 | 03:21 |
| infinity | When did this happen? | 03:21 |
| micahg | *2 per arch | 03:21 |
| infinity | Cause I've seen two ppa builds on the powerpc buildds before. | 03:21 |
| micahg | infinity: a year or so ago? | 03:21 |
| micahg | infinity: I'll only be using one PPA | 03:22 |
| micahg | it's per PPA | 03:22 |
| infinity | If you're sure you'll only eat one ppc buildd, go nuts. :P | 03:22 |
| infinity | I wasn't aware of this new shiny. | 03:22 |
| micahg | yeah, I'm sure :) | 03:22 |
| infinity | Of course, the kernel ppa will come bite me anyway. | 03:22 |
| micahg | I can't speak for the kernel team, anyways, my builds should only be 1.5 hrs at most on PPC | 03:22 |
| micahg | infinity: and since I don't need them until next week, I won't be upset if someone kills it | 03:23 |
| infinity | Mmkay. | 03:23 |
| pitti | ah, seems the netsplit has been fixed, according to global notice | 07:58 |
| pitti | jibel: so seems we can continue talking here | 07:58 |
| pitti | jibel, ev, cjwatson: I debugged bug 854717 and suggested a workaround | 08:23 |
| ubot4 | Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 1 other project) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 2) (heat: 12)" [Critical,Confirmed] https://launchpad.net/bugs/854717 | 08:23 |
| ev | pitti: thanks! I'll make that change momentarily. Reviewing your other patch now, though I don't think it's quite right. If you call stop_debconf while a page is running, you'll rip debconf from under its feet. | 08:25 |
| ev | I'll have a think about it | 08:25 |
| pitti | ev: right, I wasn't sure whether it's correct to call stop afterwards; but as it was stopped before, it seemed safer to stop it again | 08:26 |
| pitti | unless it's safe to have it there all the tiem? | 08:26 |
| pitti | ev: I'm reading i-power source right now | 08:26 |
| pitti | ev: but it seems that i-power is pretty tightly woven to g-s-d's power plugin; unfortunately it doesn't use upower directly | 08:27 |
| ev | and actually, I'll just disable that code path for now, as we're not actually using ubiquity/online just yet | 08:27 |
| ev | okay | 08:27 |
| pitti | so, it's still unclear why the earlier g-s-d fails to set the theme | 08:27 |
| pitti | if I disable ubiquity-dm's g-s-d launching, I just have one, but it doesn't set the theme either, so it's not just a race between two gsd's | 08:28 |
| seb128 | pitti, is there anything in .xsession-errors? the usual reason is "there is a xsettings manager already running" | 08:28 |
| ev | hmm | 08:28 |
| pitti | seb128: partially; but see the bug trail | 08:28 |
| seb128 | pitti, which is what we had in natty where the gdm g-s-d was not exiting before the session one starts for some users | 08:28 |
| pitti | seb128: /var/log/installer/dm doesn't have any messages about the g-s-d spawned by i-power | 08:28 |
| pitti | presumably becuase it's dbus activated, and thus its stdout/err isn't connected anywhere | 08:29 |
| pitti | which is a pity, as as it's a pain to see what's wrong with it | 08:29 |
| seb128 | well, feel free to ping jjardon about indicator-power questions | 08:29 |
| seb128 | he wrote it and he knows his stuff ;-) | 08:29 |
| pitti | oh, yes | 08:29 |
| seb128 | he's on #ubuntu-desktop | 08:30 |
| pitti | at the end of the day it seems to be a g-s-d problem, though | 08:30 |
| pitti | the one spawned by i-power should be able to set the theme as well | 08:30 |
| pitti | seb128: ^ or should it? does it need to be spawned by the session, or depend on environment variables? | 08:30 |
| pitti | .. like the session dbus, perhaps? | 08:31 |
| pitti | ah, no, it's spawned _by_ the session dbus, so that's definitively there | 08:31 |
| seb128 | pitti, I see no reason it should fail to set the theme | 08:31 |
| seb128 | it's basically just reading the gsettings value and applying the xsettings | 08:31 |
| pitti | seb128: right; but it does | 08:32 |
| pitti | so I think that's the root of the bug | 08:32 |
| seb128 | can you change g-s-d by a wrapper which call g-s-d 2>&1>/tmp/log or something? | 08:33 |
| seb128 | to get the g-s-d output | 08:33 |
| seb128 | bonus if you call it with --debug | 08:33 |
| pitti | seb128: nice idea | 08:33 |
| seb128 | you might want to include the pid number of something in the log name if you have 2 g-s-d running | 08:34 |
| pitti | I just patch away ubiquity's g-s-d spawning | 08:34 |
| seb128 | ok | 08:34 |
| * pitti has become pretty used to break=casper-bottom, hacking up the root fs, and then booting :) | 08:34 | |
| seb128 | ;-) | 08:35 |
| === doko_ is now known as doko | ||
| pitti | ev: I love the "value set" window title of ubiquity :) | 08:41 |
| ev | pitti: yeah, my most recent commit fixes that :) | 08:41 |
| ev | yay copy and paste | 08:41 |
| pitti | nice | 08:42 |
| === chrisccoulson_ is now known as chrisccoulson | ||
| pitti | ev, seb128: ah, see https://bugs.launchpad.net/ubuntu/+source/gnome-settings-daemon/+bug/854717/comments/12 | 08:51 |
| ubot4 | Launchpad bug 854717 in ubiquity (Ubuntu Oneiric) (and 3 other projects) "Broken panel icons and dialog style during ubiquity-dm and OEM install/final user configuration (affects: 2) (heat: 12)" [Critical,Confirmed] | 08:51 |
| pitti | seb128: so, it seems that g-s-d stays running, but doesn't do anything when it can't register? | 08:51 |
| seb128 | seems like a bug, I would expect it to just exit | 08:52 |
| pitti | seb128: but even if we fix that, indicator-power would just fail | 08:56 |
| seb128 | pitti, do we need indicator-power in the install mode? | 08:56 |
| pitti | so a longer-term fix would be either to make i-power use upower directly (currently discussing with jjardon) | 08:56 |
| pitti | or to start g-s-d earlier than the panel in ubiquity-dm | 08:56 |
| seb128 | I would go the g-s-d way | 08:57 |
| pitti | seb128: not crucial I think | 08:57 |
| pitti | seb128: but reading the g-s-d code it doesn't seem crucial that it registers; it should just go on | 08:57 |
| seb128 | it doesn't make sense to make efforts to write unity desktop code without GNOME | 08:57 |
| seb128 | i.e g-s-d is a basis desktop components nowadays we shouldn't try to fight to not have to use it, it's a waste of efforts | 08:58 |
| pitti | ev: long story short, I think we can just disable libupower.so in panel.c for b2; does that sound ok to you? | 08:58 |
| ev | pitti: works for me, will do now | 08:58 |
| pitti | seb128: I was mainly curious, as I don't think the g-s-d plugin provides anything that upower doesn't | 08:58 |
| pitti | seb128: and ubiquity-dm is a very case where we want the indicator without unity | 08:58 |
| seb128 | right, just convenient apis it seems | 08:59 |
| pitti | seb128: I suspect that jjardon might have missed the existence of libupower-glib, though | 08:59 |
| seb128 | pitti, well, without unity yes, but maybe g-s-d can be running | 08:59 |
| pitti | right, it should be running | 08:59 |
| pitti | cf. the other solution I suggested | 08:59 |
| pitti | start g-s-d, then the panel | 08:59 |
| seb128 | that would be my preferred solution | 09:00 |
| seb128 | pitti, libupower-glib, maybe he missed it, but why is g-s-d duplicating that logic rather than using libupower-glib as well? | 09:00 |
| ev | right, uploading a new ubiquity now | 09:00 |
| seb128 | pitti, it's the same person who wrote upower, gpm and the gsd power code, there is probably a reason why it's done the current way ;-) | 09:01 |
| pitti | seb128: g-s-d does use libupower-glib | 09:01 |
| seb128 | pitti, but anyway, not a topic for now and there, better to take that offline with jjardon | 09:01 |
| seb128 | pitti, well jjardon said the g-s-d code to copy would be non trivial so I assume it's not only a few calls to libupower-glib | 09:01 |
| pitti | seb128: yeah, as I said this wasn't meant to be a blame or a bug, I was just curious why it's using g-s-d, as I didn't see a real reason to | 09:02 |
| seb128 | pitti, should be let some of small applications in if we are going to respin? | 09:02 |
| seb128 | things like eog, etc | 09:02 |
| seb128 | or better to after beta2? | 09:02 |
| pitti | I let oneconf in, as this was small and focused | 09:03 |
| pitti | but now we have about zero margin for errors :/ | 09:03 |
| seb128 | ok | 09:03 |
| pitti | seb128: if you have something in the queue which fixes a major bug and has a safe fix, that's fine | 09:03 |
| seb128 | checking the queue | 09:03 |
| seb128 | pitti, couchdb-glib would be nice | 09:04 |
| seb128 | it fixes contacts syncing I think | 09:05 |
| pitti | hm, no bug for this? | 09:05 |
| pitti | seb128: we won't respin alternates, BTW | 09:05 |
| seb128 | ok | 09:06 |
| seb128 | is couchdb-glib on the CD? | 09:06 |
| seb128 | no bug> hum, right, I just saw that rodrigo fixed it and chrisccoulson tested the fix yesterday | 09:06 |
| pitti | seb128: ah, seems not; so shoudl be fine | 09:06 |
| * pitti accepts | 09:06 | |
| seb128 | danke | 09:06 |
| seb128 | pitti, everything else doesn't seem worth taking the risk | 09:07 |
| seb128 | so better to delay the others to after beta2 | 09:07 |
| pitti | *nod* thanks for checking | 09:07 |
| pitti | ev: seems the window title fix is not in that upload? | 09:07 |
| pitti | ev: if that's intended it's fine, the upload looks good; just wondering whether there was something wrong with a commit | 09:10 |
| cjwatson | slangasek: ack, when my brain is working well enough to understand openssl code, I'll take a look | 09:13 |
| * pitti accepts ubiqity, to give it a chance to build before the next publisher | 09:14 | |
| ev | pitti: the window title fix is not setting self.custom_title to the return value of self.db.set | 09:20 |
| pitti | aah ;) | 09:21 |
| === s1aden is now known as sladen | ||
| ogra_ | pitti, when did you start the armel builds (my log has a time skew and i need to know when i need to look after downloading them) | 10:49 |
| pitti | hey ogra_ | 10:50 |
| pitti | ogra_: at 07:23 UTC, i. e. 09:23 CEST | 10:50 |
| ogra_ | thanks ! | 10:50 |
| pitti | ogra_: the first two builds are done, the second two are building | 10:50 |
| ogra_ | so its anothe 3-4h | 10:50 |
| ogra_ | yeah | 10:50 |
| ogra_ | its ~3h per arch | 10:50 |
| pitti | after that I'll build server, then kubuntu | 10:50 |
| ogra_ | good | 10:50 |
| pitti | ogra_: no, 1.5/2 h | 10:50 |
| ogra_ | then someone did something to the buildd :) | 10:51 |
| pitti | ogra_: well, the second pair could very well take longer :) | 10:51 |
| ogra_ | it used to be 3h/flavour for two arches | 10:51 |
| ogra_ | so i assumed twice the time for 4 arches :) | 10:51 |
| ogra_ | indeed i'm happy if its faster ;) | 10:52 |
| pitti | ogra_: yeah; what do we care if the builders sweat more now :) | 10:52 |
| cjwatson | oh, whoops, I just accepted isdnutils and then realised it's in the ubuntustudio package set | 10:53 |
| ogra_ | well, i would love to have builders in the cluster that we can just randomly assign in situations like milestones :) | 10:53 |
| cjwatson | hopefully we can disregard that for image preparation purposes; it was a build fix | 10:53 |
| pitti | cjwatson: also, we don't currently plan to rebuild it | 10:53 |
| pitti | but if ISDN stops working, nobody really should notice | 10:54 |
| ScottK | pitti: I'd like to get kdepim-runtime in even if we can't get it on some/all Kubuntu images since it fixes a data loss bug. I'd appreciate if you would review/accept. | 11:09 |
| pitti | ScottK: looks fine, accepted | 11:13 |
| ScottK | pitti: Thanks. | 11:13 |
| pitti | ScottK: no worries, I can shuffle the build queue to build kubuntu a bit later, so that this has some time to publish | 11:13 |
| ScottK | Great. | 11:13 |
| pitti | ScottK: noted so on the pad | 11:14 |
| pitti | at last! ubiquity 2.7.34 | 11:21 |
| * pitti starts the build queue of doom | 11:21 | |
| pitti | jibel: so what was the thing with the "total failure" you mentinoed this morning with the alternate CD? the tracker seems have successes? | 11:41 |
| pitti | mvo, jibel: FYI, I just re-enabled the upgrade tests; should work better now with cups | 11:43 |
| pitti | ogra_: desktop builds on the buildds just finished, BTW; sycamore took 4:15 hours in total, annonaceae took 3:40 | 11:49 |
| jibel | pitti, I re-ran all the tests both manually and automatically and it passed. I don't know what happened during the night, maybe an infrastructure or network problem. | 11:56 |
| jibel | I'll retry upgrades. | 11:56 |
| ogra_ | pitti, wow, thats a lot less than i expected (still way to long though, we will add more builds next release) | 11:56 |
| * ogra_ waits for them to publish | 11:57 | |
| pitti | ogra_: they could be built on different builders perhaps? | 11:57 |
| ogra_ | we have two builders and four subarches | 11:57 |
| pitti | ogra_: will still take a bit, cron.daily-preinstalled is running | 11:57 |
| ogra_ | we already share them between two machines, but i fezar we noeed more next release | 11:58 |
| * ogra_ really doesnt want to hit 6h build times for one flavour | 11:59 | |
| cjwatson | ideally we need something that doesn't involve code on antimony having to explicitly select a builder | 12:10 |
| cjwatson | I'd rather have something that dispatches to an idle builder if available and sends us a completion indication when it's done (which we would probably just block on) | 12:10 |
| cjwatson | in some ways it would be easier if livefses were actual LP build jobs | 12:10 |
| cjwatson | that would be a big enough chunk of work to require escalation through LP stakeholders though | 12:11 |
| pitti | ogra_: http://cdimage.ubuntu.com/daily-preinstalled/20110921/ | 12:17 |
| ogra_ | yay | 12:17 |
| * ogra_ syncs | 12:17 | |
| pitti | ogra_: will we release mx5? | 12:17 |
| pitti | if so, we need a new product in the tracker, we only have imx51 (unless that's the same) | 12:18 |
| ogra_ | pitti, well, that rebuild was only for mx5 :) | 12:18 |
| ogra_ | i'll ask janimo, he owns mx5 | 12:18 |
| ogra_ | i know we want to release it ... | 12:19 |
| pitti | building server and kubuntu preinstalled now | 12:19 |
| pitti | http://cdimage.ubuntu.com/daily-live/20110921.1/ published for testing | 12:20 |
| pitti | jibel: can we rename "Ubuntu Desktop armel+imx51" to "Ubuntu Desktop armel+mx5"? | 12:21 |
| ogra_ | and there is janimo :) | 12:22 |
| pitti | hello janimo, how are you? | 12:22 |
| janimo | pitti, hi, should have the same type of testing as the omap flavours so wherever it fits in the iso tracker namespace | 12:22 |
| pitti | janimo: is imx51 == mx5? | 12:22 |
| janimo | pitti, mx5 is a more generic name for a kernel (and eventually image) | 12:23 |
| janimo | that works with mx53 and the older mx51 too | 12:23 |
| janimo | but for now we only test on mx53 | 12:23 |
| pitti | so I'll just add it as armel+imx51, and ask jibel to rename it in the DB | 12:23 |
| janimo | pitti, what we test on now is imx53 | 12:23 |
| ogra_ | well, the arch name is mx5 | 12:24 |
| janimo | imx51 is an older subarch | 12:24 |
| ogra_ | we usually use the subarch names | 12:24 |
| pitti | jibel: right, but we only have an "armel+imx51" product; as I said, we ought to rename it in the db to match the image names | 12:24 |
| janimo | ok | 12:24 |
| ogra_ | yeah, that should be fine | 12:24 |
| pitti | janimo: thanks | 12:24 |
| janimo | pitti, thanks for adding it :) | 12:24 |
| ogra_ | janimo, you will need a tracker account btw (since you will liekly want to note down test results) | 12:24 |
| janimo | ogra_, I knew there was a trap somewhere when you asked whether I want it to be on the tracker :) | 12:25 |
| ogra_ | haha | 12:25 |
| ogra_ | yeah, it was a diplomatic trick ;) | 12:25 |
| ogra_ | but seriously, the person owning a subarch should indeed have a tracker account to note down test results :) | 12:26 |
| janimo | I did not intend to own it, just for it to be on the tracker. But yes, I'll get an account | 12:27 |
| ogra_ | you should tell david :) | 12:27 |
| ogra_ | i think he assume you own it | 12:27 |
| ogra_ | *assumes | 12:27 |
| janimo | well my panda is fried, I guess I was bound to get closer to my MX53 | 12:29 |
| jibel | pitti, I'd rather add a new product, it is a preinstalled image and test case is different from the former imx51 | 12:29 |
| pitti | jibel: ah, ok; do we already have defined test cases, or do we just copy the ones from ac100/omap? | 12:30 |
| jibel | ogra_, is the testcase for mx5 http://testcases.qa.ubuntu.com/Install/ARM/PreinstalledImage like omap/ac100 ? | 12:32 |
| ogra_ | its the same desktoip testcase for all desktop images | 12:33 |
| ogra_ | (we dont build mx5 server or other images) | 12:33 |
| pitti | jibel, janimo, ogra_: ok, I delete the imx51 image from the tracker then, don't get scared | 12:33 |
| * ogra_ wont :) | 12:33 | |
| ScottK | Actually, AIUI our mx5 is mx53 only now, so calling it mx51 would be a mistake. | 12:40 |
| jibel | added product ubuntu desktop mx5 and posted build 20110921 | 12:42 |
| pitti | jibel: cheers | 12:42 |
| pitti | infinity, cjwatson, skaet: FYI, I just updated publish-image-set.py for the armel architecture list du jour, so please bzr update before you run this | 12:43 |
| ScottK | pitti: Would you please sync thaweb 3.0.12-1 from Debian non-free. There's an upload in queue that doesn't have origin set correctly and so I'd rather get it done as a proper sync. | 12:43 |
| pitti | ScottK: ack | 12:43 |
| ScottK | Thanks. | 12:43 |
| pitti | ScottK: did you already reject it? | 12:43 |
| ScottK | pitti: I did. | 12:44 |
| * pitti can't see it | 12:44 | |
| pitti | ah | 12:44 |
| pitti | ScottK: who requested it? | 12:44 |
| ScottK | Just a sec | 12:44 |
| cjwatson | pitti: ta | 12:44 |
| ScottK | "Ø£Øمد المØمودي (Ahmed El-Mahmoudy)" <aelmahmoudy@sabily.org> | 12:45 |
| cjwatson | stgraber: is POSTing to /qatracker/admin/addbuild (including hardcoding/scraping of milestone and testcase numbers) still the best way for a client script to post new builds to iso.qa? | 12:46 |
| pitti | ScottK: done | 12:46 |
| ScottK | Thanks. | 12:47 |
| lamont | cjwatson: mvo skaet: the current workaround for the archive slew is as follows: | 12:51 |
| lamont | when ftpmaster triggers syncproxy, the mirroring script now waits 25 minutes after it finishes syncing before removing the lockfile, blocking any subsequent trigger for 25 minutes beyond the ~ 20 minutes it takes for the script to run. | 12:52 |
| lamont | this sucks, but it at least means that the triggered mirrors get a chance to get a consistent copy in their rsync | 12:53 |
| lamont | and gives us a little time to test and deploy something that will eliminate the slew entirely (COW is my friend) | 12:53 |
| cjwatson | could be worse, as workarounds go. thanks | 12:55 |
| lamont | that was kind of the thinking | 12:56 |
| lamont | but it does mean that if you're doing rapid & manual publisher runs, you can get out your marker and scratch out "rapid" | 12:56 |
| lamont | sadly, this is all futurespeak, since the current run started before the change to the script | 12:58 |
| cjwatson | You say that as if the publisher is likely to finish inside 25 minutes anyway | 12:58 |
| lamont | heh | 12:58 |
| cjwatson | I suspect what went wrong here was manual mirror triggers to force out ca-certificates munging | 12:59 |
| cjwatson | lamont: and I guess http://archive.ubuntu.com/ubuntu/pool/universe/d/diffutils/diff_2.8.1-18_all.deb being AWOL is another instance of this? | 13:02 |
| lamont | cjwatson: every instance will be one where there is a symlink between components | 13:04 |
| lamont | and any of them has a reasonable liklihood of being b0rked | 13:04 |
| * cjwatson nods | 13:04 | |
| pitti | ah, I guess that mirror desync might be why the current live builds are failing? (hash sum mismatch) | 13:04 |
| lamont | pitti: verily | 13:10 |
| lamont | pitti: and at this point, I'm forecasting that it'll all be better about 40 minutes after the current (10 min old) publisher run finishes on cocoplum | 13:13 |
| pitti | lamont: that sounds fine, thanks; I'll just run the cron.daily-live's then | 13:14 |
| cjwatson | verily> have I mentioned a friend of mine's suggestion for fixing the problem that True/False Yes/No etc. don't line up in source code? | 13:16 |
| cjwatson | which was to use VERILY and NOWISE | 13:16 |
| cjwatson | and this has the bonus that it allows for tristates: VERILY NOWISE MAYHAP | 13:17 |
| lamont | cjwatson: LOL | 13:17 |
| pitti | and OHCRAP for error conditions | 13:18 |
| cjwatson | not quite in the right register, I feel :-) | 13:18 |
| pitti | cjwatson: that must be from the FORTH age | 13:18 |
| cjwatson | although I always liked dpkg's error function naming | 13:18 |
| pitti | heh, yes | 13:18 |
| pitti | fortunately few people ever see this | 13:19 |
| cjwatson | ohshit for die-with-error-message; ohshite for die-with-error-message-and-errno | 13:20 |
| pitti | http://cdimage.ubuntu.com/ubuntu-server/daily/20110921/ posted (including arm) | 13:21 |
| pitti | Daviey: ^ FYI | 13:21 |
| lamont | cjwatson: your last one violates your 6 character specification... maybe switch to latin? | 13:22 |
| lamont | heh | 13:22 |
| cjwatson | stgraber: oh, and do you think it's generally better to hardcode testcase numbers (e.g. 114) or testcase names (e.g. "Ubuntu Server EC2 EBS (Europe) amd64")? | 13:23 |
| stgraber | good morning, sorry for being a bit late my ISP decided to change my IP and so I had to spend half an hour updating DNS/IPSEC/IPv6 so that I get something working again... | 13:27 |
| stgraber | cjwatson: testcase number shouldn't change as often as the name. Using /addbuild is currently the best way of doing it when you don't have access to limequat.canonical.com | 13:29 |
| cjwatson | just thinking of writing an autoposter for cdimage | 13:29 |
| stgraber | cjwatson: otherwise, I guess we could run a small service on limequat that pushes new entries directly in the DB (with a small internal only service) | 13:29 |
| cjwatson | I guess that means hardcoding a load of testcase numbers in cdimage code? | 13:29 |
| cjwatson | presumably we should also have a role user for cdimage | 13:31 |
| stgraber | why do you need testcase number? don't you just need product number and milestone number? | 13:31 |
| stgraber | oh, nevermind just read the backscroll properly ;) you're indeed talking about product number (though as testcase number) | 13:32 |
| stgraber | so yeah, using the product number "Ubuntu Alternate amd64" should be safe and a lot more readable | 13:32 |
| cjwatson | it's called "isota_case" | 13:33 |
| stgraber | these don't change too often and when they do, they're usually different enough that you'd want to check your code anyway | 13:33 |
| cjwatson | but right, I mean products | 13:33 |
| pitti | they just changed a few hours ago, btw (imx51 -> mx5) | 13:33 |
| pitti | and we did some changes during beta-1, too | 13:33 |
| pitti | publish-image-set.py has quite some bzr history for these | 13:34 |
| doko | is heimdal on the images? or could it be approved? change to the -dev package only | 13:35 |
| cjwatson | pitti: from cdimage's point of view, mx5 was already a different product from imx51 | 13:36 |
| cjwatson | and in that case, we got a new product number as well as a new product name, anyway | 13:37 |
| cjwatson | so that's moot | 13:37 |
| ogra_ | ev, http://paste.ubuntu.com/694452/ any idea ? is it because we dont have an oem user on armel ? | 13:40 |
| ogra_ | (looks like it treis to query NM) | 13:41 |
| stgraber | cjwatson: http://paste.ubuntu.com/694453/ | 13:41 |
| stgraber | cjwatson: I guess that's something I'd need to export whenever I get an API into that thing :) | 13:41 |
| ev | ogra_: already fixed in the new ubiquity | 13:41 |
| ogra_ | bah | 13:41 |
| ogra_ | then thats not in the current armel build | 13:41 |
| ogra_ | pitti,^^^ | 13:41 |
| pitti | ogra_: erk, you need ubiquity on the preinstalled ones? | 13:42 |
| pitti | ogra_: sorry, then we need a respin | 13:42 |
| pitti | so far my mental model was "no ubiquity for preinstalled" | 13:42 |
| ogra_ | pitti, yes, all preinstalled (including server) use oem-config | 13:43 |
| ogra_ | which nowadays is ubiquity :) | 13:43 |
| * ogra_ wonders who said we dont use it | 13:43 | |
| pitti | there were cases of ubiquity bugs where in previous releases we didn't need to rebuild the armels | 13:44 |
| pitti | but presumably because of bugs which didn't affect oem-config | 13:44 |
| ogra_ | yeah, but thats just because they didnt affect arm | 13:44 |
| ogra_ | or oem-config, right | 13:44 |
| ogra_ | the fun is that i just got a success report from a user for the same image | 13:44 |
| ogra_ | the error doesnt look like he could have gotten past it | 13:45 |
| pitti | ogra_: it only crashes if you are offline | 13:45 |
| pitti | if you are connected to a network, it works | 13:45 |
| pitti | so it's quite possible | 13:45 |
| ogra_ | well, given i have wlan and it crashes before i get even access to NM ... | 13:45 |
| ogra_ | he might have a faster system (my rootfs goes to very slow USb media) | 13:45 |
| pitti | I disabled the ubuntu desktop armels in the tracker | 13:46 |
| ogra_ | oh, i also noted that g-s-d got really really crashy on startup | 13:46 |
| seb128 | use apport and send a bug | 13:46 |
| seb128 | didn't get a g-s-d issue in weeks there | 13:46 |
| ogra_ | it had to do several attempts while i saw the generic theme and icons | 13:46 |
| ogra_ | eventually it started though | 13:46 |
| pitti | ogra_: during oem-config, or the actual session? | 13:47 |
| ogra_ | i dont have that on my upgraded oneiric install | 13:47 |
| pitti | ogra_: during oem-config> that was fixed | 13:47 |
| ogra_ | pitti, ubiquity-dm i think | 13:47 |
| pitti | ogra_: yep, fixed in ubiquity .34 | 13:47 |
| ogra_ | ah, good | 13:47 |
| ogra_ | so that last rebuild was kind of a waste of time :) | 13:47 |
| ogra_ | well, jani will probably disagree, at least we got mx5 images | 13:48 |
| jibel | cjwatson, I already does the match here http://reports.qa.ubuntu.com/reports/isotesting/oneiric/report.html to track which image is ready for testing | 13:57 |
| jibel | my problem was that limequat doesn't have access to people.canonical.com to discover which image is ready | 13:58 |
| jibel | but if you can push a file to limequat with the flavor, buildnumber and name of the iso/image, it could be imported periodically and update the tracker. | 13:58 |
| === shadeslayer_ is now known as shadeslayer | ||
| utlemming | skaet: can we add the latest Oneiric daily build to tracker? http://uec-images.ubuntu.com/oneiric/20110921.1/ | 14:08 |
| skaet | utlemming, ok, will do. | 14:10 |
| utlemming | skaet: thank you kindly | 14:10 |
| pitti | hey skaet | 14:11 |
| skaet | heya pitti | 14:14 |
| skaet | how go the builds? | 14:14 |
| pitti | slowly :) | 14:14 |
| pitti | skaet: mirroring problems, and general slowness of arms | 14:15 |
| pitti | skaet: we had to do another ubiquity upload this morning | 14:15 |
| skaet | pitti, yup, etherpad let me see that. | 14:15 |
| * skaet wonders why the pad won't let me see it after 10pm *shrug* | 14:16 | |
| pitti | skaet: builtin bedtime mode? | 14:16 |
| skaet | pitti, meh, fustration mode is more like it. :P | 14:16 |
| skaet | ah well. | 14:17 |
| skaet | pitti, so we have confirmation all the certificate issues have been resolved now? | 14:17 |
| pitti | skaet: ca-certificates? we have a fix in the archive, but nobody said yet "yes, it's fixed now" | 14:17 |
| pitti | that reminds me, someone else ran into that; didrocks, was that you? | 14:18 |
| pitti | didrocks: libnss3 missing? | 14:18 |
| cjwatson | >>> import isotracker | 14:18 |
| cjwatson | >>> isotracker.product_code('Edubuntu DVD amd64') | 14:18 |
| cjwatson | u'3' | 14:18 |
| cjwatson | >>> isotracker.product_code('Edubuntu DVD i386') | 14:18 |
| cjwatson | u'4' | 14:18 |
| cjwatson | getting there | 14:18 |
| didrocks | pitti: indeed, just had it | 14:18 |
| pitti | didrocks: which versino of ca-certificates{,-java} did you upgrade from and to? | 14:19 |
| didrocks | pitti: let me see what version I had before rebooting | 14:19 |
| didrocks | checking | 14:19 |
| stgraber | cjwatson: cool! once I've got some time to work on the tracker and get some kind of API implemented it should be quite trivial to just update that python module then | 14:19 |
| skaet | stgraber, cjwatson. :D excellent news. | 14:20 |
| stgraber | cjwatson: if you want a role account for cdimage, just register one on the tracker and let me know the username so I can make it an admin | 14:20 |
| didrocks | pitti: so I booted successfully this morning (nss3 there). Then upgraded ca-certificates:i386 (20110502+nmu1, 20110502+nmu1ubuntu3) and ca-certificates-java:i386 (20110912ubuntu1, 20110912ubuntu2). After rebooting, no nss3 | 14:21 |
| pitti | didrocks: right, fix went into -java 20110912ubuntu3 | 14:21 |
| skaet | utlemming, http://uec-images.ubuntu.com/oneiric/20110921/ shows log.stdout.stderr - where do you want me refreshing the tracker from? | 14:21 |
| didrocks | pitti: yeah, I updated it before rebooting in fact: ca-certificates-java:i386 (20110912ubuntu2, 20110912ubuntu3) | 14:22 |
| didrocks | pitti: but I guess the file was already removed | 14:22 |
| pitti | right | 14:22 |
| pitti | if you install ubuntu2, you are doomed, I'm afraid | 14:22 |
| didrocks | so can't really confirm the fix | 14:22 |
| pitti | well | 14:22 |
| didrocks | can try downgrading | 14:22 |
| pitti | didrocks: you could downgrade to the old version | 14:22 |
| didrocks | doing then | 14:22 |
| pitti | then install nss3, and upgrade again? | 14:22 |
| didrocks | downgrading ca-certificates-java to 20110912ubuntu1, isn't it? | 14:23 |
| didrocks | then reboot, then upgrade to 20110912ubuntu3 | 14:23 |
| pitti | yeah | 14:23 |
| didrocks | andd check the file | 14:23 |
| didrocks | doing | 14:23 |
| pitti | shouldn't really need a reboot | 14:23 |
| pitti | just reinstall of nss3 | 14:23 |
| utlemming | skaet: http://uec-images.ubuntu.com/oneiric/20110921.1/ -- you're missing the .1 | 14:23 |
| didrocks | pitti: reinstalled is already done, otherwise, I won't be online :) | 14:23 |
| skaet | utlemming, thanks! | 14:24 |
| utlemming | skaet: :) | 14:25 |
| cjwatson | is it just me or is iso.qa refusing connections right now? | 14:26 |
| stgraber | cjwatson: works here | 14:26 |
| Laney | wfm | 14:26 |
| pitti | oh, look! mirrors work again, ubuntu DVD built | 14:27 |
| pitti | ^ lamont :) | 14:27 |
| * pitti builds the other missing live images then | 14:27 | |
| didrocks | pitti: works here, still have the file after the upgrade | 14:27 |
| * didrocks updates the bug | 14:27 | |
| lamont | pitti: cool | 14:27 |
| cjwatson | works now for me, must have been transient | 14:28 |
| Daviey | cjwatson: it was done for a period, along with all the other sites on the box | 14:28 |
| cjwatson | ah | 14:29 |
| skaet | utlemming, ok should be published. | 14:29 |
| pitti | http://cdimage.ubuntu.com/dvd/20110921/ posted | 14:30 |
| jamespage | are there current/outstanding issues with archive mirrors? I'm seeing 403 errors on all ec2 regions during litmus testing prior to testing 20110921.1 | 14:31 |
| Daviey | 403?! That is unrelated to the other issues, i believe | 14:32 |
| Daviey | I suspect the ec2 mirrors are just broken. | 14:33 |
| cjwatson | Daviey: same thing I believe; alternates between 404 and 403 | 14:34 |
| cjwatson | jamespage: I think this is what lamont has been working on | 14:34 |
| jamespage | cjwatson: OK - I'll hold off the full test and can re-run the litmus test as and when required to validate its good | 14:34 |
| Daviey | cjwatson: ah, ok. | 14:35 |
| lamont | jamespage: I'm going to guess you don't want to wait up to 3 hours for that,right? | 14:37 |
| jamespage | lamont: not really | 14:37 |
| jamespage | the full test run takes another 1.5 hours after tha | 14:37 |
| jamespage | so if we can get it fixed now that would be great | 14:37 |
| jamespage | :-) | 14:37 |
| pitti | ogra_: staring new ubuntu preinstalled build | 14:38 |
| pitti | "starting", too | 14:38 |
| ogra_ | thx | 14:38 |
| lamont | jamespage: triggered all 5 regions. they'll come current sometimeish | 14:39 |
| jamespage | lamont: thankyou | 14:40 |
| pitti | http://cdimage.ubuntu.com/xubuntu/daily-live/20110921.2/ posted | 14:52 |
| charlie-tca | Thank you | 14:52 |
| pitti | http://cdimage.ubuntu.com/mythbuntu/daily-live/20110921.1/ posted | 14:54 |
| pitti | http://cdimage.ubuntu.com/lubuntu/daily-live/20110921.1/ posted | 14:56 |
| cjwatson | is there a product I could harmlessly post something to on iso.qa for testing? | 14:56 |
| pitti | cjwatson: ubuntu netbook perhaps? | 14:56 |
| cjwatson | anyone object to that? | 15:01 |
| cjwatson | I guess it might cause some spurious mails; I'd like something nobody is subscribed to | 15:01 |
| pitti | cjwatson: Netboot arm imx51 perhaps? | 15:02 |
| cjwatson | stgraber: is anyone subscribed to ^- that? | 15:03 |
| stgraber | cjwatson: checking | 15:03 |
| GrueMaster | Probably me. Filters activated. Fire at will. | 15:03 |
| pitti | http://cdimage.ubuntu.com/kubuntu/daily-preinstalled/20110921/ posted | 15:05 |
| pitti | nice, after hours of waiting they now come in in hordes | 15:05 |
| jpds | Poor will. | 15:05 |
| stgraber | cjwatson: two users are subscribed, checking who they are | 15:06 |
| stgraber | cjwatson: GrueMaster and plars | 15:06 |
| cjwatson | ok, I guess they can both cope | 15:06 |
| GrueMaster | plars likes mail. Have fun. | 15:07 |
| cjwatson | GrueMaster: can you let plars know to ignore this? | 15:07 |
| cjwatson | excellent, that worked | 15:07 |
| cjwatson | $ ./post-image-to-iso-tracker.py 'Ubuntu Netbook armel+imx51' 20110921 | 15:07 |
| GrueMaster | yes, I'll ping him. Or can you just unsubscribe him? | 15:07 |
| cjwatson | I already posted and have removed it agan | 15:07 |
| cjwatson | *again | 15:07 |
| cjwatson | committed to ubuntu-archive-tools; hopefully I haven't broken post-amis-to-iso-tracker.py | 15:09 |
| stgraber | cjwatson: yeah! | 15:11 |
| pitti | http://cdimage.ubuntu.com/kubuntu/daily-live/20110921.1/ posted | 15:11 |
| cjwatson | skaet: do you want to specify exactly when cdimage should auto-post images to the tracker? you suggested that it should post an image that was marked rebuilding, but I wonder if perhaps we should be posting anything during certain time periods, or something like that | 15:12 |
| skaet | cjwatson, yeah, we should probably all come up with some heuristics. certainly when the iso-tracker is primed for a release (ie. switched over to beta 2 from beta 1), might be part of the heuristic | 15:13 |
| skaet | I figured it it was marked for rebuild it was obvious something was expected, and a change was expected. | 15:14 |
| skaet | One thing I'm worrying about is an image gets built and "stomps" on something that wasn't expected to be updated. | 15:14 |
| cjwatson | mm, cdimage doesn't really know whether isotracker's default release is an imminent one or not | 15:14 |
| cjwatson | yeah | 15:15 |
| cjwatson | experimental builds | 15:15 |
| skaet | indeed. maybe just keeping it when the tracker is expecting a build for now? Then work on some heuristics together either on list, or at UDS? | 15:15 |
| cjwatson | maybe just a CDIMAGE_POST_QA environmenet variable? | 15:15 |
| skaet | that could be an option too. | 15:15 |
| cjwatson | if you set to non-empty, the image gets auto-postd | 15:15 |
| cjwatson | since all of these builds are getting done manually anyway | 15:16 |
| cjwatson | you have to remember to unset it at the end of a build pass | 15:16 |
| skaet | yeah, that could work. remembering to unset it though could be triggered by the release being done? | 15:17 |
| cjwatson | can't see how that could unset environment variables in people's shells :-) | 15:18 |
| skaet | ah yeah, I was thinking it might be something on cdimage - but that's not what is happening today. :) | 15:19 |
| GrueMaster | What is the status of armel rebuilds? I heard earlier that we were respinning (yet again) due to oem-config issues? | 15:29 |
| pitti | GrueMaster: it's running | 15:29 |
| pitti | GrueMaster: kubuntu and server are already up to date and in the tracker | 15:30 |
| GrueMaster | ok. kubuntu is low on my list, but will pull separately for testing. | 15:30 |
| pitti | GrueMaster: pad and tracker are both up to date | 15:30 |
| cjwatson | phew. are we still going? | 15:35 |
| cjwatson | oh, blast, echan | 15:37 |
| pitti | cjwatson: we are still going as well, anyway :) | 15:37 |
| pitti | skaet, infinity: as noted on the pad, kubuntu DVD, edubuntu DVD, and ubuntu preinstalled images are currently building, the rest is built/published | 15:38 |
| pitti | no known blockers/breakage | 15:38 |
| pitti | skaet, infinity: can I hand over the baton back to you? I'd like to go to Taekwondo this evening | 15:39 |
| pitti | already skipped on Monday, and I can really use some exercise, I think :) | 15:39 |
| skaet | pitti, thanks. yes, baton accepted. :) | 15:39 |
| pitti | skaet: can you add the images to the tracker as they come in? kubuntu ETA 10 mins, edubuntu ETA 30 mins, ubuntu preinst ETA 3 h | 15:39 |
| skaet | pitti, sure will do. | 15:40 |
| skaet | pitti, by the way, the latest updates seem to resolve most of the crashes I was seeing yesterday. \o/ | 15:40 |
| pitti | thanks; good night everyone! | 15:40 |
| pitti | skaet: nice | 15:40 |
| * skaet reinstalling natty now, and trying to do upgrade from there. | 15:40 | |
| pitti | skaet: oh, kubuntu DVD just coming in, adding | 15:41 |
| pitti | infinity: will you do the pre-publishing later today, when some u/k desktop images testing results? | 15:41 |
| * pitti waves | 15:42 | |
| * skaet waves back to pitti | 15:49 | |
| infinity | pitti: Been a while since I did that, but I'm sure I can dust off the skills. | 15:54 |
| cjwatson | are there any install-from-USB test reports on the tracker? | 15:56 |
| jamespage | lamont, all regions aside from us-east-1 now look OK | 15:57 |
| * lamont takes a quick peek | 16:00 | |
| charlie-tca | So, after all that time, software center did not get the fix for Xubuntu. It is unusable by Xubuntu users in Oneiric. | 16:05 |
| cjwatson | mvo: ^- | 16:07 |
| cjwatson | urgh, bits of iso.qa are painful to screen-scrape | 16:08 |
| cjwatson | like the front page | 16:09 |
| infinity | charlie-tca: What's wrong with it in Xubuntu? Not that I use SC, but starting it up, it seems fine... | 16:09 |
| infinity | (Other than being unthemed because it's GTK3, and I'm using a GTK2-only theme...) | 16:10 |
| charlie-tca | in a fresh install with the latest images, it crashes | 16:10 |
| mvo | charlie-tca: its waiting in the queue | 16:10 |
| charlie-tca | It will not start | 16:10 |
| infinity | Weird. I wonder why it works here. | 16:10 |
| charlie-tca | mvo: I know | 16:10 |
| charlie-tca | but I would have thought after waiting all night for images, we might have gotten it in | 16:10 |
| charlie-tca | infinity: it will not start at all, 32bit and 64bit installs on hardware | 16:12 |
| skaet | mvo, is that what's fixed by the new update-manager that's just gone on the queue? | 16:13 |
| mvo | skaet: u-m is a different fix, its not urgent (at all) | 16:14 |
| skaet | mvo, thanks. | 16:15 |
| infinity | skaet: This is software-centre we're talking about. | 16:15 |
| infinity | I wish someone had told me how broken it was yesterday, I would have pushed it through before the last world rebuild. :/ | 16:16 |
| charlie-tca | The best I could suggest now is updates, since I am running out of hours already to get things tested. | 16:17 |
| skaet | infinity: gotcha. | 16:17 |
| charlie-tca | I have to plan 6-8 hours for all the images | 16:17 |
| infinity | charlie-tca: Updates? | 16:18 |
| charlie-tca | yeah, sudo apt-get dist-upgrade right after installing? | 16:18 |
| infinity | Oh, yeah. | 16:18 |
| infinity | I thought you meant "oneiric-updates", and I was about to point out that this is a beta, not final. :P | 16:18 |
| charlie-tca | sorry, bad wording | 16:19 |
| infinity | But yes, SC broken on Xubuntu probably isn't the end of the world for a beta, just unfortunate. | 16:19 |
| infinity | And not install-path-critical, so yes, updating tomorrow would fix it. | 16:19 |
| charlie-tca | I agree, and we still include Synaptic Package Manager by default, too. | 16:19 |
| utlemming | Automated testing for cloud-images is currently blocked due to EC2 mirrors in US-East being out. IS will be looking at that shortly. | 16:24 |
| skaet | ScottK, kubuntu dvd posted | 16:27 |
| jamespage | utlemming: just testing again now | 16:41 |
| jamespage | utlemming: https://jenkins.qa.ubuntu.com/job/oneiric-server-ec2-adhoc/ looking OK now | 16:41 |
| jamespage | will kick off the full run | 16:41 |
| skaet | mvo, jibel - fresh update from natty is stumbling into crash on update. Can anyone else confirm? | 16:50 |
| skaet | (issue is gnome-settings-daemon crashed with SIGSEGV in g_simple_asynch_result_complete()) | 16:51 |
| charlie-tca | yup | 16:52 |
| charlie-tca | confirmed on Xubuntu, bug 832603 | 16:53 |
| ubot4 | Launchpad bug 832603 in gnome-settings-daemon (Ubuntu Oneiric) (and 2 other projects) "gnome-settings-daemon crashed with SIGSEGV in g_simple_async_result_complete() (affects: 601) (dups: 75) (heat: 2762)" [High,Triaged] https://launchpad.net/bugs/832603 | 16:53 |
| jibel | skaet, bug 832603 | 16:53 |
| jibel | skaet, excuse my slow brain. charlie-tca was faster | 16:54 |
| utlemming | jamespage: thanks for kickign testing again | 16:54 |
| skaet | :) | 16:54 |
| jamespage | utlemming, np | 16:54 |
| skaet | jibel, charlie-tca - thanks. | 16:54 |
| jamespage | if we see specific issues with mirrors we can always re-run tests individually | 16:55 |
| skaet | jibel, charlie-tca - have marked mine as a duplicate of that one then. | 16:59 |
| cjwatson | I have a cdimage patch to do iso.qa posting based on an environment variable, but I guess I should hold off until after beta-2 | 17:00 |
| cjwatson | besides, pretty much EOD now anyway | 17:01 |
| skaet | stgraber, edubuntu dvd posted | 17:35 |
| stgraber | yeah! | 17:36 |
| * stgraber startings zsyncing | 17:36 | |
| ScottK | Are the current Kubuntu desktop/alternates ones we want testing on? | 17:40 |
| highvoltage | stgraber: I've been meaning to ask, when you removed some of those gnome admin packages, did you remove the slides too or are they still there? | 17:40 |
| ScottK | It looks like desktop is current. | 17:42 |
| cjwatson | skaet: oh, hmm, when rebuilding an image whose hash matches something on the iso.qa list it would probably be helpful to automatically mark it as rebuilding, right? | 17:45 |
| cjwatson | well, if we're going to post a new one anyway | 17:45 |
| skaet | cjwatson, yeah that would be very helpful indeed. | 17:45 |
| stgraber | highvoltage: removed the slides too | 17:46 |
| highvoltage | ah great | 17:49 |
| ScottK | skaet: Is there any image building going on right now? | 18:14 |
| infinity | All I see building is some arm preinstalled images. But I'm not sure what others have been up to. | 18:15 |
| ScottK | ev: Bug #855763 looks like it's exploding almost exactly where you changed stuff in the last upload. Ideas? | 18:19 |
| ubot4 | Launchpad bug 855763 in ubiquity (Ubuntu) "installer crashed (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/855763 | 18:19 |
| ev | ScottK: just fixed on trunk. Apols for that. I did test the KDE frontend stuff, so I'm baffled as to how that slipped through. | 18:23 |
| ScottK | ev: OK. I just confirmed it. | 18:24 |
| ScottK | I guess we'll need an upload and respins for it. | 18:24 |
| * GrueMaster hears the word "respins" and cringes. No armel desktop testing has happened since Beta 1. | 18:25 | |
| ScottK | skaet: ^^^ That's a blocker. | 18:25 |
| ScottK | GrueMaster: You don't use Ubiquity do you? | 18:25 |
| GrueMaster | oem-config | 18:25 |
| ScottK | Oh. | 18:26 |
| GrueMaster | Which is part of ubiquity. | 18:26 |
| ScottK | Yeah. | 18:26 |
| GrueMaster | And I'm still waiting on the last desktop respin to finish. | 18:26 |
| skaet | ScottK, ack. | 18:27 |
| ScottK | skaet: While we're waiting for that, Kubuntu alternate respins would be nice to pick up the kdepim data loss fix if there's builders available. | 18:27 |
| skaet | ev, can we live with just respinning the Kubuntu images? | 18:28 |
| GrueMaster | Guess I can do a netboot install and start testing from that. | 18:28 |
| skaet | ScottK, ok, will kick it off now. | 18:28 |
| skaet | ScottK, just to double check which package version should the data loss fix be in? | 18:31 |
| ScottK | skaet: 4:4.7.1-0ubuntu3. | 18:31 |
| ScottK | I checked and it's already on the dvd/desktop images (not that that helps) | 18:31 |
| skaet | ScottK, ok, its kicked off. Will look for it in about 30 minutes. | 18:36 |
| slangasek | GrueMaster: if it's a matter of you being blocked on doing any smoke testing of ARM images, we can certainly make sure that we get some images out for you to test even if we know they won't be final for beta-2; would that help? | 18:44 |
| slangasek | (I believe ubiquity is currently in a consistent state in the archive, so we shouldn't have to worry about that breaking the actual image building) | 18:44 |
| GrueMaster | slangasek: There are images being built now. It just takes several hours between respins. | 18:45 |
| GrueMaster | And as I said, worst case I do a netboot install and revert to app testing. | 18:45 |
| skaet | GrueMaster, per pitti's estimate, the images should be emerging from the builder shortly. Will flag you directly as soon as I spot them. | 18:47 |
| GrueMaster | Thanks skaet. | 18:48 |
| skaet | ScottK, kbuntu alternates (20110921) posted. | 19:11 |
| ScottK | Thanks. | 19:11 |
| * skaet drums fingers waiting for arm builders.... | 19:12 | |
| micahg | skaet: am I ok to upload some mozilla builds now to the security PPA? | 19:14 |
| skaet | micahg, as long as they can be killed off if testing throws up a blocker. | 19:17 |
| skaet | esp on the arm side. | 19:17 |
| micahg | skaet: yep, no problem (don't need the arm/powerpc until next tuesday) | 19:17 |
| micahg | the others are fine to kill as well if needed | 19:18 |
| skaet | micahg, ok. | 19:18 |
| micahg | these are still <1hr except on armel though, I'm still waiting on the firefox 7 builds and will check in again before uploading those (4.5hr+ on every arch) | 19:19 |
| ScottK | The armel rebuild test is done, so getting armel builders should be less of an issue than it has been recently. | 19:20 |
| micahg | yeah, half of them are free ATM | 19:21 |
| infinity | GrueMaster: I see some new daily-preinstalled images. | 19:29 |
| infinity | GrueMaster: Yeah, all 4 look there. | 19:30 |
| GrueMaster | ok. Pulling. Hope the bandwidth is decent this time. Last pull took 4 hours. | 19:31 |
| infinity | skaet / slangasek : Are we headed into another respin cycle here soon? Looks like ARM's previous run is all done, so we have stuff to smoketest. | 19:31 |
| skaet | infinity, GrueMaster - just posted the latest images fresh off the ARM builders to the iso tracker. | 19:32 |
| infinity | Oh, looks like we still need a new ubiquity? | 19:32 |
| slangasek | sounds like it | 19:33 |
| slangasek | ev: you said the kubuntu fix is on trunk? Are you preparing an upload today? | 19:33 |
| infinity | In that case, can we pull in software-center to make Xubuntu happy? :P | 19:33 |
| slangasek | sounds appropriate to me | 19:33 |
| skaet | infinity, we can pull in software-center. Just not sure if charlie-tca will have bandwith to test the updated image. | 19:34 |
| infinity | zsync is a beautiful thing. | 19:34 |
| infinity | Well, when it works. | 19:34 |
| GrueMaster | I'm still wondering what the last respin was about. I have the 20110921 desktop running on panda and while there are visual glitches, it is running smoothly. | 19:34 |
| skaet | re: ubiquity, can it just be a kubuntu spin, or is there a need for all the images. It wasn't clear to me. | 19:34 |
| stgraber | isn't the new ubiquity a kde-only fix? | 19:34 |
| infinity | GrueMaster: Sanity respin, since ubiquity keeps getting revved, probably. | 19:35 |
| skaet | stgraber, that was my understanding. | 19:35 |
| infinity | And an LP timeout. Twice. | 19:35 |
| * infinity goes to accept the old fashioned way. | 19:36 | |
| infinity | There. | 19:36 |
| slangasek | hmm, was ubiquity in the queue already? I didn't see it | 19:37 |
| infinity | charlie-tca: software-center accepted, BTW. Xubuntu respins, yay? | 19:37 |
| infinity | slangasek: No. | 19:37 |
| skaet | slangasek, ev: please post scope of respin when its known. My preference is to just redo Kubuntu unless compelling reason otherwise. | 19:37 |
| stgraber | skaet: there's also a fix for bug 848000 in the branch but I wouldn't think it's worth rebuilding for that | 19:37 |
| ubot4 | Launchpad bug 848000 in ubiquity (Ubuntu) "Shouldn't show "should be plugged in" when on a desktop (affects: 1) (heat: 6)" [Low,Fix committed] https://launchpad.net/bugs/848000 | 19:37 |
| slangasek | infinity: so it's the software-center that you accepted? | 19:37 |
| infinity | slangasek: Yeah. | 19:37 |
| * skaet looking | 19:37 | |
| charlie-tca | o | 19:37 |
| stgraber | skaet: so current ubiquity trunk contains: bugfix for bug 848000 and bug 855763 + a new unit test | 19:38 |
| ubot4 | Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 2) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/855763 | 19:38 |
| infinity | charlie-tca: Your o is missing the \/ around it. Armless man cheering? | 19:38 |
| charlie-tca | I would go with skaet on this | 19:38 |
| infinity | charlie-tca: Oh, as in you don't have time to test the fix you wanted? ;) | 19:39 |
| charlie-tca | If we need to respin, gereat1 | 19:39 |
| charlie-tca | if not, I would wait | 19:39 |
| infinity | charlie-tca: We're respinning some/all anyway for ubiquity. | 19:39 |
| charlie-tca | okay | 19:39 |
| infinity | charlie-tca: So... You get software-center. :P | 19:39 |
| charlie-tca | go for it, then | 19:39 |
| charlie-tca | Yay! | 19:39 |
| skaet | charlie-tca, :) | 19:39 |
| slangasek | skaet: the usual compelling reason is to have consistency between the images and the archive at the point of the milestone; I also see a fix for bug #848000 on trunk, which benefits Ubuntu but isn't a major issue. The fix for bug #855763 definitely only affects KDE. | 19:39 |
| ubot4 | Launchpad bug 848000 in ubiquity (Ubuntu) "Shouldn't show "should be plugged in" when on a desktop (affects: 1) (heat: 6)" [Low,Fix committed] https://launchpad.net/bugs/848000 | 19:39 |
| ubot4 | Launchpad bug 855763 in ubiquity (Ubuntu Oneiric) (and 1 other project) "installer crashed (affects: 2) (heat: 10)" [Critical,Confirmed] https://launchpad.net/bugs/855763 | 19:39 |
| infinity | slangasek: I'm pretty anal about the consistency thing, but I'll concede that since we don't snapshot the archive for pre-release milestones, it's not like it actually matters either. | 19:40 |
| slangasek | skaet: if we're pressed for time on testing and don't want to respin the world, kubuntu-only respins are viable here | 19:40 |
| infinity | Well, I may have just committed to Xubuntu too. ;) | 19:41 |
| skaet | slangasek, ok will definitely mark down kubuntu and xubuntu for respin when the ubiquity lands. I'd like to get a read from jibel on testing impact before those get posted. | 19:41 |
| slangasek | infinity: right; it's annoying to not be able to use jigdo for milestone alternates, but the window when you can do that is diminishingly small anyway | 19:41 |
| infinity | slangasek: Well, it's also good practice for "real" releases. Saying "we don't have time to test X again, so let's no refresh the image" is not the right answer. :P | 19:41 |
| Daviey | people use jigdo? | 19:42 |
| skaet | re: read from jibel, is whether he has bandwidth to do a retest on ubuntu images in time as well. Will build them after kubuntu and xubuntu, and then hold off on posting. | 19:42 |
| infinity | Daviey: With a local mirror, it's insanely nice. | 19:42 |
| Daviey | infinity: with a *local* mirror, wget should be pretty damn fast :) | 19:42 |
| stgraber | skaet, slangasek: want me to upload the current ubiquity? not sure if ev is still around | 19:43 |
| infinity | Daviey: Well, yes. Hence why jigdo's awesome. (As in, I keep a local package mirror, but not ISOs) | 19:43 |
| charlie-tca | I only have one desktop test done anyway | 19:43 |
| slangasek | Daviey: a local package mirror doesn't making wget'ing of images fast | 19:43 |
| slangasek | stgraber: yes please | 19:43 |
| Daviey | oh. i thought infinity was talking about a local iso mirror. | 19:43 |
| infinity | Daviey: Local ISO mirroring is just insanity unless you're a QA dude who tests every day. *glances at GrueMaster* | 19:44 |
| skaet | stgraber, what slangasek said. and thanks! | 19:45 |
| Daviey | infinity: Last cycle, i did rsync the server iso's daily.. but not bothered this cycle. | 19:45 |
| stgraber | ubiquity uploaded. Generating the debdiff locally shows a change in d-i/source/tzsetup/debian/common.templates (included source package), wiped my local copy of d-i/source/ and re-updated it and it's still there, so I guess that was a problem in a previous upload | 20:04 |
| skaet | stgraber, thanks. slangasek, can you review? | 20:15 |
| slangasek | looking | 20:15 |
| slangasek | do we want the one from 6 minutes ago or the one from 11 minutes ago? | 20:16 |
| skaet | stgraber, ^^ | 20:17 |
| infinity | The one with .gitignore vomit all over it seems suspect. | 20:18 |
| infinity | And yet, that's the newer one. :) | 20:18 |
| infinity | slangasek: gitignore aside, without a response from stgraber, I'd be inclined to take the newer one, since it only addresses the bugs and doesn't randomly regen/change a debconf template. | 20:21 |
| * stgraber goes to look at the queue | 20:22 | |
| stgraber | hmm, weird, I didn't see evan's upload in the branch | 20:23 |
| slangasek | it wasn't there when you uploaded... his is the newer upload | 20:24 |
| stgraber | I think it'd be best to go with my upload so that it matches what's in the branch | 20:24 |
| slangasek | stgraber: hmm, I've just accepted ev's because as infinity says, random changes to debconf templates are troubling | 20:25 |
| slangasek | especially unreviewable ones like changes to a 2000-item list | 20:25 |
| stgraber | stgraber@arkose-tmpW3TJ50:~/data/code/ubiquity$ md5sum current-tz/tzsetup-0.26ubuntu10/debian/common.templates ubiquity/d-i/source/tzsetup/debian/common.templates tmp/ubiquity-2.7.34/d-i/source/tzsetup/debian/common.templates | 20:28 |
| stgraber | 533f96595d0e372bf970dce026f5add8 current-tz/tzsetup-0.26ubuntu10/debian/common.templates | 20:28 |
| stgraber | 533f96595d0e372bf970dce026f5add8 ubiquity/d-i/source/tzsetup/debian/common.templates | 20:28 |
| stgraber | 2b607e6faffa4794d6aa284435a32822 tmp/ubiquity-2.7.34/d-i/source/tzsetup/debian/common.templates | 20:29 |
| stgraber | first one is the md5 of that debconf template from tzsetup itself, second is the ubiquity on my system (the one I uploaded earlier), third is the one in the last ubiquity upload (evan's system) | 20:29 |
| stgraber | not sure if there's any potential impact, but "mine" seems to be the right one | 20:29 |
| slangasek | stgraber: well... too late to un-accept :/ could you fix up the branches so that it gets properly imported on the next upload? | 20:31 |
| infinity | So, speaking of not respinning for package consistency. | 20:34 |
| stgraber | the included sources aren't in the branch but on the uploader's system (you basically need to run "fakeroot debian/rules update" to get them, then run debuild -S -sa to build the source package). | 20:34 |
| infinity | Who feels good about a no-change rebuild upload of nss, just to force updates on poeple who lost their libraries? | 20:34 |
| infinity | skaet / slangasek ^ | 20:36 |
| stgraber | ev: ^ (apparently you've got something weird in d-i/source) | 20:36 |
| skaet | infinity, am not sure about the implications of that. what is scope of rebuild needed? | 20:36 |
| infinity | skaet: Well, if we don't care deeply about the images and the archive having identical package versions, it means little to beta, really. | 20:38 |
| infinity | skaet: But the version rev will force an update on people who had their libnss3 library deleted by ca-certificates yesterday, without them having to hunt for support, manually download a package, etc. | 20:38 |
| micahg | I'd actually like to update nss before final, but was going to bring that up after release tomorrow | 20:38 |
| infinity | micahg: Well, there still seems to be a bit of a support panic with people who have no idea WTF has gone wrong. A quick version bump would kill a lot of that. | 20:40 |
| slangasek | infinity: if there's enough noise about it to be on your radar, I think a no-change rebuild of it would be best | 20:40 |
| micahg | infinity: yeah, I'm ok with that, was just thinking out loud, sounds like a no change rebuild wouldn't be so bad(it's pretty fast too) | 20:41 |
| infinity | Yeah, it's speedy. | 20:41 |
| skaet | infinity, ok by me then. | 20:41 |
| infinity | I'll just bump it now. | 20:41 |
| jbicha | I think it breaks network-manager so people might have to chroot anyway or use a wired connection but it seemed better to tell people to upgrade than to go find a .deb to install | 20:41 |
| slangasek | jbicha: the point is to get it to the archive so that it fixes itself for users who haven't already rebooted | 20:41 |
| jbicha | slangasek: yes :) | 20:42 |
| infinity | Uploaded. | 20:43 |
| charlie-tca | skaet: release overview updated for Xubuntu | 20:44 |
| skaet | thanks charlie-tca | 20:44 |
| * infinity daringly accepts his own upload. | 20:47 | |
| * Daviey watches the world implode. | 20:48 | |
| stgraber | wow, I didn't remember the qatracker module being such a mess ;) spent the last 30 minutes porting it from the current Drupal 4/5-ish code over to Drupal 7 and it finally loads though will need all of the DB interaction rewritten | 21:02 |
| stgraber | considering how easy it's to write a Drupal 7 module, I might just as well rewrite it, keeping the DB as it's (that part was easy to port) | 21:02 |
| skaet | ScottK, do you want the Kubuntu ARM images rebuilt? | 21:09 |
| ScottK | No. | 21:09 |
| skaet | okie, just checking. | 21:09 |
| ScottK | I doubt anyone is using kmail on armel and I'm sure GrueMaster has enough testing to do already without me adding to his trouble. | 21:10 |
| * GrueMaster twitches. | 21:13 | |
| doko | skaet, would you mind, if I set the milestone 11.10 for ftbfs issue for packages in universe which are in package sets? (5 packages) | 21:26 |
| skaet | doko, for 5 packages, sure | 21:26 |
| lamont | skaet: slangasek: so about this publisher thang... I'm trying to understand why, if we publish hourly, we get publisher triggers for archive on syncproxy every 30 minutes | 21:29 |
| lamont | and more to the point, I'd like to see that timeframe doubled for at least a little while | 21:29 |
| slangasek | lamont: ask the LP folks? | 21:29 |
| slangasek | lamont: it's really "every 30 minutes", not "twice back-to-back in a publisher run"? | 21:30 |
| lamont | it's one crontab entry that triggers at 03 * * * * | 21:31 |
| lamont | so yeah, I'll go ask the lp folks | 21:32 |
| slangasek | Daviey: hmm, you guys opted not to do the FFe for qemu-kvm? I guess that means I'm on my own for sorting out qemu-linaro then? :) | 21:32 |
| lamont | the issue right now is that every other sync request causes ZOMG email to all of us and gets dropped on the floor... so... yeah | 21:32 |
| slangasek | lamont: yeah, we don't exactly control the contents of that cronjob | 21:33 |
| slangasek | as in, I can't even work out where the actual code for the cronjob is without hurting my brane | 21:34 |
| skaet | lamont, any options for improving this part of the cycle would be very welcome. | 21:36 |
| slangasek | lamont: well, I take that back. looking at publish_ftpmaster.py, I do see that we're calling runFinalizeParts() twice, once for the "quick" security sync and once for the full-distro sync. The first one should be a very small sync; is the problem we're having that it isn't? | 21:37 |
| slangasek | lamont: should /srv/launchpad.net/codelines/current/cronscripts/publishing/distro-parts/ubuntu/finalize.d/90-trigger-mirrors have different handling based on SECURITY_UPLOAD_ONLY? | 21:38 |
| slangasek | (if so, what should the difference be?) | 21:38 |
| slangasek | ^^ makes gtalk plugin work on amd64 | 21:45 |
| skaet | stgraber, do you want edubuntu added to the respin list? | 21:47 |
| stgraber | skaet: yeah, still have plenty of time to re-test, so let's be up to date! | 21:49 |
| skaet | stgraber, ok, adding in. | 21:50 |
| skaet | anyone else what the latest ubiquity? | 21:50 |
| infinity | lamont: That's two triggers from the same script. I'm sure I've answered this before... | 21:51 |
| infinity | lamont: And it's been like that for years. | 21:51 |
| infinity | slangasek: Making it not trigger on sec_up_only sort of defeats the entire purpose of the quick-turnaround security run. :) | 21:53 |
| slangasek | infinity: unless the mirrors lamont is having problems from are not the mirrors used for mirroring security? | 21:53 |
| infinity | slangasek: Well, everything passes through syncproxy. | 21:55 |
| infinity | slangasek: And I have a sneaking suspicion that's where the angry mails are coming from. | 21:55 |
| slangasek | infinity: does it? There are three mirrors being triggered in that script | 21:56 |
| slangasek | I don't know which machine does what, but there's clearly more than one | 21:56 |
| infinity | Everything public-facing passes through syncproxy? :) | 21:56 |
| slangasek | ok | 21:57 |
| * skaet waiting on built ubiquity 2.7.35 to show up on archive now.... speaking of mirrors. | 21:59 | |
| infinity | Everything but armel should be fine. | 22:00 |
| skaet | builds started for all except armel. see pad for details. | 22:17 |
| skaet | thanks infinity | 22:17 |
| infinity | skaet: Just desktop CDs, I hope? | 22:22 |
| infinity | skaet: (Well, if you were basing it on ftpmaster having the files you wanted) | 22:22 |
| skaet | infinity, yes, just desktop cd/dvds (see pad). waiting on armel. | 22:23 |
| infinity | Oh, did I miss the memo on DVDs no longer being live/alternate hybrids? | 22:23 |
| infinity | (Let me guess, that changed 3 years ago, and I wasn't paying attention) | 22:23 |
| slangasek | it changed this cycle | 22:23 |
| skaet | :) | 22:23 |
| lamont | slangasek: its archive and security mirrors that are affected by the issue | 22:24 |
| slangasek | lamont: ok, well, see infinity's comments... the double-pulse per hour is expected then due to the security "quick-run". If that's not actually serving the intended function, it's easy enough for LP to disable the extra pulse and just do it all in one go... | 22:25 |
| slangasek | see also the discussion elsechan of whether there's cruft on the filesystem that needs cleaning up | 22:25 |
| infinity | lamont: Yeah. We can disable the quick sec run. Though there was a valid reason for it (not wanting to have to wait 45 minutes to push out something that's actually critical) | 22:26 |
| slangasek | however, if overlapping runs means you're usually waiting 1h15 instead, there's a clear lesser evil | 22:26 |
| infinity | lamont: There's also the part where IS has been laughing at LP for 6+ years about the publisher being so slow that it can't run twice an hour like dinstall did. Might not want to lose face there. ;) | 22:26 |
| infinity | (no pressure) | 22:27 |
| lamont | slangasek: having LP disable it for the rest of oneiric would probably be best | 22:56 |
| * lamont must run for a while | 22:57 | |
| skaet | ScottK, kubuntu daily-live 20110921.2 posted | 23:17 |
| skaet | charlie-tca, xubuntu desktop (20110921.2) posted | 23:31 |
| charlie-tca | skaet: that was there hours ago, already | 23:36 |
| charlie-tca | It was posted when infinity called for the respin | 23:36 |
| stgraber | charlie-tca: 21.3 just got appeared | 23:37 |
| charlie-tca | That's what I was looking for | 23:38 |
| charlie-tca | Thank you both, it is getting complicated now | 23:38 |
| stgraber | charlie-tca: I guess you want 20110921.3 on the tracker right? | 23:39 |
| charlie-tca | yes, I think so. That's the one we were waiting for | 23:39 |
| stgraber | ok, added | 23:39 |
| charlie-tca | thank you | 23:40 |
| stgraber | skaet: updated TechnicalOverview. I'll ask highvoltage to check I didn't forget anything. | 23:47 |
| ScottL | skaet, i'll get the technical overview tonight, i promise ;) | 23:50 |
| skaet | Thanks stgraber, ScottL. :) | 23:51 |
| skaet | charlie-tca, sorry 21.3 is what I was looking at and then posted 21.2. Thanks for fixing stgraber! | 23:53 |
| * skaet figures its time got go get some dinner... | 23:54 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!