[12:39] <jibel> infinity, are you coordinating the release of 14.04.1? Can you add it to the tracker?
[15:15] <jamespage> infinity, I think that I have most of the proposed docker SRU prepared and ready for upload - care to review bug 1338768?
[15:16] <infinity> jamespage: Not just now, but soon, yeah.
[15:16] <jamespage> infinity, ta
[15:32] <infinity> jibel: Should be added.
[15:41] <jibel> infinity, thanks. There is no build, is 20140722 the first candidate or you'll do a new build?
[15:59] <xnox> infinity: well, I was hoping to have bug #1275162 published for point release, but  bug #1314134  is not verified yet. Both bugs affect the installation itself.
[16:03] <jibel> xnox, I can do the verification of 1275162
[16:04] <jibel> ah, nm, it's verified.
[16:04] <xnox> jibel: that one is verified, the haevy traffic needs verification.
[16:04] <xnox> jibel: yeap.
[16:05] <xnox> cjwatson: stgraber: any clue how to simulate / test bug #1314134 ?
[16:06] <infinity> jibel: There will be new builds soon(ish)
[16:07] <cjwatson> xnox: honestly, if grub works at all, I'd just go for it ...
[16:08] <infinity> Quality advice on quality, right here folks. ;)
[16:08] <cjwatson> \o/
[16:08] <cjwatson> unless you happen to have a netboot setup already
[16:08] <infinity> But since the last d-i build would have been with that grub, we're vaguely committed anyway.
[16:09] <infinity> And it's been in proposed for eons, with no complaints.
[16:09] <infinity> So, let's do it.
[16:11] <infinity> Hrm, I guess I should turn off cron.
[16:14] <xnox> cjwatson: daily isos are netbooted in the test infrastructure, on jenkins. so that works, and our network should be busi-ish? or is this some kind of special busy?
[16:15] <xnox> trusty is 100% both on desktop-netboot and server images.
[16:15] <cjwatson> xnox: I doubt the netbooting goes through grub
[16:17] <xnox> cjwatson: oh. ok. so it's grub networking =/ no idea about that.
[18:24] <infinity> jibel: The RC builds should start spitting out soon now, if you want to remind flavour testers that they're all LTS this time around. :P
[18:25] <infinity> jibel: (especially mythbuntu, who completely forgot at release time...)
[18:44] <tgm4883> infinity: I don't suppose this will include our sru packages still in the queue
[20:28] <Pici> I'm seeing an update for base-files to 7.2ubuntu5.1 in trusty-updates.. which just caused some confusion in #ubuntu. Is this intended?
[20:29] <infinity> Pici: What confusion did it cause?
[20:30] <infinity> Pici: And yes, it's intended.  We're releasing 14.04.1 on Thursday, which means needing to update base-files a bit in advance so we can spin and test images.
[20:30] <Pici> infinity: Well, we sometimes ask people to post the contents of /etc/issue to determine which version of Ubuntu they are running.  Seeing 14.04.1 just threw us for a loop.
[20:30] <Pici> infinity: okay.
[20:30] <infinity> Pici: This happened 4 times in 12.04, you'd think people would be used to it by now. :)
[20:31] <infinity> Pici: If you want a number that never changes, you want 'lsb_release -rs'
[20:31] <infinity> Pici: /etc/issue is purely cosmetic.
[20:31] <Pici> infinity: Yeah, but thats a lot of typing for people who can barely use the terminal.  But thanks :)
[20:37] <infinity> cjwatson: Argh, why didn't we fix the linux-signed-in-live-seed issue? :(
[20:44] <cjwatson> damn, I thought I had
[20:45] <infinity> I'm going to see if there's something I can do that's less painful than the "stop using tasks" thing.
[20:45] <infinity> Though, I guess we need that change for 14.04.2 anyway.
[20:45] <pfsmorigo> hi, what's the diff between 20140722.1 and 20140722 in daily?
[20:45] <infinity> pfsmorigo: The former is newer.
[20:47] <pfsmorigo> infinity: you mean 20140722.1, right? why there isn't ppc64el in it?
[20:48] <infinity> pfsmorigo: For which image?
[20:48] <infinity> pfsmorigo: trusty server?
[20:49] <infinity> Actually, that's a good question.
[20:49] <pfsmorigo> infinity: yep... http://cdimage.ubuntu.com/ubuntu-server/trusty/daily/20140722.1/
[20:49] <pfsmorigo> infinity: I need to check a bug fix. Can I use 20140722?
[20:50] <infinity> pfsmorigo: Depends on which bug.
[20:51] <pfsmorigo> infinity: https://bugs.launchpad.net/ubuntu/+source/debian-installer/+bug/1334649/comments/2
[20:51] <infinity> pfsmorigo: You can test that with a d-i mini.iso
[20:52] <pfsmorigo> infinity: nice!
[20:52] <infinity> pfsmorigo: http://ports.ubuntu.com/ubuntu-ports/dists/trusty-proposed/main/installer-ppc64el/20101020ubuntu318.3/images/netboot/
[20:52] <pfsmorigo> infinity: let me check.. tls
[20:52] <pfsmorigo> s/tls/tks/
[20:54] <infinity> genisoimage: Volume ID string too long
[20:54] <infinity> FFS.
[20:55] <infinity> Indeed, I bet this is why the powerpc ISOs are "ppc" instead of "powerpc".
[20:56] <infinity> cjwatson: Preference on how to cheat here?  s/ppc64el/ppc64/?  s/ppc64el/POWER/?
[20:56] <infinity> cjwatson: Adding ".1" to the string sent it over the edge. :P
[20:56] <infinity> slangasek: ^-- You like to have opinions about this sort of thing.
[21:06]  * infinity will probably just go with ppc64, not terribly confusing on Ubuntu, where we don't have that dpkg arch.
[21:20] <infinity> Well, that's helpful, apt.
[21:20] <infinity> (trusty-amd64)root@cthulhu:~# apt-get install ubuntu-live^ linux-image-3.13.0-24-generic- linux-signed-image-3.13.0-24-generic- linux-image-extra-3.13.0-24-generic- linux-headers-3.13.0-24-generic- linux-headers-3.13.0-24-
[21:20] <infinity> [...]
[21:20] <infinity> The following held packages will be changed:
[21:20] <infinity>   linux-headers-3.13.0-24 linux-headers-3.13.0-24-generic linux-image-3.13.0-24-generic
[21:20] <infinity>   linux-image-extra-3.13.0-24-generic linux-signed-image-3.13.0-24-generic
[21:20] <infinity> In other words, "I heard you, and I'm going to install them anyway, nyah nyah."
[21:26] <infinity> cjwatson: Huh, the plot thickens.  These builds were working in -proposed (ie: not pulling in two kernels), but don't work with proposed turned off.
[21:27] <infinity> That doesn't even make sense...
[21:38] <slangasek> infinity: opinions> I don't know that I'd say I like to have them; they're a cross I bear
[21:39] <slangasek> infinity: if this is for genisoimage volume ID, I'm not sure I really care :) what's the actual limit?
[21:40] <cjwatson> ppc64 would be fine; we use ppc for powerpc
[21:41] <cjwatson> the limit is documented next to the code that does that
[21:41] <cjwatson> I think
[21:42] <cjwatson> oh, it's documented in cdimage/lib/cdimage/project.py
[21:42] <cjwatson> see r1406
[21:43] <cjwatson> infinity: dodgy tasks or something?
[21:44] <infinity> cjwatson: I can't sort out how to reproduce the issue by pulling add_task out of livecd-rootfs and abusing manually. :/
[21:44] <infinity> cjwatson: Then again, the quoting on this makes my head hurt.
[21:46] <infinity> I think it amounts to this, though:
[21:46] <infinity> apt-cache dumpavail | grep-dctrl -nsPackage \( -XFArchitecture amd64 -o -XFArchitecture all \) -a -wFTask ubuntu-live -a --not -Pe "^linux-(headers|image|signed)"
[21:46] <infinity> And I can't get that to give me a kernel with or without proposed enabled.
[21:46] <infinity> Which it shouldn't.
[21:46] <infinity> So, WTF.
[21:47] <cjwatson> if you can wait an hour or two I can look properly
[21:48] <infinity> cjwatson: I'd appreciate it.  It sure looks like you fixed this, so why it's unfixing itself is a mystery to me.
[21:48] <infinity> I might have some breakfast.
[21:48] <cjwatson> infinity: link me the failure while you have it?
[21:48] <infinity> At least ppc64el is fixed.
[21:48] <infinity> cjwatson: https://launchpadlibrarian.net/180527763/buildlog_ubuntu_trusty_amd64_ubuntu_FAILEDTOBUILD.txt.gz
[21:49] <infinity> cjwatson: Compare to success at https://launchpadlibrarian.net/180455287/buildlog_ubuntu_trusty_amd64_ubuntu_UPLOADING.txt.gz
[21:49] <infinity> cjwatson: Or, you know, your stellar UI at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/ubuntu ;)
[21:49] <cjwatson> shush you
[21:49] <cjwatson> I'll fix it at some point :)
[21:49] <infinity> Hey, it works.
[21:49] <infinity> It's just impossible to find.
[21:50] <cjwatson> needs an index of livefses
[21:50] <infinity> cjwatson: The log is twice the size because, unshockingly, linux-headers is all dupe files.  Othwerwise, they're pretty much identical, save proposed/!proposed, and one getting two kernels for no discernable reason.
[21:51] <cjwatson> infinity: it's using the wrong livecd-rootfs version ...
[21:51] <infinity> Well, more than two kernels, two kernels, headers, etc.  So, it really looks like the task filter is failing to filter.
[21:51] <cjwatson> so um argh how do we fix that in time
[21:51] <cjwatson> 2.208 vs. 2.208.1
[21:51] <infinity> Err, so it is.
[21:51] <infinity> Not pulling from -updates. :(
[21:51] <cjwatson> I think I know
[21:51] <cjwatson> It should work if we give it pocket="Updates"
[21:52] <cjwatson> Mostly it doesn't matter, but it does for livecd-rootfs
[21:52] <infinity> It matters in general, IMO, since we want to be able to update our build tools.
[21:52] <infinity> But, in practice, that's usually just livecd-rootfs and live-build, sure.
[21:53] <infinity> So, this bit here:
[21:53] <cjwatson> Right, I mean it doesn't matter for the inside of the livefs
[21:53] <infinity>     if config["PROPOSED"]:
[21:53] <infinity>         kwargs["pocket"] = "Proposed"
[21:53] <infinity>         metadata_override["proposed"] = True
[21:53] <infinity>     else:
[21:53] <infinity>         kwargs["pocket"] = "Release"
[21:53] <cjwatson> Right, I'm just fixing that
[21:54] <cjwatson> config["DIST"].is_latest is the relevant thing, so it stays Release for utopic but goes to Updates for <utopic
[21:54] <infinity> Mangling it to just hardcode precise, trusty for now?
[21:54] <infinity> Ahh, or that.
[21:54] <infinity> Much cleaner.
[21:54] <cjwatson> infinity: try now
[21:54]  * infinity retries ubuntu-desktop
[21:55] <infinity> Will do the rest when this appears good.
[21:55] <cjwatson> re dupe files, I canned that in utopic, just not in trusty
[21:55] <cjwatson> because we haven't cared for years
[21:55] <infinity> It's an interesting metric, but only if someone actually reads it.
[21:55] <infinity> It's just useless data in the wind otherwise, and a waste of CPU time.
[21:55] <cjwatson> More to the point, it can be computed latr.
[21:56] <cjwatson> *later
[21:56] <infinity> True, that too.  Could be a QA test.
[21:56] <cjwatson> Yeah, we could stick it on ci.ubuntu.com if we felt like it.
[21:56] <cjwatson> I don't think anyone cares enough though
[21:57] <infinity> Well, it was an interesting metric that led to things like pkgbinarymangler deduping copyright/changelog, etc.
[21:57] <infinity> Though, not sure if the livefs builds were directly responsible, or just someone saying "look, that's pointless duplication".
[21:57] <infinity> But a QA/CI read on pointless duplication wouldn't go amiss.
[21:58] <infinity> Both exact duplication (identical files, like fdupes was telling us), and suspicious possible duplication (multiple versions of libfoo[0-9] installed, for instance) would be interesting.
[22:15] <infinity> tgm4883: Sorry, missed your question in the dramatic backscroll there.
[22:15] <infinity> tgm4883: Which packages were you curious about?
[22:18] <tgm4883> infinity: we've been trying to SRU the mythtv packages, but haven't had any comments in about a month now  https://bugs.launchpad.net/ubuntu/trusty/+source/mythtv/+bug/1323391
[22:19] <tgm4883> I don't want to just ping this room every day, but I don't know what else to do
[22:20] <infinity> tgm4883: Hrm, the last comment there implies that there's a 0.27.2 around the corner.
[22:21] <phillw> hi, could some make the builds for the rest of lubuntu builds? This will be .2 builds?...
[22:21] <tgm4883> infinity: While that is true, since we weren't getting any comments on that we didn't want to have to start the process over by uploading a new one
[22:21] <infinity> tgm4883: Anyhow, short answer, no that won't be able to make the point release ISO, even if I review and accept it today.  But yes, we should push forward with this, and users can upgrade post-install.
[22:21] <tgm4883> infinity: ok, should I upload the latest point release then?
[22:22] <infinity> phillw: I'll rebuild lubuntu in a second after we verify our amd64 fix is happy.
[22:22] <tgm4883> I mean, we really only planned on doing this (SRU's) for point releases, but yes we should give them something they can upgrade to
[22:23] <infinity> tgm4883: I think moving to the latest point release is smart, but we also need to review this fairly extensively (though, I think ideally, we'll want to get you guys to apply for an MRE for this).
[22:23] <infinity> tgm4883: "For point releases" is somewhat meaningless anyway, a package upgrade is an upgrade, if it's on an ISO only really matters if it affects the installation.
[22:23] <tgm4883> infinity: I thought MRE's were only needed for packages with new features?
[22:23] <phillw> infinity: thanks.. sorry to be the person here... our TL is just back from a meeting and our other Release manager is at osscon
[22:24] <infinity> tgm4883: No, the point of an MRE is to say "there's extensive upstream QA on this, and lots of changes and we're not going to test every single commit/fix in Ubuntu to verify it".
[22:24] <tgm4883> infinity: that is true, but many of our users treat our distro as an appliance. Which means install it and forget it (for better or worse)
[22:24] <infinity> tgm4883: Without an MRE, you need to enumerate every single upstream change and validate each one.
[22:24] <tgm4883> infinity: ah ok. Is there documentation for doing an MRE, I'm only aware of what superm1 gave me, which is the SRU documentation
[22:24] <cjwatson> https://wiki.ubuntu.com/StableReleaseUpdates/MicroReleaseExceptions
[22:24] <tgm4883> (I can go looking for it too)
[22:25] <infinity> ^
[22:25] <tgm4883> reading it now
[22:25] <infinity> tgm4883: Cause, yeah, this 480K diff isn't something any of us can realistically review properly, not something you guys can realistically QA properly.  So, we need to rely on assurances that it's already sane before uploading (hence the MRE concept).
[22:26] <infinity> s/not something/nor something/
[22:26] <tgm4883> infinity: that makes sense.
[22:27] <phillw> infinity: do you if jluien got his SRU's in, in time for our bugs on lubuntu?
[22:27] <phillw> *do you know*
[22:27] <infinity> phillw: No idea, since I don't know which those were.
[22:29] <phillw> infinity: bug 1326740 and bug 1308348
[22:29] <cjwatson> if you have the bug numbers, you can look at the bug states
[22:30] <phillw> cjwatson: both say fix released... will they be in the .1 release?
[22:30] <cjwatson> that would imply yes
[22:30] <infinity> phillw: If they were Fix Released before, uhm, now, then yes.
[22:31] <infinity> phillw: Since I already pointed out that I was going to respin everything. :)
[22:32] <phillw> infinity: it was close to time called, julien is busy after a conference, so I'm a bit stuck on witing up a set of release notes... any crumbs would be apprreciated :D
[22:32] <phillw> infinity: Ahh, but are they in the list :P
[22:33] <infinity> The List?
[22:34] <phillw> the list of SRU's / bug fixes approved?
[22:34] <infinity> phillw: If it's Fix Release, it's in The List.  We build from -updates, we don't hand pick packages to update.
[22:36] <phillw> infinity: thanks... was not too sure how the diffeence between  'fix relased' and 'SRU'
[22:36] <phillw> We had 'fix released' but were told it then needed an SRU
[22:37] <infinity> phillw: It's Fix Released *in trusty* that's the important bit here.   I still do care :)
[22:40] <cjwatson> infinity: \o/
[22:44] <phillw> infinity: have you respun the world now?
[22:45] <infinity> phillw: That was just Ubuntu, not the world, but the world will now follow. ;)
[22:45] <phillw> when can the lubunteers expect images (we have alt and desktop)
[22:46] <infinity> And they're off.
[22:46] <phillw> oh, and as you know, when we've done ours, we always help out other flavours :)
[22:47] <infinity> phillw: Probably 1-2h for everything to be done.
[22:47] <phillw> I'll try to hang on for at alts.... they will hopefully be a quick zsync unless you guys have done some thing major?
[22:48] <infinity> And once these are all happy, I'll re-enable the flavour self-service stuff.
[22:48] <phillw> infinity: both of who are afk.... c'est la vie :)
[23:50] <phillw> infinity: lubuntu builds done, or still queued?
[23:51] <cjwatson> phillw: https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/trusty/lubuntu/+build/2646
[23:51] <cjwatson> it got a slower builder on powerpc, but making progress
[23:52] <infinity> phillw: Alternates are done, desktop are in progress, as cjwatson points out.
[23:52] <phillw> Ill start off with alternates :)
[23:52] <phillw> thanks


[00:14] <babbageclunk> review anyone? https://github.com/juju/juju/pull/11343
[01:22] <kelvinliu> babbageclunk: lgtm
[01:23] <babbageclunk> thanks kelvinliu
[01:23] <kelvinliu> np
[05:06] <wallyworld> jam: forgot to ask - the jujuc  PR - you looking to land that? w can then ensure it's incorporated into the release etc
[05:33] <wallyworld> jam: here's a race fix for the query tracker. i am not across the original design consideration for not allowing for concurrent access but i think it's necessary to have the mutex https://github.com/juju/juju/pull/11344
[09:14] <stickupkid> manadart, do us a solid and CR this https://github.com/juju/os/pull/20
[09:18] <manadart> stickupkid: Yep.
[09:20] <flxfoo> hi all,
[09:22] <flxfoo> We are using rackspace, somehow they change an OS image, now whatever deploy I tried an error raised up as "image not found" or so... `juju cached-image` return an empty list... is there a possibility to tell juju to use another image ID?
[09:28] <stickupkid> flxfoo, I'm totally not sure on this and someone will probably confirm that, but you may want to look into https://jaas.ai/docs/cloud-image-metadata
[09:29] <stickupkid> manadart, I'd agree, I guess this is a much better improvement over the older way, let me fix
[09:29] <manadart> stickupkid: Cool.
[09:49] <flxfoo> stickupkid: thanks, will have a look
[10:27] <flxfoo>  stickupkid , yeah I folllowed a bit the tutorial, and kind of generate some yaml files to describe the image to be used, but it seems that I can not really "update" rackspace, except bypassing it and setup a webserver which would serve the image definition to use, which seems very unlikely for me to do so...
[10:27] <flxfoo> anyone had deal with rackspace here before?
[10:43] <manadart> stickupkid: https://github.com/juju/juju/pull/11345
[10:48] <stickupkid> manadart, we have to support trusty right?
[10:48] <flxfoo> a related question would be, which provider are you guys using, which would fully support `juju` ?
[10:49] <stickupkid> flxfoo, aws, gce, lxd, maas, azure
[10:49] <stickupkid> vsphere
[10:50] <stickupkid> manual (which is to say, BYOS)
[10:50] <manadart> stickupkid: ESM, yes.
[10:50] <stickupkid> you tried bootstrapping with trusty ;-)
[10:50] <manadart> stickupkid: Not lately.
[10:51] <stickupkid> you should it's fun
[10:54] <stickupkid> manadart, https://github.com/juju/juju/pull/11346
[10:55] <stickupkid> manadart, I'll make a bug around trusty deployment
[10:55] <manadart> stickupkid: `failed to start mongo`?
[10:55] <stickupkid> yeah
[10:57] <stickupkid> manadart, https://bugs.launchpad.net/juju/+bug/1868545
[10:57] <mup> Bug #1868545: Failed to bootstrap trusty <juju:Triaged> <https://launchpad.net/bugs/1868545>
[10:57] <stickupkid> manadart, I've put it as critical, you can change if required, but seems like we should fix asap
[11:23] <flxfoo> stickupkid: thanks
[11:24] <flxfoo> stickupkid: I mean rackspace is in the list of juju supported platform but obviously there are some holes here and there :p
[11:24] <stickupkid> flxfoo, others might have different mileage, but I do know that's what I'm testing day in day out
[11:26] <flxfoo> stickupkid: ok thanks, for example I have a problem with rackspace not supporting network namespace which makes some charm relation not working between our webservers/perconas...
[12:07] <manadart> stickupkid: https://github.com/juju/juju/pull/11347 No conflicts.
[14:40] <stickupkid> manadart, https://github.com/juju/juju/pull/11348
[14:41] <stickupkid> manual CI tests
[14:42] <manadart> stickupkid: Timely. Swap you https://github.com/CanonicalLtd/juju-qa-jenkins/pull/405
[14:47] <rick_h_> ty for that manadart, was going to try to do that today after the discussions last week
[15:00] <manadart> stickupkid: Keep getting this: https://pastebin.canonical.com/p/QndmtYgsPK/
[15:00] <manadart> Test log says too many auth failures for SSH
[15:08] <achilleasa> hml: left some comments in 11342
[15:08] <stickupkid> manadart, do you wildcard your id_rsa to all hosts in ~/.ssh/config
[15:08] <hml> achilleasa:  rgr
[15:09] <stickupkid> manadart, if you do then it won't work because it doesn't know which ssh id to use. And juju doesn't say (we should pass -K) when doing ssh stuff I believe
[15:11] <stickupkid> manadart, I'll update to remove the profile, good spot
[15:20] <manadart> stickupkid: Removed my wild-carding. Same.
[15:42] <stickupkid> manadart, you have to restart your agent
[15:42] <stickupkid> manadart, i had the same thing last week, can't remember how I bounced it
[15:59] <manadart> stickupkid: I got it. I have a user systemd service for starting my agent.
[16:00] <stickupkid> yeah, bounce it
[16:03] <stickupkid> manadart, I do wonder how this hasn't be hit before, I'm sure juju could be smarter around ssh
[22:50] <tlm> hey babbageclunk, do you have 5 minutes to help me figure out how something works ?
[22:50] <babbageclunk> tlm: sure sure - in standup?
[22:51] <tlm> ok, give me 2 minutes to login and 2fa
[22:51] <babbageclunk> ok
[23:10] <tlm> mismatch at .CertGetter: non-nil functions; obtained (func() *tls.Certificate)(0x1b17a30); expected (func() *tls.Certificate)(0x1b17a30)
[23:10] <tlm> appears deep equals doesn't do functions very well
[23:34] <babbageclunk> tlm: oh yeah, it doesn't - typically we nil them out before the comparison.
[23:35] <babbageclunk> tlm: if you're feeling especially diligent you can try calling it to check that it's the right one (possibly overkill)
[23:37] <tlm> cheers babbageclunk, just rubber ducked it with hpidcock. I can't nil them because the dependency stuff complains. Checked our chehck lib and it doesn't implement functions for deep equals. Just going to fix the problem there
[23:37] <babbageclunk> no, I mean, nil it out before the DeepEquals in the test
[23:37] <tlm> um
[23:37] <tlm> that might work
[23:37] <tlm> let me check
[23:38] <hpidcock> ahh that was what I meant by nil it before the check
[23:38] <babbageclunk> oh right - yeah, if you want to fix it in the library that would be cool too
[23:38] <babbageclunk> (not sure how difficult that is)
[23:38] <hpidcock> but yeah fix the library and I'll +1 it
[23:38] <tlm> I figure if they are of the same type and the pointers match they are the same thing
[23:39] <hpidcock> "If v's Kind is Func, the returned pointer is an underlying code pointer, but not necessarily enough to identify a single function uniquely. The only guarantee is that the result is zero if and only if v is a nil func Value. "
[23:39] <hpidcock> this may be the problem
[23:41] <hpidcock> tlm: ^
[23:41] <tlm> yeah just reading, got it working with nil but I feel dirty
[23:42] <hpidcock> nah all g
[23:42] <wallyworld_> hpidcock: in api client IssueOperatorCertificate, "{Tag: applicationName}" should be {Tag: names.NewApplicationTag(applicationName).String()}
[23:43] <hpidcock> tlm: does the certgetter function need to be called in this test case?
[23:43] <hpidcock> because what you can do is compare the functions by calling them like babbageclunk said
[23:44] <hpidcock> the function could panic("testing the function") and the test just recover()
[23:45] <hpidcock> then nil it
[23:45] <hpidcock> do the DeepEquals
[23:45] <tlm> nope
[23:45] <tlm> nil it is
[23:46] <tlm> thanks hpidcock and babbageclunk. Doing some reading we could compare pointers of the values but that is not a deep equals
[23:46] <hpidcock> wallyworld_: is that where the Unauthorized is coming from?
[23:46] <wallyworld_> not sure, depends on how the apiserver side unpacks it
[23:46] <wallyworld_> i didn't look
[23:48] <babbageclunk> hpidcock, tlm: yup, or just something that returns a unique value, or sets some closed-over variable when called.
[23:48] <babbageclunk> (I mean, if you control what the function being passed in is)
[23:49] <wallyworld_> hpidcock: server side unpacks the "right" way for what's passed in, but should be a tag. i can do a driveby fix
[23:50] <hpidcock> wallyworld_: all good I'm in the area
[23:50] <hpidcock> I'll fix it with my changes
[23:50] <wallyworld_> ok, i'm working on OperatorProvisioningInfo()


[06:06] <InHisName> I go away for 2 days and NOBODY types a single letter ?? !! ??
[09:35] <rmg51> Morning
[10:52] <JonathanD> Hi.
[11:08] <rmg51> o/
[11:59] <InHisName> Morning
[12:01] <JonathanD> Howdy.
[12:10] <teddy-dbear> Morning peoples, dogs, turkeys and everything else
[12:25] <InHisName> Morning tables, chairs, keyboards, mice, monitors, computer tables, stuffed bears.
[14:11] <MutantTurkey> well I woke up today, got on the bus aned was at work in 15 minutes!
[14:12] <MutantTurkey> it's awesome!!!
[18:08] <ChinnoDog> gobble
[19:20] <ChinnoDog> so hungry
[19:25] <jedijf> i just went through that - did 2 stalks of celery and some almonds and a tootsie roll
[19:26] <pleia2> I had scrambled eggs and turkey bacon
[19:26]  * TheLordOfTime just finished two plates of stir-fry
[19:27] <ChinnoDog> jedijf: what a meal. lol
[19:27] <ChinnoDog> turkey bacon... an abomination
[19:27] <ChinnoDog> I located an apple and put some peanut butter on it
[19:27] <jedijf> that was one of my options
[19:28] <jedijf> actually considered nutella'ing the celery
[19:28] <jedijf> then i remembered that i hate nutella
[19:28] <ChinnoDog> mmm, nutella. Too much sugar though.
[19:29] <jedijf> ChinnoDog: it's after noon - aren't you cheating?
[19:30] <ChinnoDog> I abandoned that.   Or more.
[19:46] <InHisName> Ummm, make that 10.
[19:47] <jedijf> i roasted it last week-but that was too much work comapred to steaming in microwave
[23:03] <MobileTurkey> do you guys know how to forward a computer connected to my ethernet port to my wifi?