[07:57] we (Ubuntu GNOME) would like to opt-in for alpha1, what needs to be done for this to happen? [08:39] any archive admin; pleae accept the uploads of mesa*, xserver-xorg-video-intel* to fix bug #1175533 [08:39] Launchpad bug 1175533 in linux (Ubuntu Quantal) "[HSW] intel VGA driver i915 doesn't support new haswell graphics [8086:0a2e] " [Critical,In progress] https://launchpad.net/bugs/1175533 [08:39] the kernle & libdrm bits are there already [08:39] *kernel === doko__ is now known as doko [09:26] I've temporarily sync-blacklisted the packagekit transition by request of jbicha (23:42 UTC above) [09:38] Now, time to debug why force-autopkgtest isn't working [09:40] cjwatson: Oh, if you're going to make the linux stuff get all forcey, let me upload d-i. [09:42] cjwatson: Uploaded. When you get the whole mess to migrate, don't forget to change the seeds. [09:42] infinity: I tried forcing the autopkgtest bit of it at the weekend, but it didn't take for some reason [09:42] * cjwatson nods [09:43] cjwatson: And now that d-i/linux migration is way less predictable due to autopkgtest delays, I think it's time for my next upload to implement that hack I was going to do to make the seeds not need ABI knowledge. [09:43] I'll do that after I've slept. [09:44] Ah, there, I think it was just a hint permission bug [09:57] jibel: Can you make out from your end why http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html still shows "autopkgtest for linux 3.9.0.7.8: RUNNING" in a few places? [09:59] cjwatson: It got stuck due to linux's autopkgtest having a broken Depends: [09:59] cjwatson: I think Andy's fixing that in the next upload, but it won't get unstuck on the current version unless jibel works some magic. [10:01] infinity: Right, but shouldn't that have ended up as FAIL or something? [10:01] cjwatson: Possibly, yeah. [10:01] * cjwatson commits a bit more logging [10:01] And forcing linux-signed/3.9.0-7.15 [10:02] ScottK: Curious about the kde4libs block; wouldn't proposed-migration's standard "wait until everything has built" have been enough there? [10:03] Not that it's a huge problem if you're keeping an eye on it, I was just curious [10:11] infinity: hem, I don't even dare to ask more, but do you think you will have time for the unity SRU in raring? :) [10:13] didrocks: Yeahp, can you bug me in ~6h? :) [10:13] infinity: will do :) [10:25] cjwatson, correct, it should be marked as FAIL even if it timed out or in that case what adt-run considers an invalid 'Depends' field. I'll check what happened [10:26] Lots of other tests seem to be stuck at RUNNING too [10:27] e.g. the ones triggered by glib2.0 [10:27] Yeah, it'd be helpful to know which end of the channel this bug is at [10:28] * Laney nods [10:46] cjwatson: No. I put it there so that it wouldn't migrate until the rest of the release was built (kde4libs could, in theory migrate as soon as it's built on all archs since it doesn't cause the older KDE packages to become uninstallable. [10:46] Not that it matters much since armhf is broken. === mmrazik is now known as mmrazik|lunch [11:31] cjwatson: I did a lot of New processing for KDE package splits over the weekend (not quite done, but close). Would you please re-run the packageset script. [11:34] Yikes, it's been a while since I ran that. It seems to want to put unity* into the Kubuntu packageset, which seems slightly odd [11:37] it's all about unification :) [11:40] I think it's all about a seed bug. Let me see ... [12:12] cjwatson, is the libreoffice autopkgtest failure still blocking migrations? [12:16] doko: I was waiting for jibel to tell me if there was a problem at the Jenkins end before looking into that kind of thing [12:17] (Because as far as proposed-migration is concerned the libreoffice test is still "RUNNING") [12:18] I did poke Sweetshark about that failing this morning [12:22] cjwatson, I found that the job that consumes test requests had been disabled, probably for a maintenance of the server last Saturday, and not re-enabled. I ran the script manually and that triggered tests for http://paste.ubuntu.com/5795363/ [12:22] I'm waiting for the admin to show up before re-enabling that cron job [12:22] jibel: Ah, that looks relevant, thanks [12:22] Hm, I should make force-autopkgtest operate on the tested package rather than on the triggering package [12:22] as I don't know why it has been disabled in the first place === mmrazik|lunch is now known as mmrazik [12:25] (force-autopkgtest> done) [12:37] ScottK: OK, fixed up seeds at least somewhat, and refreshed the packageset [14:25] can someone delete xorg-server in raring NEW? it will cause a regression in its current state [15:28] I think I'll force kde4libs into -release, it's currently blocked on arm but I don't see that getting fixed in time for alpha 1 [15:28] also calligra and qtwebkit are the same [15:29] Riddell: Will that render things above it uninstallable? [15:30] Riddell, and rekonq?:P [15:30] cjwatson: on arm but we can live without that for alpha 1 [15:30] smartboyhw: rekonq is collateral damage rather than failing in its own right [15:31] Riddell: Hm, that will unfortunately make proposed-migration much more tolerant of mistakes [15:31] There's a BIG stack behind kde4libs [15:33] You're free to if you want but it's very unfortunate. [15:34] Re auto-sync and possibly re-enabling it tomorrow morning; I assume we're just using a migration block for alpha 1, rather than disabling auto-sync and freezing harder? [15:35] (unfortunate> as in, if it were me, I would prefer to hold kde4libs out of the saucy release pocket until it's been fixed on ARM) === mmrazik is now known as mmrazik|afk [16:24] Is proposed-migration right to say that pango1.0's autopkgtest is still running? Looks like it completed a few hours ago. [16:24] Also, shouldn't it be blocking on the failed LO test? [16:24] it/glib2.0 & co [18:40] infinity, did you get pinged again about the raring unity SRU? ;-) [18:41] slangasek, ^ if you feel like doing some SRU work? (would be really good to unblock those fixes after > 1 month) [18:41] seb128: Just now, by you. :) [18:42] seb128: I'll get to it all today (I'll start on it now). [18:42] ok [18:42] infinity, you are saying that for 1.5 weeks :p [18:42] That's not true. :P [18:42] don't make me grab my IRC logs ;-) [18:43] infinity, thanks for looking at it today ;-) [18:43] Last week was a mess, though. I'll admit to that. [18:43] hey, the package has only been in the queue for 5 days, not 1.5 weeks ;) [18:43] infinity: a lot of treading water last week? ;p [18:43] slangasek, right, because infinity looked at it a week ago and rejected the previous ones, because the original sources from the ppa expired [18:43] slangasek: Hospital scares at the beginning of the week and then, yes, lots of floating away. [18:44] slangasek: I'm fine, but friends and family aren't so lucky, and I've been running around helping. [18:44] :-( [18:44] infinity, hope things get better for your friends/family! [18:45] seb128: Well, no one lost more than stuff. Stuff's replaceable, though pricey. Just lots of cleanup and cost evaluations and rebuilding and such. [19:05] is kate the release manager for alpha1? [19:06] There is no release manager, so no? [19:10] infinity, ahh.. well I'm asking who is setting up the milestone on the tracker and managing builds [19:10] balloons: stgraber, most likely. [19:10] is stephane doing it all? ATM there is no milestone [19:10] trying not to ping him on his holiday :-) [19:10] balloons: It's a public holiday in Quebec, I assume he intends to get to it tomorrow. [19:11] balloons: It all needs some love from him specifically anyway, since he's trialling the "flavours get to request rebuilds via the UI" bits. [19:11] balloons: I'll be managing builds, will also take care of the tracker, though I only plan to do that once the first flavour says they're ready and want to get a1 builds [19:12] stgraber, I think lubuntu is chomping at the bits to get some builds (at least the testing side is, heh). Just wanted to confirm who was going to manage it so I could direct them properly [19:12] ty stgraber and infinity [20:05] cjwatson: I'm trying to force kde4libs into -release but it seems to need something more than the single force line, do you know what? [20:07] will it need every kde app forced? [20:08] Making the uninstallable count worse needs force-hint rather than force ... [20:08] (possibly as well as) [20:08] I'm still very concerned that this will destabilise proposed-migration in general, but hey [20:08] 630 uninst, grief [20:09] I hope you know what you're doing [20:28] bdmurray: do you have 5 mins for a quick PM before the bugs section of ubuntu-clasroom start? === ajmitch_ is now known as ajmitch [21:53] cjwatson: thanks for the packageset refresh. [21:57] cjwatson: re forcing kde4libs - it's the victim of a gcc issue. there's not much between forcing it and skip Alpha 1. [22:01] ScottK: Or do A1 with what's in the release pocket. Or build kubuntu A1 against proposed. [22:04] Riddell,ScottK: Just to confirm, are you OK with re-enabling auto-sync tomorrow morning as discussed on ubuntu-release, and relying on a migration block for your alpha needs? [22:06] what's in the release pocket isn't much different than raring [22:07] cjwatson: yep [22:07] cjwatson: I'm in favor of it. [22:11] OK, thanks [22:12] Will you folks either put the block in place before tomorrow morning (my time), then, or else drop me a mail with the correct block line(s)? [22:12] ScottK: Maybe you could build it with gcc-4.7? [22:12] (on armhf) [22:15] Laney: That certainly would be a valid option. [22:18] good idea [22:18] I do share Colin's concern about raising the uninstallables count so high that britney becomes much less effective for a while. [22:20] Can you educate me as to the problem there? I don't think I understand how britney works in that regard. [22:22] Well, britney's job is to make sure nothing gets worse after a migration. [22:22] If things are already hideously broken, then you can introduce new breakage as long as you fix the same number of other breakages at the same time. [22:22] Which isn't an ideal situation. [22:22] Ideally, you want the release pocket to be in a "not broken" state, rather than an "as broken as before" state. [22:23] But if you force something that causes hundreds of uninstallables, you have to be pretty careful to unwind the whole mess again, rather than spending the next month trading one break for another. [22:23] So it gives you room to trade off breakage. I thought it just didn't allow you to break new things. [22:24] Laney: calligra is built with gcc 4.7 (cos you made it so) and it seems to have the same ICE [22:24] Technically, it doesn't allow you to break new things, but when the case is that "everything that depends on Qt" is broken, that's a lot of wiggle room. :P [22:25] s/Qt/kde4libs/ [22:25] Riddell: Actually I fat fingered that calligra change when I did it but we got away with it at the time [22:25] infinity: it seems to be either this or not do alpha 1 and I'd like to do an alpha [22:25] Laney: how do you mean? [22:25] I set one of the wrong environment variables [22:26] export CXX=g++-4.7 [22:26] that one? [22:26] That only matters if the build calls CC at any point. [22:26] Riddell: No, the one above, which should have been CC, not CPP. [22:26] I think I set CPP instead of CC [22:26] yeah. [22:27] Anyhow, I don't see an ICE on calligra... [22:27] /build/buildd/calligra-2.6.92/krita/image/kis_filter_weights_applicator.h:305:26: error: conversion from 'double' to 'const KisFixedPoint' is ambiguous [22:27] Just a straight up error. [22:28] Guessing a qreal-ish porting issue? [22:29] hum, I'm sure I remember seeing an ICE before [22:29] Hrm, doesn't take kde4libs too long to fail on a Panda. I'll test it with gcc-4.7 here. [22:30] Erm, wait. Did people retry kde4libs? [22:30] "The bug is not reproducible, so it is likely a hardware or OS problem." [22:30] That means gcc tried again and succeeded the second time, and maybe the Panda was just sad. [22:31] about 142 bazillion times [22:32] Heh. Alright. [22:32] I'll try it with 4.7 here. [22:35] I even put the armhf buildds on manual briefly to make sure I retried it on each type of builder. Failed on them all. [22:35] Every time I test build on my Panda, I kick myself for not having spent the previous weekend reinstalling my mx6... [22:35] ScottK: Each type? There's only two, and they're basically the same. [22:37] ScottK: Anyhow, if this test build passes here, I'll upload ASAP. [22:37] couldn't tell if it was two or three based on how they're listed. in any case, I hit a variety to be sure. [22:37] But as for calligra, it's a straight up porting issue, not a GCC thing. [22:37] thanks [22:37] (And this is another unfortunate problem with hinting away arch problems, people tend to start seeing the same problem everywhere and getting hint happy) [22:38] The old "if all you have is a hammer" adage.