[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 0.0.0.0/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: 91.189.88.150 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_> 91.189.88.150 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 ?