[00:36] <lool> slangasek, stgraber, or infinity: ^ hey would you mind reviewing this one?  changes from libmirserver5 to libmirserver6
[00:36] <infinity> Hahahahahaha.
[00:36] <infinity> Again?
[00:37] <infinity> AGAIN?
[00:37] <lool> unity-mir + platform-api + unity-system-compostor will come in shortly
[00:37] <lool> infinity: of course!  this one is actually the ABI which is meant to be unstable  ;-)
[00:37] <slangasek> lool: you've got a little Freud there
[00:37] <infinity> lool: So they should have just called it libmirserver0 and required stricted shlibdeps.
[00:37] <lool> infinity: I actually piled up too changes, the initial plan had two ABI changes, one some hours ago and one tomorrow
[00:38] <infinity> s/stricted/stricter/
[00:38] <cjwatson> I see my arm64 build-dep change wasn't included :(
[00:38] <infinity> Anyhow.  Will review and override.
[00:38] <cjwatson> merged but I guess too late
[00:38] <lool> ah yes
[00:38] <infinity> cjwatson: If you want your changes noticed, upload to the archive and wedge the autolander. :P
[00:38] <lool> cjwatson: I can offer another upload immediately after this onr
[00:38] <lool> one
[00:38]  * infinity knows how to game the system.
[00:38] <cjwatson> lool: that'd be good, thanks
[00:38] <lool> but I'd like to get this one, then merged back etc.
[00:39] <cjwatson> infinity: seems like a CLM at the moment
[00:39] <cjwatson> for this package
[00:39] <infinity> cjwatson: I did it all through the cycle, but I agree that I wouldn't do it right NOW. :)
[00:39] <slangasek> infinity: so, you're claiming this one?
[00:40] <infinity> slangasek: Yeah, I've got it.
[00:40] <slangasek> ok
[00:40] <infinity> If I can type on my laptop without my hands setting on fire.
[00:40] <infinity> Parallel kernel and glibc builds are, apparently, a sweaty affair.
[00:41] <lool> I'll queue the rebuild ones
[00:43] <infinity> +  [ Robert Ancell ]
[00:43] <infinity> +  * Bump version to 0.0.12
[00:43] <infinity> +
[00:43] <infinity> +  [ Kevin Gunn ]
[00:43] <infinity> +  * bump version to 0.0.13
[00:44] <infinity> +
[00:44] <infinity> +  [Kevin Gunn]
[00:44] <infinity> +  * bump version to 0.0.14
[00:44] <infinity> I don't even...
[00:45] <lool> ^ rebuilds
[00:46] <lool> unity-mir has important other changes
[00:46] <lool> platform-api has one fix
[00:50] <lool> infinity: mind reviewing platform-api too?
[00:51] <infinity> lool: Already on it.
[00:52] <cjwatson> amd64: 0 uninstallables
[00:52] <cjwatson> well, as long as you don't count arch: all, which I think will be next cycle's project
[00:53] <slangasek> cjwatson: nice!  Is that the same as 100% superseding of the bootstrap archive?
[00:53] <cjwatson> amd64 != arm64
[00:53] <slangasek> oh geez
[00:53] <slangasek> and so it begins
[00:54] <slangasek> see, it *should* have been called aarch64 :P
[00:54] <lool> but then you wouldn't be able to pronounce it!
[00:54] <slangasek> lool: 'aardvarch'
[00:54] <lool> arf
[00:54] <lool> I mean arf64
[00:55] <lool> so I've pushed hud and ubuntu-keyboard too
[00:55] <lool> ubuntu-keyboard is not seeded in ubuntu
[00:55] <lool> but hud is and has some important fixes for it to stop crashing unity8
[00:56] <lool> and hud is the last one I have for tonight that needs review
[00:56] <lool> (I hope :-)
[01:01] <lool> infinity: are you looking at hud too?
[01:02] <infinity> Only because you asked nicely.
[01:04] <lool> thanks
[01:06] <infinity> lool: These changes seem to represent a lot more than what the changelog implies...
[01:09] <infinity> lool: Seems the universally disabled bamf, plus a ton of other stuff in here.  New upstart jobs, etc.
[01:09] <lool> 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] <lool> infinity: hud?
[01:09] <infinity> Yes..
[01:09] <lool> infinity: Yeah, so hud is essentially hmm "let
[01:09] <lool> "let's quickly write a platform-api backend"
[01:09] <lool> trying to be feature compatible with bamf
[01:10] <infinity> Yeah, but no.
[01:10] <infinity>  ifeq ($(DEB_HOST_ARCH),armhf)
[01:10] <infinity>         ENABLE_PLATFORM_API = ON
[01:10] <infinity> +       ENABLE_BAMF = OFF
[01:10] <infinity>  else
[01:10] <infinity>         ENABLE_PLATFORM_API = OFF
[01:10] <infinity> +       ENABLE_BAMF = ON
[01:10] <infinity>  endif
[01:10] <infinity> That implies that on !armhf, bamf is meant to still be used.
[01:10] <lool> if armhf  :-(
[01:10] <infinity> But they dropped the build-dep.
[01:10] <lool> yes
[01:10] <infinity> And bamf isn't linked anymore AT ALL.
[01:10] <lool> that seems a mistake
[01:10] <infinity> However, platform_api would also not be used on my laptop anymore, due to the above.
[01:11] <infinity> So, I get neither.
[01:11] <lool> you wouldn't want platfomr-api on your desktop I think
[01:11] <infinity> 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] <lool> yes
[01:12] <lool> but this also unbreaks the touch image a lot
[01:12] <infinity> lool: Rejected.  Please relay to whomever, since the mail goes to a blackhole.
[01:25] <lool> 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] <lool> but missed reviewing this packaging diff, my bad
[01:25] <lool> (we have a review step to look at the diff of control + CMake files etc.)
[02:11] <lool> cjwatson: ^ arm64 fix
[02:18] <infinity> lool: Danke, accepted.
[02:44] <lool> infinity: ah it turns out the bamf bdep removal was intentional
[02:44] <lool> infinity: it's now autogenerated calls from a xml file!
[02:44] <lool> my gosh
[02:45] <lool> infinity: it has a bamf dbus interface file instead of linking to the C lib
[02:46] <lool> 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] <lool> 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] <lool> well tomorrow == in some hours
[02:48] <lool> but would like to have hud in a build
[02:49] <lool> hmm maybe I've lost infinity
[02:49] <lool> slangasek: still around?
[02:52] <infinity> lool: I'm still here, just hacking away.
[02:53] <lool> infinity: ah great
[02:53] <infinity> lool: That seems like quite a change (C API to DBUS interface) to be making a week before release...
[02:53] <lool> infinity: yeah, it's a port to platform-api
[02:53] <lool> infinity: it's awfully large
[02:54] <lool> infinity: but it's not crashing and burning
[02:54] <infinity> "Not crashing" is hardly a testament to continued functionality. :P
[02:54] <lool> 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] <lool> pete comes in the morning
[02:54] <infinity> But meh.  If the people responsible are willing to own this if it blows up and sort out the aftermath...
[02:54] <lool> infinity: I'll take the blame if it breaks people desktops
[02:55] <infinity> (I don't use hud either, so it's all a mystery to me how I'd test it)
[02:55] <lool> reuploading it here
[02:55] <lool> infinity: so I have a stupid change to readd the bdep now
[02:55] <infinity> 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] <lool> infinity: will remove once I have chatted with ted and/or pete
[02:55] <lool> but it doesn't change anything
[02:55]  * infinity nods.
[02:55] <lool> the bdep was when using the C api
[02:56] <infinity> Right.  I think someone needs to train these folks to use more informative merge commit messages.
[02:57] <infinity> Make them all submit a few patches to linux or git to learn how to write useful changelogs. ;)
[02:59] <lool> hmm I'm not confident cu2d pushed it
[03:00]  * infinity spins up another eglibc build...
[03:00] <lool> it seems not
[03:00] <lool> so
[03:02] <lool> there we go
[03:02] <lool> will be there in 3mn
[03:06] <lool> infinity: ^
[03:06] <lool> (same as before, but with bdep added)
[03:07] <infinity> lool: When it all goes south, I'll be sure to blame you. :)
[03:11]  * lool hides in a cave
[03:11] <lool> infinity: I've dropped an email to maintainers already to please test when they get up and tell me about any regressions
[03:31] <roaksoax> slangasek: uploaded maas
[04:40] <infinity> 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] <slangasek> 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] <infinity> 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] <slangasek> wow, pt_chown goes away
[04:44] <infinity> 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] <infinity> 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] <slangasek> haha
[04:46] <slangasek> ugh, are you sure this strcoll patch is sane? how thorough are the existing strcoll tests?
[04:47] <infinity> Yeah, my response to Marc was "can't I just make libc6 conflict with fuse instead?"
[04:49] <infinity> 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] <slangasek> s/caution/paranoia/
[04:50] <slangasek> also, "dirp" is the best variable name the history of variables
[04:51] <infinity> slangasek: That strcoll patch is already in the security PPA and tested, and mdeslaur was planning to release soon, AFAIK.
[04:51] <infinity> slangasek: (Hence why he asked me to push to saucy)
[04:51]  * slangasek nods
[04:51] <infinity> slangasek: The only two I added that aren't in the PPA are the pt_chown and static pointer guard fixes.
[04:52] <infinity> pt_chwon speaks for itself.
[04:52] <infinity> And the stack guard thing is more testsuite than patch.
[04:53] <infinity> (Admittedly unreadable patch, if you don't speak 7 versions of assembly...)
[04:57] <slangasek> infinity: why patches/ubuntu/unsubmitted-dlopen-static-crash.diff?
[04:57] <slangasek> 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] <infinity> slangasek: That's to make our conftests stop segfaulting.  That's Colin's contribution to this upload.
[04:58] <slangasek> hmmmm
[04:58] <infinity> slangasek: Turns out that some 25% of autotools packages have conftests that do exactly that.  And segv.
[04:58] <infinity> slangasek: Which is messing with my segv-scanning magic on the arm64 buildds. :P
[04:58] <infinity> slangasek: But also just seems silly, if we can fix it anyway.
[04:59] <slangasek> that's a surprisingly high percentage
[04:59] <infinity> 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] <slangasek> ok
[04:59] <slangasek> accepted
[04:59] <slangasek> I don't suppose you have time to review maas, which was what I was planning to do instead of eglibc? :)
[05:00] <infinity> Maaaaybe.
[05:00] <infinity> Oh, doesn't look huge.  Sure.
[05:00] <slangasek> cheers
[05:00]  * infinity will regret that statement, won't he?
[05:01] <infinity> 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] <infinity> Waaaaitaminute.
[05:03] <infinity> roaksoax: Did you really re-use an FFe from August for this upload? :)
[05:08] <infinity> roaksoax: Also, why on earth does the maas-cluster-controller postinst check if apache2.2-common is installed?  It depends on it...
[05:18] <infinity> 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] <infinity> roaksoax: And handwaving and saying "we got an FFe for an upload 1.5 months ago" doesn't cut it.
[05:25] <slangasek> 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] <infinity> slangasek: That's what the changelog says, it's not what the code says.
[05:26] <slangasek> hmm
[05:27] <infinity> 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] <RAOF> That was certainly our plan :)
[06:24] <slangasek> cjwatson: still a chance of getting bug #1236625 into grub?
[06:24] <ubot2> 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] <infinity> slangasek: Poof.  It's done.  Bug #1236625 is in grub.
[06:29] <ubot2> 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] <slangasek> infinity: thanks, appreciate you taking care of that for me ;P
[06:30] <infinity> slangasek: Would you like me to add any more bugs to it while I'm being helpful?
[06:31] <slangasek> infinity: would you be a doll and break ipv6 tftp support?
[06:31] <infinity> Also done.
[07:06] <infinity> ^-- Fixes an FTBFS in the testsuite, and a minor packaging tidy up.
[07:21] <cjwatson> slangasek: yeah, was planning to look over that today
[07:30] <infinity> cjwatson: ^
[07:31] <cjwatson> looking
[07:31] <cjwatson> oh is that the segfault on arm64 too?
[07:32] <cjwatson> (or is that just a random one?)
[07:32] <infinity> You mean the one in the current logtail?
[07:32] <infinity> That's just random hate.
[07:32] <cjwatson> Yep
[07:32] <cjwatson> k
[07:32] <infinity> At least, I hope so.
[07:33] <infinity> 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] <cjwatson> (image build failures)
[07:42] <infinity> Is it in poor form in certain circles to complain that I'm only getting 9MB/s from github tonight?
[07:42] <cjwatson> lalala I can't hear you
[07:43] <infinity> Oh, there we go, 12 is a little more respectable, I guess.
[07:44] <cjwatson> and birch ICEs four minutes in
[07:46] <cjwatson> infinity: ah, nice one for getting armhf to 0 uninst (soon)
[07:47] <infinity> Alright, twombly.  Are we gonna have any problems here?  *stare*
[07:48] <infinity> 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] <infinity> (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] <wgrant> Apple has withheld the A64 source for now AIUI.
[07:49] <wgrant> So I doubt it's building anything particularly useful
[07:49] <infinity> Right, so WTF is it building? :)
[07:49] <infinity> I guess a generic frontend to all the other backends.
[07:49] <infinity> So I can build i386 binaries on arm64.
[07:49] <infinity> Can't wait.
[07:50] <wgrant> twombly fail
[07:50] <wgrant> Delicious ICE
[07:50] <wgrant> Er
[07:50] <wgrant> as segfaulted?
[07:50] <infinity> Sure, why not?
[07:50] <infinity> Everything segfaults.
[07:51] <wgrant> It's usually cc1, but I guess as works too...
[07:51] <infinity> It's only usually cc1 because cc1 spends more time on the CPU.
[07:51] <cjwatson> That's two successive eglibc segfaults in <5mins
[07:51] <infinity> Literally anything can be sniped by this hardware, so.  Whatever.
[07:52] <wgrant> Only one of the last four builds got through the first 5 minutes :/
[07:53] <infinity> I could superstitiously reboot some hardware.
[07:53] <cjwatson> WCPGW
[07:53] <infinity> 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] <wgrant> 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] <cjwatson> I'm seriously having continued trouble with the name "twombly", though.  Where did it come from?
[07:59] <cjwatson> I keep getting an "Overground, underground, wombling free" earworm
[07:59] <cjwatson> Or was it "Underground, overground"?  One of those.
[08:00] <wgrant> The names were probably selected from the list of legendary creatures by the CPUs themselves.
[08:00] <cjwatson> :-)
[08:01] <cjwatson> https://www.youtube.com/watch?v=FZ2mJPSccvo
[08:02] <cjwatson> The 70s really were on excellent drugs
[08:03] <wgrant> Is the stop-motion version of the show I saw years ago a fraud, or is this music video an exception?
[08:04] <cjwatson> I don't remember it being stop-motion, but it was a long time ago ...
[08:04] <xnox> 8] omg
[08:05] <wgrant> TWOMBLY
[08:05] <wgrant> Why do you do this, twombly.
[08:05] <wgrant> infinity: Any news on those chickens?
[08:06] <infinity> Yeah, screw it, time for religion.
[08:07] <infinity> birch is getting a completely unnecessary reboot once it goes idle.
[08:07] <infinity> And little wobbly twombles too.
[08:08] <cjwatson> 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] <wgrant> Yeah, that's the one.
[08:10] <cjwatson> They were a bit of a peculiar 70s pop sensation as well though.
[08:10] <wgrant> I would have seen them here in like '98. I had no idea they were so old.
[08:10] <infinity> I think the only low-tech entertainment I miss is The Muppets.
[08:12] <wgrant> infinity: Does birch particularly hate reboots?
[08:12] <wgrant> And/or life in general?
[08:13] <ogra_> hmm
[08:14] <infinity> How or why has dh-python found its way into minimal?
[08:14] <cjwatson> wgrant: Oh, we're on a new naming scheme, I hadn't noticed
[08:14] <wgrant> cjwatson: orly?
[08:14] <cjwatson> defunct US automobile manufacturers
[08:14] <cjwatson> I blame Spads
[08:14] <infinity> wgrant: No, it's okay with them, I decided to upgrade the base system too.
[08:14] <wgrant> infinity: Ah
[08:14] <wgrant> cjwatson: Heh
[08:14] <ogra_> 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] <cjwatson> https://en.wikipedia.org/wiki/Twombly_%28cyclecar%29
[08:15] <infinity> ogra_: It's in universe.  I'll re-promote it.
[08:15] <infinity> ogra_: Well, once your seed changes go through...
[08:15] <ogra_> infinity, ah, thanks, whats that dmidecode thing ?
[08:16] <cjwatson> That's in standard, don't know why it would be explicitly listed in touch
[08:16] <cjwatson> pastebin the full output from ./update?
[08:16] <ogra_> cjwatson, ubuntu-meta :)
[08:16] <cjwatson> Oh
[08:16] <cjwatson> Well, that'll be because somebody got it to build recently
[08:16] <cjwatson> https://launchpad.net/ubuntu/+source/dmidecode/2.12-2
[08:16] <infinity> Wait, why is webbrowser-app landing in ubuntu-desktop?
[08:17] <ogra_> http://paste.ubuntu.com/6217122/
[08:17] <cjwatson> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=715139 "on-going work to enable SMBIOS on ARM"
[08:17] <ogra_> infinity, because it is the new platform for all webapps
[08:17] <ubot2> Debian bug 715139 in dmidecode "dmidecode: Build for armhf architecture" [Wishlist,Fixed]
[08:17] <ogra_> lol
[08:17] <ogra_> SMBIOS on ARM
[08:19] <xnox> 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] <xnox> also it's probably improssible to select text in webbrowser-app.
[08:21] <cjwatson> -Architecture: all
[08:21] <cjwatson> +Architecture: foreign
[08:21] <cjwatson> +Multi-Arch: same
[08:21] <cjwatson> go libaria
[08:21] <cjwatson> (please, go)
[08:21] <infinity> Hahahaha.
[08:21] <infinity> Architecture: maybe
[08:21] <cjwatson> I wonder which the maintainer meant
[08:21] <infinity> Multi-Arch: very
[08:21] <infinity> Who knows, really.
[08:21] <cjwatson> 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] <cjwatson> No
[08:22] <cjwatson> Well, sort of
[08:22] <cjwatson> It builds all the *other* binaries
[08:22] <infinity> It'll just skip that binary
[08:22] <xnox> excellent.
[08:22] <cjwatson> And leaves that one in undocumented NBS
[08:22] <infinity> Since it's not building for the arch "foreign".
[08:22] <cjwatson> (i.e. listed in saucy_outdate_all but not actually in NBS proper)
[08:22] <infinity> I can add it to dpkg's arch table, if you like.
[08:22] <xnox> Architecture: sometimes
[08:25] <lool> lol
[08:26] <lool> Architecture: maybe made me laugh quite a bit too
[08:26] <infinity> Alright, superstition engaged.  Begin swinging chickens.
[08:27] <cjwatson> Well, the next Debian revision up fixes this but also adds Python bindings
[08:27] <cjwatson> The changes look fairly harmless, though, so I'll probably sync that.  Just build-testing
[08:37] <cjwatson> rebuilding Ubuntu desktop images
[08:37] <cjwatson> (they failed due to component-mismatch)
[08:49] <cjwatson> Riddell: I don't think that'll work, you have leading spaces instead of tabs which I expect make will object to
[08:49] <cjwatson> +else ifeq ($(DEB_HOST_ARCH),armhf)
[08:49] <cjwatson> +        ./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] <cjwatson> in that bit
[08:50] <cjwatson> 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] <cjwatson> (tst-robust8 timed out)
[08:54] <wgrant> I spy a universe release package on twombly. I guess the main queue is finally all depwaited.
[08:54] <infinity> Or twombly's just acting out.
[08:55] <Riddell> cjwatson: arg sure
[09:02] <cjwatson> wgrant: I scored up a couple of small things that proposed-migration mentioned waiting on
[09:02] <cjwatson> oh, not arpwatch though
[09:02] <cjwatson> So, yeah, main's probably depwaited
[09:02] <wgrant> Yeah, the score was in the 1700s
[09:02] <wgrant> https://launchpad.net/ubuntu/saucy/arm64/+builds?build_text=&build_state=pending is all <2000
[09:02] <cjwatson> We'll probably get quite a few successful trivial builds
[09:03] <wgrant> I noticed earlier that some armhf stuff is deadlocked in proposed-migration.
[09:03] <cjwatson> such as?
[09:03] <cjwatson> (do you mean armhf?)
[09:03] <wgrant> Er
[09:03] <wgrant> arm64
[09:03] <wgrant> djvulibre
[09:04] <wgrant> djvulibre is in -proposed, but djview won't be installable without djview4, which is in release depwaiting on libdjvulibre-dev
[09:05] <infinity> And this is why building in the release pocket is a bit broken. :/
[09:06] <infinity> We can do some manual copies from proposed to release.
[09:06] <infinity> Sadly, not to much the other way (as in, we can't magically make release builds build in proposed...)
[09:06] <infinity> Oh, but I could just add proposed to the chroots unconditionally for a bit. :P
[09:06] <wgrant> Right
[09:06] <wgrant> Heh
[09:07] <infinity> Or we could copy the binaries from proposed to the bootstrap repo.
[09:07] <infinity> Which seems saner still.
[09:07] <infinity> Then they'll still get proper migration checks when they're ready to go.
[09:07] <wgrant> Or just copy the source+binaries to release.
[09:07] <infinity> Yeah, but copying them to release is skipping the checks that are holding them out.
[09:08] <infinity> Feels dirtier.
[09:08] <wgrant> Dirtier than putting them in a sources.list.d backdoor? :)
[09:08] <infinity> Anyhow, let me do the bootstrap copy for djvuwhatever.
[09:08] <infinity> 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] <wgrant> True.
[09:09] <infinity> (The britney hack kinda mucks with that too. :( )
[09:09] <infinity> Can't wait for that to go.
[09:10] <cjwatson> 41 packages left ...
[09:11] <infinity> wgrant: Erm, djview4 was dep-wait on qt4-opengl.
[09:12] <wgrant> At the moment, yes ;)
[09:12] <wgrant> s/;/:
[09:12] <infinity> Alright, well.  djwhosit-dev is in the bootstrap archive.
[09:12] <wgrant> But once qt4 exists it'll still be stuck forever until someone prods it manually.
[09:12] <infinity> So, that'll kinda sort itself.
[09:14] <cjwatson> LP won't notice the dep-wait resolution in bootstrap, so it'll probably still need a retry
[09:14] <infinity> cjwatson: Except it was dep-wait on qt4.
[09:14] <cjwatson> Oh, right
[09:15] <infinity> 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] <infinity> Or, so they told me.
[09:15] <infinity> So I never fed them multiple from the slave side.
[09:16]  * cjwatson nods
[09:29] <cjwatson> Riddell: sorry, didn't notice that upload, re-reviewing now
[09:30] <cjwatson> right, everything in http://people.canonical.com/~ubuntu-archive/testing/saucy_outdate_all.txt now looks like it's in progress
[09:31] <cjwatson> strange libaria build failure though, worked locally, investigating
[09:40] <infinity> cjwatson: I see no indication in the log that libAria is being linked to -lpthread or -ldl
[09:40] <infinity> cjwatson: Not sure how that would work locally.
[09:45] <cjwatson> Yeah, not sure why it worked locally
[09:46] <cjwatson> Unless I fumble-fingered and test-built on unstable
[09:46] <cjwatson> Which syslog suggests I did.  Whoops
[09:47] <infinity> Say, did anyone proposed --as-needed as a jessie release goal? :P
[09:48] <infinity> Yay, birch, I love you!
[09:48] <infinity> ALL IS FORGIVEN.
[09:49] <wgrant> Near the end of a publisher run, too
[09:50] <infinity> wgrant: I'll just toss it in the bootstrap repo, so the world can benefit ASAP.
[09:50] <wgrant> Oh, better plan.
[09:51] <wgrant> cjwatson: germinate's been crashing today
[09:51] <wgrant> 2013-10-10 09:50:29 INFO    Germinating for ubuntu-gnome/saucy/arm64
[09:51] <wgrant> 2013-10-10 09:50:30 ERROR   Unhandled exception
[09:52] <wgrant> KeyError: 'hunspell-en-us'
[09:52] <cjwatson> ok, I'll have a look
[09:52] <wgrant> OTOH it makes the publisher much faster :)
[09:53] <cjwatson> I bet
[09:53] <cjwatson> Though ubuntu-gnome is probably fairly late in the list
[09:53] <wgrant> But arm64 is second
[09:53] <cjwatson> Ah
[09:53] <wgrant> So it does amd64, then part of arm64, then boom
[09:53] <cjwatson> Forgot it was that way round
[09:53] <ogra_> infinity, webbrowser-app is still unknown ...
[09:54] <infinity> Oh dear lord, it's dragging the world in with it.
[09:54] <cjwatson> Urgh, yeah, http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.txt doesn't look good
[09:55] <infinity> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[09:55] <infinity> Prettier in graph/blame form.
[09:55] <Laney> didn't we already revert a webbrowser-app promotion because of that?
[09:55] <cjwatson> That doesn't look desperately feasible for 13.10
[09:55] <infinity> ogra_: Did anyone actually examine the rdeps here before deciding to do this 12h before final freeze?
[09:56] <ogra_> infinity, no idea, there is an approved MIR and it is needed for webapps to work
[09:56] <infinity> wgrant: Merry Christmas, have a wayland.
[09:56] <wgrant> infinity: Is that why birch is manual?
[09:56] <cjwatson> ogra_: There aren't approved MIRs for all the dependencies.
[09:57] <infinity> wgrant: Yeah.
[09:57] <cjwatson> Indeed several of them have been disapproved IIRC.
[09:57] <wgrant> infinity: Wanna do gst-plugins-base0.10 as well? It has all the src:src segfaults and is the remaining qt4-x11 blocker...
[09:57] <ogra_> hmm bug 1206268 was the one i looked at
[09:57] <ubot2> Launchpad bug 1206268 in webbrowser-app (Ubuntu) "[MIR] unity-webapps-qml" [Undecided,Fix committed] https://launchpad.net/bugs/1206268
[09:57] <infinity> ogra_: An approved MIR for webbrowser-app doesn't mean an approved MIR for every single one of its many rdeps.
[09:57] <cjwatson> wgrant: You think libc will make any difference to that?
[09:58] <wgrant> cjwatson: I don't think so.
[09:58] <infinity> ogra_: Did you look at the rdep graph?
[09:58]  * cjwatson starts retrying conftest bugs
[09:58] <ogra_> infinity, nope
[09:58] <wgrant> Remember that the conftest segfault only didn't happen on x86 because the build failure was ignored
[09:58] <infinity> wgrant: Do you think the src:src stuff is harmless?  Do we know it is? :P
[09:58] <cjwatson> Were alsa-lib and autogen conftest bugs?
[09:58] <infinity> alsa-lib is.
[09:58] <wgrant> Yes, just retried them
[09:59] <wgrant> infinity: No, we don't, unfortunately. :/
[09:59] <infinity> I'm inclined to just do a mass-give-back and see what sticks.
[09:59] <infinity> Unless someone's been keeping a list.
[09:59] <cjwatson> I'd rather check - we have such limited build time
[09:59] <cjwatson> Going through the logs now
[10:00] <infinity> Aaaaalso...
[10:00] <infinity> https://launchpadlibrarian.net/153371510/buildlog_ubuntu-saucy-arm64.ircd-ratbox_3.0.7.dfsg-3_FAILEDTOBUILD.txt.gz
[10:00] <ogra_> infinity, looking at the binary deps i dont see anything special (all stuff that unity8 will even need on the desktop and which was actually supposed to be MIRed long ago) ...
[10:01] <infinity> ^-- New glibc in chroot, still has conftest faults.
[10:01] <cjwatson> ogra_: We explicitly rejected the roaraudio etc. stack IIRC
[10:01] <infinity> ogra_: Don't look at the binary deps, look at the graph I linked to you.
[10:01]  * ogra_ doesnt see that in the binary deps ... 
[10:01] <infinity> http://people.canonical.com/~ubuntu-archive/component-mismatches-proposed.svg
[10:02] <ogra_> infinity, oh, ouch
[10:02] <ogra_> thanks, i missed the link above
[10:03] <xnox> infinity: ogra_: wasn't qtmultimedia-opensource-src be dropped from the ui toolkit?! Maybe that didn't happen this cycle yet?
[10:03] <infinity> cjwatson: Oh, hrm.  That's an l3 permission fault instead of an l2 translation.  Fun.
[10:03] <wgrant> libprelude is weird like that as well
[10:03] <ogra_> xnox, might be, but seems currently it is still used
[10:03] <wgrant> It has a non-0x8 FAR
[10:03] <wgrant> But it runs the right test to trigger the 0x8 FAR
[10:04] <infinity> ogra_: I just don't see this happening for release.  If we need this "for webapps to work", perhaps people need to rethink webapps working how they used to.
[10:04] <infinity> (Or people need to go back in time and remember that Feature Freeze for non-touch was a month ago)
[10:05] <ogra_> heh
[10:05] <infinity> wgrant: Okay, no dmesg badness from pulse yet.
[10:05] <cjwatson> Was libtool/arm64 a conftest bug?
[10:05] <wgrant> 2013-10-10 10:03:57+0000 [QueryProtocol,client] Processing finished OK build PACKAGEBUILD-4960053 (arm64 build of aspell 0.60.7~20110707-1build1 in ubuntu saucy RELEASE) from builder twombly
[10:05] <wgrant> We're good
[10:05] <wgrant> cjwatson: No
[10:05] <wgrant> cjwatson: It has a separate segfault that doesn't appear on amd64
[10:06] <cjwatson> ok
[10:06] <wgrant> gst-plugins-base0.10 lsof libtool mksh python3.3
[10:06] <wgrant> are the five that were like that in core this morning
[10:06] <wgrant> wayland (deliberate) udisks2 (deliberate) ibus (???) libtimezonemap (???) are reproducible on amd64, not sure if the last two are deliberate
[10:07] <infinity> wgrant: Are you sure the libtool one might not be a manifestation of the same bug, though?  I mean, it's libtool.  Its job is to do stupid things with libraries.
[10:07] <cjwatson> libtimezonemap is a bug
[10:07] <ogra_> GRRRR !
[10:07] <cjwatson> A fairly harmless one normally but still a bug
[10:07]  * infinity tries libtool for kicks.
[10:07] <ogra_> why did we have to name the display server Mir ....
[10:07] <wgrant> libtool[7670]: unhandled level 3 permission fault (11) at 0x2000008a2c, esr 0x9200004f
[10:07] <wgrant> That's no 0
[10:07] <wgrant> But I guess
[10:07] <infinity> Oh, it's l3.  Boo.
[10:07] <wgrant> Well, no
[10:08] <wgrant> We explicitly fixed the case where FAR=0x8
[10:08] <ogra_> it got really hard to google any MIR wikipages nowadays (ubuntu wiki mir ...)
[10:08] <wgrant> If we fixed anything else then the fix is horribly wrong :)
[10:08] <infinity> ogra_: People don't use MIR wiki pages anymore...
[10:08] <infinity> (Does anyone?)
[10:08] <infinity> ogra_: Or do you mean the page that documents the process?
[10:08] <ogra_> i link to them in bugs if people obviously didnt follow the process
[10:09] <wgrant> alsa-lib success too
[10:09] <wgrant> Oh, interesting question.
[10:09] <wgrant> Does the test return yes or no now?
[10:09] <infinity> ogra_:  https://wiki.ubuntu.com/MainInclusionProcess
[10:10] <infinity> ogra_: First hit on google for "main inclusion report"
[10:10] <ogra_> infinity, yeah, i was looking for "requirements" (linked from there though)
[10:10] <infinity> wgrant: Which test was it?
[10:10] <wgrant> checking whether a statically linked program can dlopen itself... no
[10:10] <wgrant> So it still fails, but at least doesn't segfault
[10:10] <ogra_> infinity, already commented on the bug :)
[10:10] <infinity> wgrant: Pretty sure that should be a no.
[10:10] <wgrant> It fails everywhere else too because it fails to link, just thought this fix might make it work on arm64.
[10:10] <infinity> wgrant: dlopening yourself sounds like something libdl would take pretty seriously.
[10:11] <wgrant> Sure, but it was segfaulting yesterday, I guess it must fail more pleasantly now.
[10:11] <cjwatson> What was pygobject?
[10:11] <wgrant> This error
[10:12] <wgrant> https://launchpadlibrarian.net/152846674/buildlog_ubuntu-saucy-arm64.pygobject_3.10.0-1_FAILEDTOBUILD.txt.gz
[10:12] <cjwatson> retried
[10:12] <cjwatson> ah yes
[10:12] <infinity> 4 times, no less.  Overachiever.
[10:12] <wgrant> x4, but I guess it runs configure 4 times
[10:12] <cjwatson> wgrant: It's yes for dynamic, no for static
[10:12] <cjwatson> Which is fine
[10:12] <infinity> If lazy upstreams didn't just say "yeah, I'll use all the default autoconf tests", we'd never hit this. :P
[10:13] <wgrant> Yeah, creates config.status 4 times, so 4 faults is expected.
[10:13] <infinity> Cause I can't imagine any of them actually care about if they can dlopen a static binary from itself.
[10:13] <cjwatson> infinity: This one's from libtool, actually, I think
[10:13] <cjwatson> I can imagine dlopening yourself being useful for a dynamic binary introspecting its own symbols by name or something
[10:13] <cjwatson> A fairly crazy one, but not totally crazy
[10:15] <wgrant> So all looking good so far.
[10:15] <cjwatson> I love sunpinyin/arm64 failing in src/portability.cpp
[10:15] <cjwatson> Subject: sunpinyin: misnamed source file
[10:15] <wgrant> Heh
[10:15] <infinity> Hah.
[10:20] <wgrant> 2013-10-10 10:19:43+0000 [QueryProtocol,client] Processing finished PACKAGEFAIL build PACKAGEBUILD-5082847 (arm64 build of libprelude 1.0.0-11ubuntu1 in ubuntu saucy PROPOSED) from builder birch
[10:20] <wgrant> conftest[8608]: unhandled level 2 translation fault (11) at 0x0a9648d8, esr 0x92000046
[10:20] <wgrant> sigh
[10:21] <infinity> Random kill, or different unresolved issue?
[10:21] <wgrant> Different unresolved and repeatable issue.
[10:21] <infinity> Balls.
[10:21] <wgrant> Rather.
[10:22] <wgrant> I thought it might have been some manifestation of the dlopen bug, given that it was the sole failure in a build that ran the buggy test.
[10:22] <infinity> I'm beginning to wonder if maybe crashing conftests are just a way of life, and something I've never noticed until today.
[10:22] <cjwatson> Seems somewhat likely
[10:22] <wgrant> I don't think I've tested libprelude locally, actually.
[10:22] <wgrant> So that's plausible.
[10:22] <cjwatson> OK, I think that's all the conftest failures retried
[10:23] <wgrant> Everything's passed so far except libprelude, and it was dubious anyway
[10:23] <cjwatson> So even with some remaining issues we should be able to make progress
[10:23] <infinity> On the other hand, we've still had weird things like random unreproducible faults in dpkg-* and such go unnoticed, which makes me wary of turning off the check.
[10:23] <wgrant> Oh yeah, turning off the check entirely would be insane.
[10:23] <infinity> But for the oddball ones, if we can determine they're a non-issue, I can slip in an extra filter for them like I did for wayland.
[10:23] <wgrant> btw
[10:24] <wgrant> easy way to determine which conftest failed
[10:24] <wgrant> run ./configure on the console, look for interpersed kernel spew
[10:24] <infinity> That's too easy for me to have thought of.
[10:25] <infinity> Do we get to have both the gstreamers?  That should unsnag a chunk.
[10:26] <wgrant> gstreamer1.0 should build, not sure 0.10 will
[10:26] <wgrant> Oh yeah, both will
[10:26] <wgrant> But we're still stuck on the 0.10 plugins
[10:27] <infinity> Oh, right, that weird src:src thing.
[10:28] <tkamppeter> Hi, I have uploaded cups-filters 1.0.40. It is a pure bug fix release. Besides some smaller bugs it fixes the problem that many users of Brother printers have margin problems and users of expensive Konica Minolta PostScript printers cannot print at all. So please take it into Saucy. Thanks.
[10:34] <tkamppeter> Thanks.
[10:36] <xnox> Please accepted ubiquity - fixes crasher in the U1 plugin when trying to sing-in or sign-up.
[10:37] <wgrant> Is that like Android's face unlock?
[10:37]  * xnox blinks to confirm i am alive
[10:37] <xnox> wgrant: yes =)
[10:38] <xnox> wgrant: or like apples touchID, with some people using other body parts instead of fingerprints....
[10:38] <wgrant> So I've heard!
[10:39] <xnox> thanks for ubiquity
[10:39] <Laney> Not sure I'd like to try that on my laptop
[11:28] <knome> hey, could somebody help xubuntu get pm-utils to our seed? we don't have uploaders available at the moment. bug 1232027
[11:28] <ubot2> Launchpad bug 1232027 in xubuntu-meta (Ubuntu) "pm-utils not installed by default in 13.10" [Medium,Confirmed] https://launchpad.net/bugs/1232027
[11:35] <infinity> knome: I can help with that.
[11:35] <knome> infinity, cheers!
[11:35] <knome> let me know if you need any additional information
[11:36] <infinity> I'm actually a little puzzled as to how it makes it on ubuntu-desktop...
[11:37] <infinity> Ahh, gnome-power-manager -> upower -> pm-utils.
[11:38] <infinity> knome: Based on what kubuntu did, I'm guessing you might want a (upower) recommend, instead of a direct pm-utils dependency.
[11:38] <knome> infinity, that works for me
[11:39] <xnox> infinity: yeap, i have same analysis, but slower to work it out =)
[11:40] <knome> upower seems to be in xubuntu 13.04. i assume that has changed for a reason or another for saucy
[11:40] <infinity> knome: Something probably used to depend on it and you got it transitively.
[11:40] <knome> yep
[11:40] <infinity> knome: Or maybe you used to ship gnome-power-whatever.
[11:41] <knome> that's probably it, but i can't remember clearly. but yeah, i'm fine with installing upower
[11:41] <infinity> Wait.  xfce4-power-manager  Do you not ship that anymore?
[11:41] <knome> afaik we should
[11:41] <infinity> Then you should have upower in your desktop, and thus pm-utils.
[11:42] <infinity> Oh.  Unless you ship something that provides systemd-services
[11:42] <infinity> And germinate is outsmarting you.
[11:42] <infinity> That's probably what's up.
[11:42] <knome> heh
[11:42] <knome> oki
[11:43] <infinity> I'll just explicitly seed pm-utils.  Screw it.
[11:43] <knome> worksforme
[11:43] <knome> we can look at it for 14.04
[11:44] <xnox> retoaded: ubiquity auto-pkg-test failure: I cannot reproduce it locally, and it looks like it's using 2.15.22 unit-tests, but running them against older binaries (? 2.15.21)? from the logs it's not obvious which versions of binary packages under test were installed.
[11:44] <xnox> can it please be retried?
[11:47] <retoaded> xnox, link?
[11:50] <xnox> it was retried and it's blue now.
[11:50] <xnox> (well passed)
[11:50] <xnox> retoaded: https://jenkins.qa.ubuntu.com/view/Saucy/view/AutoPkgTest/job/saucy-adt-ubiquity/
[11:55] <retoaded> xnox, ack. While I have the ability to disable a test/job it is probably better to take that proposal to the owner/maintainer of the job. In this case it appears to be jibel or pitti.
[11:55] <xnox> retoaded: ack.
[11:58] <infinity> knome: ^-- That's for you.
[11:58]  * knome bows
[11:59] <jibel> xnox, run 221 is green or you still want a retry?
[11:59] <xnox> jibel: all is good, it was retried and passed, and is in release pocket as off 5 minutes ago =)
[11:59] <xnox> jibel: thanks.
[12:47] <zul> cjwatson:  can you approve  #1236901 please?
[12:49] <cjwatson> zul: done
[12:49] <zul> cjwatson:  also can you approve swift rc1? as well
[12:52] <cjwatson> zul: sounds big, kinda busy with arm64, maybe somebody else can?
[12:52] <zul> cjwatson:  sure
[13:07] <cjwatson> libpwquality/arm64 I think is best addressed by taking the new upstream bugfix release - only a couple of other fairly trivial changes
[14:04] <sil2100> Hi guys! We need a new libunity released into -proposed (and to release) for touch related things, it's currently in the unapproved queue - can anyone push that forward?
[14:04] <sil2100> cjwatson, infinity: ^ ;)
[14:04] <sil2100> Pretty please with cherries on top! ;)
[14:05]  * ogra_ thinks beers would work better 
[14:05] <sil2100> Pretty please with beer on top..?
[14:05] <ogra_> (see /topic)
[14:05] <ogra_> :)
[14:05] <sil2100> That somehow doesn't sound right ;)
[14:11] <cjwatson> sil2100: looking
[14:12] <cjwatson> accepted
[14:13] <Laney> What happens with touch stuff after Final Freeze?
[14:13] <sil2100> cjwatson: \o/ thank yoU!
[14:13] <Laney> Either touch-only or touch-parts-in-other-things uploads
[14:14] <ogra_> touch only should still go through
[14:14] <ogra_> it is gated before entering usually
[14:15]  * didrocks uploads the seed refresh then
[14:15] <seb128> ogra_, what about e.g indicators?
[14:16] <didrocks> Laney: this go through automatically as it's touch only or something changed since last week?
[14:16] <seb128> I guess we should start getting those to saucy-proposed for SRU and build the image from there?
[14:16] <ogra_> seb128, no idea, ask asac ?
[14:16] <Laney> 'this'?
[14:16] <didrocks> Laney: ubuntu-touch-meta
[14:16] <apw> i thought it was a blanket feature freeze exception
[14:16] <didrocks> I guess it's accepted
[14:16] <apw> (for touch)
[14:17] <ogra_> apw, well, everything needs to go through the spreadsheet for touch ...
[14:17] <ogra_> apw, thats a way stricter process than a freeze
[14:18] <apw> ogra_, i more meant, that is an exception for feature freeze, this is final freeze, a different freeze
[14:18] <ogra_> apw, on -proposed  and release-team level it just goes through
[14:18] <ogra_> ah
[14:28] <zul> can an archive admin approve python-cinderclient and swift please
[14:29] <zul> infinity: can you approve python-cinderclient and swift please?
[14:30] <roaksoax> infinity: can you approve MAAS please?
[14:31] <infinity> roaksoax: Did you read scrollback?
[14:33] <infinity> roaksoax: When you filed that FFe a month and a half ago, was the intent really for it to cover every upload right up to final freeze?
[14:33] <infinity> roaksoax: Cause this upload, despite its changelog claiming otherwise, is not a "bugfix release".  It's very featureful.
[14:34] <roaksoax> infinity: yes! I had the understanding that the FFe was an standing FFe. maas-cluster-controller checks if apache2.2-common is present because we use maas against 2.2 and 2.4 (precise/saucy) and the module version needs to be rpesent in saucy (i got that from the debian migration notes for 2.2 to 2.4). And they are not really features, mostly bug fixes and improvements to what had already been uploaded
[14:35] <roaksoax> smoser: thought the FFe for maas was an standing FFe... (so I was told)
[14:37] <smoser> it largely was the intent of the ffe.
[14:37] <roaksoax> infinity: ^^
[14:37] <smoser> roaksoax, is there much that is not listed in that ffe that is feature?
[14:37] <stgraber> probably best to ask slangasek then since he's the one who approved it
[14:37] <smoser> i guess your moonshot work.
[14:37] <stgraber> though "FFe granted for the changes described." doesn't really suggest an open FFe to me
[14:38] <roaksoax> smoser: yeah i guess that's the only thing not really there,which is really hw enablement
[14:38] <smoser> well, we can wait for slangasek, but my argument would be that the changes described there are now just landing
[14:38] <roaksoax> smoser: yeah some of those granted on nFFe didn't land in the first upload
[14:42] <slangasek> smoser: getting a feature freeze exception never implies "it's ok to upload this any time up until release".  It's meant to be understood that FFes are supposed to be acted on before beta freeze.  When roaksoax asked me about this upload last night, he said bugfixes, not new feature work
[14:42] <infinity> roaksoax: I think my confusion was that you closed the FFe and then reused it, as if it were a standing exception.
[14:43] <smoser> infinity, that confussion is quite reasonable.
[14:43] <infinity> roaksoax: Either way, it's a far cry from "just bugfixes", but I can also sympathise that you don't want to ship with half-done features.
[14:43] <smoser> ok...
[14:43] <slangasek> so I would have to look closely at what's going on here, I'm not going to wave it through
[14:43] <smoser> ok. so we need these changes in.
[14:43] <smoser> what can we do to accomplish that.
[14:44] <smoser> i do understand the confusion, pushback, and general "ITS 1 WEEK BEFORE RELEASE!"
[14:47] <roaksoax> infinity: thank you! I also understand your frustation of me doing such an upload one week before release.
[14:47] <roaksoax> but you are right, we don't want to ship with half-done features
[14:48] <roaksoax> and some of those who were uploaded last night, where covered on the FFe that hadn't been uploaded in the first upload post requesting the FFe
[14:48] <roaksoax> the only other new feature is moonshot stuff, which is hardware enablement that I just got tasked with by the end of last week
[15:18] <didrocks> cjwatson: is britney down? it seems that last run was from Generated: 2013.10.10 13:55:26 +0000
[15:18] <lool> Seems britney didn't run in an hour?
[15:18]  * stgraber checks
[15:19] <cjwatson>   File "/srv/ubuntu-archive/proposed-migration/code/b2/hints.py", line 69, in check
[15:19] <cjwatson>     assert package.version is None, package
[15:19] <cjwatson> AssertionError: eglibc/2.17-93ubuntu3
[15:19] <stgraber> right
[15:19] <cjwatson> I've fixed that block
[15:19] <cjwatson> pretty sure they need to be unversioned
[15:20] <stgraber> cjwatson: you're way too fast, I was just about to look at infinity's hint file ;)
[15:20] <cjwatson> infinity: ^- FYI
[15:21] <infinity> Oh, bah.
[15:21] <infinity> Thanks for fixing.
[15:23] <cjwatson> running p-m manually for you now
[16:01] <smoser> hey...
[16:01] <smoser> asking for pre-approval for uploading
[16:01] <smoser> http://bazaar.launchpad.net/~smoser/simplestreams/trunk/revision/316
[16:05] <smoser> oh well. to me it seems reasonable, there is a good positive and negative test included there. i'm gonna upload.
[16:11] <roaksoax> slangasek: howdy! So I want to clarify a few things about the maas upload I did last night. This is the debdiff with what's currently on the archive with the package I uploaded yesterday. http://paste.ubuntu.com/6218653/
[16:12] <roaksoax> slangasek: 1. the changelog that talks about the major new features is not for *this* particular upload/upstream release. It is simply the addition of the changelog with the new features that currently are in saucy.
[16:14] <roaksoax> 2. the second major change is the new maas-import-ephemerals. In the newest upload, we simply replaced maas-import-ephemerals with maas-import-ephemerals.py (which is in archives) so there's really no change there, but rather we just renamed it and provided various bug fixes to it
[16:15] <roaksoax> 3. the third major change is moonshot support, which is hardware enablement which I was tasked with just last week with the goal of having it released. Sorry for not including that in the FFe
[16:15] <roaksoax> 4. other than that everything are bugfixes, including the changes to maas-import-ephemerals
[16:16] <roaksoax> slangasek: so in reality, the only "new" feature in the last upload, is the moonshot stuff, everything else, are bugfixes
[16:16] <slangasek> roaksoax: I haven't reviewed this at all yet, it's infinity who's said that the upload includes new features; I'll leave it to him to explain what he's seeing that constitutes feature work.  Maybe it's just the moonshot, I don't know.
[16:17] <roaksoax> slangasek: alright! thanks!
[16:17] <roaksoax> infinity: ^^ :)
[16:35] <xnox> please reject gccxml i don't actually know if that works. Upload to archive by accident.
[16:56] <roaksoax> thanks for the maas acceptance!
[16:59] <balloons> how we looking for getting the rc images and milestone up and running ? :-)
[17:00] <infinity> balloons: That'll be probably Sunday night.
[17:01] <balloons> infinity, I thought we were good for today :-(
[17:02] <balloons> I've been communicating that out; remember I wanted to ensure I gave people the proper timeline
[17:02] <stgraber> that lxc fix (and a dbus change to follow in the next few minutes) are required to fix the desktop QA environment, would be nice if someone could review.
[17:02] <infinity> Well, I'm sure stgraber can set up the milestone in the tracker for today, but I wouldn't count anything until Sundayish as an actual "RC".  That's not to say people shouldn't be testing now.
[17:02] <stgraber> (I'll take care of the dbus review since I'm not the author)
[17:05] <balloons> infinity, that's fair enough. If we're ok with migrating to an RC milestone today, that would be helpful.. Having people start now means a better image for sunday
[17:05] <lool> infinity: FYI, Pete Woods and Ted Gould had tested new hud on desktop, and Pete Woods has now retested the new one in archive and it's all good!  They'll revert the useless bdep addition at some later point
[17:11] <infinity> balloons: Agreed.
[17:11] <infinity> stgraber: Can you set up the milestone in the tracker, so people feel comfy that they're testing the right thing over the weekend?
[17:11] <infinity> balloons: I just sent the freeze announcement too.
[17:12] <stgraber> infinity: sure, do you want all new builds redirected there already?
[17:13] <stgraber> infinity: and do we actually do an RC milestone? last time we just went with Final as it was a huge mess to deal with RC => Final a few releases earlier (and confused people since we don't actually release an RC)
[17:14] <infinity> stgraber: No, no RC milestone.  This is "RCs toward final", so Final it is.
[17:14] <stgraber> ok
[17:14] <infinity> stgraber: All new builds there is fine.  We won't bother de-cronning until the weekend, though.
[17:14] <stgraber> infinity: ok, should I turn off e-mail+IRC notifications then?
[17:15] <stgraber> until we de-cron that is
[17:15] <infinity> It's not that much noise, but your call.
[17:15] <infinity> Does the IRC notification also hit QA/testing channels, or just here?
[17:15] <stgraber> also hits -testing
[17:15] <infinity> If it hits QA channels, that might prompt people to test. :P
[17:16] <infinity> I'm all for more testing.
[17:16] <balloons> hehe
[17:16] <stgraber> ok, I'll keep the notifications enabled, we can always silence them if it's a problem
[17:16] <infinity> I look forward to xnox working 29 hour days for the next week to fix all the installer bug people should have found 3 months ago.
[17:16] <infinity> s/bug/bugs/
[17:16] <balloons> so people should anticipate new images into early next week before things really tighten down on respins, etc
[17:17] <infinity> And I still have a few installer things on my plate to deal with before release too. :/
[17:17] <infinity> But first, I need a nap (which is why I sent the announce 3h early).
[17:17] <stgraber> infinity: does http://iso.qa.ubuntu.com/admin/config/services/qatracker/series/37/manifest look vaguely correct to you? (since that's the list of builds that'll show up in the Final milestone)
[17:17] <balloons> stgraber, I would note we need to remove Daviey and add jamespage in his place on the owners
[17:18] <jamespage> balloons, please do
[17:18] <jamespage> stgraber, please do
[17:18] <jamespage> rather :-)
[17:18] <infinity> stgraber: There's no more  armhf+armadaxp ... Hasn't been for a couple of releases.
[17:18] <balloons> I don't want us both to edit it at the same time, so ;-) go for it
[17:18] <stgraber> balloons: done
[17:19] <stgraber> infinity: and I guess the two omap can die too, right?
[17:19] <infinity> stgraber: omap == generic, and omap4 will be generic tonight or tomorrow, yeah.
[17:20] <stgraber> infinity: right, do we actually have separate d-i images for those still or is that a generic d-i image too?
[17:20] <infinity> stgraber: ubuntu-desktop armhf+omap4 is dead.
[17:20] <infinity> stgraber: It'll all be one d-i target, though there are separate binaries with the uboot blobs wrapped around them.
[17:20] <stgraber> infinity: ok, I'll just keep generic then, it's not like it actually matters anyway since it's not an iso
[17:20] <infinity> (I'm also going to keep some symlinks in place so the maas people don't yell at me for moving things around at the last minute)
[17:22] <infinity> stgraber: So, yeah.  desktop-armhf+omap4 goes away.  I'm not sure what will happen with server, I'll tell you later when I figure it out. :P
[17:22] <infinity> stgraber: The rest looks good.
[17:22] <stgraber> infinity: I guess the ubuntu server images should also get tweaked to be -generic instead of having both an omap and omap4 .img but I won't mess with that now
[17:22] <infinity> stgraber: For a lark, if the bootstrap archive fills up completely with everything I need, I might hand-roll an arm64 ubuntu-core too. :)
[17:23] <infinity> stgraber: No, the images need to have one for every target, because they include the bootloader blob. :/
[17:23] <stgraber> infinity: that seems like a bit of a waste but ok ;)
[17:23] <infinity> stgraber: So, we either drop arches (which I'd like to do, but that's the server team's call), or I make more than one.
[17:23] <stgraber> infinity: I guess that's easier than to tell people to do offset dd with a separate .img for the bootloader ;)
[17:23] <infinity> stgraber: Honestly, I'd prefer to drop all the armhf server images and just have netboot.
[17:24] <infinity> stgraber: But, up to the server team.  I'll ask jamespage for an opinion when I'm awake.
[17:29] <stgraber> (just noticed #ubuntu-testing is now #ubuntu-quality and queuebot didn't know about that)
[17:32] <balloons> stgraber, oO
[17:34] <balloons> stgraber, thanks for making the milestone. I'll share the news with everyone once the builds hit
[17:34] <slangasek> would someone be willing to review the grub2 that cjwatson uploaded?  considering the actual changes are all mine, I probably shouldn't do the review :)
[17:35] <slangasek> (and yes, I would rather like this into the candidate images, along with grub2-signed, since UEFI+LVM is currently broken in grub)
[17:36] <stgraber> slangasek: I'll take care of it
[17:36] <slangasek> stgraber: thanks!
[17:38] <stgraber> slangasek: in exchange can I get you to review lxc? :)
[17:38] <slangasek> stgraber: sure
[17:42] <cyphermox> seb128: ^
[17:42] <seb128> ^ would be nice to get that one it, it's an annoying issue with keyboard layouts, especially impacting non-latin users
[17:43] <seb128> the fix is simple, it's to make the greeter codepath run only in the greeter
[17:43] <seb128> e.g just a if() around some code
[17:43] <seb128> cyphermox, thanks ;-)
[17:48] <slangasek> ^^ please don't approve grub2-signed yet until grub2 has been accepted
[17:48] <infinity> slangasek: Did you not set the build-dep on it?
[17:49] <stgraber> slangasek: s/accepted/published/? because I accepted grub2 a few minutes ago
[17:49] <infinity> Apparently not.
[17:50] <slangasek> infinity: no, because it didn't get incremented last time either so I assumed we weren't doing that :)
[17:50] <infinity> I do it, not everyone does. :P
[17:50] <infinity> (Just lets it dep-wait nicely instead of having to wait for publishing and be sure)
[17:51] <slangasek> yep
[17:52] <infinity> Should probably mangle the packaging to work like the linux-signed packaging that looks for a specific version of the signed bits and fails hard when it doesn't find them, etc.
[17:52] <infinity> Makes it somewhat idiot-proof.
[17:52] <apw> plus we have an ./update-version ../linux incantation to do it for you
[18:19] <knome> hey infinity, do you have a minute?
[19:36] <shadeslayer> could someone accept kubuntu-meta ? has some fixes for non existent packages
[19:40] <cyphermox> hey, would it be okay to upload a fix for https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1238137 ? it's a minimal change and only affects touch, I already have the package ready and it was confirmed to fix the issue
[19:40] <ubot2> Launchpad bug 1238137 in network-manager (Ubuntu) "Maguro: Network Manager is not reconnecting ofono's gprs connection after a cellular turn off" [High,Triaged]
[19:54] <sil2100> didrocks: uh oh!
[19:54] <didrocks> sil2100: hey (in a meeting) :)
[19:54] <sil2100> didrocks: whaaaat? At this hour?!
[19:54] <didrocks> sil2100: you are handling what's assigned to you? everything's fine?
[19:54] <sil2100> didrocks: slowly, yes, HUD published, but in unapproved
[19:54] <didrocks> sil2100: yeah, you were not in the end of the last meeting when I was aked to come :p
[19:54] <sil2100> Looking for someone that could push it further ;)
[19:54] <didrocks> sil2100: you need to bribe people!
[19:55] <ogra_> sil2100, see /topic
[19:55] <sil2100> FREE BEER! Anyone who pushes HUD from the queue gets free beer!
[19:57] <didrocks> sil2100: maliit crash is under control?
[19:58] <didrocks> sil2100: please, send to me and timo an email so that we can continue tomorrow morning
[19:58] <didrocks> sil2100: robru as well
[19:58] <sil2100> cjwatson: hello! Sorry to ask you for a second time, but can you push HUD further? ;)
[19:59] <sil2100> didrocks: cyphermox was handling that from what I saw, let me take a look how it went
[19:59] <stgraber> sil2100: accepted
[19:59] <didrocks> sil2100: platform-api?
[20:00] <cyphermox> sil2100: I didn't touch maliit..
[20:00] <sil2100> stgraber: super awesome!
[20:00] <didrocks> thanks stgraber
[20:00] <sil2100> cyphermox: oh, I saw seb poke about that and you said you'll take care of that, but it seems you meant something else
[20:00] <didrocks> sil2100: platform-api is in a good shape for landing?
[20:01] <sil2100> cyphermox: I misread stuff then! Will tackle that later once I finish this here
[20:03] <didrocks> sil2100: not wanting to harass you, but platform-api? (need an answering) :p
[20:03] <didrocks> sil2100: you are handling that one + maliit then?
[20:04] <sil2100> didrocks: yesss!
[20:07] <didrocks> thanks!
[20:09] <didrocks> sil2100: needing to go away, have a nice evening!
[20:09] <didrocks> and good luck ;)
[20:09] <sil2100> ;)!
[20:09] <sil2100> Goodnight!
[20:11] <didrocks> thanks!
[20:13] <slangasek> cyphermox: that seems like an appropriate thing to get fixed, in terms of the bug impact; will have to review the patch once in the queue to say for sure
[20:14] <slangasek> infinity: what's the timeline for starting to churn out candidate images?
[20:14] <cyphermox> slangasek: ok
[20:39] <slangasek> infinity, stgraber: do we want a proposed-migration added sometime soon, so that SRUs can be staged in -proposed without accidentally leaking across?
[20:40] <slangasek> fyi, adding a block for libhybris gst-plugins-bad1.0 android, per discussion with rsalveti
[20:40] <stgraber> I think your sentence above was missing a "block" but yeah, we probably should
[20:41] <slangasek> yeah, it was ;)
[20:41] <slangasek> according to the logs, for raring Colin added it on 4/22
[20:41] <stgraber> what did we do last time? massive block?
[20:41] <slangasek> that seems quite late to me
[20:42] <slangasek> stgraber: no, 'block-all source'
[20:42] <stgraber> if we do that we probably should also turn off auto-accept as otherwise we'll forget about those packages
[20:43] <stgraber> it's reasonably easy to add stuff as unblock when accepting unseeded packages, but having to watch and manually check the proposed-migration list would be a pain
[20:46] <slangasek> hmm.  I think we've given ourselves too many dials.
[20:56] <stgraber> we'll have a late landing of dbus because of the ubuntu-touch testing madness. Sorry about that, the package has been ready and working for hours and doesn't even do any change that are touch-related.
[20:57] <tyhicks> stgraber: will you be able to sponsor the debdiff as well? (I'm really sorry about all the time you've had to spend on this)
[20:57] <stgraber> tyhicks: I'd rather not, if I sponsor it I'm not supposed to then accept it in the queue
[20:58] <stgraber> tyhicks: and since there are more coredevs than release team member, it'd be more efficient for you to use another sponsor
[20:58] <tyhicks> ok
[21:03] <tyhicks> stgraber: kirkland will sponsor it for me once he takes a look at it and the AP tests finish running on your mako device
[21:04] <stgraber> cool
[21:04] <kirkland> stgraber: I'm looking at it now
[21:05] <stgraber> my phone just finished reflashing today's image so I should have the results pretty quickly if I can get the damn thing to stay connected to the wifi for more than a minute (mako has the buggiest wifi driver I've ever seen)
[21:13] <slangasek> stgraber: "doesn't even do any changes that are touch-related"?  so why is it landing at all?
[21:17] <zul> slangasek:  can you ack python-cinderclient and swift when you get a chance please
[21:19] <stgraber> slangasek: probably because tyhicks made the mistake of asking in ci-eng instead of just getting it uploaded to the archive
[21:19] <slangasek> stgraber: that's not an answer to the question I asked
[21:19] <slangasek> I asked "why is it landing", not "why is it late" :)
[21:19] <stgraber> slangasek: do you mean, why do we want that in the archive?
[21:20] <stgraber> slangasek: without that change dbus is busted in LXC and that prevents all of the desktop QA tests from running
[21:21] <slangasek> only the desktop tests?  I thought there was discussion about unity8
[21:21] <stgraber> that's unrelated, unity8 is failing because of Mir not because of dbus
[21:21] <slangasek> ok
[21:22] <stgraber> tyhicks: so all the webbrowser tests failed here, though I have no idea how they can ever succeed since apparently the app is called with invalid arguments
[21:23] <tyhicks> ugh
[21:23] <tyhicks> asac: is that expected ^
[21:24] <stgraber> http://paste.ubuntu.com/6219840/
[21:25] <stgraber> note how the app always complains about invalid options
[21:25] <slangasek> zul: these are new upstream releases of components that don't appear to be listed in the micro-release exception; what's the justification for why these are safe and appropriate to include?
[21:26] <slangasek> smoser, jamespage: ^^ the only bits of openstack that were mentioned to be missing from the MRE were ceilometer or heat; did you guys overlook some components?
[21:27] <jamespage> slangasek, python-cinderclient would not fall under the MRE - its been approved under a FFe (see the changelog)
[21:27] <jamespage> I thought swift already was
[21:27]  * jamespage looks
[21:28] <slangasek> ah, I see the FFe now; curse firefox for always opening the window on the *wrong* desktop
[21:28] <jamespage> slangasek, but you are quite correct about swift...
[21:28]  * jamespage sighs
[21:29] <jamespage> they behave a bit differently upstream which is probably why - we don't get stable point releases from that project like we do the others
[21:29] <slangasek> ok
[21:29] <slangasek> that makes a new upstream RC the week before release rather worrisome to me
[21:29] <slangasek> (python-cinderclient accepted, though)
[21:29] <jamespage> slangasek, whats the best way to proceed with swift? we want to line up with what OpenStack havana is baselining against upstream
[21:30] <jamespage> urgh - the timing on the releases sucks
[21:30] <slangasek> jamespage: convince me that there's been rigorous testing to make up for the fact that this will have no burn-in time before release
[21:33] <jamespage> slangasek, let me throw it somewhere and I'll give it a blast
[21:35] <stgraber> tyhicks, asac: tried camera-app instead, that one looks sane:
[21:35] <stgraber> Ran 11 tests in 45.055s
[21:35] <stgraber> OK
[21:35] <tyhicks> that's good
[21:36] <tyhicks> anxious to hear about the expected results of the unity8
[21:36] <stgraber> well, unity8 passed the tests on sf and failed as badly as it usually does on Mir, so no worse than before
[21:41] <jdstrand> stgraber: thank you for doing that
[21:42] <stgraber> tyhicks: anyway, wasted enough time over this, it's fairly clear to me that if we had a bug in that change, the phone wouldn't work at all, it does seem to work fine and the tests that aren't buggy appear to pass. I'll go do something more productive now and will do the queue review once it's uploaded.
[21:43] <jdstrand> stgraber: yes. sorry about all that. your frustration is shared
[21:44] <tyhicks> thanks for all your help, stgraber
[21:47] <jdstrand> lovely
[22:10] <asac> stgraber: webbrowser test should work
[22:11] <asac> let me lok at your paste
[22:11] <asac> stgraber: if camera is good i guess it fine.
[22:11] <asac> webbrowser might need to unlock screen manuallyu frist
[22:11] <jdstrand> stgraber: fyi, I got the ok to upload dbus
[22:11] <asac> kk
[22:12] <jdstrand> stgraber: I updated the landing page/etc with the testing
[22:12] <jdstrand> stgraber: and uploaded just now
[22:16] <stgraber> jdstrand: ok, I'll review it now
[22:17] <stgraber> good, diff didn't change since I last reviewed, accepted
[22:17] <jdstrand> stgraber: thanks!
[22:23] <jamespage> slangasek, OK - so I've deployed 1.10.0 in our standard, 3 zone, 3 replica test deployment integrated into and openstack deployment via keystone
[22:24] <jamespage> and I've run swift-bench against it which exercises object puts, gets and deletes on the deployment
[22:25] <jamespage> all looks good; 0 failures on the 5 cycles of swift-bench I put the deployment through
[22:27] <jamespage> zul, fyi ^^
[22:28] <slangasek> jamespage: ok.  and those are the only things that we need to worry about testing?  There's a python-swiftclient in the archive; is there any risk that it will be broken by the update?  (not that this would strictly be a blocker anyway, since the new swift release is happening whether or not we include it in saucy and python-swiftclient ought be compatible :)
[22:31] <jamespage> slangasek, fortunately swift-bench -> python-swiftclient -> swift HTTP api
[22:31] <jamespage> so that test exercises the client as well
[22:32] <slangasek> ok, great
[22:32] <jamespage> slangasek, tbh of all of the openstack projects swift is the one I worry about least; its much more mature and generally moves at a slower pace
[22:34]  * jamespage goes eod
[22:35] <jamespage> until tomorrow folks
[22:35] <slangasek> rightyo - accepted
[22:35] <jamespage> slangasek, thanks1
[22:35] <jamespage> I hate my shift key obviously
[22:35] <jamespage> ttfn
[23:07] <slangasek> cjwatson: why does click-dev depend on perl?  That's very unhelpful for a -dev package to do in multiarchland :)
[23:08] <slangasek> cjwatson: dh_click itself seems to be perl-base-clean
[23:09] <slangasek> cjwatson: or maybe click-dev should just be M-A: foreign, since it's Arch: any only "to avoid binNMU irritation"