[00:36] slangasek, stgraber, or infinity: ^ hey would you mind reviewing this one? changes from libmirserver5 to libmirserver6 [00:36] Hahahahahaha. [00:36] Again? [00:37] AGAIN? [00:37] unity-mir + platform-api + unity-system-compostor will come in shortly [00:37] infinity: of course! this one is actually the ABI which is meant to be unstable ;-) [00:37] lool: you've got a little Freud there [00:37] lool: So they should have just called it libmirserver0 and required stricted shlibdeps. [00:37] infinity: I actually piled up too changes, the initial plan had two ABI changes, one some hours ago and one tomorrow [00:38] s/stricted/stricter/ [00:38] I see my arm64 build-dep change wasn't included :( [00:38] Anyhow. Will review and override. [00:38] merged but I guess too late [00:38] ah yes [00:38] cjwatson: If you want your changes noticed, upload to the archive and wedge the autolander. :P [00:38] cjwatson: I can offer another upload immediately after this onr [00:38] one [00:38] * infinity knows how to game the system. [00:38] lool: that'd be good, thanks [00:38] but I'd like to get this one, then merged back etc. [00:39] infinity: seems like a CLM at the moment [00:39] for this package [00:39] cjwatson: I did it all through the cycle, but I agree that I wouldn't do it right NOW. :) [00:39] infinity: so, you're claiming this one? [00:40] slangasek: Yeah, I've got it. [00:40] ok [00:40] If I can type on my laptop without my hands setting on fire. [00:40] Parallel kernel and glibc builds are, apparently, a sweaty affair. [00:41] I'll queue the rebuild ones [00:43] + [ Robert Ancell ] [00:43] + * Bump version to 0.0.12 [00:43] + [00:43] + [ Kevin Gunn ] [00:43] + * bump version to 0.0.13 [00:44] + [00:44] + [Kevin Gunn] [00:44] + * bump version to 0.0.14 [00:44] I don't even... [00:45] ^ rebuilds [00:46] unity-mir has important other changes [00:46] platform-api has one fix [00:50] infinity: mind reviewing platform-api too? [00:51] lool: Already on it. [00:52] amd64: 0 uninstallables [00:52] well, as long as you don't count arch: all, which I think will be next cycle's project [00:53] cjwatson: nice! Is that the same as 100% superseding of the bootstrap archive? [00:53] amd64 != arm64 [00:53] oh geez [00:53] and so it begins [00:54] see, it *should* have been called aarch64 :P [00:54] but then you wouldn't be able to pronounce it! [00:54] lool: 'aardvarch' [00:54] arf [00:54] I mean arf64 [00:55] so I've pushed hud and ubuntu-keyboard too [00:55] ubuntu-keyboard is not seeded in ubuntu [00:55] but hud is and has some important fixes for it to stop crashing unity8 [00:56] and hud is the last one I have for tonight that needs review [00:56] (I hope :-) [01:01] infinity: are you looking at hud too? [01:02] Only because you asked nicely. [01:04] thanks [01:06] lool: These changes seem to represent a lot more than what the changelog implies... [01:09] lool: Seems the universally disabled bamf, plus a ton of other stuff in here. New upstart jobs, etc. [01:09] infinity: So not sure which one specifically, but indeed; usually one line in the changelog is one merge proposal potentially of a huge rework; perhaps it's easier to review the corresponding bzr log -n0 [01:09] infinity: hud? [01:09] Yes.. [01:09] infinity: Yeah, so hud is essentially hmm "let [01:09] "let's quickly write a platform-api backend" [01:09] trying to be feature compatible with bamf [01:10] Yeah, but no. [01:10] ifeq ($(DEB_HOST_ARCH),armhf) [01:10] ENABLE_PLATFORM_API = ON [01:10] + ENABLE_BAMF = OFF [01:10] else [01:10] ENABLE_PLATFORM_API = OFF [01:10] + ENABLE_BAMF = ON [01:10] endif [01:10] That implies that on !armhf, bamf is meant to still be used. [01:10] if armhf :-( [01:10] But they dropped the build-dep. [01:10] yes [01:10] And bamf isn't linked anymore AT ALL. [01:10] that seems a mistake [01:10] However, platform_api would also not be used on my laptop anymore, due to the above. [01:11] So, I get neither. [01:11] you wouldn't want platfomr-api on your desktop I think [01:11] I'm not sure I care if I have either one, but I assume some people do care about regressing the bamfy bits a week before release. [01:12] yes [01:12] but this also unbreaks the touch image a lot [01:12] lool: Rejected. Please relay to whomever, since the mail goes to a blackhole. [01:25] infinity: BTW thanks for the review; yes, I'm passing this on or fixing it and I should have catched that in review [01:25] but missed reviewing this packaging diff, my bad [01:25] (we have a review step to look at the diff of control + CMake files etc.) [02:11] cjwatson: ^ arm64 fix [02:18] lool: Danke, accepted. [02:44] infinity: ah it turns out the bamf bdep removal was intentional [02:44] infinity: it's now autogenerated calls from a xml file! [02:44] my gosh [02:45] infinity: it has a bamf dbus interface file instead of linking to the C lib [02:46] infinity: so I have a build here which is like the previous one, but readds the bdep; I've tested it locally, and hud starts, the upstart log says stuff about the voice engine starting that I dont know how to test, but it's not crashing [02:47] infinity: I'd like to followup with upstream tomorrow, but would you think we could take this change that is at least not breaking desktop startup as to unblock touch image? [02:48] well tomorrow == in some hours [02:48] but would like to have hud in a build [02:49] hmm maybe I've lost infinity [02:49] slangasek: still around? [02:52] lool: I'm still here, just hacking away. [02:53] infinity: ah great [02:53] lool: That seems like quite a change (C API to DBUS interface) to be making a week before release... [02:53] infinity: yeah, it's a port to platform-api [02:53] infinity: it's awfully large [02:54] infinity: but it's not crashing and burning [02:54] "Not crashing" is hardly a testament to continued functionality. :P [02:54] infinity: desktop session is fine; I wont pretend I know how to test all the features (I never use hud), but I can commit to chekcing with ted and or pete-woods [02:54] pete comes in the morning [02:54] But meh. If the people responsible are willing to own this if it blows up and sort out the aftermath... [02:54] infinity: I'll take the blame if it breaks people desktops [02:55] (I don't use hud either, so it's all a mystery to me how I'd test it) [02:55] reuploading it here [02:55] infinity: so I have a stupid change to readd the bdep now [02:55] lool: Alright, well, I'm not sure why we'd need the b-d back, if it doesn't link the library anymore. [02:55] infinity: will remove once I have chatted with ted and/or pete [02:55] but it doesn't change anything [02:55] * infinity nods. [02:55] the bdep was when using the C api [02:56] Right. I think someone needs to train these folks to use more informative merge commit messages. [02:57] Make them all submit a few patches to linux or git to learn how to write useful changelogs. ;) [02:59] hmm I'm not confident cu2d pushed it [03:00] * infinity spins up another eglibc build... [03:00] it seems not [03:00] so [03:02] there we go [03:02] will be there in 3mn [03:06] infinity: ^ [03:06] (same as before, but with bdep added) [03:07] lool: When it all goes south, I'll be sure to blame you. :) [03:11] * lool hides in a cave [03:11] infinity: I've dropped an email to maintainers already to please test when they get up and tell me about any regressions [03:31] slangasek: uploaded maas [04:40] slangasek: If you're around, can you review that eglibc? We need the last patch for arm64, I threw in a bunch of security updates for good measure. :P [04:42] infinity: you couldn't have left the security updates for the -security pocket, where we don't have to worry about them introducing regressions a week before release? [04:44] slangasek: Marc was going to upload most of those security fixes a few days ago, I asked him to hold off while we looked into a few other bits. But meh? Testsuite passes, diffs all look sane. [04:44] wow, pt_chown goes away [04:44] slangasek: Yeah, I have to think about how that will impact Debian, and if I have to re-enable it for non-Linux kernels, but the answer for Linux is simple, just make it go away. [04:45] * slangasek nods [04:45] slangasek: Apparently, someone has discovered how to use pt_chown to exploit fuse, which made its long-term known-insecure status much, much worse. [04:46] haha [04:46] ugh, are you sure this strcoll patch is sane? how thorough are the existing strcoll tests? [04:47] Yeah, my response to Marc was "can't I just make libc6 conflict with fuse instead?" [04:49] slangasek: There are a few strcoll tests, two for general sanity, and two for bugs. [04:49] * slangasek checks, out of an abundance of caution, that the dirstream struct is genuinely opaque [04:49] s/caution/paranoia/ [04:50] also, "dirp" is the best variable name the history of variables [04:51] slangasek: That strcoll patch is already in the security PPA and tested, and mdeslaur was planning to release soon, AFAIK. [04:51] slangasek: (Hence why he asked me to push to saucy) [04:51] * slangasek nods [04:51] slangasek: The only two I added that aren't in the PPA are the pt_chown and static pointer guard fixes. [04:52] pt_chwon speaks for itself. [04:52] And the stack guard thing is more testsuite than patch. [04:53] (Admittedly unreadable patch, if you don't speak 7 versions of assembly...) [04:57] infinity: why patches/ubuntu/unsubmitted-dlopen-static-crash.diff? [04:57] no related regression test; no bug report; fixes a corner case (who calls dlopen from a statically-linked executable and can we have them flogged?) [04:58] slangasek: That's to make our conftests stop segfaulting. That's Colin's contribution to this upload. [04:58] hmmmm [04:58] slangasek: Turns out that some 25% of autotools packages have conftests that do exactly that. And segv. [04:58] slangasek: Which is messing with my segv-scanning magic on the arm64 buildds. :P [04:58] slangasek: But also just seems silly, if we can fix it anyway. [04:59] that's a surprisingly high percentage [04:59] slangasek: Large portions of that are rewritten in 2.18. I'll be testing if this is still a problem in 2.18/2.19 and submit it upstream with a proper testcase if it is. [04:59] ok [04:59] accepted [04:59] I don't suppose you have time to review maas, which was what I was planning to do instead of eglibc? :) [05:00] Maaaaybe. [05:00] Oh, doesn't look huge. Sure. [05:00] cheers [05:00] * infinity will regret that statement, won't he? [05:01] I think ChangeLog/NEWS files nees a "Bugs created in this release" section under the "Bug fixed" section. Would make it much easier to review. [05:03] Waaaaitaminute. [05:03] roaksoax: Did you really re-use an FFe from August for this upload? :) [05:08] roaksoax: Also, why on earth does the maas-cluster-controller postinst check if apache2.2-common is installed? It depends on it... [05:18] roaksoax: Okay, seriously, not trying to be a jerk here, but it's a week before release, and this has a LOT of new features and pretty massive changes. [05:19] roaksoax: And handwaving and saying "we got an FFe for an upload 1.5 months ago" doesn't cut it. [05:25] infinity: well, I read that changelog as saying "this is a bugfix-only upstream release fixing features that were already uploaded under the mentioned FFe"? [05:26] slangasek: That's what the changelog says, it's not what the code says. [05:26] hmm [05:27] slangasek: I think someone's using a rapid double-talk variant of the term "bug fix" to mean "fill in the blanks on all the features we half-implemented for our last exception", or similar. [05:35] That was certainly our plan :) [06:24] cjwatson: still a chance of getting bug #1236625 into grub? [06:24] Launchpad bug 1236625 in grub2 (Ubuntu) "grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root" [High,In progress] https://launchpad.net/bugs/1236625 [06:29] slangasek: Poof. It's done. Bug #1236625 is in grub. [06:29] Launchpad bug 1236625 in grub2 (Ubuntu) "grub-install fails to set up /boot/efi/EFI/ubuntu/grub.cfg with UEFI and LVM root" [High,In progress] https://launchpad.net/bugs/1236625 [06:30] infinity: thanks, appreciate you taking care of that for me ;P [06:30] slangasek: Would you like me to add any more bugs to it while I'm being helpful? [06:31] infinity: would you be a doll and break ipv6 tftp support? [06:31] Also done. [07:06] ^-- Fixes an FTBFS in the testsuite, and a minor packaging tidy up. [07:21] slangasek: yeah, was planning to look over that today [07:30] cjwatson: ^ [07:31] looking [07:31] oh is that the segfault on arm64 too? [07:32] (or is that just a random one?) [07:32] You mean the one in the current logtail? [07:32] That's just random hate. [07:32] Yep [07:32] k [07:32] At least, I hope so. [07:33] It's mildly disconcerting that it spit out the bug report instructions instead of the "hey, we tried this twice and it's totally your crap hardware's fault, yo". [07:40] * cjwatson belatedly moves python-commandnotfound to main [07:41] (image build failures) [07:42] Is it in poor form in certain circles to complain that I'm only getting 9MB/s from github tonight? [07:42] lalala I can't hear you [07:43] Oh, there we go, 12 is a little more respectable, I guess. [07:44] and birch ICEs four minutes in [07:46] infinity: ah, nice one for getting armhf to 0 uninst (soon) [07:47] Alright, twombly. Are we gonna have any problems here? *stare* [07:48] Whoa. Wait a minute. Does LLVM actually have a functional arm64 port, or is it just happily building arm64 binaries that can cross to every arch it DOES support, but no arm64 backend? [07:48] (I mean, I know it must have a functional armv8 port internally at Apple, but I didn't remember seeing it in the packages. Didn't look hard either, though) [07:49] Apple has withheld the A64 source for now AIUI. [07:49] So I doubt it's building anything particularly useful [07:49] Right, so WTF is it building? :) [07:49] I guess a generic frontend to all the other backends. [07:49] So I can build i386 binaries on arm64. [07:49] Can't wait. [07:50] twombly fail [07:50] Delicious ICE [07:50] Er [07:50] as segfaulted? [07:50] Sure, why not? [07:50] Everything segfaults. [07:51] It's usually cc1, but I guess as works too... [07:51] It's only usually cc1 because cc1 spends more time on the CPU. [07:51] That's two successive eglibc segfaults in <5mins [07:51] Literally anything can be sniped by this hardware, so. Whatever. [07:52] Only one of the last four builds got through the first 5 minutes :/ [07:53] I could superstitiously reboot some hardware. [07:53] WCPGW [07:53] But I imagine we're just victims of random distribution being, y'know, random, and human brains being unable to cope with that. [07:53] I don't think superstition is unwarranted with this hardware. [07:54] * cjwatson starts building stone circles [07:54] * infinity looks online for mail-order chickens. [07:59] I'm seriously having continued trouble with the name "twombly", though. Where did it come from? [07:59] I keep getting an "Overground, underground, wombling free" earworm [07:59] Or was it "Underground, overground"? One of those. [08:00] The names were probably selected from the list of legendary creatures by the CPUs themselves. [08:00] :-) [08:01] https://www.youtube.com/watch?v=FZ2mJPSccvo [08:02] The 70s really were on excellent drugs [08:03] Is the stop-motion version of the show I saw years ago a fraud, or is this music video an exception? [08:04] I don't remember it being stop-motion, but it was a long time ago ... [08:04] 8] omg [08:05] TWOMBLY [08:05] Why do you do this, twombly. [08:05] infinity: Any news on those chickens? [08:06] Yeah, screw it, time for religion. [08:07] birch is getting a completely unnecessary reboot once it goes idle. [08:07] And little wobbly twombles too. [08:08] https://www.youtube.com/watch?v=aCf_PpDUTdA does look awfully stop-motion to me, so perhaps wgrant's memory is better here [08:09] Yeah, that's the one. [08:10] They were a bit of a peculiar 70s pop sensation as well though. [08:10] I would have seen them here in like '98. I had no idea they were so old. [08:10] I think the only low-tech entertainment I miss is The Muppets. [08:12] infinity: Does birch particularly hate reboots? [08:12] And/or life in general? [08:13] hmm [08:14] How or why has dh-python found its way into minimal? [08:14] wgrant: Oh, we're on a new naming scheme, I hadn't noticed [08:14] cjwatson: orly? [08:14] defunct US automobile manufacturers [08:14] I blame Spads [08:14] wgrant: No, it's okay with them, I decided to upgrade the base system too. [08:14] infinity: Ah [08:14] cjwatson: Heh [08:14] so i was just asked to seed webbrowser-app ... which i did, but now regenerating meta gets me " Unknown desktop package: webbrowser-app" ... even though madison sees it in saucy and b) it wants to seed dmidecode on armhf ?!? [08:15] https://en.wikipedia.org/wiki/Twombly_%28cyclecar%29 [08:15] ogra_: It's in universe. I'll re-promote it. [08:15] ogra_: Well, once your seed changes go through... [08:15] infinity, ah, thanks, whats that dmidecode thing ? [08:16] That's in standard, don't know why it would be explicitly listed in touch [08:16] pastebin the full output from ./update? [08:16] cjwatson, ubuntu-meta :) [08:16] Oh [08:16] Well, that'll be because somebody got it to build recently [08:16] https://launchpad.net/ubuntu/+source/dmidecode/2.12-2 [08:16] Wait, why is webbrowser-app landing in ubuntu-desktop? [08:17] http://paste.ubuntu.com/6217122/ [08:17] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715139 "on-going work to enable SMBIOS on ARM" [08:17] infinity, because it is the new platform for all webapps [08:17] Debian bug 715139 in dmidecode "dmidecode: Build for armhf architecture" [Wishlist,Fixed] [08:17] lol [08:17] SMBIOS on ARM [08:19] infinity: i love webbrowser-app, it's the only browser on ubuntu so far that scrolls on touch input, instead of selecting text. (kind of handy with convertable touch notebooks) [08:19] also it's probably improssible to select text in webbrowser-app. [08:21] -Architecture: all [08:21] +Architecture: foreign [08:21] +Multi-Arch: same [08:21] go libaria [08:21] (please, go) [08:21] Hahahaha. [08:21] Architecture: maybe [08:21] I wonder which the maintainer meant [08:21] Multi-Arch: very [08:21] Who knows, really. [08:21] I'm going to guess all/foreign, given that it's -dev-doc [08:21] * xnox looks cross-eyed, does that even build? [08:21] No [08:22] Well, sort of [08:22] It builds all the *other* binaries [08:22] It'll just skip that binary [08:22] excellent. [08:22] And leaves that one in undocumented NBS [08:22] Since it's not building for the arch "foreign". [08:22] (i.e. listed in saucy_outdate_all but not actually in NBS proper) [08:22] I can add it to dpkg's arch table, if you like. [08:22] Architecture: sometimes [08:25] lol [08:26] Architecture: maybe made me laugh quite a bit too [08:26] Alright, superstition engaged. Begin swinging chickens. [08:27] Well, the next Debian revision up fixes this but also adds Python bindings [08:27] The changes look fairly harmless, though, so I'll probably sync that. Just build-testing [08:37] rebuilding Ubuntu desktop images [08:37] (they failed due to component-mismatch) [08:49] Riddell: I don't think that'll work, you have leading spaces instead of tabs which I expect make will object to [08:49] +else ifeq ($(DEB_HOST_ARCH),armhf) [08:49] + ./Tools/Scripts/build-webkit --qt DEFINES+=ENABLE_JIT=0 DEFINES+=ENABLE_YARR_JIT=0 DEFINES+=ENABLE_ASSEMBLER=0 DEFINES+=WTF_USE_3D_GRAPHICS=0 [08:49] in that bit [08:50] Riddell: could you replace those eight spaces with a hard tab and reupload? [08:50] * cjwatson retries what looks like an ephemeral eglibc/amd64 failure [08:51] (tst-robust8 timed out) [08:54] I spy a universe release package on twombly. I guess the main queue is finally all depwaited. [08:54] Or twombly's just acting out. [08:55] cjwatson: arg sure [09:02] wgrant: I scored up a couple of small things that proposed-migration mentioned waiting on [09:02] oh, not arpwatch though [09:02] So, yeah, main's probably depwaited [09:02] Yeah, the score was in the 1700s [09:02] https://launchpad.net/ubuntu/saucy/arm64/+builds?build_text=&build_state=pending is all <2000 [09:02] We'll probably get quite a few successful trivial builds [09:03] I noticed earlier that some armhf stuff is deadlocked in proposed-migration. [09:03] such as? [09:03] (do you mean armhf?) [09:03] Er [09:03] arm64 [09:03] djvulibre [09:04] djvulibre is in -proposed, but djview won't be installable without djview4, which is in release depwaiting on libdjvulibre-dev [09:05] And this is why building in the release pocket is a bit broken. :/ [09:06] We can do some manual copies from proposed to release. [09:06] Sadly, not to much the other way (as in, we can't magically make release builds build in proposed...) [09:06] Oh, but I could just add proposed to the chroots unconditionally for a bit. :P [09:06] Right [09:06] Heh [09:07] Or we could copy the binaries from proposed to the bootstrap repo. [09:07] Which seems saner still. [09:07] Then they'll still get proper migration checks when they're ready to go. [09:07] Or just copy the source+binaries to release. [09:07] Yeah, but copying them to release is skipping the checks that are holding them out. [09:08] Feels dirtier. [09:08] Dirtier than putting them in a sources.list.d backdoor? :) [09:08] Anyhow, let me do the bootstrap copy for djvuwhatever. [09:08] wgrant: Well,the backdoor is only for build-deps, the actual migration of the package in the archive is still guarded by making sure it's installable. Sort of. [09:09] True. [09:09] (The britney hack kinda mucks with that too. :( ) [09:09] Can't wait for that to go. [09:10] 41 packages left ... [09:11] wgrant: Erm, djview4 was dep-wait on qt4-opengl. [09:12] At the moment, yes ;) [09:12] s/;/: [09:12] Alright, well. djwhosit-dev is in the bootstrap archive. [09:12] But once qt4 exists it'll still be stuck forever until someone prods it manually. [09:12] So, that'll kinda sort itself. [09:14] LP won't notice the dep-wait resolution in bootstrap, so it'll probably still need a retry [09:14] cjwatson: Except it was dep-wait on qt4. [09:14] Oh, right [09:15] cjwatson: Because, way back when, whoever wrote that for me was too lazy to emulate the wanna-build ability to have multiple dep-waits. [09:15] Or, so they told me. [09:15] So I never fed them multiple from the slave side. [09:16] * cjwatson nods [09:29] Riddell: sorry, didn't notice that upload, re-reviewing now [09:30] right, everything in http://people.canonical.com/~ubuntu-archive/testing/saucy_outdate_all.txt now looks like it's in progress [09:31] strange libaria build failure though, worked locally, investigating [09:40] cjwatson: I see no indication in the log that libAria is being linked to -lpthread or -ldl [09:40] cjwatson: Not sure how that would work locally. [09:45] Yeah, not sure why it worked locally [09:46] Unless I fumble-fingered and test-built on unstable [09:46] Which syslog suggests I did. Whoops [09:47] Say, did anyone proposed --as-needed as a jessie release goal? :P [09:48] Yay, birch, I love you! [09:48] ALL IS FORGIVEN. [09:49] Near the end of a publisher run, too [09:50] wgrant: I'll just toss it in the bootstrap repo, so the world can benefit ASAP. [09:50] Oh, better plan. [09:51] cjwatson: germinate's been crashing today [09:51] 2013-10-10 09:50:29 INFO Germinating for ubuntu-gnome/saucy/arm64 [09:51] 2013-10-10 09:50:30 ERROR Unhandled exception [09:52] KeyError: 'hunspell-en-us' [09:52] ok, I'll have a look [09:52] OTOH it makes the publisher much faster :) [09:53] I bet [09:53] Though ubuntu-gnome is probably fairly late in the list [09:53] But arm64 is second [09:53] Ah [09:53] So it does amd64, then part of arm64, then boom [09:53] Forgot it was that way round [09:53] infinity, webbrowser-app is still unknown ... [09:54] Oh dear lord, it's dragging the world in with it. [09:54] Urgh, yeah, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt doesn't look good [09:55] http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg [09:55] Prettier in graph/blame form. [09:55] didn't we already revert a webbrowser-app promotion because of that? [09:55] That doesn't look desperately feasible for 13.10 [09:55] ogra_: Did anyone actually examine the rdeps here before deciding to do this 12h before final freeze? [09:56] infinity, no idea, there is an approved MIR and it is needed for webapps to work [09:56] wgrant: Merry Christmas, have a wayland. [09:56] infinity: Is that why birch is manual? [09:56] ogra_: There aren't approved MIRs for all the dependencies. [09:57]