| jdstrand | cjwatson: I don't have the context of the conversation, but if you need my team to flag certain packages for some reason and coordinate that with you, let me know and we'll make that happen | 00:04 |
|---|---|---|
| jdstrand | cjwatson: (referring to the libssl conversation in backscroll) | 00:05 |
| slangasek | jdstrand: this is specifically to do with ABI changes and d-i not respecting versioned dependencies | 00:09 |
| slangasek | shouldn't be a problem for security updates | 00:09 |
| jdstrand | ok, thanks | 00:09 |
| jdstrand | we're here if you need us :) | 00:09 |
| Daviey | d-i is good now.. thanks :) | 00:10 |
| pitti | Good morning | 05:39 |
| pitti | cjwatson: FYI, cd image cronjobs on manual now | 05:44 |
| pitti | cjwatson: I set OFFICIAL="Beta" in cdimage now; that's a reason to rebuild everything, marking in the tracker | 05:54 |
| pitti | err, pad | 05:54 |
| slangasek | pitti: I think that needs to be set to 'Beta 2' to avoid confusion | 05:54 |
| slangasek | (it was set to 'Beta' last time rather than 'Beta 1', but at least 'Beta 2' will still be unique) | 05:55 |
| pitti | slangasek: oh, ok; I wasn't sure whether that gets parsed and compared anywhere | 05:55 |
| slangasek | I believe it winds up in the iso diskinfo | 05:55 |
| slangasek | I don't think it's *parsed* anywhere, but it's confusing to have two images called 'Beta' | 05:55 |
| pitti | hm, beta-2 to be safe, or do you know that a space works? | 05:56 |
| pitti | tools like usb-creator parse the version (but that comes much ealier in the string) | 05:56 |
| * pitti digs history for lucid | 05:56 | |
| slangasek | I'm reasonably certain that 'Beta 1'/'Beta 2' was what we used last cycle | 05:57 |
| pitti | ahh, there's precedent for "beta 2", nevermind | 05:57 |
| pitti | done | 05:57 |
| slangasek | cheers | 05:58 |
| * slangasek wanders off to bed now | 05:58 | |
| jibel | pitti, IIRC wubi uses this info to identify the image and the regex fails if there is a version in the sub-version e.g Beta 2 | 06:56 |
| pitti | jibel: bonjour | 06:56 |
| jibel | pitti, morgen :) | 06:56 |
| pitti | jibel: oh, so did that break in hardy/lucid/oneiric as well? | 06:56 |
| jibel | pitti, In natty I think | 06:57 |
| jibel | unless that was fixed in wubi, let me check | 06:58 |
| jibel | pitti, it is the regex used by wubi to parse disk/info | 07:00 |
| jibel | disk_info_re = '''(?P<name>[\w\s-]+) (?P<version>[\d.]+)(?: LTS)? \"(?P<codename>[\D]+)\" - (?P<subversion>[\D]+) (?P<arch>i386|amd64) \((?P<build>[\d.]+)\)''' | 07:00 |
| jibel | so it still fail with "Beta 2" | 07:01 |
| pitti | jibel: ok, thanks; so I better change that to Beta-2 | 07:06 |
| pitti | jibel: done | 07:07 |
| pitti | https://launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=44328 | 07:08 |
| pitti | hmm, 43 bugs | 07:08 |
| * pitti gardens them a bit | 07:12 | |
| pitti | ^ csync is unseeded, and a no-change rebuild to fix uninstallability, accepting | 07:22 |
| === rsalveti` is now known as rsalveti | ||
| micahg | pitti: I still want to kill sqlite2, but I guess the rebuild's ok (will send e-mail to -release when I'm ready to work on it) | 07:46 |
| pitti | micahg: thanks | 07:47 |
| pitti | micahg: yeah, at least it's installable now | 07:47 |
| micahg | pitti: being that no one's complained yet, I'm guessing it's not very used | 07:47 |
| pitti | micahg: it was an easy thing to get off the beta-2 bug list; sorry if I got in your way | 07:47 |
| micahg | pitti: not at all, only reason why I added to beta 2, was I was hoping to have sqlite done by now | 07:48 |
| micahg | pitti: actually, was tempted to ask you to remove | 07:48 |
| micahg | csync, not sqlite | 07:49 |
| pitti | can do that as well, if there's a good reason for it | 07:49 |
| pitti | if it's the only package that still uses sqlite2, that would be a good reason :0 | 07:49 |
| micahg | pitti: sqlite2 deprecated :), I guess at this point, it might as well wait until the rest of the sqlite cleanup | 07:49 |
| === mmrazik is now known as mmrazik|lunch | ||
| pitti | https://launchpad.net/ubuntu/precise/+bugs?field.milestone%3Alist=44328 is a bit shorter now | 09:36 |
| * cjwatson has a look through archive admin bugs | 09:58 | |
| * Laney arghs at still not having filed the other haskell removal one | 09:59 | |
| === greyback is now known as greyback|lunch | ||
| cjwatson | newlib should be safe despite being in main; it's only there for newlib-spu which is a build-time-only thing only on powerpc | 10:02 |
| cjwatson | Laney: https://bugs.launchpad.net/ubuntu/+source/haskell-attoparsec-text/+bug/955521/comments/3 | 10:07 |
| ubot2 | Launchpad bug 955521 in haskell-xml-enumerator "Various discontinued Haskell packages to remove from precise" [Undecided,Confirmed] | 10:07 |
| cjwatson | and comment 4 | 10:09 |
| Laney | yeah there's some yesod syncage to do | 10:09 |
| cjwatson | and hledger-web | 10:10 |
| Laney | yeah | 10:11 |
| Laney | brb | 10:11 |
| === mmrazik|lunch is now known as mmrazik | ||
| Laney | i'm syncing some more stuff which should make the rdeps go away | 10:41 |
| === greyback|lunch is now known as greyback | ||
| * Laney pulls at threads | 10:54 | |
| pitti | cjwatson: thanks for the newlib fix, accepted | 11:01 |
| pitti | cjwatson: FYI, I'm accepting the GNOME 3.4.0 bits; they go into -proposed, and only update translations | 11:02 |
| cjwatson | OK; do you want to get them onto beta-2 images? | 11:02 |
| pitti | so that we can stash up 3.4 in -proposed, and move it to precise after the freeze | 11:02 |
| cjwatson | ah right | 11:03 |
| pitti | cjwatson: I see no need for this | 11:03 |
| pitti | translations are stripped anyway, and we dont' get new b2 langpacks | 11:03 |
| pitti | cjwatson: it's mostly for seb128 to get them out of the way, and in -proposed they avoid arch skew | 11:03 |
| pitti | I mean uninstallability due to arch skew | 11:03 |
| cjwatson | certainly | 11:04 |
| seb128 | hum | 11:04 |
| seb128 | https://launchpadlibrarian.net/98386576/buildlog_ubuntu-precise-armel.gnome-panel_1%3A3.4.0-0ubuntu1_CHROOTWAIT.txt.gz | 11:04 |
| seb128 | "bzip2: Data integrity error when decompressing." | 11:04 |
| pitti | erk | 11:04 |
| seb128 | does it mean the builder is buggy? | 11:04 |
| cjwatson | I think I'd be inclined to just mash retry | 11:05 |
| cjwatson | that sounds like a network transmission error on the chroot | 11:05 |
| cjwatson | and bzip2 has done part of its job and spotted it | 11:05 |
| seb128 | thanks | 11:05 |
| cjwatson | if it happens multiple times we can be more worried | 11:05 |
| ogra_ | hmm, seems nusakan didnt do the DST switch ... i just got the daily health checks mail 1h late | 11:06 |
| ogra_ | (or didnt the uk switch ?) | 11:06 |
| seb128 | cjwatson, https://launchpadlibrarian.net/98386775/buildlog_ubuntu-precise-armel.gnome-panel_1%3A3.4.0-0ubuntu1_CHROOTWAIT.txt.gz | 11:07 |
| cjwatson | it's intentionally on UTC | 11:07 |
| seb128 | cjwatson, same issue on second try | 11:07 |
| seb128 | (same build, caph) | 11:07 |
| ogra_ | oh ... silly me, indeed | 11:07 |
| cjwatson | seb128: hmm - ask #launchpad-ops (internal) | 11:07 |
| seb128 | builder | 11:07 |
| seb128 | cjwatson, ok | 11:07 |
| Daviey | all servers should stick to UTC :) | 11:07 |
| ogra_ | Daviey, all the world should :) | 11:07 |
| ogra_ | would aviod me getting confused | 11:07 |
| Daviey | ogra_: I'm happy to stick my working day to UTC :) | 11:07 |
| pitti | cjwatson: I found a fix for bug 963069, the breaker du jour for the lucid->precise universe auto-dist-upgrade test | 11:09 |
| ubot2 | Launchpad bug 963069 in gtk+2.0 "Lucid -> Precise universe: pkgProblemResolver::Resolve generated breaks - does not replace gir1.0-gtk-2.0 with gir1.2-gtk-2.0" [High,New] https://launchpad.net/bugs/963069 | 11:09 |
| pitti | cjwatson: would you consider accepting this for beta-2 at this point? it's just adding a new Conflicts: | 11:09 |
| pitti | err, breaks | 11:09 |
| pitti | I'm test-building locally now to ensure it still builds | 11:10 |
| pitti | cjwatson: I can also use -proposed if you want | 11:10 |
| cjwatson | what's the state of image testing? | 11:11 |
| cjwatson | a few tests registered, not lots | 11:12 |
| cjwatson | so yeah, I'd consider it | 11:13 |
| pitti | cjwatson: we need to rebuild everything anyway still, for the OFFICIAL change | 11:16 |
| cjwatson | oh, you didn't do that already? OK | 11:21 |
| pitti | cjwatson: I did it this morning | 11:21 |
| pitti | but images haven't rebuit since then | 11:21 |
| pitti | cjwatson: and I updated it to say "Beta-2" instead of "Beta 2" to avoid breaking wubi (cf. jibel's ping around 0700 UTC here) | 11:22 |
| cjwatson | sure; for lucid we just said Beta in both cases | 11:26 |
| cjwatson | I'm actually fairly sure that "Beta 2" would have worked in the specific case of wubi; jibel misread the regex | 11:27 |
| cjwatson | ... actually, both of them break equivalently, thinking about it | 11:27 |
| cjwatson | \D matches anything that's not a digit | 11:28 |
| pitti | hm, so just "Beta" after all? | 11:28 |
| cjwatson | I understand slangasek's point about confusion, but I think avoiding triggering bugs ought to take precedence | 11:28 |
| pitti | +1 | 11:29 |
| pitti | and that's only for the .disk/info stamp, right? | 11:29 |
| pitti | or does it go anywhere on the .html pages? | 11:29 |
| pitti | (these are edited manually anyway) | 11:29 |
| cjwatson | html is done separatey | 11:29 |
| cjwatson | +l | 11:29 |
| pitti | and the .iso file names are a publish-release argument | 11:29 |
| * pitti adds ^ to the etherpad | 11:32 | |
| cjwatson | accepted | 11:34 |
| pitti | thanks | 11:35 |
| pitti | cjwatson: I'll move it to precise once it's built everywhere | 11:36 |
| pitti | erk, powerpc build ETA in 15 h | 11:36 |
| pitti | seems the wesnoth backports own the ppc builders for a while | 11:37 |
| Daviey | wesnoth is release critical | 11:38 |
| cjwatson | oh, blast, I was just clearing them while I remembered. surely you can just score things up though? | 11:41 |
| cjwatson | otherwise feel free to ask #launchpad-ops for build cancellations | 11:42 |
| pitti | cjwatson: scoring doesn't help, already tried | 11:43 |
| pitti | cjwatson: yeah, will do that | 11:43 |
| * pitti questions the utility of maverick backports at this point.. | 11:44 | |
| seb128 | cjwatson, pitti: #launchpad-ops sorted the armel builder issue btw | 11:45 |
| pitti | seb128: cool, thanks | 11:45 |
| pitti | gtk+2.0 ppc building now | 11:56 |
| scott-work | just subscribed release-team for bug #963498 | 12:33 |
| ubot2 | Launchpad bug 963498 in ubuntustudio-default-settings "[FFe] menu is not ubuntu studio version" [Undecided,New] https://launchpad.net/bugs/963498 | 12:33 |
| pitti | cjwatson: FYI, out for doctor appointment for ~ 1 hour; gtk 2.0 still building :/ | 12:34 |
| cjwatson | pitti: ok | 12:35 |
| cjwatson | scott-work: I'm not sure I see why this is an FFe; isn't it just a bug? | 12:35 |
| scott-work | cjwatson: i would think this is just a bug and could be addressed without the release-team's approval, but i was just being cautious | 12:36 |
| cjwatson | confirmed anyway | 12:37 |
| scott-work | cjwatson: thank you | 12:38 |
| scott-work | i think there is a bit of a culture in some quarters to be cautious about bugs after freezes...perhaps, overly cautious, i will try to be more judicious in the future however | 12:38 |
| cjwatson | it's fine to be cautious, but don't hamstring yourself :) | 12:47 |
| === bladernr_afk is now known as bladernr_ | ||
| jdstrand | fyi, I just sponsored a freetype upload to precise for security updates. it is not required for beta-2, but is fine if it is pulled in | 13:13 |
| pgraner | cjwatson, the unity guys might have a fix for https://bugs.launchpad.net/ubuntu/+source/unity/+bug/963633 (or a best a partial fix) | 13:21 |
| ubot2 | Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress] | 13:21 |
| pgraner | cjwatson, dbarth has more info | 13:21 |
| cjwatson | OK, they can ask somebody from desktop to apply it to the package as a patch, and then we (release team) can review it once it's in the queue | 13:22 |
| dbarth | cjwatson: hi | 13:22 |
| cjwatson | or one of their own people with upload privileges if possible | 13:22 |
| cjwatson | until then it doesn't need to go through me :) | 13:22 |
| dbarth | we're testing a small fix in the gconf backend from which we suspect the hangs and corruptions come from | 13:22 |
| pgraner | cjwatson, more of a heads up that a respin will be needed | 13:22 |
| cjwatson | pgraner: we haven't spun yet | 13:23 |
| dbarth | it's 4-5 lines of changes, but means a respin would be needed to integrate the change | 13:23 |
| cjwatson | the existing images still say alpha, we were waiting for gtk+2.0 to land | 13:23 |
| pgraner | cjwatson, ah ok, I thought we had spun then nevermind.... | 13:23 |
| cjwatson | but certainly if you could get something uploaded ASAP rather than later that would help | 13:23 |
| * dbarth hopes we'll beat gtk+2 | 13:23 | |
| cjwatson | I doubt it, it was well on its way building | 13:24 |
| dbarth | ugh, well | 13:24 |
| ralsina | question! We found a security issue on ubuntuone-client on friday. We have fix today, is there ay chance of uploading a fixed package? | 13:52 |
| ogra_ | you can in any case upload to the queue, letting the package in is a manual process during beta freeze | 13:57 |
| ralsina | ogra_: thanks! | 13:58 |
| ogra_ | (assuming you talk about precise indeed :) ) | 13:59 |
| nessita | ogra_: yes, this is for precise. So, just dputting to ubuntu will leave the package in the proper queue? | 13:59 |
| nessita | (hi there!) | 13:59 |
| cjwatson | nessita: yes | 13:59 |
| ogra_ | nessita, right, you should see it being announced here by the queuebot | 14:00 |
| nessita | ogra_, cjwatson: thanks! | 14:00 |
| jdstrand | ralsina: is this only in the precise version? | 14:02 |
| ralsina | jdstrand: yes | 14:02 |
| jdstrand | ok | 14:02 |
| cjwatson | pitti: FWIW most of my sponsored uploads from today can happily wait for post-beta2; in particular I'd prefer if busybox weren't accepted | 14:26 |
| pitti | cjwatson: ack | 14:26 |
| cjwatson | it's not a disaster if it is but I'd have to respin d-i | 14:26 |
| cjwatson | pitti: pgraner/dbarth asked for us to wait until they've got a fix for bug 963633 uploaded before we start rolling images | 14:29 |
| ubot2 | Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress] https://launchpad.net/bugs/963633 | 14:29 |
| cjwatson | (scrollback ~ 1 hour ago) | 14:29 |
| pitti | cjwatson: I was told this only affects upgrades | 14:29 |
| pitti | but ok | 14:29 |
| pgraner | pitti, no true I got it on a freshly installed system as well | 14:29 |
| pgraner | s/no/not/ | 14:29 |
| pitti | pgraner: ah, thanks for the update | 14:30 |
| skaet | Daviey, today's CD report still has server amd64 oversize. Will we get one today that fits? | 14:37 |
| Daviey | skaet: Today's was built before i made nay changes. :) | 14:42 |
| Daviey | hold out.. still on track. | 14:42 |
| skaet | :) ok | 14:43 |
| Daviey | skaet: sorry for being brief, otp | 14:51 |
| skaet | Daviey, np | 14:52 |
| rickspencer3 | hi skaet and dbarth | 14:59 |
| dbarth | cjwatson, pitti, pgraner: sorry to report that the fix we were on is not working so far | 15:00 |
| dbarth | so, it will take us still a couple of hours to confirm a fix | 15:00 |
| cjwatson | perhaps we should go ahead and spin images anyway? | 15:01 |
| skaet | hiya rickspencer3, about ^ ? | 15:01 |
| pgraner | skaet, https://bugs.launchpad.net/ubuntu/+source/unity/+bug/963633 | 15:01 |
| ubot2 | Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress] | 15:01 |
| pitti | gtk+2.0 armhf/armel are in pkgbinarymangler stage | 15:01 |
| dbarth | i don't think we can give you a fixed package within the next 2-3h | 15:02 |
| dbarth | :/ | 15:02 |
| pitti | but I guess if we'll respin anyway, or don't care about gtk 2 being out of date on the images, that's not a blocker | 15:02 |
| rickspencer3 | skaet, my gut tells me that unity is not going to be shippable before tomorrow | 15:02 |
| pgraner | rickspencer3, +1 | 15:02 |
| rickspencer3 | I'm watching didrocks et al debug it ... they are working hard, but there are no easy answers | 15:03 |
| skaet | pitti, can we revert the pocket copies, and go with the original one? | 15:03 |
| skaet | (ie. one at freeze) | 15:03 |
| pitti | skaet: for unity? no, we can't | 15:03 |
| pitti | we could upload the whole stack as 5.8+really5.6 again | 15:04 |
| pitti | in -proposed | 15:04 |
| pitti | and then move over everything in a couple of hours when everything is built | 15:04 |
| rickspencer3 | pitti, skaet I would propose that we set a deadline for such a reversion | 15:04 |
| skaet | pitti, might be prudent to do that then, and if no resolution by the time it builds. | 15:04 |
| skaet | we switch over | 15:05 |
| pitti | yes, sounds good to me; not sure if we also need to revert the compiz bits, or just unity | 15:05 |
| cjwatson | skaet: reverting as +really5.6 is a giant mouthful | 15:05 |
| pitti | didrocks: ^ ? | 15:05 |
| cjwatson | do we REALLY want that? | 15:05 |
| cjwatson | I don't mind setting a deadline for it, but I don't like the idea of doing it up-frfont | 15:05 |
| rickspencer3 | I would propose that we prepare to do that tomorrow | 15:05 |
| cjwatson | *up-front | 15:05 |
| didrocks | well, it doesn't impact beta2 as per see, the issue are only on upgrade | 15:05 |
| rickspencer3 | give the unity team 1 day to sort it out | 15:05 |
| pitti | didrocks: pgraner says otherwise | 15:05 |
| didrocks | hum, for the interface not showing? | 15:06 |
| skaet | didrocks, ^ comments from pgraner... | 15:06 |
| pgraner | cjwatson, I hit the blank desktop on a fresh install about an hour ago | 15:06 |
| cjwatson | -> didrocks | 15:06 |
| didrocks | pgraner: ah, can you please talk about it to duflu? he's on something else then | 15:06 |
| didrocks | there are 3 bugs in fact | 15:06 |
| skaet | dbarth, didrocks, how tightly is compiz tied in with unity fixes? | 15:07 |
| pgraner | cjwatson, a netboot install then a apt-get install ubuntu-desktop and a reboot | 15:07 |
| didrocks | and everyone is puzzled in it | 15:07 |
| didrocks | skaet: we can revert compiz only, we didn't try it | 15:07 |
| didrocks | skaet: because new compiz + old unity showed the hang that we workarounded | 15:07 |
| skaet | didrocks, so, best advice is to revert the entire stack and have it ready in proposed to switch to? | 15:08 |
| skaet | if we don't get this sorted by end of day? | 15:09 |
| didrocks | skaet: well, reverting the stack will take some hours still, so I continue to work like hard and try to get dx people on board… | 15:09 |
| cjwatson | also reverting the stack will make it harder for people to reproduce and help ... | 15:09 |
| didrocks | skaet: the revert will take approx 5 hours to proceed with the dep chain | 15:09 |
| rickspencer3 | cjwatson, pitti, skaet, didrocks thoughts about letting the unity team work for the next 24 hours to fix the bugs, and then work on reverting if it's not substantially closer to be being solved tomorrow? | 15:10 |
| cjwatson | we could do with a bit under 24 hours really | 15:10 |
| pitti | that gets really tight then | 15:10 |
| skaet | rickspencer3, not sure we have 24 hours, need to get the testing happening, and there could be follow on problems | 15:11 |
| gema | agree with cjwatson , if we want to test it properly | 15:11 |
| pitti | that means we'd be looking at candidate images Wednesday morning | 15:11 |
| cjwatson | yes, particularly if we revert the whole stack that means it will take another 5 hours for the fix to build as we have to unrevert everything | 15:12 |
| cjwatson | and adds that much more source of human error | 15:12 |
| skaet | suggest we have until 1900 UTC and then decide, revert or not. And then have the images built. | 15:12 |
| pitti | perhaps something like "give them 24 hours, and stage a reversion in -proposed in parallel when there is no solution in sight in 16 hours"? | 15:12 |
| rickspencer3 | pitti, that works for me | 15:12 |
| didrocks | pgraner: so, when you upgrade | 15:13 |
| skaet | didrocks, uploading reverted stack - when? | 15:13 |
| cjwatson | do we have any idea what percentage of users this affects? | 15:13 |
| didrocks | skaet: well, if I upload the reverted stack now | 15:13 |
| didrocks | that would mean nobody more will work on the fix | 15:13 |
| didrocks | seeing as I'm the only one active on it… | 15:13 |
| pitti | didrocks: no need for "now"; we need it (fix deadline minux 5 hours) | 15:13 |
| seb128 | are we sure it affects lot of "new install"? | 15:13 |
| skaet | what! | 15:13 |
| seb128 | everybody who did a unity --reset got it fixed so far | 15:14 |
| gema | didrocks: why not, don't they want to fix it asap? | 15:14 |
| pitti | err, shoudln't the whole DX team be all over this? | 15:14 |
| seb128 | it seems out pgraner most issues are upgraded profiles | 15:14 |
| didrocks | seb128: seems not, with his new install + ubuntu-desktop metapackage | 15:14 |
| didrocks | pitti: … | 15:14 |
| * cjwatson wonders if pgraner has a separate bug; after all the symptom is quite generic-sounding | 15:14 | |
| pgraner | seb128, I don't know, I hit it like I said with a net install with the alternate installer then did a apt-get install ubuntu-desktop, rebooted and got the blank screen issue | 15:14 |
| rickspencer3 | hmmm | 15:14 |
| seb128 | that's quite a special install | 15:15 |
| rickspencer3 | that seems rather round-a-bout | 15:15 |
| seb128 | not a standard desktop install | 15:15 |
| seb128 | do we have any proof it happens with desktop images? | 15:15 |
| cjwatson | perhaps worth a file-by-file comparison of that with a standard install | 15:15 |
| rickspencer3 | can someone who has the bug from upgrade do a fresh install and see it happens? | 15:15 |
| seb128 | also reverting would make us loose 1 week or trying to get that issue fixed for final | 15:15 |
| didrocks | rickspencer3: until now, I didn't see any of this | 15:15 |
| seb128 | we can't stay on 5.6 for the lts | 15:15 |
| pgraner | cjwatson, let me burn a usb stick and install on the same box | 15:15 |
| rickspencer3 | can someone take the responsibility of determining the scope of the problem? who is impacted (only upgraders?) and how many upgraders are impacted? | 15:16 |
| rickspencer3 | pgraner, someone from QA? | 15:17 |
| pgraner | rickspencer3, sure jibel and I will work this | 15:17 |
| pitti | bug 957805 is the oldest dupe, and reported against oneiric already | 15:17 |
| ubot2 | Launchpad bug 957805 in unity "Black screen after update on unity (with solution) (dup-of: 963633)" [Undecided,Confirmed] https://launchpad.net/bugs/957805 | 15:17 |
| ubot2 | Launchpad bug 963633 in unity "Unity 5.8: Login to blank screen (all black or just wallpaper)" [Critical,In progress] https://launchpad.net/bugs/963633 | 15:18 |
| pitti | aside from that, it piled up some 25 dupes over the past two days | 15:18 |
| rickspencer3 | pitti, so it seems very widespread to you? | 15:19 |
| pitti | so I think the first dupe was something diffent, or 5.8 just greatly aggravated the conditions under which this occurs | 15:19 |
| skaet | pitti, indeed, which indicates its going to be fairly common, and critical is not unwarrented. | 15:19 |
| pitti | yes, I think critical is appropriate | 15:19 |
| rickspencer3 | pitti, can we tell why some people get affected and some don't? | 15:20 |
| seb128 | one issue to consider is that going through with that will increase the chances to get it fixed by hard freeze, rolling back will put us behind on the goal | 15:20 |
| pitti | just to have all options on the table, we could also release on Friday, couldn't we? | 15:20 |
| pitti | rickspencer3: I can't | 15:20 |
| rickspencer3 | pitti, yes, we could release on Friday | 15:20 |
| rickspencer3 | but, let's not :) | 15:20 |
| pitti | it's not my favourite either, as it extends the freeze quite a bit | 15:20 |
| pitti | but we have -proposed for staging uploads, if people really want to | 15:21 |
| rickspencer3 | let's stick with Plan A (fix Unity) if at all possible | 15:21 |
| pitti | I'm fairly sure that's everyone's favourite :) | 15:21 |
| didrocks | so, unity --reset works for most of cases | 15:22 |
| * skaet nods | 15:22 | |
| pitti | but can we ask for some more DXers to help out with this, instead of just didrocks? | 15:22 |
| didrocks | we can even envision doing the settings revert ourselves | 15:22 |
| didrocks | pitti: well, that's why I'm trying since this morning | 15:22 |
| didrocks | duflu was on it, but it's late for him now | 15:22 |
| skaet | pitti, dbarth said duflu is working on it as well. | 15:22 |
| didrocks | and he's not around anymore | 15:23 |
| seb128 | it's like 2am for him yeah... | 15:23 |
| * skaet thought that was sam? | 15:23 | |
| cjwatson | there's bug 965390 as well; we could debate critical or high for that, but at any rate it looks like an easy fix | 15:24 |
| ubot2 | Launchpad bug 965390 in ubiquity "prompt to remove cryptsetup on an encrypted LVM install during end user setup" [Critical,Triaged] https://launchpad.net/bugs/965390 | 15:24 |
| cjwatson | (the alternate-ness there is not intrinsic; if we supported that partitioning mode on the desktop CD, as we'd like to do for Q, it would have the same problem there) | 15:25 |
| seb128 | skaet, sam and duflu both live in australia and both work on compiz | 15:26 |
| skaet | thanks seb128 | 15:26 |
| cjwatson | damn that round planet anyway | 15:26 |
| pitti | cjwatson: sounds like we'd have plenty of time to accomodate that fix.. | 15:26 |
| * skaet nods | 15:27 | |
| skaet | cjwatson, you going to be working on that fix? | 15:27 |
| cjwatson | yes | 15:28 |
| * skaet can take over kicking images out later today | 15:28 | |
| cjwatson | just need half an hour or so for a test install to make sure I know the right fix | 15:28 |
| * skaet nods | 15:28 | |
| pitti | skaet: we could then at least start building the non-ubuntu images and the ubuntu arm preinstalled | 15:29 |
| * pitti wonders what's up with that gtk-2.0 build -- it's been sitting at pkgbinarymangler for an hour | 15:29 | |
| skaet | pitti, yes, that seems appropriate. | 15:29 |
| pitti | skaet: oh, edubuntu has compiz, too | 15:30 |
| cjwatson | get a webops to attach strace or get a ps dump or something? | 15:31 |
| * pitti asks in the channel | 15:31 | |
| * didrocks can at worst try to do a http://launchpadlibrarian.net/60658417/compiz_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu2_1%3A0.9.2.1%2Bglibmainloop3-0ubuntu3.diff.gz | 15:45 | |
| === x4 is now known as Guest39014 | ||
| pitti | ^ accepting gtk+3.0, it's for -proposed | 15:57 |
| === Guest39014 is now known as x4 | ||
| pitti | everything else in unapproved is seeded somewhere | 16:01 |
| stgraber | ^ is used by Edubuntu (AFAIK we're the only one shipping it), this upload contains a fix to a bug preventing arkose from working at all | 16:08 |
| pitti | skaet, cjwatson: I wonder if I can go to Taekwondo now, or rather stay online for the evening? | 16:09 |
| cjwatson | pitti: go on, I'll be around off and on for a bit | 16:10 |
| pitti | ack; good night then! | 16:11 |
| skaet | pitti, go to Taekwondo. we're in wait mode now. If you could check in when you get back | 16:11 |
| skaet | would be appreciated | 16:11 |
| pitti | skaet: yep, can do | 16:11 |
| skaet | thanks pitti | 16:11 |
| cjwatson | ^- that's for -proposed since ubiquity wants to be in sync across all architectures; please review/accept | 16:19 |
| cjwatson | stgraber: accepted | 16:24 |
| stgraber | cjwatson: thanks | 16:27 |
| skaet | cjwatson, looks like straightforward extra checking. accepted. | 16:29 |
| cjwatson | thanks | 16:30 |
| dbarth | cjwatson, skaet, pitti: just an update about the bug; we're going with another workaround for now, since none of our fixes has proved to be 100% reliable so far | 16:37 |
| dbarth | cjwatson, skaet, pitti: didrocks is building a package with a patch he used some time ago, to force a --reset on the plugin list | 16:37 |
| didrocks | the difference is that I'll only do it on the plugin list | 16:37 |
| didrocks | on the whole configuration | 16:37 |
| didrocks | (and only once) | 16:37 |
| dbarth | ie, the list of plugins is fixed-set, but the settings are preserved | 16:37 |
| didrocks | but still, the real issue has to be worked on | 16:38 |
| dbarth | eta? (sil2100 volunteered to do a sanity check on the packages) | 16:38 |
| didrocks | he has a broken setting? | 16:39 |
| dbarth | didrocks: no, just verify that there is no obvious regression, for whatever reason (since this patch is known to have worked before) | 16:45 |
| cjwatson | so I guess you want to punt this into -proposed first? | 16:46 |
| didrocks | cjwatson: yeah, seems better | 16:46 |
| didrocks | cjwatson: I'm buiding it, it's a silly patch, but at least, it should unblock the situation for now | 16:47 |
| didrocks | cjwatson: while we are at it, there is an unity patch which can make beta2 (bad interaction with software-center which can cause in a crash) | 16:48 |
| cjwatson | didrocks: will need to see the patch, but ok ... | 16:55 |
| slangasek | jibel: the latest upgrade failures of lucid-main are a strange regression that I can't reproduce locally by installing the lucid version of puppetmaster and then upgrading to the precise version. Do you have any more info about what's happening here? | 16:56 |
| slangasek | are we expecting the fix for bug #916291 in before beta-2? | 16:58 |
| ubot2 | Launchpad bug 916291 in libreoffice "failed to upgrade from Oneiric to Precise: ERROR: Cannot determine language! - exit status 134" [Critical,In progress] https://launchpad.net/bugs/916291 | 16:58 |
| slangasek | well, in progress as of 4h ago; but not sure if that will land on CDs | 16:59 |
| cjwatson | the build is 31 hours on armhf | 17:01 |
| cjwatson | and pretty long even on x86 | 17:01 |
| * slangasek nods | 17:02 | |
| cjwatson | (12-13 hours) | 17:02 |
| * skaet *blinks* at 31 hours on harmmhf... | 17:04 | |
| cjwatson | welcome to libreoffice :-/ | 17:05 |
| * cjwatson -> dinner | 17:06 | |
| slangasek | jibel: btw, I can't quite figure out why /etc/init/console-setup.conf is being shown as an obsolete conffile of console-setup in the lucid->precise upgrade, given that keyboard-configuration replaces this conffile and is shown as being unpacked... could we perhaps get a copy of /var/lib/dpkg/status from one of these systems post-upgrade? | 17:12 |
| slangasek | wow, what is wrong with the javascript in jenkins? It pegs my CPU | 17:12 |
| didrocks | cjwatson: sorry for the time taken for the workaround, but compiz is making bad implication about what it should copy/erase under your feet | 17:14 |
| didrocks | making a final build to ensure everything is fine | 17:15 |
| skaet | Riddell, pad doesn't seem to have kubuntu active on it for rebuilds, can you add? | 17:23 |
| infinity | doko: You were discussing a rebuild test last week, did you still plan to do that? | 17:25 |
| skaet | Daviey, when the fix lands from didrocks, will the changes be there for server images to fit, or will we still need to wait on that? | 17:32 |
| skaet | s/fix/workaround/ | 17:32 |
| didrocks | skaet: thanks for hilighting it's a workaround, because it really is :) | 17:35 |
| didrocks | (uploaded to -proposed, tested with a lot of reboot here) | 17:36 |
| didrocks | but as I never got a hang… at least, for everyone it fixed with a --reset, it should work the same | 17:36 |
| skaet | pgraner, jibel ^ who will be around to test the image once its built later today? | 17:36 |
| Daviey | skaet: no, not yet. Unity isn't on the server cd btw :) | 17:37 |
| pgraner | skaet, myself & hggdh | 17:37 |
| skaet | Daviey, it was more, want to kick them all off at the same time. Assumed you want to pick up the ubiquity bug | 17:37 |
| skaet | or rather bug fix. :) | 17:37 |
| skaet | pgraner, thanks. | 17:38 |
| pgraner | skaet, I'm here as long as it takes and I'm making hggdh stay too cuz he loves this stuff :) | 17:38 |
| hggdh | skaet: I am a mere paw in this game, I do what my manager volunteers me to | 17:39 |
| skaet | pgraner, glad of the company. ;) | 17:39 |
| skaet | hggdh, glad of your company too. :) | 17:41 |
| hggdh | :-) | 17:42 |
| didrocks | cjwatson: ^ | 17:42 |
| skaet | didrocks, cjwatson's at dinner, looking | 17:43 |
| didrocks | skaet: I targeted -proposed | 17:44 |
| infinity | I'll look too. | 17:45 |
| skaet | thanks infinity, didrocks | 17:45 |
| infinity | didrocks: ... | 17:47 |
| infinity | didrocks: You weren't kidding about this being a workaround. :P | 17:47 |
| nessita | hello! the new ubuntuone-control-panel 2.99.91-0ubuntu2 has a minor fix where I added a missing dependency for a binary package | 17:47 |
| didrocks | infinity: I'm always serious on my speech :) | 17:48 |
| * infinity giggles at current_profile_gconfvalue.set_string('fooo') | 17:49 | |
| didrocks | infinity: yeah, compiz is aweful with the gconf backend | 17:50 |
| didrocks | infinity: basically, copying you 2 trees | 17:50 |
| didrocks | so if you reset some keys | 17:50 |
| didrocks | you need to force again to copy the keys | 17:50 |
| didrocks | this is triggered by the "profile" change | 17:50 |
| infinity | Brilliant. | 17:50 |
| infinity | Well, it appears to do what it's meant to do, +1 from me. | 17:50 |
| infinity | Were "+1" is "+0.5" with an added "ew". :P | 17:51 |
| skaet | infinity, accepted then. | 17:51 |
| skaet | infinity, could you take a look at software-center as well? | 17:51 |
| infinity | skaet: Already was. ;) | 17:52 |
| * skaet thinking we might want to pick it up as well, based on the bug fixes mentioned in it. | 17:52 | |
| didrocks | infinity: yeah, I can only say "sorry for the kittens…" | 17:52 |
| skaet | nessita, its been accepted now. | 17:53 |
| nessita | skaet: thanks! | 17:53 |
| infinity | skaet: Yeah, givne the obvious bugs I see fixed just in a cursory scan, there's no way s-c can be more broken than it was previously. | 17:54 |
| infinity | (There's a ringing endorsement, right?) | 17:54 |
| skaet | indeed | 17:54 |
| infinity | But yeah, the theme oopses and the fixing of incorrect returns already looks worth it, and nothing else looks obviously wrong. | 17:55 |
| infinity | (Accepted) | 17:55 |
| skaet | infinity, thanks! | 17:55 |
| infinity | And picking up vorlon's bash-completion upload too. | 17:56 |
| slangasek | that one's ultra-low priority for beta-2 | 17:56 |
| slangasek | but ok :) | 17:56 |
| infinity | slangasek: Yeah, but if other things with longer build times are building anyway. | 17:56 |
| infinity | slangasek: And if we're respinning anyay. | 17:56 |
| didrocks | infinity: slangasek cjwatson pitti: I just hope we won't have any bad surprise with looking at the schema thing if nothing is setup (before even compiz is run for the first time). At worse, the smaller wrapper crashes the first time, but compiz will then still load (as it ignores the subprocess report) | 17:56 |
| didrocks | I'll try with a new account to ensure | 17:57 |
| infinity | didrocks: What's important is that you thought of that AFTER you uploaded. ;) | 17:57 |
| infinity | didrocks: But yeah, the fact that compiz blindly ignores the return of the fork should be enough. | 17:57 |
| infinity | Maybe. | 17:58 |
| didrocks | infinity: yeah, just looked more at the compiz code… and it's settings a *schema* for the current profile | 17:58 |
| didrocks | not using any normal "key" | 17:58 |
| * Daviey wonders why keystone is in the desktop set. | 18:01 | |
| slangasek | looks like fatfingering to me | 18:02 |
| * skaet curious about that as well, dependency pulling it in? | 18:02 | |
| Daviey | nah, but NFI what is causing it. | 18:03 |
| slangasek | no, I'm pretty sure that's just a bug in the packageset metadata | 18:04 |
| infinity | Task: openstack | 18:04 |
| slangasek | which someone will want to fix | 18:04 |
| rickspencer3 | if we can put Ubiquity on the server, we can put keystone on the desktop | 18:04 |
| infinity | Oh, I guess that Task info is right. | 18:04 |
| infinity | No idea why it's in the above sets, however. | 18:04 |
| Daviey | infinity: i created an openstack Task. | 18:04 |
| Daviey | I've seen similar skew before.. not too worried at this stage TBH | 18:05 |
| infinity | Is it intentional that all this openstack stuff in universe gets the "Supported: 5y" tag, or is that an accidental side-effect of it being in the -server packageset? | 18:06 |
| zul | infinity: the intention is to get it promoted to main | 18:07 |
| * Daviey will take keystone | 18:08 | |
| * skaet sees some enlighted self interest on that last bit of volunteering :) | 18:08 | |
| Daviey | it's a universe package, so why would there be self interest :P | 18:09 |
| === ralsina is now known as ralsina_lunch | ||
| skaet | infinity, compiz on armhf seems to be triggering some unmet dependencies. libgtk-3-0, which has a package building, just wait and retry or something more serious? | 18:21 |
| skaet | https://launchpadlibrarian.net/98429219/buildlog_ubuntu-precise-armhf.compiz_1%3A0.9.7.2-0ubuntu2_FAILEDTOBUILD.txt.gz | 18:21 |
| infinity | skaet: Just wait and retry, nothing to see here. | 18:22 |
| infinity | (Well, nothing except a missing feature I meant to add to lp-buildd 5 years ago and didn't) | 18:22 |
| didrocks | infinity: I tried in a blank new session and indeed there is a harmless stack, let me test a fix though | 18:24 |
| didrocks | just try: except: pass (as if there is no schema, we don't want to enforce one) | 18:24 |
| infinity | didrocks: Just test for the key existing first? | 18:24 |
| infinity | Or that. | 18:24 |
| infinity | Same net result. | 18:24 |
| didrocks | infinity: it's not a key, it's a schema, gconf is not that nice :) | 18:24 |
| didrocks | but yeah | 18:24 |
| didrocks | the idea is that ;) | 18:24 |
| didrocks | (it should be a key, but compiz makes it a schema…) | 18:25 |
| infinity | Sadly, thanks to apport, there's no such thing as a harmless stack trace. :P | 18:25 |
| infinity | Not in a development release anyway. | 18:25 |
| didrocks | infinity: indeed, that's why I want to prevent that :) | 18:25 |
| didrocks | the unity package here fix an interesting issue for beta2 IMHO ^ | 18:25 |
| didrocks | (do not freak out on the "inline patch", it's because I bzr merge using bzr merge-upstream workflow from upstream) | 18:26 |
| nessita | hello again! the new ubuntuone-client 2.99.91-0ubuntu2 has a security fix where we removed some code that was logging the user's proxy credentials | 18:27 |
| infinity | didrocks: Inline patches don't bug me. I'm old enough to remember when diff.gz was nothing but. :P | 18:28 |
| infinity | didrocks: Looks sane enough. | 18:29 |
| didrocks | infinity: thanks! | 18:30 |
| infinity | nessita: Eek. | 18:30 |
| infinity | nessita: I'm not going to ask at what point someone thought it was a good idea to log that. ;) | 18:31 |
| nessita | infinity: I can give some details... this is the first release we're doing with proxy support for UBuntu One, and thus the developers have been doing lots of work and lots of debugging was needed. Of course, we should have checked this before releasing to Ubuntu. | 18:32 |
| infinity | nessita: Heh. It happens. Just a bit of an unfortunate oops. | 18:32 |
| Laney | wow, caph is still busted? | 18:32 |
| nessita | infinity: yeah :-) | 18:32 |
| Laney | armel is not happy today | 18:32 |
| nessita | thanks! | 18:32 |
| infinity | Laney: Grr, I thought from backscroll in another channel that had been fixed. | 18:33 |
| Laney | it had been | 18:33 |
| infinity | Laney: I'm just going to set caph to broken and retry all those. | 18:34 |
| Laney | on https://launchpad.net/builders/caph/+history you can see it worked for a small while | 18:34 |
| infinity | On the other hand, the opportunity to mark a machine as a "sad panda" never gets old. | 18:35 |
| Laney | didrocks: you might want to retry https://launchpad.net/~unity-team/+archive/staging/+build/3319350 | 18:36 |
| === ralsina_lunch is now known as ralsina | ||
| Laney | (chort was also affected, but seems to be building gtk+3.0 alright now) | 18:36 |
| didrocks | Laney: it's fine, there will be a new commit soon and it will trigger another build :) | 18:37 |
| Laney | righto | 18:37 |
| infinity | The fact that this is hitting multiple machines doesn't make me feel good at all... | 18:38 |
| Laney | yeah, and that it came back on one of them ... | 18:38 |
| infinity | No recent updates to tar or bzip2, though. | 18:39 |
| infinity | That would be too easy. :/ | 18:39 |
| Laney | 26/03 13:41:14 <wgrant> Laney: Yeah, the chroot file in caph's cache seemed to be randomly corrupted (correct length, incorrect content). We forced it to refetch and it's happy now. | 18:40 |
| skaet | infinity, didrocks, could you please look at https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.2-0ubuntu2 - attempted rebuild in armhf failed. | 18:40 |
| infinity | skaet: Transitive, just needs gtk+3.0 to finish. | 18:40 |
| Laney | btw, haskell-yesod-default could do with a nudge through NEW if anyone likes pressing buttons | 18:40 |
| didrocks | infinity: speaking of which, here is the fix tested in a blank new session (and tested as well on existing ones, with different cases) ^ | 18:41 |
| didrocks | infinity: do not hesitate if you spot anything bad, should be straightfoward | 18:41 |
| skaet | infinity was looking at the gtk-2.0, now looking at the right place, and yup, seeing it is still finishing... https://launchpad.net/ubuntu/+source/gtk+3.0/3.4.0-0ubuntu1 | 18:43 |
| infinity | Laney: Ugh. Why does everything in the world end up build-depending on ghci? :P | 18:44 |
| Laney | people keep on using Template Haskell | 18:46 |
| infinity | Laney: (Actually, that's a half serious question, I don't know ghc very well, but why would one need an interactive interpreter at build time?) | 18:46 |
| Laney | it's a compile-time metaprogramming extension | 18:47 |
| Laney | I guess it shares code with the interpreter | 18:47 |
| infinity | Fun. | 18:47 |
| infinity | Well, here's hoping someone feels that should work on more than just x86 some day. | 18:47 |
| Laney | Someone does, but not the same someone that gets paid for GHC sadly | 18:51 |
| didrocks | infinity: does the change in compiz looks sane to you? | 18:51 |
| infinity | didrocks: If AttributeError is the only thing it's going to throw, yep. | 18:53 |
| didrocks | infinity: seems so from my tests at least | 18:53 |
| didrocks | no GError or whatever | 18:53 |
| infinity | Also, that diff touches on my one biggest annoyance with indenting-as-flow-control. That diff is completely unreadable, where it could have been a 3-line diff in C. :P | 18:53 |
| infinity | (Not that you'd want it as a 3-line diff if you were keeping it, but for a hack on a hack?) | 18:54 |
| didrocks | infinity: yeah, and it makes you reading it 3 times to ensure you are not missing something obvious | 18:54 |
| infinity | Yeahp. | 18:54 |
| infinity | Anyhow. I've read it 3 times, and accepted it. :P | 18:54 |
| didrocks | accepted 3 times as well? :p | 18:55 |
| infinity | Just the once. | 18:55 |
| didrocks | I like diff -b, a pity there is not that option on the generated ones :) | 18:55 |
| skaet | infinity, didrocks - reset the rebuild trigger to wait on that latest compiz drop? | 18:56 |
| infinity | skaet: Aye. | 18:56 |
| seb128 | just for info, the GNOME 3.4 uploads I'm (and others are) doing to proposed are staging for post beta | 18:56 |
| infinity | skaet: It'll be the same time anyway, given that arm* can't build it until GTK is done. :P | 18:56 |
| seb128 | it's to avoid cahos on friday after unfreeze and work duplication | 18:56 |
| infinity | seb128: Check. | 18:56 |
| skaet | thanks seb128 | 18:57 |
| * Laney likes this staging in -proposed business | 18:57 | |
| infinity | Yeah, we really should do it more. | 18:58 |
| skaet | just means a bit more tracking when some are loading to -release, and some are loading to -proposed with the intent of it being copied over for -release. | 18:59 |
| stgraber | ^ might fix an ubiquity bug (saying might as it's a race condition and it's not clear that it's indeed messing with debconf) | 19:06 |
| stgraber | if it doesn't fix the bug, it'll at least do some useful logging | 19:06 |
| GrueMaster | skaet: Could you add bug 963512 to the rebuild triggers list? Everthing in arm+omap4 will need respin if/when this gets fixed. | 19:07 |
| ubot2 | GrueMaster: Error: Could not parse data returned by Launchpad: The read operation timed out (https://launchpad.net/bugs/963512) | 19:07 |
| skaet | GrueMaster, done. added it to under investigation. | 19:08 |
| GrueMaster | Thanks. | 19:08 |
| === shadeslayer_ is now known as shadeslayer | ||
| slangasek | stgraber: which ubiquity bug might it fix? | 19:15 |
| stgraber | slangasek: bug 964857 at least (I seem to hit it every 5 installs or so here) | 19:16 |
| ubot2 | Launchpad bug 964857 in ubiquity "12.04 Beta 2 candidate install stuck at "Configuring target system..."" [Undecided,New] https://launchpad.net/bugs/964857 | 19:16 |
| cjwatson | I've accepted it, it's definitely correct | 19:16 |
| cjwatson | though I'd have used echo >&2 rather than logger, but meh | 19:16 |
| stgraber | slangasek: the only way you can track it down is if running with debconf debug turned on, otherwise it just hangs | 19:16 |
| * slangasek nods | 19:16 | |
| slangasek | huh, wasn't there another instance of that bug reported previously? | 19:17 |
| slangasek | ISTR seeing it on one of the bug lists | 19:17 |
| cjwatson | staging in -proposed> it'll be great once we have any tools at all for managing it | 19:17 |
| cjwatson | slangasek: target-config scripts get it wrong from time to time, but I don't remember noticing it in g-k before | 19:17 |
| stgraber | yeah, I think we had it reported already or something very similar anyway. I just looked at the "recently changed" list on LP and picked the first one matching what I had in my VM :) | 19:18 |
| slangasek | I don't know if anyone fingered g-k for it, but I do think I saw another bug with that description | 19:18 |
| slangasek | checking | 19:18 |
| cjwatson | there was an ubuntustudio one you may be remembering | 19:19 |
| cjwatson | I fixed it in casper recently-ish | 19:19 |
| slangasek | oh, I was thinking of bug #946663, which is a different hang | 19:19 |
| ubot2 | Launchpad bug 946663 in ubiquity "Installer stuck at "Removing conflicting operating system files..."" [High,Confirmed] https://launchpad.net/bugs/946663 | 19:19 |
| infinity | didrocks: Oh, pretty please tell me there'll be a less insane fix for that bug in the next week or so? | 19:19 |
| cjwatson | I'm going to add logging to ubiquity to make it vaguely feasible to debug this | 19:19 |
| didrocks | infinity: I totally hope so. I told dx that no more code will enter precise before there is a sane fix for it | 19:20 |
| didrocks | infinity: do not forget that I uploaded to -proposed, so a copy will be needed before triggering the iso rebuild | 19:21 |
| infinity | didrocks: Well, even if a sane fix can't be found, a less insane workaround in C/C++ that doesn't have compiz forking python? :P | 19:21 |
| didrocks | infinity: oh, that's for sure at least :) | 19:21 |
| didrocks | infinity: I just went to the quickest | 19:21 |
| didrocks | infinity: I try to sneaked another workaround better in libcompizconfig before | 19:21 |
| didrocks | but the code path is insane | 19:21 |
| didrocks | and even sam was giving bad directions, with functions not called at boot | 19:22 |
| didrocks | (before == earlier today) | 19:22 |
| didrocks | just went to the urgency now… | 19:22 |
| cjwatson | slangasek: ah, and when jodh was trying to debug that, it looks as though he ran into the bug stgraber just fixed | 19:22 |
| cjwatson | (comment 30) | 19:23 |
| cjwatson | tools> hey, I guess we have suite-diff.py at least, crude though it is | 19:24 |
| cjwatson | for x in main restricted universe multiverse; do suite-diff.py ubuntu/dists/precise{,-proposed}/$x/source/Sources.gz lt; done | 19:24 |
| cjwatson | anyone mind if I copy the ones that are done | 19:25 |
| cjwatson | ? | 19:25 |
| cjwatson | they'll probably go into the queue actually, I'll give it a try | 19:25 |
| skaet | cjwatson, yes please copy over the ones that are done. | 19:30 |
| cjwatson | ok, those look like the two that require copying right now | 19:30 |
| cjwatson | compiz seems to have failed to build on ARM? | 19:30 |
| skaet | cjwatson, watch out for the gnome ones though - they're just hanging around there until after beta 2 | 19:31 |
| didrocks | cjwatson: was gtk mismatch, isn't it? | 19:31 |
| cjwatson | oh, right | 19:31 |
| skaet | cjwatson, was waiting on gtk-3.0 building | 19:31 |
| cjwatson | skaet: yeah, I skipped gtk+3.0 and gnome-panel | 19:31 |
| cjwatson | does it matter if we copy compiz built against new gtk+3.0, but not gtk+3.0? | 19:31 |
| seb128 | cjwatson, skaet: there is not issue accepting any of the GNOME updates (i.e if you do that by error don't worry), they are mostly translation updates | 19:32 |
| * cjwatson checks shlibdeps | 19:32 | |
| * skaet was worrying about that... | 19:32 | |
| seb128 | cjwatson, gtk didn't bump shlibs | 19:32 |
| didrocks | so should be fine | 19:32 |
| seb128 | none of the GNOME update would bump anything, they were code frozen since .92 | 19:32 |
| cjwatson | confirmed, it just has compiz-dev Depends: libgtk-3-dev | 19:33 |
| cjwatson | (unversioned) | 19:33 |
| infinity | Surely, it's the non-dev deps that are interesting... | 19:33 |
| cjwatson | there weren't any | 19:34 |
| infinity | Oh. | 19:34 |
| cjwatson | given back compiz/armhf; armel will need to wait a bit more | 19:34 |
| infinity | Quite a bit more. The build had to start over, thanks to whatever's plaguing chort and caph. | 19:34 |
| infinity | Looking into that. | 19:34 |
| cjwatson | $ grep-aptavail -nsPackage -XS compiz -a -FDepends libgtk-3 | sort -u | 19:35 |
| cjwatson | compiz-dev | 19:35 |
| didrocks | infinity: cjwatson: yeah, the build-dep was optional at some point, but you can still used compiz-dev that exposed some gtk API for a conditional build | 19:35 |
| cjwatson | I suppose technically there's libgail-3-* too but blah | 19:35 |
| didrocks | seems the dep changed and we should maybe build-dep on it | 19:35 |
| didrocks | (with all the unity-window-decorator apart from gtk-window-decorator and now back in…) | 19:36 |
| skaet | cjwatson, infinity: http://pad.ubuntu.com/ubuntu-release is up to date now I think. [5] and [9] are pretty much waiting on armhf build, then [5] needs to be copied over, then can trigger the rebuilds. See anything missing? | 19:39 |
| cjwatson | infinity: https://launchpad.net/ubuntu/+source/gtk+3.0/3.4.0-0ubuntu1/+build/3319831 is pretty wacky | 19:39 |
| cjwatson | Currently building on nasl (arm panda) on chort (arm panda) | 19:40 |
| cjwatson | panda-on-panda action, apparenty. | 19:40 |
| cjwatson | +l | 19:40 |
| infinity | cjwatson: Yeah, that's just a display bug. | 19:42 |
| infinity | cjwatson: It'll self-sort once the build on nasl is done. | 19:42 |
| cjwatson | Daviey: server size> dropping mailman looks like it'd come out fairly close? | 19:43 |
| cjwatson | skaet: we shouldn't copy over compiz until builds on all architectures are done, even if they aren't release architectures. I'm fairly sure LP won't be happy otherwise, and if we do that it may not be possible to copy compiz/armel at all until there's a new version. | 19:44 |
| skaet | cjwatson, including waiting for armel? | 19:45 |
| cjwatson | This is a particularly hairy part of LP and it's best treated with kid gloves. | 19:45 |
| cjwatson | Yes. | 19:45 |
| skaet | Noted, and thanks for the warning. | 19:45 |
| cjwatson | (LP may not even let you, but I don't want to try.) | 19:45 |
| slangasek | based on past experience, I expect LP will let you copy and then you'll be screwed wrt getting the binaries over | 19:47 |
| skaet | lovely... :P | 19:48 |
| cjwatson | # Conflicting candidates pending build or building in a different | 19:48 |
| cjwatson | # series are a blocker for the copy. The copied source will | 19:48 |
| cjwatson | # certainly produce conflicting binaries. | 19:48 |
| cjwatson | build_summary = candidate.getStatusSummaryForBuilds() | 19:48 |
| cjwatson | building_states = ( | 19:48 |
| cjwatson | BuildSetStatus.NEEDSBUILD, | 19:48 |
| cjwatson | BuildSetStatus.BUILDING, | 19:48 |
| cjwatson | ) | 19:48 |
| cjwatson | if build_summary['status'] in building_states: | 19:48 |
| cjwatson | raise CannotCopy( | 19:48 |
| cjwatson | "same version already building in the destination " | 19:48 |
| cjwatson | "archive for %s" % candidate.distroseries.displayname) | 19:49 |
| cjwatson | But you probably won't see that error anywhere terribly useful and you'll be left trying to divine it from chicken guts. | 19:49 |
| cjwatson | So, yeah, you gotta wait. | 19:49 |
| skaet | cjwatson, urk. indeed. | 19:49 |
| slangasek | (that's why I have my checkout of lp:haruspex) | 19:49 |
| cjwatson | (Similarly it checks for unpublished binaries.) | 19:49 |
| skaet | cjwatson, has debian-cd/CONF.sh been set to OFFICIAL? | 19:50 |
| * skaet doing a pass for the release-3 day checklist | 19:50 | |
| cjwatson | OFFICIAL has been set to Beta there, yes | 19:50 |
| infinity | cjwatson: Oh, for the record, if you copy/move something from pocket A to pocket B (and then remove it from A), you can still repair the issue for unbuilt arches by just copying the source back to pocket A, building, and copying to B again. :P | 19:51 |
| cjwatson | erk | 19:51 |
| infinity | cjwatson: (I've done this a few times) | 19:51 |
| cjwatson | Beta-2 still | 19:51 |
| cjwatson | that really needs to go to Beta as I explained this morning | 19:51 |
| cjwatson | otherwise it busts wubi | 19:51 |
| * cjwatson cowboys that for now | 19:51 | |
| infinity | cjwatson: Not that I recommend relying on this fallback, but it works if someone messes up and does a partial copy. | 19:51 |
| cjwatson | ew | 19:52 |
| cjwatson | creative but foul | 19:52 |
| cjwatson | and you end up with a spaghetti publishinghistory | 19:53 |
| infinity | The history is arguably less important than the result. | 19:56 |
| infinity | But yes, it's not ideal. | 19:56 |
| skaet | proposed gtk+3.0 has built armhf, but not armel yet... which is still in the chain for compiz... | 19:58 |
| * pitti waves | 19:58 | |
| pitti | so, I see we have a workaround for unity after all, nice | 19:58 |
| pitti | gtk+2.0 finally built at last, I'll move to precise | 19:58 |
| skaet | hiya pitti, board is up to date. we probably need to talk about conventions a bit for what goes in proposed, and when, some extra tracking has been needed. | 19:59 |
| cjwatson | I already did | 19:59 |
| cjwatson | pitti: | 19:59 |
| pitti | cjwatson: ah, thanks | 19:59 |
| pitti | skaet: well, when in doubt, use -proposed | 19:59 |
| cjwatson | skaet: we're trying to do all this in advance of the plan of record for adding tools ;-) | 19:59 |
| pitti | skaet: in particular, anything with nontrivial build times, anything which, when it fails on only some arches woudl have a devastating effect, and anything which involves library transitions | 19:59 |
| skaet | pitti, not so sure about that, since extra tracking and interactions with other stuff in propsed... | 19:59 |
| cjwatson | not that it's a *detailed* plan of record, but | 20:00 |
| pitti | like, LibO is a definitive example for -proposed | 20:00 |
| skaet | pitti, latest compiz should have been in -releases.. | 20:00 |
| pitti | as it makes armhf uninstallable for two days otherwise | 20:00 |
| pitti | compiz/unity are as well, due to a build dep chain of at least 3 | 20:00 |
| skaet | pitti, yup +1 on that example. | 20:00 |
| skaet | pitti, problem is when other parts of that chain are preseeding into -proposed gtk+3.0 for instance. | 20:01 |
| cjwatson | there is a well-established tool for all this in Debian | 20:01 |
| infinity | britney? :P | 20:01 |
| cjwatson | we need to figure out how to integrate it without going insane in other ways | 20:01 |
| cjwatson | yes | 20:02 |
| infinity | I wonder how well it would perform if you just ran it without the aging period. | 20:02 |
| infinity | So, jam stuff in ASAP when it can. | 20:02 |
| cjwatson | something like that; needs experimentation | 20:02 |
| Daviey | cjwatson: Yep, i have that in my local branch.. trying to find a few other things. | 20:03 |
| cjwatson | does it need more? that looked like about 9mb iirc | 20:04 |
| Daviey | cjwatson: Is it really that big? | 20:04 |
| Daviey | wow | 20:04 |
| cjwatson | I assumed you'd started your investigations with a sorted-by-size list of packages. | 20:05 |
| Daviey | cjwatson: I was trying to make space for keystone aswell, but that can(will) slip b2. | 20:05 |
| cjwatson | ah | 20:05 |
| Daviey | cjwatson: No, i was using a poke-it-and-see approach | 20:05 |
| cjwatson | mailman is Size: 9648660 | 20:05 |
| cjwatson | on i386 | 20:05 |
| cjwatson | um, I strongly recommend sorting by size :) | 20:05 |
| pitti | Daviey: btw, do you know about ~/iso-deb-size-compare on nusakan? | 20:06 |
| cjwatson | otherwise you waste a lot of time on things that look complex but are small | 20:06 |
| Daviey | pitti: i do not.. | 20:06 |
| pitti | Daviey: you give it two (alternate-style) isos, and it gives you an overview of added, removed, and significantly grown packages | 20:06 |
| Daviey | that looks handy | 20:06 |
| pitti | i. e. you can compare it against the beta-1 image etc. and see what grew fat | 20:06 |
| Daviey | cjwatson: I was trying to work out why the heck we have, computer-janitor | 20:06 |
| pitti | Daviey: c-j has a CLI backend | 20:07 |
| Daviey | i thought it was dropped.. | 20:07 |
| Daviey | isn't that barry's project? | 20:07 |
| pitti | and given that we never worked out how to get rid of the plethora of kernels that pile up, it's the next best thing.. | 20:07 |
| Daviey | pitti: we do have a kirk-o-matic this cycle, no? | 20:07 |
| slangasek | a what now? | 20:08 |
| pitti | Daviey: ? | 20:08 |
| Daviey | I thought kirkland produced a script to scrub old kernels? | 20:08 |
| pitti | do they get beamed away? | 20:08 |
| pitti | ah, I'm sure there's a bunch of those around | 20:08 |
| cjwatson | Daviey: Size: 34648 => not worth thinking about | 20:08 |
| Daviey | cjwatson: Well there are a few crap things we can drop, including fortunes-ubuntu-server :) | 20:09 |
| cjwatson | Size: 32298 | 20:09 |
| Daviey | the small things do add up, right? | 20:09 |
| cjwatson | it's a lot quicker to go for the big things first | 20:09 |
| Daviey | ok | 20:09 |
| * Daviey bzr reverts | 20:09 | |
| cjwatson | you'll be arguing forever if you try to chip away at small things | 20:09 |
| cjwatson | not that it isn't worth removing them if they're pointless, but they aren't really useful low-hanging fruit ... | 20:10 |
| slangasek | Daviey: Dustin may have written a script, but I don't believe such a one has been integrated anywhere | 20:10 |
| Daviey | cjwatson: puppet would remove ruby? | 20:10 |
| pitti | Daviey: http://paste.ubuntu.com/901079/ | 20:10 |
| pitti | Daviey: diff between beta-1 and current daily i386, FYI | 20:11 |
| slangasek | puppet+facter are the only reason for ruby in main at all, IIRC | 20:11 |
| Daviey | pitti: right, those are by design. | 20:11 |
| Daviey | but very useful if an iso balloons by suprise! | 20:11 |
| pitti | rabbitmq-server (Δ 1.6 MB - 2.6.1-1ubuntu4: 1.2 MB 2.7.1-0ubuntu2: 2.7 MB) | 20:11 |
| slangasek | it's by design that rabbitmq-server doubled in size? :/ | 20:11 |
| pitti | that looks worth a second look | 20:11 |
| Daviey | slangasek: I'd like puppet still seeded, but don't care for it on the iso. | 20:12 |
| cjwatson | rabbitmq-server borged several smaller packages | 20:12 |
| slangasek | mmk | 20:12 |
| * skaet notes unity is done.... still waiting on the gtk+3.0 build for armel, so that compiz armle can build, and then get copied over... grr. | 20:12 | |
| cjwatson | bug 948993 | 20:12 |
| ubot2 | Launchpad bug 948993 in rabbitmq-stomp "[FFe] [MIR] rabbitmq-stomp, rabbitmq-erlang-client" [Undecided,Fix released] https://launchpad.net/bugs/948993 | 20:12 |
| slangasek | bwuh? libgconf-2-4? | 20:12 |
| cjwatson | http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/libgconf2-4 -> checkbox-cli | 20:13 |
| pitti | docutils-doc (1.3 MB) | 20:13 |
| Daviey | slangasek: it increaed because 2 seperate source packages beacme part of it upstream. | 20:13 |
| slangasek | cjwatson: ah, doh | 20:13 |
| Daviey | slangasek: as in, they were seperate sources upstream, now part of core | 20:13 |
| slangasek | Daviey: right | 20:13 |
| cjwatson | well, checkbox-cli Depends: checkbox Recommends: gstreamer0.10-gconf Depends: libgconf2-4 | 20:13 |
| cjwatson | most of the increase was MaaS, realistically, wasn't it? | 20:14 |
| cjwatson | so I think you have to look for pre-existing stuff | 20:14 |
| cjwatson | Daviey: you could move puppet to platform.precise/supported-misc-servers, then, I guess | 20:15 |
| * pitti is slightly confused about the "Finished ..." line on https://launchpad.net/ubuntu/+source/gtk+3.0/3.4.0-0ubuntu1/+build/3319831 | 20:15 | |
| pitti | was gtk+3.0 build aborted and restarted, in a weird way? | 20:15 |
| cjwatson | 20:42 <infinity> cjwatson: Yeah, that's just a display bug. | 20:15 |
| cjwatson | 20:42 <infinity> cjwatson: It'll self-sort once the build on nasl is done. | 20:15 |
| cjwatson | pitti: ^- | 20:15 |
| cjwatson | and yes, it was | 20:15 |
| pitti | ah, thanks | 20:16 |
| cjwatson | 20:34 <infinity> Quite a bit more. The build had to start over, thanks to whatever's plaguing chort and caph. | 20:16 |
| Daviey | http://pb.daviey.com/0L3V/ | 20:16 |
| pitti | so, at this point I have the feeling that I can be more useful tomorrow early morning | 20:17 |
| Daviey | cjwatson: yep, same with bacula and tomcat | 20:17 |
| Daviey | and awstats | 20:17 |
| cjwatson | Daviey: http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.precise/rdepends/ALL/ruby1.8 says puppet and facter, yes | 20:17 |
| skaet | pitti, thanks for checking in. see you on the flip side. | 20:17 |
| cjwatson | and puppetmaster | 20:17 |
| pitti | ack, good night! | 20:17 |
| Daviey | most of the python-* things i've listed were added to flag them for MIR, really they are already there through depends | 20:17 |
| skaet | pitti, sleep well. | 20:17 |
| Daviey | i'm waiting for elmo to kick me for dropping zsh from the cd pool. | 20:18 |
| cjwatson | so are you going to move those to supported-misc-servers or some other supported-*? I don't think this should be intrinsically linked to dropping stuff out of main | 20:18 |
| infinity | Daviey: I doubt elmo cares deeply what's on the ISO. | 20:19 |
| cjwatson | it can't be in the one commit unfortunately due to the seed structure, but it would be nice for future archaeologists if the commits were at least close together in time | 20:19 |
| infinity | Though, to be fair, I doubt that 99% of cloud users care either. | 20:19 |
| infinity | Which makes a lot of this shuffling feel odd to me. | 20:19 |
| infinity | I'd rather have stuff to make a "small business server" on the ISO than stuff that most users will do via pre-seeding and local mirrors. | 20:20 |
| Daviey | cjwatson: I will added them elsewhere to make sure they stay in main. | 20:20 |
| * skaet going to get some food while waiting for those builders to finish off.. biab | 20:20 | |
| Daviey | cjwatson: I'm going to wait to see what changes on c-m, candiates for demotion, before re-adding them elsehwre.. It might be duplicated content. | 20:22 |
| kirkland | slangasek: Daviey: I have one, I was just putting it in bikeshed, until such time as you folks agreed on where it should/would live | 20:24 |
| slangasek | kirkland: ah, alrighty. Yeah, cf. ubuntu-devel discussion from last month :) | 20:25 |
| kirkland | slangasek: yup | 20:26 |
| cjwatson | Daviey: OK - you could run germinate locally though | 20:26 |
| kirkland | slangasek: I didn't see that discussion come to a consensus that this was something that ubuntu-devel@ wanted to solve in general for users, in a seeded, supported manner | 20:26 |
| Daviey | cjwatson: I could.. but is there any benefit from having it done for me? | 20:26 |
| slangasek | kirkland: er, I would have assumed that was the consensus from the outset | 20:27 |
| kirkland | slangasek: so we, as users of ubuntu-server in production, have our own scripts (that are now rebased on what kees sent to the list) | 20:27 |
| cjwatson | Daviey: anyone else who looks at c-m asynchronously from this may get confused and process some of the output? :-) | 20:27 |
| slangasek | no one likes /boot filling up, it's just been awkward to integrate without the risk of regression | 20:27 |
| kirkland | slangasek: okay, where should I put what I have? | 20:27 |
| slangasek | I don't know ;) | 20:27 |
| kirkland | slangasek: heh | 20:27 |
| slangasek | but it's also certainly not server-specific | 20:28 |
| Daviey | cjwatson: Okay, Okay! :) | 20:28 |
| * cjwatson goes to look after the kids for a bit. SMS me if needed | 20:29 | |
| Daviey | slangasek: Why doesn't linux-generic depend on the current kernel, Recommend on current-1, and let apt clear up? | 20:30 |
| Daviey | slangasek: if users want a specific kernel, they should install it directly | 20:30 |
| slangasek | Daviey: because current-1 is not necessarily the kernel you last booted successfully or have running currently | 20:30 |
| kirkland | slangasek: I'll post what I have to ubuntu-devel as a followup now | 20:30 |
| kirkland | slangasek: well, as soon as I can | 20:30 |
| infinity | Daviey: Because that doesn't help if the one you're booted... What he said. | 20:30 |
| infinity | This really needs to be a kernel postinst hook, so we know right that moment what "latest installed" and "currently running" are. | 20:31 |
| infinity | And we can mark them as auto-installed at that point, so autoremove reports them. | 20:31 |
| infinity | (Mark the ones we don't want anymore, that is) | 20:31 |
| kirkland | pitti: would a shell script, remove-old-kernels (that accepts an optional parameter of --all-but INTEGER number of kernels), be acceptable to the computer-janitor package? | 20:32 |
| Daviey | current, and current-1 seems reasonable IMO.. if you have a troublemaker kernel, mark it as isntalled, and/or don't autoremove. | 20:32 |
| slangasek | why are you asking pitti? :-) | 20:32 |
| kirkland | Daviey: would the computer-janitor package (with its dbus dependencies) be acceptable for the server seed? | 20:32 |
| slangasek | computer-janitor belongs to foundations | 20:32 |
| kirkland | slangasek: sorry, I thought it was pitti's | 20:32 |
| Daviey | How many users who get failed boot, would know to tap down to current-2 in grub? | 20:33 |
| infinity | Daviey: We don't want people removing running kernels. | 20:33 |
| Daviey | slangasek: pitti mentioned it had a cli backend, so i was discussing the project with him. :) | 20:33 |
| slangasek | kirkland: I think we would prefer to see this included in apt itself | 20:33 |
| slangasek | (which is where the kernel autoremoval blacklist already lives) | 20:33 |
| kirkland | slangasek: okay, then I'm not of much help, then | 20:33 |
| infinity | slangasek: What of my above suggestion? | 20:34 |
| slangasek | I mean the apt package, not the apt binary | 20:34 |
| slangasek | infinity: and have apt provide that hook? | 20:34 |
| infinity | slangasek: I suppose apt could, since it'll ultimately be calling back there to update the auto/noauto status. | 20:34 |
| Daviey | slangasek: We have 'recovery' mode on cd media to allow people to unblock themselves, right? | 20:35 |
| slangasek | Daviey: er, if the currently booted kernel is current-3, there's no reason to install current-1 *at all*; so the last-good-boot kernel should still be the second boot option | 20:35 |
| Daviey | slangasek: right, and there is no need to do security updates, ever. | 20:35 |
| slangasek | non sequitur | 20:35 |
| infinity | Daviey: The only two kernel people should have in a fully automated setup are "latest from the archive" and "currently running". | 20:35 |
| slangasek | the kernels you care about keeping on the system are the one you're running, and the newest one | 20:35 |
| Daviey | I think the problem is being overcomplicated IMNSHO. | 20:36 |
| infinity | I think we just reduced it to something fairly simple, actually. | 20:36 |
| infinity | But YMMV. | 20:36 |
| Daviey | The target audience for this problem is powerusers or less-than-powerusers? | 20:36 |
| infinity | Everyone. | 20:37 |
| infinity | There's no difference. No one wants their current kernel removed, some people just don't know they don't want that. | 20:37 |
| Daviey | ok | 20:37 |
| slangasek | among other things because removing the current kernel means you can't auto-load any of the modules it contains, which you might be in need of between now and your next reboot | 20:38 |
| infinity | And it's also the only kernel we currently know actually functions on your hardware. | 20:38 |
| slangasek | yes | 20:40 |
| Daviey | a hook does allow granular end settings of behaviour easier, i suppose | 20:48 |
| phillw | we use https://help.ubuntu.com/community/Lubuntu/Documentation/RemoveOldKernels as we never quite know what the user is up to :) (The advanced one is being re-written as it looks a mess!). | 20:48 |
| infinity | phillw: *smirk*... I like the Problems section. | 20:50 |
| phillw | infinity: we were really stuck, when a guy had done it! | 20:50 |
| phillw | one of the forum staffers suggested about the link for when you are poking about. | 20:51 |
| Daviey | *sigh*, who approved keystone? | 21:05 |
| ScottK | Daviey: I did. | 21:07 |
| ScottK | It's in universe and unseeded. | 21:07 |
| Daviey | ScottK: No, it's no unseeded. It's in universe, and showing in c-m. | 21:08 |
| Daviey | I specifically said i was reviewing it. | 21:08 |
| ScottK | Sorry. Missed that. | 21:08 |
| Daviey | Sorry, it *is* seeded. | 21:08 |
| ScottK | Got that. My mistake. | 21:10 |
| * skaet notes gtk+3.0 is still building for armel, and blocking compiz. :P | 21:27 | |
| bdrung | hi, may someone look at the FFe bug #965659? | 21:29 |
| ubot2 | Launchpad bug 965659 in shunit2 "FFe: Sync shunit2 2.1.6-1 (universe) from Debian sid (main)" [Wishlist,New] https://launchpad.net/bugs/965659 | 21:30 |
| skaet | infinity, compiz is build in proposed for all but the armel port 9which is waiting still on gtk+3.0) to build. Any ideas how much longer its going to take? am wondering if worth making a much and copying compiz over to -release, so we can start rebuilding the images.... | 21:30 |
| * skaet looks back at that sentence and shakes her head. | 21:38 | |
| skaet | compiz is building in proposed for all but the armel port (which id waiting on a gtk-3.0 in proposed that it doesn't need to, and armel isn't a factor for the images). Any ideas how much longer the gtk+3.0 build is going to take, and then the armel for compiz? am wondering if its worth making a "mess" and copying over the compiled compiz binary bits to -release so we can start rebuilding the images... | 21:40 |
| skaet | infinity, slangasek, ^ thoughts? | 21:41 |
| ogra_ | skaet, armhf is there ? | 21:41 |
| skaet | ogra_, yes armhf is done. | 21:41 |
| skaet | we're waiting on something that we don't need from what I can tell. | 21:41 |
| ogra_ | well, it would need careful handling of the image builds ... | 21:42 |
| skaet | https://launchpad.net/ubuntu/+source/compiz/1:0.9.7.2-0ubuntu3 | 21:42 |
| tumbleweed | skaet: would you mind throwing a mention of seeded-in-ubuntu into future freeze announcement e-mails? We've noticed that most DMB applicants haven't come across it yet | 21:42 |
| ogra_ | iirc infinity did split the builds into armel/hf but you will likely still have to define ARCHES= | 21:42 |
| ogra_ | beyond that i dont see why armel shouldnt just be copied later | 21:43 |
| slangasek | because you can't "just copy later" | 21:43 |
| skaet | ogra_ http://pad.ubuntu.com/ubuntu-release has the commands, and they're split. | 21:43 |
| slangasek | the binaries have to all go in at the same time | 21:43 |
| slangasek | so either we wait, or we can't release any armel images for beta-2 | 21:43 |
| ogra_ | slangasek, do we care about armel ? | 21:44 |
| slangasek | (I'm not sure we need to release any armel images for beta-2 though, so that's the question) | 21:44 |
| ogra_ | as long as armhf is there i think its fine | 21:44 |
| * skaet nods, its not on the manifest. | 21:44 | |
| ogra_ | armel is a best effort thing now | 21:44 |
| skaet | other than in core... | 21:44 |
| ogra_ | well, core doesnt carry compiz ) | 21:44 |
| ogra_ | :) | 21:44 |
| skaet | and its not in server either, which is the other one that wasn't split. | 21:47 |
| skaet | there is kubuntu preistalled though... | 21:47 |
| ogra_ | armel ? | 21:47 |
| slangasek | that seems like a bug in the manifest, because there's certainly no kubuntu preinstalled being built for armel | 21:47 |
| ogra_ | hmm | 21:47 |
| skaet | yeah, manifest only calls for armhf, so we should probably just edit the buidl script on this one. | 21:50 |
| slangasek | skaet: so we're looking at roughly another 1.5h before compiz would be ready on armel; if we want to say compiz will not be installable on armel for beta-2, so be it | 21:50 |
| slangasek | as long as we get another compiz upload after beta-2 to get it back in sync | 21:50 |
| skaet | slangasek, yes, now the question is does someone feel confident in doing the copies over? | 21:51 |
| * ogra_ doesnt get the "have to go in at the same time" part | 21:51 | |
| ogra_ | if i upload compiz to the pool the binaries wont show up at the same time either | 21:51 |
| skaet | ogra_, check out the backscroll, good discussion earlier between cjwatson and infinity on the subject. | 21:51 |
| ogra_ | k | 21:52 |
| ogra_ | (indeed i didnt reall everything above :) ) | 21:52 |
| ogra_ | *read | 21:52 |
| slangasek | I also would point out here that gtk+3.0 in proposed doesn't seem to even be targeted for beta-2, so the fact that it gets in the way of a compiz rebuild is a telling example of how diverting everything to proposed for building is not a guarantee of keeping development velocity high during freezes without paying a price elsewhere | 21:53 |
| skaet | yes | 21:53 |
| slangasek | skaet: what are the packages in -proposed that are supposed to be copied? Is it just compiz? | 21:53 |
| skaet | slangasek, its just compiz at this point. | 21:53 |
| skaet | other bits were copied by cjwatson earlier | 21:53 |
| skaet | http://pad.ubuntu.com/ubuntu-release | 21:54 |
| slangasek | skaet: you know, another option we have is to do a no-change upload of compiz to the release pocket *instead* of the proposed pocket, which would get you x86 binaries as quickly as a pocket copy would, and arm* binaries within an hour | 21:55 |
| skaet | slangasek, that would work too, and I'd feel a bit better it being compiled against the pieces it was actually meant to be compiled against. | 21:55 |
| skaet | s/it/compiz/ | 21:56 |
| bjf | skaet: just fyi: Oneiric, linux-3.0.0-17.30 and Hardy, linux-2.6.24-31.100 are ready to be copied to -updates at someones convenience | 21:58 |
| skaet | bjf, ok. | 21:59 |
| slangasek | skaet: compiz -0ubuntu4 uploaded to precise | 21:59 |
| * skaet hugs slangasek | 21:59 | |
| ogra_ | slangasek, and another option would be to mangle the seeds to not install unity in armel, its not like it would actually be possible to *run* compiz on armel :) | 22:00 |
| slangasek | ogra_: the seeds don't matter for this if we're not building armel images anyway; this is just about the archive consistency | 22:00 |
| ogra_ | though i guess that would end up in dependency hell | 22:00 |
| slangasek | skaet: so if you can accept that immediately, we'll have compiz ready to go for x86 image builds within the hour | 22:01 |
| ogra_ | yeah, i wasnt 100% serious there :) | 22:01 |
| * skaet doing | 22:01 | |
| ogra_ | its just a shame that we get issues with SW that nobody is able to run anyway | 22:01 |
| slangasek | i.e., we'll miss the :03 publisher run and catch the :33 run | 22:02 |
| skaet | its approve now. | 22:03 |
| cjwatson | skaet,slangasek: and for the record, a reupload was the *only* way to bypass the armel build here. | 22:07 |
| ogra_ | silly LP | 22:07 |
| cjwatson | as I explained earlier, LP would have rejected an attempt to copy from -proposed while the armel build was still in progress, AIUI because doing so would have created another conflicting build job in the release pocket. | 22:08 |
| ogra_ | yeah, i understood that, still ... | 22:09 |
| cjwatson | feel free to hack on LP to remove the need for the restriction! | 22:10 |
| cjwatson | I don't think it's arbitrary given the current code | 22:11 |
| skaet | we're going to need to be careful about what we upload to -proposed, when there is a potential dependency in it, that is different from what's in -release. | 22:12 |
| cjwatson | yep - until our tools are much improved, it should only be used when we know the benefits outweigh the costs | 22:14 |
| Daviey | cjwatson: Debian doesn't allow migration from unstable to testing if there are still pending binaries aswell, right? | 22:15 |
| Daviey | Did LP copy that logic? | 22:15 |
| ogra_ | debian doesnt allow it, but i think technically it would be possible with dak | 22:16 |
| cjwatson | no, it's more subtle than that in Debian | 22:16 |
| ogra_ | (correct me if i'm wrong) | 22:16 |
| cjwatson | the LP restriction arose independently, from what I can tell | 22:16 |
| * Daviey cries at having what should be an init script, in /usr/sbin/ | 22:17 | |
| cjwatson | in LP it's more a consequence of a limitation of the current model, rather than the (AFAICR sometimes overridable) policy decision that it is in Debian | 22:17 |
| ogra_ | anyway, we dont build any armel images at all apart from core and moving armel to best effort but then letting it block us based on a package you cant even run on that arch seems inconsequent | 22:18 |
| cjwatson | certainly in Debian the restriction is not there to avoid triggering conflicting builds in different contexts | 22:18 |
| cjwatson | the LP restriction here does not take any account of the "importance" of an architecture | 22:18 |
| cjwatson | we can rail about that all we like but I respect their opinion that db integrity takes precedence | 22:19 |
| Daviey | cjwatson: I do find it odd that after a given time, dep-wait's are allowed to move to testing.. but AIUI, the dep-wait won't be satisfied in testing ever? | 22:19 |
| Daviey | as in, the build won't happen. | 22:19 |
| cjwatson | err that sounds like a confused version of something | 22:19 |
| cjwatson | dep-wait isn't something that applies to suites in that way, apart from anything else | 22:20 |
| cjwatson | the rule in Debian for unstable to testing propagation is that the total uninstallability of testing may not be made worse by promoting a set of packages | 22:20 |
| cjwatson | sorry, a rule, there are several | 22:21 |
| Daviey | cjwatson: no, i mean - after the age is satisfied, whatever is built is migrated to testing, providing there are no ftbfs.. dep-waits aren't a factor, right? | 22:21 |
| Daviey | And a dep-wait won't be triggered in testing, when the dep is satisfied, right? | 22:21 |
| cjwatson | no, that isn't accurateq | 22:21 |
| Daviey | cjwatson: the premise or the build? | 22:22 |
| cjwatson | your statement | 22:22 |
| cjwatson | another of the rules is that a package must be built on all the release architectures where it was previously built | 22:22 |
| cjwatson | it doesn't matter why it didn't build, if it didn't | 22:22 |
| cjwatson | ftbfs == dep-wait for this purpose | 22:22 |
| Daviey | and if it wasn't previously successfully built on a given arch? | 22:23 |
| cjwatson | then that isn't considered | 22:23 |
| cjwatson | (this is policy rather than an implementation restriction, and may be overridden) | 22:23 |
| Daviey | and when it does hit testing, if the dep-wait is satisfied, will it be given back? | 22:23 |
| cjwatson | builds happen in unstable, not testing | 22:24 |
| cjwatson | it's entirely possible for a dep-wait to be satisfied later in unstable, the package to be built, and the build for a single arch to be promoted to testing if it meets the other criteria | 22:24 |
| cjwatson | this happens routinely | 22:25 |
| Daviey | ok, thanks. | 22:25 |
| cjwatson | it's quite deliberate that builds don't happen in testing, because that would make it difficult to apply the consistency checks to them | 22:25 |
| cjwatson | though there is testing-proposed-updates for security updates to testing when unstable has diverged badly | 22:26 |
| cjwatson | I wouldn't expect we'd want -proposed to diverge that much | 22:26 |
| Daviey | That was my thought, but I thought that new bins couldn't be considered separately. | 22:26 |
| Daviey | I was wrong. :) | 22:26 |
| cjwatson | it's the only way for a new architecture to be added to testing; but it also happens when an arch is catching up for one reason or another | 22:27 |
| cjwatson | Debian's archive system is very flexible, and the flexibility is used. The price is that the Debian release team has to spend a lot of time babysitting the testing promotion process, because it's quite easy for lots of things to get intertwined in unstable - mainly though not entirely due to the enforced delay. | 22:30 |
| cjwatson | But I think we could make use of much of the same code that implements the core logic, with different policy. | 22:31 |
| Daviey | cjwatson: Do you think an enforced delay would be helpful in our dev cycle? | 22:31 |
| Daviey | (and dropping/shrinking the freeze windows) | 22:32 |
| cjwatson | Not really. The purpose of it is to allow some time for release-critical bugs to be filed. I'd rather hook it up to automated testing for that. | 22:32 |
| stgraber | oh, fun, my gnome-keyring upload failed to build on amd64 and i386: https://launchpad.net/ubuntu/+source/gnome-keyring/3.2.2-2ubuntu2 | 22:32 |
| cjwatson | In general I think there's a lot to be said for the Debian testing process, but the delay is one of the least pleasant aspects of it. | 22:33 |
| stgraber | anyone from desktop still awake at this time? (it's definitely not my one line change in a script that caused it ;)) | 22:33 |
| Daviey | stgraber: the perils of TIL :) | 22:33 |
| Daviey | doko has caught me on that too many times. | 22:34 |
| cjwatson | has gnome-keyring been built since the last p11-kit upload? | 22:34 |
| Daviey | cjwatson: Yeah.. we've been doing automated CI to a testing PPA for much of the stuff we care for... But it doesn't stop other crap spilling in. | 22:35 |
| cjwatson | Daviey: sure, I don't think we should be aiming for something that prevents all possible badness; we need to preserve velocity too | 22:35 |
| Daviey | right! | 22:35 |
| Daviey | cjwatson: limiting the ability to add crack as the freeze window looms is also desirable. :) | 22:36 |
| stgraber | cjwatson: last upload was on the 1st of February, so no | 22:36 |
| Daviey | stgraber: someone from my loco reported this morning, < AlanBell> anyone else getting *** VTE ***: Failed to load terminal capabilities from '/etc/termcap' when launching gnome-terminal today on 12.04 | 22:36 |
| Daviey | So before your upload.. might be related.. | 22:37 |
| broder | Daviey: you have to close all terminals | 22:37 |
| cjwatson | stgraber: hmph, there goes my best guess | 22:37 |
| cjwatson | Daviey: gnome-keyring doesn't depend on vte | 22:37 |
| broder | Daviey: gnome-term is a single process for all terminals, and it's running with the old libvte | 22:37 |
| Daviey | okay, sure... seemed worthy to mention. | 22:37 |
| cjwatson | stgraber: oh, wait, by "no" you meant ... err ... "no". I forgot the sense of my question. :-) | 22:38 |
| stgraber | cjwatson: right, by "no" I mean it's perfectly possible p11-kit is the problem :) | 22:38 |
| stgraber | what's interesting is that only i386 and amd64 failed, I'm used to all the other ones failing ;) | 22:39 |
| * cjwatson tries in a local sbuild | 22:39 | |
| stgraber | also wondering why the build on armel took 50 minutes but the i386 one took 3 hours... | 22:41 |
| cjwatson | because it hung in the test suite and waited for the timeout | 22:41 |
| cjwatson | I notice it failed a few tests before that, which don't (all, anyway) seem to fail locally | 22:45 |
| stgraber | fun... | 22:46 |
| Daviey | racey test suite \o/ | 22:46 |
| Daviey | django's is the same, i get scared each time i touch it. | 22:46 |
| skaet | stgraber, https://launchpadlibrarian.net/98459486/buildlog_ubuntu-precise-amd64.gnome-keyring_3.2.2-2ubuntu2_FAILEDTOBUILD.txt.gz | 22:47 |
| * skaet reads the backscroll, and sees you're looking into it. | 22:47 | |
| skaet | sorry | 22:47 |
| cjwatson | hm; well, for me, it's test-gnupg-collection that hangs | 22:48 |
| === bladernr_ is now known as bladernr_afk | ||
| stgraber | I guess I could hit retry until it builds, but that sounds like a waste of buildd power when we're not even sure it'd eventually succeed :) | 22:51 |
| cjwatson | it doesn't look particularly unreproducible here | 22:52 |
| cjwatson | hangs in the same place every time I run this test. admittedly different, but my system passed a few tests that the buildds didn't, perhaps due to different kernel, so I don't think the buildd ever tried this particular one | 22:52 |
| cjwatson | I mean the test suite is run with 'make -k check || true' anyway so you know in some ways it's slightly academic | 22:52 |
| cjwatson | but it would be nice to at least have some idea that the resulting binaries aren't busted | 22:53 |
| cjwatson | seems to be hanging while polling on an eventfd | 22:53 |
| cjwatson | bigods I hate threads with an unbridled passion | 22:55 |
| cjwatson | http://paste.ubuntu.com/901301/ <- thread apply all bt from the hang here | 22:58 |
| cjwatson | hmm, 500000-second timeout there | 22:59 |
| stgraber | that seems a bit high | 23:01 |
| cjwatson | it ought to not matter | 23:01 |
| cjwatson | I can't reproduce the buildd hang here, but maybe if I attack the one I've got ... | 23:02 |
| cjwatson | can you reproduce it? | 23:02 |
| cjwatson | it happened on two independent buildds, I'm not inclined to believe it's accidental | 23:03 |
| cjwatson | http://git.gnome.org/browse/gcr/commit/gcr/tests/test-gnupg-collection.c?id=f3b9d46c75675e9b4b451164dd32ed9b1af0dfb1 | 23:05 |
| cjwatson | "Remove threading from testing framework, as gcr isn't threadsafe in all parts." | 23:05 |
| cjwatson | ... thanks | 23:05 |
| cjwatson | http://git.gnome.org/browse/gcr/commit?id=f3b9d46c75675e9b4b451164dd32ed9b1af0dfb1 (possibly more helpful, broader diff) | 23:06 |
| stgraber | build is still running here (was busy with something else for a bit) | 23:06 |
| cjwatson | that doesn't help though | 23:07 |
| stgraber | ok, tests running here now | 23:09 |
| stgraber | let's say where it hangs | 23:09 |
| stgraber | *see | 23:09 |
| skaet | stgraber, cjwatson - am going to go ahead with the image rebuilds at this point, unless you raise the flag. compiz is built and published. | 23:09 |
| * cjwatson tries upstream gcr | 23:10 | |
| stgraber | hangs at /gcr/gnupg-collection/load: here | 23:10 |
| cjwatson | here too | 23:11 |
| infinity | skaet: I'm a bit too lazy to read the results of the discussion in scrollback, but we don't build any armel images except core. | 23:11 |
| skaet | infinity, yes | 23:11 |
| skaet | pad had us doing it for kubuntu pre-installed. fixed. | 23:12 |
| infinity | skaet: It did? It shouldn't have. | 23:12 |
| cjwatson | './autogen.sh && make && make check' in gnome:gcr passes | 23:12 |
| slangasek | cjwatson, stgraber: I notice that all of the hangy thread code is pulled from gnome-keyring git as a distro patch... debian/patches/00git_glib_2.31_deprecations.patch | 23:13 |
| skaet | infinity, we'll only image on the manifest for kubuntu preinstalled right now is armhf+omap4 so that's what its now set to. | 23:13 |
| cjwatson | (it's been split out of gnome-keyring in the 3.3 series) | 23:13 |
| skaet | s/we'll/well/ | 23:14 |
| slangasek | ah, but we're behind upstream and upstream has split the source? useful | 23:14 |
| cjwatson | slangasek: that might well be useful anyway, thanks | 23:14 |
| cjwatson | oldest tag in gnome:gcr (3.3.1) fails but not in a hangy way | 23:16 |
| cjwatson | oh, and not every time even | 23:16 |
| infinity | skaet: The pad shouldn't have been defining any arches for kubuntu at all. | 23:25 |
| infinity | skaet: And neither should the crontab (noting your note there) | 23:27 |
| infinity | skaet: arches are already limited in etc/default-arches. The only reason they're specified for ubuntu is to split the build into two jobs. | 23:28 |
| cjwatson | some kind of similar errors from gnome-keyring bde64e94f83a6da4eaff6503744e200c9f1f0081 (which I think corresponds to the patch slangasek mentioned) built against gcr 3.3.1 | 23:35 |
| cjwatson | but no hang | 23:35 |
| stgraber | cjwatson: apparently disabling only /gcr/gnupg-collection/load was enough here, all the others ran properly (no hang, not sure if some failed though) | 23:36 |
| cjwatson | stgraber: ok, but that's not the test that hung on the buildd | 23:42 |
| cjwatson | so I was hoping for something more fundamental ... | 23:43 |
| cjwatson | what was the cause of setcap in debian/gnome-keyring.ubiquity failing, anyway? | 23:44 |
| stgraber | not too sure about that one actually ... on all installs where it failed the file actually had the right attributes set and calling the hook manually would succeed | 23:45 |
| cjwatson | 3.2.2 with bde64e94f83a6da4eaff6503744e200c9f1f0081 applied (and an extra build tweak) hangs; bde64e94f83a6da4eaff6503744e200c9f1f0081 itself succeeds | 23:45 |
| * cjwatson starts bisecting | 23:48 | |
| skaet | infinity, kubuntu preinstalled was releasing armhf+omap and armhf+omap4. Manifest only has armhf+omap4 on it. | 23:48 |
| infinity | skaet: The manifest doesn't have every arch built, true. | 23:49 |
| infinity | *cough*powerpc*cough* | 23:49 |
| infinity | skaet: If Kubuntu only wants omap4 built, however, that should be changed in default-arches, not hacked all over everywhere else. | 23:49 |
| skaet | infinity, agreed. :) | 23:50 |
| skaet | alternate images emerging on the iso tracker now. | 23:52 |
| skaet | hggdh, pgraner, ubuntu-alternate on the tracker now, ubuntu-server, ubuntu-desktop should be emerging shortly. | 23:59 |
| Daviey | neat | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!