[00:08] <nacc> jgrimm: https://code.launchpad.net/~usd-import-team/ubuntu/+source/at/+git/at
[00:18] <pdeee> RAOF, hlieberman picking up the conversation about a xenial update to Certbot:
[00:18] <RAOF> pdeee: Hi!
[00:18] <pdeee> Hi!
[00:19] <pdeee> (we have to distract ourselves from depressing news today)
[00:19] <RAOF> I'm going to get a coffee right now, but I'll be back in 5 :)
[00:19] <pdeee> RAOF, okay, I'll give you a status update then go and get a coffee :)
[00:19] <pdeee> Certbot 0.9.3 is now in zesty
[00:19] <pdeee> However, the team has identified a few reasons why they might want to wait for 0.10.0 if the updates process is sufficiently complex and time consuming
[00:20] <pdeee> It both includes a couple of important bugfixes, and also a couple of very valuable features we'd want Xenial users to have
[00:20] <pdeee> However, there's one noteworthy way in which 0.10.0 alters workflows
[00:20] <pdeee> in a subjective if not substantive way
[00:21] <pdeee> in particular, the dialog-based user interface has been removed
[00:21] <RAOF> Hm.
[00:23] <pdeee> (because it was both mysteriously rendering in broken ways when sshing into some servers, and because of weird annoying bugs like these:
[00:23] <RAOF> That doesn't particularly scream “let's push this as a bugfix only release to all our most conservative users”.
[00:23] <pdeee> https://github.com/certbot/certbot/issues?q=is%3Aissue+dialogerror+is%3Aclosed
[00:24] <pdeee> So running Certbot 0.10.0 will be like running Certbot 0.9.3 with -t
[00:25] <RAOF> So, the SRU process for 0.9.3 shouldn't be terribly onerous.
[00:26] <pdeee> But you think it would be harder for 0.10.0?
[00:26] <RAOF> I'd be more hesitant to SRU something that drops a previous UI, yes.
[00:26]  * pdeee nods
[00:27] <RAOF> I understand that this is not ideal for you - or, even, for new users - but if existing users have successfully used the dialog UI then they haven't been hitting the bugs in it, and removing it breaks whatever documentation they've put into place.
[00:28] <RAOF> (We're meant to be the ones getting all the bugs related to the dialog UI, but that doesn't always end up being the case)
[00:28] <pdeee> And, if you were going to score the strength of this objection out of ten, how high would you score it?
[00:29] <RAOF> Off hand, I'd probably put it at a 7 or so?
[00:29] <pdeee> Here are some examples of the dialog bugs:
[00:29] <pdeee> https://github.com/certbot/certbot/issues/2025
[00:30] <RAOF> What does the new text interface look like?
[00:30] <pdeee> RAOF, do you have a copy of Certbot?
[00:30] <pdeee> If so, run it with -t
[00:30] <pdeee> if not, I can screenshot you something
[00:31] <pdeee> (Certbot on Zesty or Yakkety)
[00:31] <RAOF> Hm. I can run it, but it fails immediately because I don't have a webserver on this laptop.
[00:31] <pdeee> okay, I'll screenshot
[00:32] <RAOF> To
[00:32] <RAOF> Ta
[00:35] <pdeee> https://isnot.org/certbot-t.jpg
[00:36] <RAOF> Ah, cool.
[00:37] <RAOF> So, I'm still hesitant; I'd start a discussion with the rest of the SRU team about that.
[00:37] <RAOF> But I'm happy to sponsor 0.9.3 into xenial- (and yakkety-) proposed.
[00:38] <RAOF> We can easily do that in parallel.
[00:42] <pdeee> okay, nice
[00:42] <pdeee> our team had concluded that we should work to switch the instructions we provide at https://certbot.eff.org from Xenial packages to pointing folks toward a PPA,
[00:42] <pdeee> but if the SRU is fairly easy I think we can stick with that
[00:43] <nacc> mdeslaur: is it just me or did bind9 get a security update in y that it didn't get in z? 1:9.10.3.dfsg.P4-10.1ubuntu1.1
[00:43] <pdeee> btw, if you want to play with Certbot on a box with no webserver, the following invocations should work:
[00:43] <pdeee> sudo certbot certonly --standalone # bind to a port to prove control of a domain
[00:45] <pdeee> sudo certbot certonly --manual # manually prove control of a domain. Can also be run as non-root with some extra flags
[00:45] <pdeee> You can add -t to the 0.9.3 command line to see how things will look in 0.10.0
[00:46] <sarnold> pdeee: just out of curiosity, could you amend the eff.org instructions to tell people to pass the -t option?
[00:47] <pdeee> sarnold, in all cases or just some?
[00:48] <pdeee> Do you mean, as a way to get that result without changing our code?
[00:48] <sarnold> pdeee: yeah
[00:49] <sarnold> like the sru sounds useful, but adding a -t to instructions sounds easier, and most people copy-paste things anyway :)
[00:54] <pdeee> sarnold, I think our dev team was keen to close all the dialog-related bugs, and remove that extra dependency and complexity from the code
[00:54] <pdeee> I meant to paste a few of the dialog bugs, but got interrupted:
[00:54] <sarnold> pdeee: hehe with that list of bugs I can certainly see why :)
[00:54] <pdeee> https://github.com/certbot/certbot/issues/2025
[00:55] <pdeee> https://github.com/certbot/certbot/issues/3764
[00:55] <pdeee> Providing instructions in one place, even the most prominent place, to use -t wouldn't actually get the word out to all of our users
[00:56] <pdeee> Personally, I would have kept dialog in place and switched the default, but others on the team are more focused on simplicity than I am, and I'm happy for them to overrule me :)
[00:57] <pdeee> However, I'll say this:
[00:57] <pdeee> if Ubuntu really wants to keep dialog as the default, we could consider going back to that plan
[00:57] <pdeee> then Ubuntu could flip the default back to "dialog" on Xenial
[00:58] <pdeee> I think folks would be unhappy with that stuff staying in the tree, and the complexity of some users having Certbot behave differently than others, but they might live with it.
[00:59] <pdeee> I think the prevailing view is, "let's get this to the place we want it to be, then call it 1.0.0 -- until then, it's in beta, expect a few [nonbreaking] changes"
[01:10] <mdeslaur> nacc: I usually wait to sync from debian...but it looks like it's not in debian yet....I'll upload it to Z tomorrow, thanks
[01:11] <nacc> mdeslaur: np, i was just updating a PPA for a bugfix-test and noticed
[01:13] <RAOF> pdeee: That's a perfectly sensible approach; we've just already declared it 1.0 downstream by shipping it in 16.04 LTS :)
[01:16] <jgrimm> thanks nacc!
[01:16] <pdeee> RAOF, :)
[01:26] <RAOF> pdeee: So, I guess to move this onto actionable items: who is going to dedicate some time to SRUing 0.9.3?
[01:27] <pdeee> I can if hlieberman doesn't have cycles
[01:27] <pdeee> or he and I can work on it together
[01:27] <pdeee> but presumably we'll also need a Canonical / Ubuntu person
[01:29] <pdeee> Do you need us to compile a list of High Impact Bugs?
[01:29] <pdeee> Do you additionally need us to list new features?
[01:29] <pdeee> (of the sort that may be important enough to warrant inclusion)
[01:31] <pdeee> Or would a list of fixed bugs be sufficient?
[01:31] <sarnold> this template ought to guide what'd be most useful https://wiki.ubuntu.com/StableReleaseUpdates#SRU_Bug_Template
[01:34] <pdeee> sarnold, if I filled that out once for every important bug we've closed, it would be a very long document
[01:34] <pdeee> will it be okay to provide a narrative, "we fixed these kinds of bugs, <links to lots of examples>",
[01:34] <RAOF> Are you aware which bugs on launchpad are fixed in 0.9.3?
[01:35] <pdeee> <These are the steps we took in general to prevent regressions of any sort>
[01:35] <pdeee> RAOF, a couple, but mostly bugs are filed with our github repo rather than launchpad, even for xenial packages
[01:36] <pdeee> I can of course make some Launchpad bugs for you, though that's more work :)
[01:46] <RAOF> pdeee: Not really any need for launchpad bugs; it's nice if you can identify some of them, you don't need to have one per issue fixed.
[01:48] <smoser> nacc, am i doing something wrong ?
[01:48] <smoser> $ time ./bin/usd -h >/dev/null
[01:48] <smoser> real	0m3.248s
[01:48] <smoser> user	0m0.560s
[01:48] <smoser> sys	0m0.044s
[01:49] <nacc> smoser: no, i think there's an issue with one of the constructors
[01:49] <nacc> smoser: i need to debug it still
[01:50] <nacc> smoser: i got it functional first :)
[01:50] <nacc> smoser: i think i need to defer one of the init steps for the importer object
[01:50] <smoser> and i think i suggest renaming '__main__' to just 'main'. then you can do things like: python3 -m  usd.main (or even add __main__ to the 'usd')
[01:51] <nacc> smoser: interesting, ok -- i read somethjing that setuptools uses that specific naming
[01:51] <nacc> smoser: but i trust your knowledge
[01:51] <smoser> oh. silly. you did do that interestingly.
[01:51] <smoser> ah. well,
[01:51] <smoser> python -m usd
[01:51] <smoser> er... python3 -m usd
[01:51] <smoser> does work because usd.__main__
[01:51] <RAOF> pdeee: So, next steps would be to (a) file a launchpad bug along the lines of “please SRU 0.9.3 to xenial and yakkety” with the justification and some details of the testing done, (note that xenial has letsencrypt 0.4, and so predates certbot) and (b) prepare the Debian packaging for those SRUs - which will start with a copy from zesty's 0.9.3 packaging, and add a changelog entry mentioning at least the SRU bug and preferably the other LP bugs
[01:51] <RAOF> fixed.
[01:51] <smoser> i'd not seen it done like that. but ok.
[01:52] <nacc> smoser: :)
[01:52] <nacc> smoser: magic!
[01:58] <RAOF> pdeee: Oh, and I'm happy to sponsor the upload of the packaging to *-proposed.
[01:58] <nacc> jgrimm: i submitted a build that should fix heimdal in -proposed, and sent the patch to debian
[01:59] <pdeee> great okay I'm preparing a template; I will file a bug containing it, and ask hlieberman to do the packaging work
[01:59] <pdeee> which sounds pretty minimal
[02:00] <pdeee> and then be back in touch
[02:01] <smoser> nacc, http://paste.ubuntu.com/23453623/
[02:01] <smoser> still crashes with ./bin/usd clone cloud-initramfs-tools
[02:01] <smoser> but through a couple failures :)
[02:06] <nacc> smoser: http://paste.ubuntu.com/23453650/
[02:07] <nacc> smoser: with that and passing -l nacc, it works
[02:08] <nacc> pushed up
[02:09] <nacc> smoser: fixed the lp prompt case too
[02:11] <smoser> nacc, AttributeError: module 'os' has no attribute 'getwcd'
[02:12] <smoser> getcwd not getwcd
[02:12] <nacc> smoser: fixed and pushed
[02:12] <smoser> AttributeError: 'int' object has no attribute 'encode'
[02:12] <smoser> :)
[02:12] <smoser> i got to run
[02:12] <nacc> yeah that's the input returning 0 for some reason
[02:12] <nacc> smoser: i'll fix that tmrw
[02:12] <smoser> later.
[02:13] <nacc> smoser: fixed, fwiw, pushed
[02:19] <nacc> jgrimm: heimdal built successfully, hopefully it migrates now
[06:30] <cpaelzer> good morning
[07:12] <pitti> Good morning
[07:44] <mwhudson> pitti: morning
[07:44] <pitti> hey mwhudson, how are you?
[07:44] <mwhudson> pitti: just curious really, but wondering where routes: support in netplan is on your roadmap?
[07:44] <mwhudson> pitti: good, spent a while learning all about netlink which is fun but doesn't feel very 21st century somehow :)
[07:47] <pitti> mwhudson: more like the good old assembly days? :-)
[07:48] <mwhudson> not quite that bad, but definitely more C than nodejs :)
[07:48] <pitti> mwhudson: routes: is a work item (the last remaining one that concerns netplan itself, in fact)
[07:49] <pitti> mwhudson: indeed, it's 2016, give us a kernel written in JS already!
[07:49] <pitti> make the kernel great again!
[07:49] <pitti> (sorry..)
[07:49] <mwhudson> heh
[07:49] <mwhudson> pitti: oh cool (routes: being the last netplan thing missing)
[07:49] <pitti> mwhudson: so, I haven't thought about some syntax or use cases for this yet -- do you have one?
[07:50] <mwhudson> pitti: only overriding the default route i think
[07:50] <pitti> mwhudson: that already exists
[07:50] <mwhudson> pitti: gateway4/gateway6?
[07:50] <pitti> mwhudson: i. e. gateway[46]:
[07:51] <mwhudson> hm, that's only per-interface isn't it?
[07:51]  * mwhudson doesn't understand networking configuration use cases very well though
[07:51] <pitti> right, but that's what they conceptually are anyway
[07:52] <pitti> i. e. there is no "free floating" default route by default, all default routes are attached to some interface (AFAIUI)
[07:53] <pitti> mwhudson: that might be a bit confusing, let me try again
[07:54] <pitti> mwhudson: so, an interface can add a route to <IP_ADDRESS>/0 (IOW the "default" route) via a given IP
[07:54] <mwhudson> no that makes sense i think
[07:54] <pitti> mwhudson: and all routes have a metric
[07:54] <pitti> mwhudson: so if the kernel needs to route a packet to an IP which doesn't have a more specific route, it picks the default route amongst the above set with the lowest metric
[07:55] <mwhudson> pitti: afk for a few mins
[07:55] <pitti> which is really just the same algorithm as for picking the "most specific" route
[09:02] <pitti> happyaron: hey, how are you? I was wondering how the NM 1.4 update was coming along?
[09:35] <happyaron> pitti: hey, guess tommorrow. or by next Mon
[13:10] <cpaelzer> is there a better way than "uploading to archive and crossign fingers" after writing a new dep8 test to run it on "the other archs"?
[13:11] <cpaelzer> I wonder if that is the day I could/should use bileto the first time and check if permissions actually work
[13:16] <rbasak> I feel that pain too. I'm not sure how to use Canonical's porterboxes for dep8 test testing.
[13:17] <rbasak> (they seem a bit too locked down for that)
[13:22] <rbasak> mdeslaur: FYI, taking your TIL lock on the squid3 merge.
[13:22] <cpaelzer> I mean I can technically do ppc64el and s390x due to being lucky and only cross fingers for arm
[13:22] <cpaelzer> uh wait s390 had issues
[13:22] <cpaelzer> time to check that again with all updates
[13:26] <mdeslaur> rbasak: ack, thanks
[13:28] <cpaelzer> pitti: are you sure on that reject of the dovecot SRU?
[13:29] <cpaelzer> pitti: 2.2.22-1ubuntu4 never (really) went into the archive nor did 2.2.22-1ubuntu3
[13:29] <cpaelzer> pitti: last SRU was 1:2.2.22-1ubuntu2.1
[13:29] <cpaelzer> pitti: Refering to "Rejected by Martin Pitt: needs to rebase against 1:2.2.22-1ubuntu4"
[13:39] <xnox> cpaelzer, rbasak - go to https://bileto.ubuntu.com/ request new ppa; add source package name; click build that creates ppa; upload into said ppa; and it will run autopkgtests on all arches and report britney results too (for uninstalability)
[13:39] <xnox> that's what i do.
[13:40] <xnox> it runs the tests on the same infra as the proposed-migration autopkgtests.
[13:40] <cpaelzer> xnox: thats what we talked about a few months ago, and sil2100 was so kind to check if it could be set up for non-core dev
[13:40] <cpaelzer> I guess it is the day then
[13:40] <cpaelzer> I'll poke #ubuntu-ci-eng with questions if I have some
[13:40] <xnox> cpaelzer, if you need sponsoring, i'm happy to upload experimental things into bileto ppas =)
[13:41] <sil2100> Yeah
[13:41] <xnox> cpaelzer, sil2100 - honestly using bileto ppas for experimental builds is totally fine, even if you do say in description "will be abandonned"
[13:42] <sil2100> Sure, Bileto PPAs are also for this since we have ephemeral PPAs now, so yeah
[13:52] <pitti> cpaelzer: hm, they exist in https://launchpad.net/ubuntu/+source/dovecot/1:2.2.22-1ubuntu3 and https://launchpad.net/ubuntu/+source/dovecot/1:2.2.22-1ubuntu4, but I guess that was a very confusing case then
[13:52] <cpaelzer> pitti: yes, in september we did the 2.1 SRU
[13:52] <cpaelzer> pitti: if wrong it was wrong there already :-/
[13:53] <cpaelzer> pitti: can you un-reject the upload or is the case worse and we need to clean up even more?
[13:53] <pitti> cpaelzer: no, I can generate a real diff manually and accept from rejected
[13:54] <cpaelzer> pitti: ok, I'll do nothing on this case then; unless you tell me to do so - ok
[13:54] <cpaelzer> ?
[13:55] <pitti> cpaelzer: should be all good now; sorry for the trouble
[14:00] <cpaelzer> pitti: thank you for sorting out, no reason to excuse at all
[14:00] <cpaelzer> pitti: it is a weird case
[14:14] <ogra_>  Err:1 http://ports.ubuntu.com/ubuntu-ports xenial/universe armhf libtext-unidecode-perl all 1.27-1
[14:14] <ogra_>   403  Forbidden [IP: <IP_ADDRESS> 80]
[14:14] <ogra_> wow
[14:14] <ogra_> whats that ?
[14:15] <pitti> ogra_: since Trump it is forbidden to write new software in Perl!
[14:15] <ogra_> LOL
[14:16] <dobey> ogra_: it's an issue with the ports server it would seem. i'd say bug IS
[14:18] <ogra_> well, looks like the Packages file is out of sync with the actual archive content
[14:18] <ogra_> http://ports.ubuntu.com/ubuntu-ports/pool/universe/libt/libtext-unidecode-perl/
[14:19] <ogra_> weird
[14:19] <ogra_> (the files in that dir are from 2005 and 2008)
[14:20] <ogra_> aha
[14:20] <ogra_> and now the dir updated
[14:20] <ogra_> yep ... and it works ... weird
[14:20] <ogra_> smells racy
[14:30] <Laney> ogra_: weird that it gives a 403 and not a 404
[14:30] <Laney> it's not updated here
[14:30] <pitti> ogra_, Laney: presumably one of the mirrors is out of date, and you just hit that one (or not) at random?
[14:31] <Laney> I tried from a few boxen
[14:31] <persia> Is the feed to ports.u.c still managed by ubumirror?  If so, it's (intentionally) racy w.r.t content vs. packages files, but the intended raciness should avoid the situation described above.
[14:32] <Laney> but us.ports.ubuntu.com works
[14:32] <persia> That would be mirrored from ports.u.c, rather than from the internal all-arches true master archive.
[14:33] <Laney> I don't know that ports is even round robin
[14:33] <Laney> persia: This particular package hasn't changed in $ages
[14:33] <persia> (unless mirroring is very different than my memory.  I'll stop blathering now, in case it has changed)
[14:34] <ogra_> Laney, well, it magically started working, pitti might be correct
[14:35] <Laney> ogra_: It's all guessing isn't it
[14:35] <ogra_> yep
[14:36] <Laney> what IP are you getting?
[14:36] <ogra_> <IP_ADDRESS> was the one that did not work initially ...
[14:37] <pitti> same as me
[14:37] <ogra_> and i get the same when pinging now
[14:37] <pitti> maybe that's just a load balancer
[14:37] <ogra_> so it was the same server
[14:38] <xnox> pitti, i would vote for such policy =)
[14:38] <Laney> Then one of the backends is broken
[14:39] <Laney> I'll go ask, since nobody else wants to
[15:05] <Laney> (being debugged, FYI)
[15:34] <smoser> pitti, your comment 27 on bug 1636912
[15:36] <smoser> 'drop "Wants=networking.service"' .  What we have there is 'After=networking.service'
[15:36] <smoser> and i think that is necessary or we wont run after ifup has been done..
[15:37] <rharper> smoser: we also had Requires=networking.service
[15:37] <rharper> smoser: IIRC, there's a built in wants for networking.service via /etc/systemd/system/network-online.target
[15:37] <smoser> right..
[15:37] <rharper> so, ifupdown will run if installed
[15:37] <rharper> when means we should be able to just say After for ordering
[15:38] <smoser> right, but by not Wanting it we dont force it to run otherwise.
[15:38] <rharper> correct
[15:38] <smoser> the other thign that Require did (which is why i used it) is it says "It ran and succeeded"
[15:38] <smoser> After just says "it ran"
[15:38] <rharper> correct
[15:38] <pitti> smoser: right, sorry, I meant "Requires=", not "Wants="
[15:38] <smoser> so thats less than ideal, but maybe ok.
[15:39] <rharper> but if we have an either networking or networkd;  we'd like to say that either ran and which ever one selected succeeded
[15:40] <smoser> right. ideally is saying "whatever would configure the network ran and succeeded"
[15:40] <smoser> but i guess honestly if it didnt succeed then we're kind of sol
[15:43] <rharper> right
[15:43] <rharper> well, for network based datasources
[15:44] <rharper> or if someone wanted networking...
[15:44] <rharper> it's possible for a device to use cloud-init with nocloud seed and not care about networking (during boot)
[15:44] <rharper> so ideally we'd somewhat not care in the sense that it only matters truely if the user-data/metadata is over the network  (as in that will fail)
[15:53] <smoser> rharper, well right. that'd have no networkign, but that would be succeed
[15:53] <smoser> right  ? an empty /etc/network/interfaces just says "don't do anything".  and that succeeds very quickly.
[15:54] <smoser> pitti, you have a minute for some questions about cloud-init's systemd jobs generally ?
[15:54] <pitti> smoser: literally one minute, yes (our meeting starts in 5, currently prepping)
[15:55] <smoser> you ahve time after ?
[15:55] <smoser> i'd like hangout if you can
[15:55] <smoser> some stuff here: https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547
[15:55] <smoser> but woudl ike to just review all of it.
[15:56] <pitti> smoser: LGTM, as long as cloud-init-local.service makes no assumptions at all about writable root and mounts?
[15:57] <pitti> smoser: sorry, not after either, meeting someone for dinner
[15:57] <smoser> pitti, well, it does assume it can write to /var/lib
[15:57] <smoser> and /run
[15:58] <smoser> how should i say that ?
[15:59] <pitti> smoser: reviewed
[15:59] <pitti> smoser: /run is always there, so add After=systemd-remount-fs.service and RequiresMountsFor=/var/lib
[16:22] <pitti> smoser, rharper: http://summit.ubuntu.com/uos-1611/meeting/22716/netplan-introduction-and-next-steps/ → do you want to attend?
[16:25] <rharper> pitti: yes
[16:27] <smoser> pitti, sure
[16:40] <nacc> rbasak: do you have a link to the pad from yesterday? for some reason, i'm disconnected
[16:41] <rbasak> nacc: http://pad.ubuntu.com/git-workflow-talk
[16:41] <nacc> rbasak: thanks
[16:56] <nacc> caribou: i'm working through your import requests, fyi
[16:56] <nacc> rbasak: --^
[16:56] <caribou> nacc: thanks!
[17:03] <nacc> smoser: i might add a default value for the lp username prompt -- at least i find it really annoying to have to type my local username or pass it (i don't need to do this for the importer, e.g.)
[17:06] <smoser> nacc, how would you add a default ?
[17:06] <smoser> and you only provide it once.
[17:06] <smoser> then it stores it.
[17:07] <nacc> smoser: only if i tell it to :)
[17:07] <nacc> smoser: same way we do for the importer
[17:07] <smoser> why dont you answer yes
[17:07] <nacc> smoser: maybe we shouldn't, i just don't like that clone behaves differently
[17:07] <smoser> then fixed
[17:07] <smoser> and its right.
[17:07] <nacc> smoser: becasue i'm going to delete the tree
[17:07] <nacc> smoser: i don't care about configuration caching
[17:08] <smoser> it storees it in your ~/.git
[17:08] <smoser> ~/.gitconfig
[17:08] <smoser> you probably dont delete that too often :)
[17:08] <smoser> doesnt it?
[17:08] <nacc> oh you're doing --global
[17:08] <nacc> hrm, ok
[17:09] <rbasak> nacc: I think launchpadlib has something. When I use other Launchpad API tools that need privilege, they don't prompt me.
[17:09] <nacc> so we probably have a bug, as i do have local configs in .gitconfig
[17:09] <nacc> smoser: will investigate
[17:09] <nacc> rbasak: ack
[17:10] <nacc> caribou: thank you, btw, you helped me find a bug :)
[17:11] <nacc> at least not one i didn't introduce in my rewrite :/
[17:11] <caribou> nacc: always happy to help ;-)
[17:15] <nacc> rbasak: jgrimm: do you want to stay on the HO?
[17:17] <jgrimm> nacc, rbasak: i'll defer to you if wanting to start now or need a break
[17:18] <nacc> jgrimm: ack, we're in the HO now
[17:34] <smoser> nacc, http://paste.ubuntu.com/23457110/
[17:34] <smoser> that method is much more standalone , so i made it a staticmethod there. can just as easily move it somewhere more common.
[17:35] <smoser> and just fyi, you were 'match' with beginning '^'. i'm pretty sure thats redundant.
[17:38] <nacc> smoser: nice, thanks!
[17:46] <tdaitx> bdmurray, from where does the UnreportableReason in the error tracker comes from?
[17:46] <bdmurray> tdaitx: from apport
[17:47] <tdaitx> bdmurray, right, then my question is from where does apport fetch that information?
[17:48] <bdmurray> tdaitx: it creates it - what are you seeing?
[17:48] <tdaitx> bdmurray, just trying to figure out what that field mean on those package-data-downloader errors
[17:48] <bdmurray> tdaitx: out of date packages
[17:49] <tdaitx> yeah, but why?
[17:49] <bdmurray> tdaitx: because they haven't installed all their updates.
[17:50] <tdaitx> ok, so it's just a usual message fom apport
[17:50] <bdmurray> tdaitx: wrt apport you could read apport/report.py and data/general-hooks/ubuntu.py
[17:50] <bdmurray> tdaitx: yes
[17:51] <tdaitx> bdmurray, anyway, I noticed that /usr/lib/update-notifier/package-data-downloader is also called from update-notifier-common.postinst
[17:51] <tdaitx> not sure it that one can ever have no stdout/stderr set
[17:52] <bdmurray> tdaitx: okay, thanks for looking
[18:25] <nacc> rbasak: ah i think i see what is wrong with kexec-tools -- you did the merge step that the importer is expecting to do, is all
[20:03] <nacc> smoser: can you send me a MR?
[20:32] <smoser> nacc, https://code.launchpad.net/~smoser/usd-importer/+git/usd-importer/+merge/310580
[20:48] <pitti> smoser, rharper: is bug 1636912 also eventually relevant for Debian? I. e. are they following upstream relatively closely and will be aftected by this networkd > dbus.service thing?
[20:48] <pitti> smoser, rharper: (it would actually make things easier if they are -- then removing the After=dbus.service wouldn't be an Ubuntu specific thing)
[20:48] <rharper> pitti: possibly, not sure if we upload cloud-init to debian, but we do support debian as an os target
[20:49] <rharper> pitti: that's a netword change, right, so it's certainly a reasonable common change
[20:49] <smoser> we do not maintain cloud-init in debian
[20:49] <pitti> they have 0.7.8-1, and https://tracker.debian.org/pkg/cloud-init looks reasonably active
[20:49] <smoser> but there is cloud-init in debian
[20:49] <pitti> right, I mean this will eventually go into 0.7.9 or 0.8 or whatever? i. e. "upstream"; or stay in ubuntu?
[20:55] <smoser> pitti, oh, i'd put it upstream
[20:56] <pitti> smoser: ack
[20:56] <smoser> pitti, that is correct for debian too, right ?
[20:56] <smoser> i think all those systemd files are ...
[20:56] <smoser> at least hope
[20:56] <smoser> and even for fedora is the goal
[20:56] <pitti> smoser: yes; but we'd run into the same networkd After=dbus.service issue in Debian then, so we'd need to patch it out there too (and break UseHostname:)
[21:41] <LocutusOfBorg> highvoltage, sorry for not looking at the RFS
[21:41] <LocutusOfBorg> I'll try to look at it tomorrow if nobody beats me
[21:41] <LocutusOfBorg> I have too many packages to look at, and today I'm fixing llvm stack :/
[21:58] <nacc> smoser: thanks!
[22:11] <smoser> pitti, can you fix typo in https://code.launchpad.net/~smoser/cloud-init/+git/cloud-init/+merge/310547
[22:11] <smoser> what bug is that ?


[01:54] <LPCIBot> Yippie, build fixed!
[01:54] <LPCIBot> Project db-devel build (331): FIXED in 6 hr 22 min: https://hudson.wedontsleep.org/job/db-devel/331/
[01:54] <LPCIBot> Launchpad Patch Queue Manager: [rs=buildbot-poller] automatic merge from stable. Revisions: 12284
[01:54] <LPCIBot> included.
[02:02] <lifeless> [02:02] <lifeless>     Hard / Soft  Page ID
[02:02] <lifeless>      182 /  299  BugTask:+index
[02:02] <lifeless>       13 /   12  Archive:+copy-packages
[02:02] <lifeless>       12 /    3  Cve:+index
[02:02] <lifeless>       10 /   11  Branch:+index
[02:02] <lifeless>        8 /    0  BinaryPackageBuild:+retry
[02:02] <lifeless>        7 /   27  DistroSeriesLanguage:+index
[02:02] <lifeless>        7 /    8  Person:+uploaded-packages
[02:14] <StevenK> Why is the top 10 only 7?
[02:17] <wgrant> Indeed, 2-4 are omitted.
[02:17] <wgrant> Bad lifeless.
[02:34] <lifeless> that would be freenode fail
[02:34] <lifeless> their new software throttles far too aggressively
[19:24] <thumper> Monday morning, and all quiet
[19:25] <lifeless> heh
[19:25] <lifeless> can fix that
[19:26] <lifeless> thumper: btw maxb reopened your stuck builds fix
[19:26] <thumper> yeah
[19:26] <thumper> saw that
[19:35] <lifeless> hmm
[19:35] <lifeless> in linking series to branch
[19:36] <lifeless> would it make sense to offer a likely list? e.g. code imports + branches called 'trunk', 'MAIN', 'HEAD' etc
[19:43] <thumper> lifeless: file a bug :)
[19:44] <lifeless> ok
[19:56] <thumper> are the windmill tests disabled?
[19:56] <lifeless> I'm not sure
[20:18] <jelmer> g'morning nz
[20:57] <lifeless> woo
[20:57] <lifeless> no new bugs
[20:57] <lifeless> no confirmed bugs
[20:58] <thumper> hi jelmer
[21:01] <wallyworld> morning
[21:02] <thumper> wallyworld: morning
[21:02] <thumper> wallyworld: thanks for taking the CHR slot
[21:02] <wallyworld> thumper: np
[21:06] <lifeless> and woo every undecided importance bug is incomplete.
[21:08] <mwhudson> ah, this is why i have so much email, perhaps
[21:08] <mwhudson> not that i get launchpad bug mail any more
[21:11] <lifeless> james_w: bug 645640
[21:12] <james_w> yes?
[21:12] <lifeless> james_w: you commented that its blocked, but not by what
[21:13] <lifeless> ah bah
[21:13] <lifeless> wrong bug
[21:13] <lifeless> hang a sec while I try to find the right one again
[21:13] <james_w> well, why is that one incomplete?
[21:14] <lifeless> it was incomplete pending a reply, which you have given
[21:15] <lifeless> james_w: though I do have another question for you on that bug :)
[21:18] <lifeless> james_w: bug 395200
[21:46] <lifeless> poolie: call?
[22:18] <wgrant> Anyone up for reviewing https://code.launchpad.net/~wgrant/launchpad/bug-710360-gina-wheezy/+merge/47942?
[22:19] <lifeless> wgrant: ugh
[22:19] <wgrant> Yes.
[22:19] <lifeless> wgrant: are you a reviewer yet?
[22:19] <wgrant> No.
[22:22] <wgrant> I need a mentor.
[22:24] <lifeless> ok, I'll mentor you
[22:27] <wgrant> lifeless: Sure?
[22:28] <lifeless> yes, I think I can handle it
[22:30] <wgrant> Thanks!
[22:33] <wallyworld> thumper: you free yet?
[22:33] <thumper> wallyworld: yep
[22:33] <thumper> sorry
[22:34] <thumper> mumble?
[22:34] <wallyworld> ok
[22:34] <lifeless> wgrant: can you let bac know, get yourself on the roster etc etc
[22:38] <thumper> StevenK: ping
[22:38] <thumper> StevenK: mumble ping
[22:38] <StevenK> thumper: Hai
[22:40] <StevenK> thumper: I can
[22:41] <StevenK> thumper: You think?
[22:46] <StevenK> thumper: I need a bit more time to clean up some SQL
[22:46] <StevenK> thumper: Yes
[22:46] <StevenK> Same thing
[22:46] <StevenK> It's all IPerson.merge
[22:47] <wgrant> Speaking of which, can I object to the delete-recipes-on-merge thing? :)
[22:47] <StevenK> wgrant: thumper just did
[22:48] <wgrant> Yay!
[22:49] <StevenK> thumper: So, I don't think the queue-recipes will take very long
[22:49] <StevenK> thumper: Then I'll rip team-merge apart
[22:49] <StevenK> thumper: branch merging is all done with SQL
[22:50] <StevenK> thumper: def _mergeBranches(
[22:55] <thumper> wallyworld: https://launchpad.net/oops-tools
[23:00] <thumper> wallyworld: http://pastebin.ubuntu.com/560402/
[23:02] <thumper> lifeless, mwhudson: didn't someone organise to have the doctests rendered as ReST and available somewhere on a site?
[23:03] <mwhudson> thumper: BjornT_ was working on that
[23:03] <lifeless> thumper: benji presented a plan
[23:03] <mwhudson> thumper: ages ago though
[23:03] <lifeless> thumper: in july
[23:03] <thumper> so not yet then...
[23:03] <lifeless> not yet
[23:04] <mwhudson> searching my mail archive turns up http://people.canonical.com/~bjorn/lp-architecture/
[23:05] <mwhudson> but i don't know if that ever got past proof-of-concept
[23:05] <lifeless> it was a redo
[23:05] <lifeless> new docs
[23:05] <lifeless> new subtree
[23:05] <lifeless> existing stuff untouched
[23:05] <mwhudson> ah right
[23:05] <lifeless> I decided it wasn't worth pursuing in that form
[23:08] <lifeless> wow RootObject:+daily-builds is sick
[23:08] <thumper> lifeless: how sick?
[23:08] <lifeless> https://devpad.canonical.com/~lpqateam/ppr/lpnet/latest-daily-timeout-candidates.html
[23:09] <lifeless> never renders in < 9 seconds
[23:09] <thumper> heh
[23:10] <thumper> 273 queries won't help
[23:10] <thumper> should aim for < 20
[23:10] <lifeless> yup
[23:12] <lifeless> I was looking for pages whose 99% completing fell between 14 and 15 seconds
[23:12] <lifeless> to see the impact of dropping the timeout by a second
[23:12] <lifeless> only two
[23:13] <lifeless> that, and PillarNameSet:EntryResource:search
[23:13] <lifeless> both < 50 hits a day
[23:13] <thumper> lifeless: probably a day or so to fix that one
[23:17] <thumper> StevenK: the morning standups just aren't the same if you can't talk
[23:17] <thumper> StevenK: plz fix :)
[23:18] <StevenK> Here I was thinking you'd say they're better if I can't talk
[23:26] <wgrant> lifeless: You know that armel PPAs are coming RSN, right?
[23:27] <mwhudson> fsov rsn
[23:27] <wgrant> I believe that's included in the definition of RSN.
[23:27] <jelmer> wgrant: I thought we already had armel PPAs?
[23:28] <mwhudson> jelmer: well sort of, but they're not virtualized
[23:28] <wgrant> jelmer: We have restricted fake virtualized builders.
[23:28] <wgrant> That are not virtualized.
[23:28] <jelmer> right, so we have armel PPAs :-)
[23:44] <StevenK> lifeless: Does http://pastebin.ubuntu.com/560425/ look sane to you? I don't think Storm is bracketting the two date_created conditions correctly
[23:46] <lifeless> StevenK: why do you have the two comparisons with date created ?
[23:47] <StevenK> lifeless: Because if there is a build that's been created within the last 24 hours, we don't want to schedule another
[23:47] <lifeless> that only requires a <
[23:48] <lifeless> not < is equivalent to >=
[23:49] <StevenK> Er, won't that return builds that have been scheduled in the last 24 hours?
[23:49] <lifeless> StevenK: I think your math is broken :)
[23:50] <lifeless> StevenK: date created is a point in time; we are interested when the build was scheduled before now-23h50m
[23:50] <lifeless> StevenK: if we had an interval, we would query on interval > 23h50
[23:51] <lifeless> StevenK: if we have a position, we query on things before that position
[23:52] <StevenK> lifeless: Keep in mind a recipe can have more than BuildFarmJob
[23:52] <StevenK> More than one
[23:52] <lifeless> ah yes
[23:52] <lifeless> I really dislike this data model
[23:53] <StevenK> So I'd like to make sure if there is one BFJ, it was created more than one day ago, and if there are more than one, that they all were created more than one day ago
[23:54] <StevenK> lifeless: Patches welcome
[23:54] <StevenK> lifeless: But keep in mind that BFJs are used by more than just recipes
[23:55] <lifeless> sure
[23:55] <lifeless> the basic problem is that you want to work on stuff that is 'current' but the schema is an archival schema
[23:56] <lifeless> better to hav a current schema and an archive schema, if you want archiving.
[23:58] <wgrant> lifeless: What does current mean?
[23:58] <lifeless> wgrant: live, active
[23:58] <wgrant> In this case we are looking for records that might have built a day ago.
[23:58] <wgrant> Are they archived?
[23:59] <lifeless> wgrant: in a different model you wouldn't be looking for anything in the archive schema
[23:59] <lifeless> wgrant: so that question is noddy
[23:59] <wgrant> Oh?
[23:59] <wgrant> How would you model it?
[23:59] <lifeless> StevenK: so, we want SPR with either (no builds) or (no builds in the last 24 hours) right ?


[07:39] <dholbach> good morning
[09:13] <jose> dpm: ping
[09:19] <dholbach> hola dpm
[09:20] <dpm> hola jose, dholbach
[09:21] <jose> hey dpm, estoy por ir a dormir en un minuto, pero quería saber si podemos tener un hangout rápido a las 15 UTC?
[09:24] <dpm> jose, a las 15UTC tengo otro hangout, pero hazme un ping cuando estes de nuevo online y hablamos
[09:24] <jose> dpm: genial, gracias! :)
[09:25]  * jose finishes testing this charm and goes to bed
[14:52] <jose> dpm: ping :)
[14:52] <elfy> hi jose - how did the LoCo on air thing go - totally missed that
[14:53] <jose> elfy: it went great! video is still linked at ubuntuonair.com if you wanna take a look
[14:54] <elfy> you can link me it - I'll certainly have a look today/tomorrow
[14:54] <elfy> nvm - you did link me to it :p
[14:58] <jose> :P
[14:59] <dpm> jose, as I said, I've got a call in 2 mins, but perhaps we can talk in about 30 mins? Do you want to talk about what you mentioned in your e-mail re: the Catalan team?
[14:59] <jose> dpm: yep! 30m should be good :)
[14:59] <jose> topic is correct
[15:36] <dpm> jose, I'm free for a hangout now if you want
[15:36] <jose> dpm: sure, give me a second
[15:36] <dpm> cool, no rush :)
[15:38] <jose> dpm: ready for it now, want me to set it up?
[15:38] <dpm> jose, if you don't mind, that'd be great!
[17:21] <mhall119> jose: look at you and your rapid charming, jcastro owes you a beer :)
[17:21] <jose> :)
[17:21] <jcastro> hmm what did I miss?
[17:22] <mhall119> jcastro: did you read my blog about the community cast app?
[17:22] <jcastro> I scanned it
[17:22] <mhall119> jcastro: http://mhall119.com/2014/03/my-phone-is-lonely-lets-fix-that/#comment-17344
[17:22] <jcastro> NICE!
[17:22] <mhall119> jcastro: now I just need juju integrated in the SDK
[17:22] <jose> (and still, I have charms on the review queue and I wait every day standing on my door to see a package arrive)
[17:23] <jcastro> yeah so that's probably harder
[17:23] <jcastro> heh
[17:23] <jcastro> jose, did you not get a shirt yet?
[17:23] <jose> jcastro: not at all!
[17:23] <jcastro> !!!
[17:23] <jose> :P
[17:23] <mhall119> jcastro: dude, don't let the community down like that
[17:23] <jcastro> ok they're being redesigned, I'll make sure you get one
[17:23] <jose> \o/
[17:23] <jose> thanks
[17:23] <jcastro> dang, I thought you had one, otherwise I would have given you one at SCALE!
[17:24] <jose> well, I can wait for it
[17:27] <jcastro> jose, without looking, did you reuse the django charm or did you do it from scratch?
[17:28] <jose> jcastro: I did it from scratch, didn't know there was a django charm
[17:29] <jcastro> https://jujucharms.com/sidebar/search/bundle/~charmers/django/2/example-single/?text=django
[17:29] <jcastro> I made a bundle too
[17:29] <jcastro> lol @ our URLs
[17:30] <jose> oh, that's cool
[17:30] <jcastro> what would be cool in the future
[17:30] <jcastro> is you deploy one unit and it does sqlite
[17:31] <jcastro> but when you connect it to postgres it Does The Right Thing(tm)
[17:31] <jcastro> that would let mhall119 scale when he becomes popular
[17:31] <jose> well, it doesn't use postgres
[17:31] <jcastro> right, I mean in the future
[17:32] <jose> well, that could be done, I think
[17:32] <jose> I believe I have an idea on how to do that
[17:32] <jcastro> we have a charm that does that somewhere
[17:32] <jcastro> that does single node with sqlite and then can move to a bigger db when the time comes
[17:32] <jcastro> marcoceppi, ^^^^
[17:36] <marcoceppi> jcastro: jose I forget, I've seen it though
[17:36] <jose> hmm, would be nice to know
[17:36] <jcastro> http://manage.jujucharms.com/charms/precise/owncloud/hooks/db-relation-changed
[17:36] <jcastro> Found it!
[17:37] <jcastro> hmm, maybe not
[17:43] <jose> :P
[17:43] <jose> I'm working on another charm atm, one for pagekite
[17:47] <dholbach> I call it a day - see you all tomorrow! *hugs*