[05:37] -queuebot:#ubuntu-release- New sync: gnome-dvb-daemon (zesty-proposed/primary) [1:0.2.91~git20170110-2]
[06:27] -queuebot:#ubuntu-release- New binary: graywolf [amd64] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[06:27] -queuebot:#ubuntu-release- New binary: graywolf [ppc64el] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[06:27] -queuebot:#ubuntu-release- New binary: graywolf [i386] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[06:27] -queuebot:#ubuntu-release- New binary: graywolf [s390x] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[06:28] -queuebot:#ubuntu-release- New binary: graywolf [arm64] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[06:28] -queuebot:#ubuntu-release- New binary: graywolf [powerpc] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[06:28] -queuebot:#ubuntu-release- New binary: graywolf [armhf] (zesty-proposed/universe) [0.1.4+20170307gite1bf319-1] (no packageset)
[07:06] -queuebot:#ubuntu-release- Unapproved: accepted cgroup-lite [source] (precise-proposed) [1.1.6]
[07:07] -queuebot:#ubuntu-release- Unapproved: accepted cgroup-lite [source] (xenial-proposed) [1.11ubuntu0.16.04.1]
[07:41] -queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
[07:41] -queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
[07:41] -queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
[07:42] -queuebot:#ubuntu-release- Unapproved: fwupdate (zesty-proposed/main) [8-3 => 9-1] (core)
[09:25] -queuebot:#ubuntu-release- Unapproved: signon-ui (xenial-proposed/main) [0.17+16.04.20151125-0ubuntu1 => 0.17+16.04.20170116-0ubuntu1] (kubuntu, ubuntu-desktop) (sync)
[10:19] <ginggs> would an archive admin please take a look at removals in LP: #1653238 and LP: #1636259 ?
[10:59] <apw> ginggs, normally those show up and get removed automatically
[10:59] <apw> (NBS binaries)
[11:08] <ginggs> apw: even if it is only on certain architectures?
[11:09] <apw> ginggs, oh that likely nt
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [amd64] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [armhf] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [powerpc] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [s390x] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [arm64] (zesty-proposed) [0.00.03-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [i386] (zesty-proposed) [0.00.03-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [ppc64el] (zesty-proposed) [0.00.03-1]
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [arm64] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [ppc64el] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [armhf] (zesty-proposed) [0.00.03-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [s390x] (zesty-proposed) [0.00.03-1]
[11:54] -queuebot:#ubuntu-release- New: accepted graywolf [i386] (zesty-proposed) [0.1.4+20170307gite1bf319-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [powerpc] (zesty-proposed) [0.00.03-1]
[11:54] -queuebot:#ubuntu-release- New: accepted pagein [amd64] (zesty-proposed) [0.00.03-1]
[12:57] <tjaalton> could and archive-admin remove resteasy from zesty, it's bug 1662654 again
[12:57] <tjaalton> *an
[12:57] <tjaalton> and zesty-proposed of course
[13:01] -queuebot:#ubuntu-release- Unapproved: tftp-hpa (trusty-proposed/main) [5.2-7ubuntu3 => 5.2-7ubuntu3.1] (desktop-core, ubuntu-server)
[13:01] -queuebot:#ubuntu-release- Unapproved: tftp-hpa (yakkety-proposed/main) [5.2+20150808-1ubuntu1 => 5.2+20150808-1ubuntu1.16.10.1] (ubuntu-desktop, ubuntu-server)
[13:01] -queuebot:#ubuntu-release- Unapproved: tftp-hpa (xenial-proposed/main) [5.2+20150808-1ubuntu1 => 5.2+20150808-1ubuntu1.16.04.1] (ubuntu-desktop, ubuntu-server)
[13:17] <ginggs> thanks apw! pbdagcon,pbalign,blasr,pbseqlib all migrated now
[13:22] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (xenial-proposed) [0.96.20.6]
[13:24] -queuebot:#ubuntu-release- Unapproved: accepted software-properties [source] (yakkety-proposed) [0.96.24.7.1]
[13:25] <jbicha> bdmurray: can we ignore that bug 1660063 might not be completely fixed?
[13:33] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (xenial-proposed) [0.90ubuntu0.4]
[13:34] -queuebot:#ubuntu-release- Unapproved: accepted unattended-upgrades [source] (yakkety-proposed) [0.92ubuntu1.3]
[13:36] -queuebot:#ubuntu-release- Unapproved: accepted ktp-text-ui [source] (xenial-proposed) [4:15.12.3-0ubuntu2]
[13:44] -queuebot:#ubuntu-release- Unapproved: accepted apt [source] (xenial-proposed) [1.2.20]
[13:52] -queuebot:#ubuntu-release- Unapproved: accepted wget [source] (xenial-proposed) [1.17.1-1ubuntu1.2]
[13:56] -queuebot:#ubuntu-release- Unapproved: accepted simple-image-reducer [source] (xenial-proposed) [1.0.2-3ubuntu0.16.04.1]
[14:01] <tjaalton> armhf binaries of openmw should be removed, the new version doesn't build and old one is blocking mesa
[14:15] <apw> tjaalton, "doesn't build" do we know why ?
[14:16] <tjaalton> apw: it doesn't build on debian either and doesn't seem upstream is too busy fixing it
[14:22] <apw> tjaalton, i would say file a removal request for that, so we have all the details in one place
[14:26] <tjaalton> okay
[14:30] -queuebot:#ubuntu-release- Unapproved: snapd (trusty-proposed/universe) [2.23~14.04 => 2.23.1~14.04] (no packageset)
[14:30] -queuebot:#ubuntu-release- Unapproved: snapd (xenial-proposed/main) [2.23 => 2.23.1] (desktop-core, ubuntu-server)
[14:31] -queuebot:#ubuntu-release- Unapproved: snapd (yakkety-proposed/main) [2.23+16.10 => 2.23.1+16.10] (desktop-core, ubuntu-server)
[14:35] -queuebot:#ubuntu-release- New source: ukui-menu (zesty-proposed/primary) [1.0.0-0ubuntu1]
[14:44] <tjaalton> apw: bug 1671129
[14:47]  * apw will review those snapd's once they pass testing in yakkety
[14:53] <jbicha> you can remove ukui-session-manager/zesty 1.0.0, we are reuploading as a regular (non-native) package
[14:56] <jbicha> and the older gnome-games-app/zesty
[14:56] <jbicha> from the new queue
[14:57] -queuebot:#ubuntu-release- New source: ukui-session-manager (zesty-proposed/primary) [1.0.0-0ubuntu1]
[16:46] <cyphermox> hi, could someone from the release team please review my FFe? https://bugs.launchpad.net/ubuntu/+source/nplan/+bug/1670495
[17:26] <bdmurray> jbicha: looking
[17:34] <bdmurray> slangasek: Could you fully phase chrome-gnome-shell for yakkety?
[17:37] <bdmurray> rbasak: I believe the SRU team discussed in Sevilla using Incomplete more as a way of quickly conveying information about the status of an SRU e.g. setting the systemd task to Incomplete in bug 1649931.
[17:38] <bdmurray> rbasak: This way I don't have to scroll all the way through the report to read you comment about the testing being incomplete.
[17:38] <bdmurray> And also using it for items in the -proposed queue that might be missing a test case or whatever.
[17:42] <rbasak> bdmurray: sorry. I must have forgotten that. I had noticed you were using it. I'm happy to do that every time I make a comment if that's the consensus?
[17:42] <rbasak> (if the comment is blocker I mean)
[17:43] <bdmurray> rbasak: I didn't mean to come across as saying you were not doing something. Its possible you weren't in the room at the time! I think we should make it the consensus. ;-)
[17:43] <bdmurray> slangasek: I think you are the one who said we should use Incomplete more...
[17:45] <rbasak> I don't like overloading the status like that, but pragmatically if that communicates it better then I'm fine with it.
[17:46] <jbicha> bdmurray: the chrome-gnome-shell update is still in yakkety-proposed
[17:47] <rbasak> Separately, I have been planning to propose a script auto-comment when there are autopkgtest failures, asking the SRU driver to check and tag the bug with autopkgtest-false-positive or something like that, and then having pending-sru not treat those as green unless the tag exists.
[17:47] <rbasak> Similarly, perhaps we could have an sru-blocked tag instead of using the Incomplete status? Only a suggestion; I'm happy to follow the consensus.
[17:48] <jbicha> bdmurray: it's blocked because you removed the verification-done tag
[17:50] <bdmurray> jbicha: While that's true it won't matter if an AA fully phases it.
[17:51] <jbicha> bdmurray: I think we're miscommunicating; the SRU team has not accepted it from -proposed yet because it's not verification-done
[17:51] <bdmurray> rbasak: I believe robru is close to having autopkgtest results emailed to uploaders so two notifications might be a lot. Although, I guess having it on the public record (the bug) would be good.
[17:52] <robru> bdmurray: I'm close to having stuck package notifications emailed out. autopkgtest results not included.
[17:53] <bdmurray> jbicha: oh, i can read now. 8.2ubuntu4 not 8.2ubuntu3
[17:53] <robru> bdmurray: also the email gets sent after the package is stuck for a day
[18:08] <jbicha> bdmurray: thanks
[18:09] <bdmurray> jbicha: yep, sorry for being slow!
[18:09] <jbicha> rbasak: could you look into accepting chrome-gnome-shell and ubuntu-gnome-meta for trusty,xenial,yakkety even though it's not aged 7 days?
[18:10] <jbicha> the SRUs were slowed down because of the trouble getting new packages into -updates, but Firefox 52 was released yesterday
[18:19] <jbicha> to clarify, chrome-gnome-shell have been accepted into xenial and yakkety but trusty is still needed and u-g-meta for all 3 releases
[18:38] <rbasak> jbicha: I'm finished for the day now, sorry. Ping me tomorrow if nobody else manages to look please?
[18:38]  * rbasak is half asleep already :-/
[18:40] <jbicha> ok thanks
[19:12] <zul> can someone reject horizon 9.1.1 from the queue as well please
[19:17] <slangasek> bdmurray: chrome-gnome-shell phasing done
[19:18] <apw> zul, from where ?
[19:19] <zul> apw: sorry xenial-proposed
[19:20] <slangasek> bdmurray, rbasak: I don't recall if I proposed incomplete for incomplete testing, but that seems not-unreasonable to me
[19:23] <bdmurray> slangasek: ah, my notes do lean more towards incomplete SRU information not verficiation
[19:25] -queuebot:#ubuntu-release- Unapproved: rejected horizon [source] (xenial-proposed) [2:9.1.1-0ubuntu1]
[19:26] <apw> zul, ^
[19:26] <zul> thanks
[20:03] <Laney> robru: Hey. I'll do a final pass over your MP tomorrow. Any chance you could provide a commit in another branch or something to log what it would do (who it would email for which excuse) instead of emailing so that I can do a dry run?
[20:04] <robru> Laney: yeah i made this branch which prints out packages/versions/email addresses instead of sending anything.: https://code.launchpad.net/~robru/britney/+git/britney2-ubuntu/+ref/email-dry-run
[20:05] <Laney> convenient
[20:05] <Laney> does that end up in the normal log?
[20:13] <robru> Laney: well, I *assume* stdout is captured in the normal log...
[20:14] <robru> Laney: confirmed, self.log() is just a wrapper around print() anyway, so yeah, it'll be the same log
[20:18] <Laney> robru: ok then, thanks
[20:20] <robru> Laney: so what's the plan? you'll just copy that commit to snakefruit and we can look at the log? ;-)
[20:21] <Laney> something like that
[20:56] -queuebot:#ubuntu-release- New source: ukui-screensaver (zesty-proposed/primary) [1.0.0-0ubuntu1]
[21:05] <robru> slangasek: gaughen: Laney: Ok I tried it locally and came up with this list of people to email: http://paste.ubuntu.com/24141582/ This is about 1/10 of the emails I was expecting, not clear to me if my attempt at setting up the britney env locally has failed, or if 90% of the stuff stuck in proposed is really auto-syncs that would not be emailed.
[21:07] <gaughen> looks like slangasek will get a lot of email
[21:07] <robru> hehe
[21:08] <robru> I'm running it again with more verbose logging and it does look like there's a lot of stuff that qualifies for a mail but has nobody to mail (so, auto syncs)
[21:08] <slangasek> robru: why do I get emailed for orthanc-webviewer?  Did I do something manual there?
[21:09] <slangasek> possibly a manual sync to override the autosync behavior of not reintroducing removed packages
[21:09] <robru> slangasek: yeah, lp api is blaming you, likely a manual sync.
[21:16] <robru> slangasek: gaughen: http://paste.ubuntu.com/24141654/ this is more in line with my expectations
[21:18] <robru> slangasek: so should I send that email and you can roll it out? ;-)
[21:19] <slangasek> robru: "more in line"> what changed?
[21:20] <robru> slangasek: it printed the stuck packages that won't be emailed about, so I can see there's more than 37 stuck packages.
[21:20] <slangasek> robru: and I understood that Laney was on top of this for deployment
[21:20] <robru> slangasek: going by excuses, I was expecting 370 emails, so when I saw only 37 I was surprised, thought maybe I was missing a chunk of packages somehow. but there's just a bunch that don't get emailed.
[21:21] <slangasek> ok - so you didn't change anything about who would get mailed, just showing more stuck packages
[21:21] <robru> yeah
[21:45] -queuebot:#ubuntu-release- New source: ukui-control-center (zesty-proposed/primary) [1.0.0-0ubuntu1]
[21:55] <Laney> robru: that doesn't seem to have a "Stuck" line for every excuse
[21:56] <robru> Laney: it should be only if daysold >= 1
[21:58] <Laney> e.g nautilus, gobject-introspection, openstack-doc-tools, systemd not mentioned
[21:59] <robru> hmmmm
[22:03] <bdmurray> slangasek: Do you think that bug 1654008 which has tens of thousands of incidences is worth SRU'ing given that something is wrong if int(time.time()) is greater than 2147483647?
[22:04] <bdmurray> slangasek: It does prevent them from using update-manager, but we'd also need to SRU update-notifier which uses the launch-time key.
[22:04] <robru> Laney: ok I'm running it again with maximum raw data dump just so I can inspect what's going on...
[22:05] <Laney> nod
[22:06] <slangasek> bdmurray: it would fix it so that anyone whose dconf value isn't /yet/ broken will be saved future(heh) pain, right?
[22:13] <bdmurray> slangasek: afaict can tell the dconf value can't be broken because it doesn't fit in the range of allowed values. the test case is faketime to the future and update-manager crashes trying to write the value.
[22:13] <robru> Laney: ok so what I'm seeing is that nautilus has excuse.is_valid = True, which doesn't make a lot of sense, but that's why it's not in the list of things to be emailed.
[22:13] <bdmurray> slangasek: but it'll fix anybody whose clock is wrong
[22:13] <robru> same with g-i
[22:14] <robru> Laney: same with all four packages that you mentioned.
[22:14] <slangasek> bdmurray: ok; that seems worth an SRU to me then
[22:15] <bdmurray> alrighty
[22:15] <robru> Laney: slangasek: seems that maybe excuse.is_valid isn't especially trustworthy? I can change the algo to ignore that value and go just by daysold if you think that makes sense.
[22:18] <Laney> robru: I'm not sure - if slangasek doesn't know then you could ask nthykier for advice maybe
[22:18] <Laney> Might be that it's not being set to false in some circumstances, and that could possibly be a bug
[22:18] <slangasek> robru: what are you looking for out of excuse.is_valid?
[22:18] <robru> Laney: it's possible those ones are being rejected by britney after my policy is inspecting them
[22:19] <robru> slangasek: the code as it exists does not send mails when excuse.is_valid is True, however Laney pointed out four packages that are stuck for over a day, excuses says "Not considered", but they have excuse.is_valid = True at the time my policy runs.
[22:20] <slangasek> robru: "is_valid" means that it is a candidate according to update_excuses, it does /not/ mean that it will migrate
[22:20] <slangasek> robru: so you should not key on excuse.is_valid
[22:20] <robru> slangasek: ok, will fix, thanks
[22:20] <slangasek> robru: great :)
[22:20] <Laney> Hmm?
[22:21] <Laney> I don't understand that statement
[22:21] <slangasek> Laney: "is_valid" means "valid candidate"; but things can be stuck because they increase uninstallibility - i.e. anything that needs update_output.txt to debug
[22:21] <robru> Laney: which
[22:21] <Laney> The policy is supposed to email for things that are not candidates on excuses isn't it?
[22:21] -queuebot:#ubuntu-release- New source: ukui-desktop-environment (zesty-proposed/primary) [1.0.0]
[22:22] <Laney> Or you want to email for transitions too?
[22:22] <slangasek> Laney: AIUI we want to email for any package that is wedged in -proposed, including those that are wedged because of other packages
[22:22] <Laney> mmkay
[22:22] <slangasek> perhaps there should be different aging times for the two cases?
[22:23] <robru> slangasek: britney gives daysold as an int unfortunately, so unless your idea is 1 day and 2 days...
[22:23] <slangasek> robru: I don't understand
[22:24] <robru> slangasek: I'm not sure what you mean by different aging times, but the grantularity I'm working with is integer days.
[22:25] <Laney> He's saying that something can be 'valid' but still blocked, and that maybe we might want to have a different daysold threshold in that case
[22:25] <slangasek> what Laney said
[22:25] <slangasek> days are a unit of time
[22:25] <robru> yeah. So I'm saying that would be 1 or 2, but I'm not able to do 1.5 or 0.5.
[22:26] <slangasek> yes, that's fine
[22:26] <Laney> Seems like a good idea to me
[22:26] <robru> slangasek: ok so what are you saying then? 1 day if is_valid == False, 2 days if is_valid == True?
[22:26] <Laney> But that puts you back in the position that is_valid is (maybe) wrongly False for some things
[22:27] <robru> but at least then it's just 2 days until you get your email instead of never getting an email
[22:27] <slangasek> I am not specifying a particular number of days here
[22:28] -queuebot:#ubuntu-release- New sync: genwqe-user (zesty-proposed/primary) [4.0.18-2]
[22:28] <slangasek> I am saying that if the package has is_valid == True, we might want to wait "longer" before sending mail, but not specifying how long that should be
[22:28] <robru> slangasek: ok that's fine if you want that, we should figure out what that number is so I can finish this.
[22:28] <Laney> For systemd it should be is_valid = False because it's rejected by the autopkgtest policy, and your one runs after that
[22:28] <slangasek> Laney: do you have an opinion what the number should be?
[22:28] <Laney> I think that's worth debugging
[22:28] <slangasek> right
[22:29] <Laney> slangasek: Umm, not a hard one - probably something like 5?
[22:29] <Laney> It's hard to generalise for all transitions
[22:29] <slangasek> Laney: that was the number I was thinking of
[22:29] <Laney> Usually a "few"
[22:29] <slangasek> ;)
[22:29] <slangasek> robru: 5
[22:29] <robru> ok
[22:30] <robru> I'm just generating the report for what emails would be sent when ignoring is_valid. that information will still be useful, once it finishes I'll make it use a dynamic daysold cutoff.
[22:41] <robru> slangasek: Laney: http://paste.ubuntu.com/24142092/ ok, there they all are: 142 emails and 400 stuck
[22:44] <jbicha> robru: gnome-software 3.22.6-0ubuntu1 isn't stuck
[22:45] <robru> jbicha: did it just migrate? I have stale indexes I'm working with locally.
[22:45] <jbicha> yes it just migrated but it also was only uploaded a few hours ago
[22:46] <robru> but but
[22:46] <robru> jbicha: britney seems to think daysold > 1
[22:46] <robru> >= 1 I mean
[22:48] <robru> jbicha: I don't know what to say about that, I only inspect excuse.daysold, I didn't change the way britney calculates it.
[22:49] -queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-contrib [source] (yakkety-proposed) [16.20151226ubuntu0.16.10.1]
[22:50] <robru> slangasek: Laney: ok I changed it to use a cutoff of 5 days when is_valid == True, and 1 day for is_valid == False. Merge pls?
[22:50] <jbicha> if it's going to email me about gnome-software, maybe you should bump the day from 1 to 2
[22:51] -queuebot:#ubuntu-release- Unapproved: accepted nagios-plugins-contrib [source] (xenial-proposed) [16.20151226ubuntu0.16.04.1]
[22:52] <robru> jbicha: https://launchpad.net/ubuntu/+source/fwupdate-signed/1.13 this upload was 15 hours ago but still shows as 0 days old.
[22:53] -queuebot:#ubuntu-release- New binary: ubuntu-wallpapers [amd64] (zesty-proposed/main) [17.04.0-0ubuntu1] (ubuntu-desktop)
[22:53] <robru> jbicha: I think something goofy is going on with my local indexes, I don't think it's going to email people for things migrating in hours.
[22:53] <jbicha> is it possible your index is from that weird time while gnome-software was migrating?
[22:54] <robru> jbicha: I just downloaded the index a few hours ago and have been running on it since, so yeah
[22:55] <jbicha> I'm thinking of the gap when https://launchpad.net/ubuntu/+source/gnome-software will not show the package in either zesty-proposed or zesty while it's being published
[22:56] <robru> jbicha: actually gnome-software shows here as is_valid = True which means it'd get the 5 day threshold anyway
[22:57] <robru> jbicha: no it was definitely in -proposed when I downloaded it otherwise it wouldn't be being inspected.
[23:16] <robru> slangasek: where should i send the announcement email to?
[23:20] <slangasek> robru: it should go to ubuntu-devel-announce
[23:21] <robru> slangasek: is now a good time?
[23:21] <slangasek> robru: no reason not to AFAICS; does the mail just tell people that they'll "soon" start receiving emails?
[23:22] <slangasek> it'll sit in the moderation queue anyway until a list admin looks at it
[23:22] <robru> Yeah
[23:52] <nacc> robru: nice feature!
[23:52] <robru> nacc: thanks
[23:53] <robru> Get ready for the deluge!
[23:53] <nacc> robru: although the email address in your above paste for me is not my contact address
[23:54] <nacc> robru: it is one of my two linked addresses
[23:54] <nacc> robru: but not my preferred one for lp
[23:54] <robru> nacc: it's what's on your gpg key. I'm unfortunately unable to query lp for preferred addresses
[23:55] <nacc> robru: ah i see
[23:55] <nacc> robru: that's interesting -- do you need to be logged in for that?
[23:56] <robru> nacc: yeah it needs to be logged in, which snakefruit does have credentials for, but the code is python3 and snakefruit is very old, so it only has lplib for py2. So we're unfortunately stuck with anonymous lp access for now.
[23:57] <nacc> robru: totally understood, i've had to do sort of similar things for the importer at times (as to what is visible anonymously)
[23:57] <robru> At some point snakefruit can be updated to xenial and then this code can be ported to py3 lplib