| === pitti_ is now known as pitti | ||
| === highvolt1ge is now known as highvoltage | ||
| === Guest37602 is now known as jpds | ||
| rickspencer3 | pitti, around at all? | 10:17 |
|---|---|---|
| pitti | hey rickspencer3 | 10:17 |
| rickspencer3 | hey pitti, I have a silly question for you | 10:17 |
| rickspencer3 | basically, I wake up each morning and check https://jenkins.qa.ubuntu.com/view/Precise/ first thing | 10:18 |
| rickspencer3 | however, the daily builds are quite ready and so the smoke tests aren't run yet | 10:18 |
| rickspencer3 | this is going to sound crazy, but ... | 10:18 |
| rickspencer3 | is there anyway to start the dailies about 2 hours earlier so the results are there first thing in the morning here? | 10:18 |
| rickspencer3 | oops | 10:19 |
| rickspencer3 | the dailies *aren't* quite ready | 10:19 |
| pitti | in theory that's possible, of course; in practice, we'd probalby need to adjust a lot of other images as well, as we shouldn't run them in parallel | 10:19 |
| rickspencer3 | hmmm | 10:20 |
| pitti | unfortunately they failed over the weekend due to buildd lag | 10:21 |
| pitti | we had a massive number of uploads on Friday due to armhf; not much we can do there, I'm afraid | 10:21 |
| rickspencer3 | indeed | 10:21 |
| rickspencer3 | pitti, this is far from an emergency situation, it would just be nice to be able to follow up on any significant problems first thing, rather than waiting | 10:22 |
| pitti | actually, yesterday's desktops did build (and today's) | 10:22 |
| pitti | rickspencer3: actually, I quite like them at the current time; it gives me about two hours to fix problems before we build images | 10:22 |
| pitti | so at 6:30 my time I can look at http://people.canonical.com/~ubuntu-archive/testing/precise_probs.html, and fix uninstallability in time for the image builds | 10:23 |
| * rickspencer3 looks | 10:23 | |
| pitti | if we do them earlier, we'll need to re-spin a lot more often | 10:23 |
| rickspencer3 | pitti, that totally makes sense | 10:23 |
| pitti | but yeah, I see how it would be nicer for you to have them earlier :) | 10:23 |
| cjwatson | I think the reason I didn't originally want them too much earlier is that it reduces the chance of end-of-the-day Pacific time uploads being incorporated | 10:23 |
| rickspencer3 | so you look for problems in the archive before you try to spin an ISO | 10:23 |
| pitti | so, we can have them earlier at the expense of lessening the probability of them succeeding | 10:24 |
| rickspencer3 | pitti, no that makes sense | 10:24 |
| rickspencer3 | I see that for you, daily quality starts *before* the builds and smoke testing | 10:24 |
| rickspencer3 | I think it's smarter to optimize for that | 10:24 |
| rickspencer3 | so ... | 10:24 |
| rickspencer3 | carry on :) | 10:24 |
| pitti | rickspencer3: yes, our archive reports usually catch failures before we attempt the image build | 10:24 |
| pitti | we get an hourly feedback loop with them | 10:25 |
| rickspencer3 | pitti, for your uninstallable packages report, can you tell which ones will cause the ISOs not to build? | 10:25 |
| pitti | rickspencer3: yes | 10:25 |
| pitti | rickspencer3: whenever ubuntu-desktop is uninstallable | 10:25 |
| rickspencer3 | does ubuntu-server have a similar metapackage? | 10:26 |
| pitti | rickspencer3: it's not 100% correct (as we ship a few additional packages in live-ship), but usually good enough | 10:26 |
| pitti | of ubiquity is uninstallable, that's bad as well, of coruse | 10:26 |
| pitti | rickspencer3: no, I don't think so; but in general we just try to keep above list at zero | 10:26 |
| pitti | so that all images will build | 10:26 |
| rickspencer3 | ok | 10:26 |
| * rickspencer3 stops trying to gild the lily | 10:27 | |
| rickspencer3 | thanks pitti | 10:27 |
| rickspencer3 | as usual, you are a true scholar and gentleman ;) | 10:27 |
| pitti | rickspencer3: thanks to you, too; it's always good to check the justification of how we have things set up :) | 10:28 |
| rickspencer3 | jibel, pitti, can I assume that https://jenkins.qa.ubuntu.com/view/Precise/job/precise-desktop-i386_encryptedhome/ fail because of bug #894768 | 11:02 |
| ubot4 | Launchpad bug 894768 in linux (Ubuntu Precise) (and 1 other project) "Installation randomly fails with: File "/usr/lib/ubiquity/ubiquity/install_misc.py", line 621, in copy_file targetfh.write(buf) IOError: [Errno 22] Invalid argument (affects: 23) (dups: 23) (heat: 353)" [High,In progress] https://launchpad.net/bugs/894768 | 11:02 |
| rickspencer3 | ? | 11:03 |
| cjwatson | rickspencer3: yeah, looks like the same bug | 11:03 |
| rickspencer3 | thanks cjwatson | 11:03 |
| * rickspencer3 shakes fist at 894768 | 11:03 | |
| rickspencer3 | cjwatson, I know it's being worked on :) | 11:04 |
| pitti | rickspencer3: correct, it's in the d-i syslog | 11:04 |
| pitti | but nice that these builds now actually appear, thanks jibel for fixing that | 11:04 |
| pitti | last week they just didn't appear at all | 11:04 |
| pitti | rickspencer3: these days, when amd64 succeeds and i386 fails, it's most likely that bug | 11:04 |
| jibel | rickspencer3, yes it is. line 2902 of d-i-syslog Dec 5 08:50:18 ubuntu install.py: IOError: [Errno 22] Invalid argument | 11:05 |
| rickspencer3 | ok | 11:05 |
| rickspencer3 | thanks guys | 11:05 |
| cjwatson | uh, who just flushed my syncs? | 11:44 |
| cjwatson | or removed, I can't tell | 11:44 |
| infinity | cjwatson: Flushed, I'd guess, based on the build queues all shooting up. | 11:51 |
| infinity | (And no idea who) | 11:52 |
| doko_ | cjwatson, I'm guilty ... | 12:58 |
| === bladernr_afk is now known as bladernr_ | ||
| stgraber | infinity: just saw your upload of livecd-rootfs, should that package get added to the list in https://wiki.ubuntu.com/NewReleaseCycleProcess? | 15:05 |
| stgraber | good morning skaet | 15:06 |
| skaet | goodmorning stgraber. :) | 15:07 |
| infinity | stgraber: Nah. The default suite in BuildLiveCD is a convenience to people hacking on it (to avoid passing "-d precise"), it makes no real difference. | 15:07 |
| infinity | stgraber: The buildds all pass the suite explicitely anyway. | 15:07 |
| infinity | (And I usually do when testing too, which is why I never notice the default) | 15:07 |
| stgraber | ok | 15:08 |
| === Guest76640 is now known as NCommander | ||
| === NCommander is now known as Guest67564 | ||
| === Guest67564 is now known as NCommander | ||
| cjwatson | Subject: LiveFS --f-omap4/ubuntu/armel+omap4 failed to build on 20111205 | 17:41 |
| cjwatson | uh | 17:41 |
| slangasek | heh | 17:41 |
| * cjwatson fails to puzzle that out | 17:44 | |
| infinity | cjwatson: Someone screwed up a manual build, I assume. | 18:18 |
| infinity | cjwatson: ogra and I were puzzling over the same thing. | 18:18 |
| infinity | cjwatson: The only way I could fathom that subject line is with --f on the buildlive command line. | 18:18 |
| infinity | (Which is weird, in and of itself) | 18:18 |
| infinity | cjwatson: Oli's suggesting we tag Log mails with SUDO_USER to call people out. ;) | 18:19 |
| ogra_ | well, we wouldnt need to log the name | 18:19 |
| stgraber | jibel, skaet: http://91.189.93.73/qatracker/milestones/204/builds/7471/testcases/115/results/ | 18:19 |
| ogra_ | but put "manual build" in the mail subject if SUDO_USER isnt empty | 18:19 |
| ogra_ | so we can at leats see its manual fiddling that caused it | 18:20 |
| stgraber | jibel, skaet: So support for multiple results for the same user is there. There are still a few bugs around the feature though, will fix a bit later (need to get some food, then DMB meeting) | 18:20 |
| infinity | ogra_: Pfft. If you're going to go partway, just finish the job and make the subject line: "Nelson: Ha, ha, ${SUDO_USER} sucks!" | 18:20 |
| ogra_ | LOL | 18:20 |
| skaet | infinity, ogra_ some of my manual tests didn't end until after midnight it appears, so I could be the culprit. All of them suceeded (they were no publish though). | 18:21 |
| * skaet was doing timings on arm builds yesterday | 18:22 | |
| infinity | skaet: I assume the conclusion was "slow"? | 18:22 |
| ogra_ | well, i got that failure mail 90min ago ... | 18:22 |
| skaet | infinity, glacial | 18:22 |
| ogra_ | livefs builds should take 90min each | 18:22 |
| skaet | infinity, I'll bounce you the numbers... arms the highwater mark now on full respins. | 18:23 |
| ogra_ | plus about 30-40 for the post live-build stuff cdimage/debian-cd do | 18:23 |
| infinity | skaet: It always was. | 18:23 |
| ogra_ | so all in all 2.5h for one image | 18:23 |
| === doko_ is now known as doko | ||
| skaet | ogra_ yeah, that's about what I was seeing. | 18:23 |
| ogra_ | we used to have 4h builds, dont complain ! | 18:23 |
| ogra_ | :) | 18:23 |
| skaet | :) yeah, but we have more images to build now, so.... ;) | 18:24 |
| ogra_ | indeed | 18:24 |
| infinity | I'll have it all parallelised by February, at least. | 18:24 |
| ogra_ | well, spice seeds would help with that | 18:24 |
| infinity | ogra_: livefs-in-soyuz will help more. | 18:24 |
| * skaet looking forward to the parallelization. :) | 18:24 | |
| ogra_ | 90min for buildlive once and then 15min per subarch to mangle it ;) | 18:24 |
| infinity | ogra_: Don't sell something we're not (currently) working on. ;) | 18:25 |
| infinity | ogra_: But livefs-in-soyuz, I've promised for this cycle. | 18:25 |
| ogra_ | infinity, well, i always wanted to just have a three layered casper filesystem setup ... one for rootfs, one for kernel/modules and a cow | 18:26 |
| skaet | stgraber, excellent. :D | 18:26 |
| ogra_ | that would have solved it earlier | 18:26 |
| skaet | cow? | 18:26 |
| ogra_ | copy on write :) | 18:26 |
| skaet | lol | 18:26 |
| ogra_ | else i would have written pony ... i'm not *that* much into cows :) | 18:27 |
| * skaet was definitely wondering about those cows. ;) | 18:27 | |
| ogra_ | infinity, when i was about to start on that we came up with preinstalled so i never implemented it | 18:28 |
| infinity | Anyhow. Once lamont and I get the armhf builder to admit that it's actually meant to build things, I might spin ubuntu/armhf+omap for the lolz. | 18:28 |
| infinity | Shame we don't have a more useful kernel yet. | 18:28 |
| ogra_ | omap4 would really be nice | 18:28 |
| infinity | Well, I could probably make ti-omap4 build without any serious effort. | 18:29 |
| infinity | I just don't want to step on toes, and ppisati said he was on it. | 18:29 |
| ogra_ | you could just cp it on ports :) | 18:29 |
| infinity | Uhm, no. | 18:30 |
| infinity | I'd have to repack it, at the very least. | 18:30 |
| infinity | But no. | 18:30 |
| infinity | And many other times no. | 18:30 |
| ogra_ | heh | 18:30 |
| * cjwatson checks that ogra doesn't have a cocoplum account :-P | 18:30 | |
| ogra_ | lol | 18:30 |
| ogra_ | infinity, btw, looking at buildlive, SUDO_USER would always be set ... | 18:35 |
| infinity | Eh? | 18:36 |
| ogra_ | (if root runs it it forcefully sudos to "cdimage") | 18:36 |
| ogra_ | if [ "$(id -u -n)" != "cdimage" ]; then | 18:36 |
| ogra_ | exec sudo -H -u cdimage $0 "$@" | 18:36 |
| ogra_ | fi | 18:36 |
| ogra_ | (or cron or whoever) | 18:37 |
| infinity | No, that's if a user runs it. | 18:37 |
| infinity | It's legacy code. | 18:37 |
| ogra_ | though, cron runs it as cdimage | 18:37 |
| infinity | cron executes it as cdimage. | 18:37 |
| ogra_ | snap | 18:37 |
| ogra_ | k | 18:37 |
| charlie-tca | I broke the daily testing tracker | 19:07 |
| charlie-tca | it won't let me update an in-progress test | 19:07 |
| charlie-tca | http://91.189.93.73/qatracker/milestones/204/builds/7503/testcases/131/results | 19:08 |
| stgraber | charlie-tca: that's likely my fault :) | 19:08 |
| * stgraber looks | 19:08 | |
| charlie-tca | Okay, I will agree ") | 19:08 |
| stgraber | charlie-tca: ah, could it be you didn't see the UI change? | 19:08 |
| stgraber | charlie-tca: you can now post multiple results | 19:08 |
| charlie-tca | huh? | 19:08 |
| stgraber | charlie-tca: so you need to click on the edit icon to change an existing one | 19:09 |
| charlie-tca | but I can not update the test that says in-prgress. It errors | 19:09 |
| stgraber | ah, ok, that part is probably my fault then :) | 19:09 |
| charlie-tca | Should I post the error to pastebin? | 19:09 |
| stgraber | nope, got it in the log | 19:09 |
| charlie-tca | Okay | 19:09 |
| stgraber | resultid does not exist | 19:09 |
| stgraber | fixing | 19:09 |
| charlie-tca | Anyway, I did the test and it worked today | 19:10 |
| stgraber | charlie-tca: should be fixed now | 19:11 |
| charlie-tca | stgraber: Thank you | 19:11 |
| stgraber | I'd expect removal of results to still be broken though, that's pretty high on my to-fix list (post DMB meeting) | 19:11 |
| charlie-tca | Worked now. That is great! | 19:12 |
| stgraber | cool | 19:13 |
| jibel | stgraber, nice, there will some ui work though, because it is not really intuitive. | 20:17 |
| jibel | and I confirm that removal of results is a bit broken ATM | 20:18 |
| stgraber | jibel: yep, wokring on the removing results part. I agree the UI is not terribly intuitive, especially after 4 years of a similar UI that could only add/update the results :) | 20:18 |
| jibel | stgraber, no problem, step by step | 20:19 |
| stgraber | jibel: oh, actually, removed results are only a problem for admins because we're supposed to see them and that part of the code fails :) | 20:21 |
| === bladernr_ is now known as bladernr_afk | ||
| === bladernr_afk is now known as bladernr_ | ||
| stgraber | jibel: fixed. So now admins should be able to see any removed result (you can restore by updating them without any change) and users can only see their own removed results (and restore them too) | 20:38 |
| stgraber | hehe, I guess http://91.189.93.73/qatracker/milestones/204/builds/7471/testcases/115/results is a good example of what an admin can expect to see on release week :) | 20:40 |
| stgraber | maybe with a few less removed results though :) | 20:40 |
| stgraber | which reminds me I need to make the LP integration script a bit more clever to avoid tagging bugs linked to a removed result | 20:42 |
| jibel | stgraber, and blacklist bug 1 please :) | 20:47 |
| ubot4 | Launchpad bug 1 in tilix (and 28 other projects) "Microsoft has a majority market share (affects: 1119) (dups: 2) (heat: 5202)" [High,New] https://launchpad.net/bugs/1 | 20:47 |
| jibel | sorry | 20:47 |
| stgraber | jibel: yeah, I guess a bugnumber blacklist could be useful :) I did a mass remove of that one last week but I'm sure we have many more like it | 20:47 |
| stgraber | I see we have 0, 2 and 5 on the list of bugs that have never been updated from LP | 20:48 |
| stgraber | I'll cleanup these that are clearly invalid, that should make the cronjob a bit faster | 20:49 |
| stgraber | jibel: qatracker=> DELETE FROM qatracker_bug WHERE bugnumber IN (0,2,5,91919191,3737384,5577744); | 20:50 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!