[00:12] infinity, ok, guess its not a huge issue anyway, given live session and 2nd+ boots work fine [00:12] darkxst: It's not a blocker, I'd say, but it would still be nice to know WTF happened. [00:12] darkxst: Can you reproduce on a fresh install on the same VM? [00:21] infinity, it happened twice [00:21] third re-install seems to have booted ok [00:32] infinity, so maybe it is something racy, vmware does boot incredibly fast [00:35] darkxst: If it's racy, just rebooting a dozen times should show it up. It might be a race between upstart events and jobs or something, though I'd also suspect that's not a regression from 14.04.2 then, but just bad luck. :/ [00:35] darkxst: Bad luck that your system is just the wrong speed to race it, I mean. Or that some update got 10ms faster or 10ms slower, perturbing the bug that was already there. [01:02] ok, what the heck are opencolorio and openimageio that they warrant circular build-deps on each other [01:14] slangasek: I vaguely recall having to break that loop on every bootstrap. [01:17] yeah, I would consider adding a build profile, except that doesn't help for the soname transition problem [01:17] and therefore I do not care [01:18] in fact I'm inclined to drop the dependency from opencolorio-tools to libopenimageio and not re-add it [02:15] slangasek: Oh, also, there's a mass retry in progress to see if it unsticks any of the bad failures/dep-waits from previous lp-buildd/sbuild versions. If any of that gets in your way, feel free to score up C++ stuff (or holler if you don't have the permissions to do so...) [03:42] infinity: I was amused to find that in fact, TB seems to confer magic buildd powers [03:43] so yeah, I've been rescoring what I need, while ignoring all the new build failure mails for things that failed long ago ;) [03:43] slangasek: TB might own buildd-admins... [03:44] slangasek: Indeed it does. [03:44] And they're a member too. [03:44] Which might be a mistake. [03:44] But meh. [04:53] jackyu: Hey! Are you guys testing kylin 14.04.3 over the next 8 hours while I sleep? :) [04:54] infinity, sure. doing now^... [04:55] jackyu: We were considering respinning your ISOs for the fix for https://bugs.launchpad.net/ubuntukylin/+bug/1380981 but weren't sure if you'd started testing already, etc. [04:55] Error: Could not gather data from Launchpad for bug #1380981 (https://launchpad.net/bugs/1380981). The error has been logged [04:55] jackyu: If you'd like us to land that before you start, I think cyphermox and I can still find the time before bed. [04:58] jackyu: Your call. [04:58] infinity, we are testing now. But we'd like to retest the new one. [04:58] infinity, so, please respin it [04:58] jackyu: Well, if you don't mind a 1hr (or less) delay to merge this and respin, I'm happy to do it. I just didn't want to do it without asking first. [04:58] jackyu: Kay. Will do. [04:59] infinity, yes, in call just now^ [04:59] infinity, got it, thanks. [05:02] jackyu: Respinning now. [05:03] cyphermox: Looks like we're getting the kylin fix after all. [05:10] If it turns out that the fix for that bug breaks the 20150806 image somehow, if you also test 20150805, we can release the old one, since the only difference is that one bootloader language change. [05:10] jackyu: ^ [05:10] jackyu: But it's a direct backport of the fix we used for wily, so it should work. [05:35] jackyu: There's your new builds. [06:15] doko: fwiw the answer is that openimageio doesn't build cleanly with g++ 5 because it has code that monkeys with the internals of std::string [06:16] nice [06:16] http://paste.ubuntu.com/12011886/ [06:17] can be disabled via ifdef, but I'll check for an upstream fix first [06:22] http://paste.ubuntu.com/12011904/ [06:22] so... sorta? [06:35] looks ok [07:04] Laney, slangasek: openimageio now fails with opencv mess (Laney, could you fix?) [07:05] oh seriously? I *just* succeeded in building it locally [07:05] doko: and no, Laney has said he's off today [07:06] I'll have a look, have to prepare for travel too [07:06] I can take a brief look before I turn into a pumpkin [07:06] what does openimageio block? [07:08] half of opencv depends on new package names and half on old package names [07:08] opencolorio and blender [07:08] yes, that's what I saw as well [07:09] opencolorio and blender, which is only seeded in ubuntustudio (which doesn't do non-LTS releases), shouldn't there be some main libraries that are higher priority? [07:10] I was looking at failing autopkg tests for gcc-5. fine if you override these ... [07:11] yes, we can probably override those. I'm more concerned about getting the rebuilds done for the stacks of package name changes in main [07:12] then probably a test rebuild of main for amd64 only would be good at this point [07:22] uploading opencv [07:30] doko: opencv has a self-build-dep; maybe can be worked around be removing the broken binaries from wily-proposed [07:30] * slangasek gets some sleep [09:04] bdmurray, hi [10:04] infinity, Ubuntu Kylin is ready:). === utlemming is now known as utlemming_away [10:18] slangasek, infinity, doko: we need the wily touch seeds updated [10:53] Hello release team! Does anyone know why in the ubuntu-touch-seeds in the sdk-libs-dev we actually hard-dep on a specific boost version? [10:55] sil2100, the seed history (and bzr blame) can tell you ... it seems ot have been added with the whole block surrounding it for scope stuff [11:00] sil2100, looks like it comes from pete-woods ... best to ask him [11:08] ogra_, sil2100: it was for scopes, yes. there's no specific dependency on a specific version of boost, so if there's a meta/virtual package that should be there instead, please do change it [11:08] my package-fu is weak [11:10] well, not sure how sane that is ... buut you could indeed just seed libboost-dev instead ... thouogh then you will likely not catch ABI incompatibilities [11:11] sure, please let people who actually know about packaging make the call. I just added the version that the pure c++ scopes were using [11:12] well, "packaging" is kind of moot, since we talk about frameworks here, this is all kind of special anyway [11:12] but we dont have any other versioned deps in the framework seed so it could work i guess [11:17] That's what I wanted to propose [11:17] Simply depping in the seed for libboost-dev, then we would unblock some things and avoid breakage when the main boost libraries change [11:17] sil2100, yeah, looking at the rest of the seed that seems sane to me [11:17] Ok, proposing [11:23] ogra_, slangasek: https://code.launchpad.net/~sil2100/ubuntu-seeds/ubuntu-touch-remove-boost-hard-version-dep/+merge/267177 [11:23] ogra_, slangasek: this should at least unblock the qtcreator-plugin-ubuntu parts that are blocked in -proposed === jhodapp is now known as jhodapp|sick === utlemming_away is now known as utlemming [14:44] infinity, cyphermox: So I've tested now most of what I can on server/desktop/netboot the images look good, I've also used the dell install to drop the xps back to the default 14.04.2 release that was on the it and upgraded and that is fine too \o/ [14:49] davmor2: great [14:50] * cyphermox zsyncs kylin again to test the debian-cd fix [14:58] sil2100: follow-up comment posted to the merge [14:59] slangasek: thanks, looking! [15:01] arges, hi, around [15:05] infinity: if you hadn't had an ok for it yet, I verified that kylin booting in UEFI now properly defaults to zh_CN [15:05] cyphermox: They marked the images ready last night, so they seem to agree. [15:06] yeah [15:10] infinity: anything else you need from me? [15:12] zhhuabj: hi [15:17] davmor2: studio could use some testing. Not entirely sure if maybe zequence forgot when the point release was and took a vacation. :P [15:17] davmor2: But I'd hate to see them miss the point release if some quick smoke tests show the images are okay. [15:17] Riddell: kubuntu testing seems a bit sparse, do you have more on the way, or is it "good enough"? [15:19] let me ask testers [15:23] slangasek: ok, confirmed and your proposition makes sense, updated the MR [15:26] arges, hi chris, I have a patch need to SRU, could you help me ? https://bugs.launchpad.net/ubuntu/+source/mysql-5.5/+bug/1273462 [15:26] Launchpad bug 1273462 in lsb (Ubuntu Trusty) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [High,In progress] [15:42] zhhuabj: i'll take a look in a bit [16:03] infinity: aha, that germinate change for build profiles, turns out I already did it a month or two back and deployed it to publisher machines [16:03] infinity: but not to nusakan, hence recent failures, so doing that now [16:09] Well, now-ish, need an RT first for git [16:22] cjwatson: Indeed, I remember you doing that. When you talked about germinate and profiles yesterday, I assumed you'd found a new bug. [16:24] infinity: I'm just old. [16:24] cjwatson: Join the club. [16:25] cjwatson: Also, the buildd queues are clearing/cleared nicely, if you wanted to check if your new dep-wait parser is behaving any better. [16:26] infinity: I haven't done any systematic checks; the spot checks I did look better [16:26] infinity: amd64 done [16:26] infinity: i386 downloading [16:30] zhhuabj: hey, i'm looking at this a bit more closely, I think having others review it too will help. I'll update the bug with my comments. [16:42] ok, germinate upgraded on nusakan [16:44] Just wondering, are there any rules as to age when you are contributing to Ubuntu? I am a teen and I would like to do some QA test cases, but I don't know if I could... [16:45] Can anybody confirm? [16:46] anon212230: ultimately a question for ubuntu-quality but no there are no such rules. have fun and thanks in advance :) [16:46] Thanks [16:48] are all the seeds for all flavors under version control in one particular place? [16:50] zhhuabj: commented on bug 1273462, i'm not comfortable sponsoring until a proper regression potential analysis is done. [16:50] bug 1273462 in lsb (Ubuntu Trusty) "Users can mistakenly run init.d scripts and cause problems if an equivalent upstart job already exists" [High,In progress] https://launchpad.net/bugs/1273462 [16:53] wxl: https://code.launchpad.net/ubuntu-seeds [16:53] thanks cjwatson [16:55] argh somewhere in the last 3 revisions infinity did, lubuntu trusty got oversized https://code.launchpad.net/~lubuntu-dev/ubuntu-seeds/lubuntu.trusty [16:55] oh no wait [16:55] the last one [16:55] just changing from lts-utopic to lts-vivid [16:55] not sure why that would make that much of a difference [16:56] wxl, how much bigger did it get, teh kernel tends to grow quite quickly [16:56] yeah well could have been the kernel then as that did change [16:56] let me figure that out apw [17:01] apw: it's not much. 13M, but it's enough to push it over. [17:09] infinity: Yes, sorry I had missed that [17:09] Let's see [17:10] I'm going to mark ready. [17:11] Thanks apw and davmor2 for testing :) [17:11] infinity: done [17:14] wxl: Not sure there's much we can do about that on release day, sadly. [17:15] yeah well c'est la vie infinity. i don't blame you anyways. [17:15] wxl: But, much like my argument about HWE alternates being useless, people who need CD-sized ISOs probably aren't the same people who *need* HWE, so they don't need 14.04.{2,3} install media. [17:15] wxl: So, I'd say test and mark ready, and if we can shrink for .4, yay. If we can't, it's not world-ending to tell people with CD drives to use 14.04/14.04.1 [17:16] thanks infinity [17:16] zequence: It's a good thing you have friends. :) [17:22] Bah, how did no one fix https://bugs.launchpad.net/ubuntu/+source/tex-common/+bug/1236951 in trusty yet? That's a bit embarrassing. [17:22] Launchpad bug 1236951 in tex-common (Ubuntu Trusty) "package tex-common 4.04 failed to install/upgrade: ErrorMessage: subprocess installed post-installation script returned error exit status 1" [High,Confirmed] [17:32] infinity, perhaps because it is marked for .2 and once a thing is in the past it is gone in the LP reports [17:33] apw: Oh, that certainly wouldn't help its case. [17:33] apw: I just noticed cause it's (still) in the release notes. [17:33] * infinity retargets. [17:34] stgraber: Are you happy to mark Edubuntu ready based on current testing? [17:34] superm1 / tgm4883: Ditto for you and Myth. [17:35] infinity: there weren't any rebuilds since I tested yesterday? [17:35] tgm4883: Nope. [17:35] infinity: then we're good to go [17:36] darkxst: You cool with marking GNOME ready? [17:36] darkxst: It passed all my tests, but my bar is low for flavours, I just want them to boot/install/reboot and not set my laptop on fire. :P [17:37] (The no fire bit is important) [17:40] infinity: yep [17:41] infinity: I was hoping highvoltage would do it, but I can certainly do it myself now [17:50] stgraber: A little late now, but all the server links seemed to be lacking /trusty/ === utlemming is now known as utlemming_away === utlemming_away is now known as utlemming [18:05] Oh, hello queuebot. [18:06] :) [18:08] darkxst: *nudge* [18:08] ScottK: You around to make the call on Kubuntu 14.04.3? [18:08] darkxst: Failing a response, I'm going to mark GNOME ready in a few minutes, since I tested it myself. :) [18:13] Riddell: Did anything come of your asking testers things? [18:36] Riddell: Okay, I'm going to start pushing images (including yours) anyway. If you come back and tell me "NO, STAHP, OURS SUCKS" before I release, I'll delete yours for you. :P [18:47] infinity: \o/ [18:53] infinity: is that it we are done with iso's? [18:53] davmor2: Unless you'd really like to respin and retest them all before lunch. [18:54] infinity: wow trippy I can go back in time Lunch was 6 hours ago already ;) [18:56] davmor2: One can never have too many lunches. [18:58] infinity: jibel is more eloquent in his mails but I'm not jibel so people got thanked, heart felt at that too :) [18:59] davmor2: You could have just copy and pasted one of his previous mails, and subbed in the right values for the testers. :P [19:00] davmor2: Oh, you didn't do his usual "list all the testers" thing. [19:04] infinity: no idea where he gets all the info from, I'm assuming admin [19:05] davmor2: I'm guessing there's a fancy API call to the ISO tracker. Or maybe just a magic link somewhere. [19:05] stgraber: Where does jibel scrape the milestone tester list from? [19:05] got it [19:08] * infinity runs to buy more caffeine. [19:13] I'm going night all [19:13] infinity: probably http://iso.qa.ubuntu.com/qatracker/reports/testers [19:16] now that's all done and dusted - wily daily for Xubuntu is still stuck on yesterday, must be something awry - usually builds ~10:00 [19:20] flocculant: I have mirror syncing disabled on cdimage right now while I prep the point release, you might just be stuck in that. [19:22] mmk - was that disabled hours 10 hours ago? [19:22] flocculant: Oh. No. Your issue is something else, then. :P [19:22] :) [19:22] flocculant: Ask after the point release is out. [19:22] No can multitask right now. [19:23] okey doke - I'll try and remember tomorrow [19:24] flocculant: Oh. [19:24] flocculant: http://people.canonical.com/~ubuntu-archive/cd-build-logs/xubuntu/wily/daily-live-20150806.log [19:24] flocculant: Was a germinate bug. Colin fixed that, tomorrow will be fine. [19:25] infinity: ok thanks - I did see the logs, but ignored it while I was looking at trusty [19:58] oh, debian/README.symbols, that's not actually a symbols file at all is it [20:00] slangasek: gcc -o foo foo.c -lREADME ? [20:01] -fno-strict-README [20:01] FUNROLLREADME [20:02] which is funny because usually you have to roll the readme the other way [20:06] can someone please delete this upload to vivid ^ [20:06] kirkland: I can delete petname from all series', if you like. [20:27] utlemming: Feel free to pull the trigger on the cloud 14.04.3 bits. [20:27] infinity: ack, doing so now [20:27] it seems arm64 is the long pole in the tent for rebuilds. is this the actual capacity we have right now and I'm noticing it because we're throwing a lot more than usual at the builders, or are there any problems currently affecting arm64? [20:29] slangasek: the former IMO [20:29] I mean I haven't measured but it fits my instinct [20:29] it's a particularly long pole due to a mass give-back, and there may well have been more failures to give back in the first place on arm64 ... [20:30] right [20:30] x86 and arm have lots more parallelism obviously, and the power builders are just plain faster [20:36] infinity: ^^^ [20:37] slangasek: hopefully obviously, the answer will be scalingstack, I just wish it had been ready before this transition [20:38] I wish it had been ready a year ago, but wishes never work out. [20:38] Those poor arm64 builders do alright, given what we throw at them, but the capacity certainly has scaling issues. [20:39] And ppc64el would be done if one hadn't crashed overnight and another gotten stuck on a hung build for a day. Oh well. [20:40] Oh, I didn't notice the hung build. [20:40] cjwatson: Yeah, that same "kill sucks when running in chroot=sudo mode" bug. Oh well. [20:41] cjwatson: I'm all for investigating leveraging schroot at some point, so long as we don't derp it up. [20:41] THough, there must be a way to make chroot=sudo DTRT too. [20:41] Yeah. I feel like I've spent more than enough time on buildd recently though ... [20:42] cjwatson: It's hardly critical. It only hangs up once in a while. Just, of course, happens on every give-back. :) [20:42] cjwatson: With the move to scalingstack, at least it won't kill 25% of the capacity when it happens. [20:42] In fact, with decent overcommit, it would, in theory, kill 0%, or close enough to it. [20:43] manage-builders tells us about stuff that's hung, eventually, but its lower threshold is a day. [20:43] cjwatson: Yeah, and a day is probably a fine threshold for scalingstack, cause losing a little VM slice for a day is meh. [20:44] cjwatson: For the 4 ppc64el or 5 arm64 builders, it's a bit more dire, but I tend to notice eventually. :P [20:46] slangasek: FYI the haskell transition will be migratable by tomorrow, but it's all stuck together with icu which is of course blocked on gcc-5. [20:46] Hopefully Debian won't switch to ghc 7.10 before gcc-5 is done ... [20:48] that... seems preferable [20:53] cjwatson: I'm guessing the Debian release team might stab someone if they upload ghc 7.10 [20:54] infinity: that's the sense I've got, yes [20:58] utlemming: cloud-images is still missing the http://cloud-images.ubuntu.com/releases/14.04.3/release/ path that release notes typically expect. Is that me being impatient, or did your end break? [20:59] infinity: no, that's me [20:59] * utlemming fixes [21:01] infinity: done, try again [21:02] utlemming: Looks like it has some things now. [21:03] utlemming: I assume the filenames are 14.04 (rather than 14.04.3) because you don't actually do point releases, it's just a symlink to the latest rolling update? [21:03] infinity: correct [21:03] Alright. Shiny. [21:04] infinity: I learned my lesson about making point releases in the file names with 12.04.1. Apparently automated things break when you change file names. [21:05] utlemming: Yeah. Servery people do so love stable interfaces to automate against. I guess cloudy people are the same. :P [21:05] It's really the only reason d-i has a current/ symlink too, IMO. [21:06] Cause any human can sort out "bigger number is newer", computers are a bit dumber. [21:06] Especially computers programmed by humans. [21:07] infinity: until the singularity [21:09] utlemming: I have every confidence that computers programmed by computers will be even more stupid. [21:11] infinity: we can only hope [21:12] utlemming: It'll be some generations, anyway. AI is one thing, messy creative thought is another. [21:12] utlemming: And, honestly, if I were a computer programming another computer, I'd consider creativity a flaw, not a goal. Human brains are gross and irrational. [21:18] infinity: so you're saying that when computers start to program other computers, they'll be writing in javascript? === beisner is now known as beisner-afk [21:20] slangasek: wat. [21:20] infinity: none of that messy creativity [21:21] just cut'n'paste from one pastebin or stackexchange to another until it works ;) [21:21] slangasek: No, I meant wat: https://www.destroyallsoftware.com/talks/wat [21:21] oh [21:22] .. which doesn't load anymore. [21:22] sorry, that has become so ingrained in my vocabulary that I forgot the reference ;) [21:22] The internet has failed me. === beisner-afk is now known as beisner [21:23] slangasek: It was part of my Internet vocabulary long before that talk, but the talk definitely made me associate it with javascript. :P [21:23] WHY, FINGERS, WHY?! [21:24] WHY DO YOU INSIST ON MAILING THINGS TO UBUNTU-ANNOUNCE@LISTS.DEBIAN.ORG? [21:30] what is pkgkde_symbolshelper? [21:32] slangasek: The only way to deal with C++ symbols files without clawing your eyes out. [21:32] does it deal with them by ignoring that they have changed? [21:32] No, it's just a tool for yanking dpkg-gensymbols output from build logs and tooling it into symbols files. [21:33] What you choose to do with it after that is entirely your fault (ie: ignoring ABI breaks) [21:33] because libkolabxml1 sure has a symbols file that lists references to std::basic_string, and it's not FTBFS [21:33] and I don't see anything in the build log that even tells me that pkgkde_symbolshelper is *doing* anything [21:34] and debian/rules is empty of hatefulness [21:34] ... and the symbols file isn't copied into the binary package [21:34] Oh, right, there's a buildtime component to that thing, I always forget that. I have no idea what that does, and don't use it. [21:34] I only use the build log mangly symbol file updatey bits. [21:35] what it does is add a path override to dpkg-gensymbols [21:35] and then... nothing? I don't know [21:36] so I think pkgkde_symbolshelper's dpkg-gensymbols implementation is currently broken === infinity changed the topic of #ubuntu-release to: Released: Trusty 14.04.3, Vivid 15.04, Wily Alpha 2 | Archive: wily open | Wily Release Coordination. Please don't upload things during freezes where you shouldn't, or be prepared to apologise to the release team | We accept payment in cash, check or beer | melior malum quod cognoscis [21:48] xnox: jamespage: anybody working on this ceph failure? https://launchpad.net/ubuntu/+source/ceph/0.94.2-0ubuntu2 [21:49] infinity: Were you going to use your new superpowers for metarelease or shall increment the number? [21:50] bdmurray: Go ahead. You still need to larn me what I do on the actual system after updating bzr. [21:50] bdmurray: And I think I might be too tired to actually care right now. [21:52] infinity: 'kay [21:53] cjwatson: Can you abuse UbuntuHashes for me? I'm not sure if I have access, or if SSO trying for 5 minutes to log me in means "no". [21:54] infinity: Think so. Let me remember my routine for making it less painful to do [21:56] cjwatson: Oh wow. It finally logged me in after, quite literally, 5 minutes. [21:56] cjwatson: And no, I don't have edit permissions. :P [21:56] cjwatson@nusakan:~/cdimage/www$ find -L simple full -name MD5SUMS 2>/dev/null | grep 14.04.3 | xargs cat | grep 14.04.3 | sed 's/$.*$ \*$.*$/|| \1 || \2 ||/' [21:56] plus the itsalltext firefox extension [21:56] and a bit of manual rearranging [21:56] I'm sure I had something neater last time, but this'll do [21:57] and wubi.exe but anyway [21:58] infinity: No Lubuntu for powerpc? There was one for .2 apparently [21:59] cjwatson: nopey nope nope [21:59] ok [21:59] cjwatson: Huh. So there was. And no there isn't. [22:00] infinity: done [22:00] cjwatson: Ta. [22:34] infinity: it's safe to release SRUs for trusty now? [22:46] bdmurray: Oh, yes. Go nuts. [22:54] infinity, your not likely to get answers from me at 4am in the morning ;) but yes the images were ready! [22:56] darkxst: Well, good. Cause they're released now. :) [22:58] infinity, yes I saw!