[01:55] <Pharaoh_Atem> nacc: I've verified that the extension works :)
[02:07] <darkxst> infinity, oh the symlink was borked, can you take a look at this fix http://pastebin.com/ttxZLdxP
[02:16] <infinity> slangasek: ^-- Can you sponsor/review that for Tim?
[02:50] <cyphermox> infinity: slangasek: I will sponsor that ^ if you haven't already taken care of it
[02:54] <sarnold> cyphermox: is the destination of that symlink correct? it's still /root/etc/..
[02:54] <cyphermox> the file needs to go in /root, but what it links to should be the path without /root
[02:54] <cyphermox> the diff looks correct to me
[02:55] <sarnold> thanks
[02:55] <cyphermox> this is because casper runs outside the chroot where our live system is
[02:56] <sarnold> I always think of /root as a user directory, for uid 0 .. not as a mount point. It kinda hurts my head. :)
[02:57] <cyphermox> ;)
[04:09] <darkxst> cyphermox, thanks!
[04:10] <cyphermox> np
[04:33] <tjaalton> doko: i don't have time to wait for it to get past debian NEW, there's no diff
[04:50] <Mirv> pitti: morning. if you want to look at one before I publish the silo, here's one stuck Test in progress: https://requests.ci-train.ubuntu.com/static/britney/vivid/landing-010/excuses.html
[05:40] <cpaelzer> good monring
[05:40] <cpaelzer> may be too early for a well typed morning :-)
[05:50] <ginggs_> morning pitti, thanks for htop!
[05:51] <pitti> Good morning
[05:52] <pitti> Mirv: right, let me look into the logs in some 10 mins
[06:22] <tjaalton> pitti: hi, you might remember working with mlankhorst 2y ago on xorg-lts-transitional? any idea why the packages were limited to just amd64 & i386?
[06:22] <tjaalton> this package was added to trusty to allow upgrades from lts-foo stacks
[06:22] <tjaalton> and I had no idea about it until yesterday :P
[06:23] <pitti> tjaalton: yes, I think we discussed the upgrade approach back then; but no idea why it's limited to these arches
[06:24] <pitti> tjaalton: perhaps because we only did the enablement stacks on those?
[06:25] <tjaalton> well they are built on every arch but I guess there are no desktop images for other than these
[06:26] <tjaalton> images that use an lts stack
[06:51] <pitti> Mirv: I followed up to bug 1571353
[06:51] <pitti> Mirv: so the tests actually did run, but there's something between ci train and britney that doesn't pick them up
[06:51] <pitti> Mirv: I asked robru about getting a debug log
[06:52] <robru> pitti: Hmmmmmmm?
[06:53] <robru> pitti: you want me to re enable -v on the britney runs?
[06:53] <pitti> (OTP, brb)
[06:59] <pitti> robru: yes, that would be nice; either in production, or an one-off run
[07:26] <robru> pitti: Mirv: ok I added the -v flag back, you should see the verbose logs in the next run, maybe ~1hr
[07:26] <pitti> robru: cool, thanks
[07:27] <robru> yw
[07:39] <Mirv> pitti: thank you for looking into it
[07:46] <pitti> mwhudson: so, I started another run from your branch with -s, and will let you ssh into the testbed right after the failure happens
[07:46] <pitti> mwhudson: then we can poke around
[07:46] <mwhudson> pitti: yeah that would be very useful i think
[07:47] <mwhudson> step 1: wtf is actually listening on 10.0.8.1:8443
[08:11] <Odd_Bloke> infinity: Did you see we have powerpc images at http://cloud-images.ubuntu.com/xenial/current/? ^_^  If you have the time (you don't have much else going on this week, right?), a test would be appreciated. :)
[08:12] <Odd_Bloke> (Getting them in to streams is WIP; I'm poking this along when I have a minute between tamping down release-critical fires, and it doesn't matter too much if this lands post-GA :)
[09:40] <cjwatson> nacc: lazr.restfulclient fix working its way into xenial-proposed now; thanks for the nudge
[09:56] <jtaylor> are there differences between debians ppc64el and ours?
[09:57] <jtaylor> seems like at least some compiler macros are defined in xenial that aren't in unstable
[10:01] <jtaylor> ah no the compiler reports itself as ibm oO
[10:19] <Mirv> pitti: did you get better logs now?
[10:49] <jtaylor> does someone have access to a ppc64el box for a quick test?
[10:49] <jtaylor> not necessary as I can likely fix it without access but I am curious what the compiler doing
[11:02] <pitti> Mirv: yes, I did, and I just finished writing the followup to the bug
[11:02] <pitti> robru: you can disable verbosity again, thanks for your help
[11:02] <pitti> Mirv: it's clear now what happened, I'll restart your lost test
[11:05] <Mirv> pitti: thanks a lot! the silo is already gone through QA so I was just holding off for getting this debugged which should help people in the future.
[11:05] <Mirv> pitti: interestingly the silo was already britney approved last week (which is why it went to QA queue), but at some point I noticed all of its tests, including passed ones, were restarted.
[11:05] <pitti> Mirv: ah! well, nothing lost except for some additional universe heating then :)
[11:06] <Mirv> :)
[11:06] <pitti> Mirv: hm, that's curious -- it should see the previously passed results then
[11:06] <pitti> unless the whole silo got cleared
[11:06] <pitti> or did that involve a followup upload? (this would re-trigger all tests)
[11:06] <Mirv> pitti: nothing happened in the silo, I guessed it was some sort of global restart of things.
[11:07] <Mirv> the silo has stood still since last Wednesday
[11:07] <pitti> Mirv: ok, whatever then :) I understand what's going on, I'll think about how to solve this in the least possible ugly way
[11:07] <Mirv> yet something caused that. so I noticed it from the fact that suddenly bileto showed "Running" instead of "Approved"
[11:07] <Mirv> thank you again for looking into it
[11:13] <sveinse> What is the difference from Ubuntu core and a system which is debootstrapped?
[11:16] <pitti> jtaylor: can test something for you if you want
[11:16] <jtaylor> pitti: if you have time great, I already fixed the problem but my curiousity remains :)
[11:17] <pitti> meh, no xenial schroot on the porter box; -- moving to a scalingstack instance
[11:18] <pitti> jtaylor: so what do you want me to run?
[11:19] <jtaylor> pitti: http://paste.ubuntu.com/15928177/
[11:19] <jtaylor> should be cat ftest.s, not cat test.s
[11:23] <pitti> jtaylor: http://paste.ubuntu.com/15928232/
[11:23] <pitti> jtaylor: that's actually the first piece of Fortran that I'm looking at, from the last 20 or so years :)
[11:23] <jtaylor> pitti: thx so there is an IBM in there which trips the package up
[11:24] <jtaylor> and also looks like its ubuntu specific which explains why debian is not affected
[11:24] <jtaylor> pitti: if only I could say the same ._.
[11:25] <jtaylor> still ahve to occasionally deal with f77 code, written when f77 was actually new ...
[11:25] <pitti> +  * Update the ibm branch to 20160324.
[11:25] <pitti> jtaylor: ^ in https://patches.ubuntu.com/g/gcc-5/gcc-5_5.3.1-14ubuntu2.patch
[11:25] <pitti> jtaylor: can I delete that ppc instance again, or do you still need anythign?
[11:26] <jtaylor> pitti: no thats it thanks
[11:26] <jtaylor> the ibm in the output in ubuntu is fine its just the package that does a pretty dumb check
[11:26] <jtaylor> it just does essentially grep IBM = ibm compiler
[11:26] <Laney> nice, I was eyeing that failure
[11:26] <jtaylor> Laney: the latest upload has fixed it
[11:27] <Laney> I see that
[11:27] <jtaylor> I did check debian if all arches work first but this was ubuntu specific :/
[11:40] <Laney> barry: sounds like https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/t/tox/20160419_041620@/log.gz is caused by the new virtualenv
[12:13] <barry> Laney: see, i don't quite understand that because 15.0.1+ds-2 fixes it for me locally :(
[12:15] <barry> Laney: and the same versions work in an sid chroot
[12:15] <barry> *and* a xenial chroot
[12:15]  * barry retries
[12:16] <barry> at least it will give me time to get some breakfast and caffeine first ;)
[12:16] <Laney> :(
[12:22] <Laney> barry: adt-run --output-dir /tmp/virtualenv/out --timeout-copy=6000 --setup-commands 'if grep -q trusty /etc/lsb-release; then apt-get install -y build-essential; fi; apt-get purge --auto-remove -y ubuntu-snappy-cli || true' --apt-pocket=proposed=src:python-virtualenv --apt-upgrade tox --env=ADT_TEST_TRIGGERS=python-virtualenv/15.0.1+ds-2 --- qemu ~/temp/adt-xenial-amd64-cloud.img
[12:22] <Laney> this makes it reproduce
[12:22] <Laney> with an adt-buildvm-ubuntu-cloud thing
[12:50] <barry> Laney: okay thanks.  let me see if i can figure out what's up
[13:08] <barry> Laney: so the problem with your reproducer is that it doesn't pick up python-pip-whl 8.1.1-2 which is where one half of the fix is.  if you add ,src:python-pip to the --apt-pocket option, then it does pick up 8.1.1-2 and all the tests pass.  notice in the excuses log file that it is picking up pip 8.1.1-2 but it's still picking up virtualenv 15.0.1+ds-1 but the other half of the fix is from 15.0.1+ds-2.
[13:08] <barry> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/p/python-virtualenv/20160418_153721@/log.gz
[13:08] <barry> Laney: so why isn't excuses picking up both pip 8.1.1-2 and virtualenv 15.0.1+ds-2?
[13:09] <barry> similarly, the tox failure is picking up python-pip-whl 8.1.1-1 and virtualenv 15.0.1+ds-2
[13:10] <Laney> barry: It's using the smallest amount of stuff possible from -proposed
[13:10] <Laney> do you want a Breaks or something?
[13:11] <barry> Laney: i guess, if that'll make sure the right versions of both are picked up
[13:11] <Laney> barry: We could retry with both, but it seems correct to add it if you need both pieces to have working stuff
[13:11] <barry> Laney: let me look
[13:12] <barry> doesn't help that debian broke my sbuild ;)
[13:13] <barry> maybe just add a Depends: python-pip-whl (>= 8.1.1-2) to virtualenv? (and similar to tox)
[13:13] <barry> Laney: ^^
[13:27] <Laney> barry: Probably just virtualenv is enough?
[13:32] <barry> Laney: possibly.  let's try that first and see.  i'll upload to debian momentarily and syncpackage it over when lp picks it up.  if that's not good enough i'll add a version constraint to tox on virtualenv
[13:32] <barry> Laney: http://paste.ubuntu.com/15929623/
[13:32] <Laney> barry: That'll force the new one to be installed, which I think is Good Enough
[13:32] <barry> Laney: +1
[13:33] <Laney> feel free to syncpackage --no-lp imho
[13:33] <barry> Laney: ack
[14:11] <caribou> Excuse the noob's question but I've been running Xenial since the beginning so why is the archive pushing me >500 packages two days from release ?
[14:12] <gQuigs> caribou: what packages?   I maybe got 30 in last two days
[14:14] <caribou> gQuigs: well, 629 packages to be exact so most of everything including LibreOffice, vim, xorg,juju
[14:15] <rbasak> caribou: are you using a mirror that has just been kicked into life perhaps or something?
[14:15] <caribou> rbasak: archive.ubuntu.com
[14:15] <rbasak> There have been many minor (bugfix) updates flowing through recently BTW.
[14:18] <cjwatson> libreoffice was last changed in xenial on 2016-04-08
[14:19] <gQuigs> caribou: I last updated libreoffice on 2016-04-13
[14:19] <cjwatson> perhaps your apt-get update was failing for some reason
[14:20] <caribou> cjwatson: I was on training last week, I didn't do any upgrade during this time so the dates make sense
[14:20] <gQuigs> caribou: do you have IPv6 by any chance?
[14:20] <gQuigs> oh ok
[14:20] <caribou> gQuigs: no still ipv4 but looks like it's normal, sorry for the noise
[14:20] <cjwatson> there you go, so not "two days before release" :)
[14:21] <caribou> cjwatson: indeed
[14:56] <pitti> stgraber, apw, smoser: FYI, I filed bug 1572188 about the underlying bug for the weird lxc test failures
[14:57] <nacc> cjwatson: thanks!
[14:57] <nacc> Pharaoh_Atem: awesome, thanks!
[14:57] <smoser> pitti, apt-get install distro-info
[14:57] <pitti> smoser: ooh
[14:58] <pitti> smoser: curious, why does it work for precise and trusty then?
[14:58] <smoser> $ grep KNOWN_RELEASES /usr/bin/ubuntu-cloudimg-query
[14:58] <smoser> KNOWN_RELEASES="hardy karmic lucid maverick natty oneiric precise quantal
[14:58] <smoser> 	local releases="${KNOWN_RELEASES}" r=""
[14:58] <pitti> some hardcoded fallback list? (I thought this queries the remote json for available releases, not distro-info)
[14:58] <pitti> aah
[14:59] <smoser> ubutnu-cloud-image-query just needs *really needs* to be replaced by something reading the stream data.
[15:02] <pitti> smoser: thanks for this
[15:02] <stgraber> I guess it recommends distro-info but doesn't depend on it or something?
[15:02] <pitti> yep
[15:02] <stgraber> and we somehow had some images that did have it for whatever reasons, explaining the random results
[15:03] <pitti> stgraber: I think I know this
[15:03] <stgraber> pitti: is distro-info something we should have in the adt image or do you prefer a new test dep on lxc instead?
[15:03] <pitti> stgraber: for a while now creating adt images on lcy01 has failed
[15:03] <smoser> it is a recommends.
[15:03] <stgraber> ah, so old images have it, new ones do or something
[15:03] <pitti> stgraber: so sometimes we run tests on full fat cloud images (on lcy01), and sometimes on adt images (on lgw01 or bos01)
[15:03] <pitti> and the latter are minimized and presumably don't have distro-info
[15:03] <stgraber> smoser: yeah, won't do us much good since adt doesn't pull recommends
[15:04] <pitti> stgraber: well, you can tell it to
[15:04] <pitti> Either add "Restrictions: needs-recommends" or add "distro-info" as a test dependency
[15:04] <pitti> (just wrote that to the bug)
[15:04] <stgraber> oh, then I guess I should do that everywhere because that's kinda what we expect with it being the distro default :)
[15:04] <smoser> "The Recommends field should list packages that would be found together with this one in all but unusual installations. "
[15:04] <pitti> well, depends what you want to test
[15:04] <stgraber> I want to test the thing my users will get
[15:04] <stgraber> which means, having the recommends
[15:04] <smoser> unless you want to test unusual installations :)
[15:04] <pitti> if you want to verify that your recommends are really optional, then you don't want that
[15:05] <hallyn> for days now i've not been able to update my xenial laptop, alwyas get Hash Sum mismatches
[15:05] <stgraber> well, someone installing lxc with --no-install-recommends wouldn't be getting the templates at all :)
[15:05] <pitti> stgraber: anyway, let me know if I should upload lxc with that, or you want to do it from teh airpirt
[15:05] <pitti> airport too
[15:05] <smoser> hallyn, hm... those shoudl be gone the way of the dinosaur
[15:05] <stgraber> pitti: I can do it
[15:06] <hallyn> smoser: ...
[15:06] <smoser> https://bugs.launchpad.net/launchpad/+bug/1430011
[15:06] <smoser> and http://www.chiark.greenend.org.uk/~cjwatson/blog/no-more-hash-sum-mismatch-errors.html
[15:06] <pitti> hallyn: using apt-cacher-ng by any chance?
[15:06] <smoser> so that is interesting that you see it.
[15:06] <hallyn> smoser: then i call that a big fat fail :)
[15:06] <hallyn> yeah
[15:06] <hallyn> i was thinking i should turn it off for a bit, but...
[15:06] <smoser> There will still be some people who won’t yet benefit from this. debmirror doesn’t support by-hash yet; apt-cacher-ng only supports it as of xenial, although there’s an easy configuration workaround
[15:06] <pitti> hallyn: I had lots of troubles with that until cjwatson helpfully pointed out /etc/apt-cacher-ng/backends_ubuntu
[15:06] <smoser> (see the cjwatson link there, hallyn)
[15:06] <pitti> hallyn: for me this was pointing to "de.archive.ubuntu.com",  i. e. it would divert all requests to *archive.ubuntu.com to that
[15:07] <pitti> hallyn: which caused hash sum mismatches to no end
[15:07] <smoser> pitti, we can update cloud-utils if yiou want.
[15:07] <hallyn> pitti: so you removed it?  pointed it to locahost?
[15:07] <smoser> to contain 'xenial'
[15:07] <pitti> I changed that to just a.u.c. and I've never gotten it ever since
[15:07] <hallyn> a?
[15:07] <cjwatson> I raised this in https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=819852; no response yet
[15:07] <cjwatson> a = archive
[15:07] <pitti> hallyn: archive.ubuntu.com
[15:08] <hallyn> cjwatson: oh, so i should turn it off?
[15:08] <pitti> hallyn: well, full contents is: http://archive.ubuntu.com/ubuntu/
[15:08] <hallyn> pitti: ok, thats where mine is pointing
[15:08] <stgraber> pitti: uploaded
[15:08] <hallyn> no, us.archive...  ok lemme try dropping us.
[15:08] <pitti> hallyn: hmm, so it's not that then; for me that was it
[15:08] <cjwatson> hallyn: that's not what I said :)
[15:08] <cjwatson> hallyn: dropping us.archive.ubuntu.com from /etc/apt-cacher-ng/backends_ubuntu will probably indeed deal with it for the moment
[15:08] <pitti> stgraber: cheers
[15:08] <hallyn> cjwatson: i'm having a hard time following
[15:08] <stgraber> pitti: didn't test to see if we may need more than that though, not enough bandwidth for that, but since all the other tests passed, that should really be it
[15:08] <cjwatson> hallyn: just interleaved IRC conversations
[15:09] <cjwatson> hallyn: my last-but-one statement is in agreement with pitti, so do that
[15:09] <hallyn> neither emptying the file nor using http://archive.ubuntu.com/ubuntu/ seems to help
[15:10] <pitti> stgraber: should be fine
[15:10] <hallyn> do i need to apt clean?
[15:10] <cjwatson> hallyn: apt-get -oDebug::Acquire::http=1 -oDebug::Hashes=1 update
[15:10] <cjwatson> hallyn: apt clean -> no, that's entirely useless here
[15:12] <hallyn> http://paste.ubuntu.com/15931040/ and http://paste.ubuntu.com/15931043/
[15:14] <pitti> that doesn't look like a hash sum mismatch
[15:14] <pitti> just google's repo not being signed enough
[15:14] <pitti> I had that too, I just removed it
[15:14] <cjwatson> indeed, I see no hash sum mismatches there.
[15:15] <cjwatson> I'm happy to debug a hash sum mismatch, but only if you can show me update output with those debug options that actually exhibits a hash sum mismatch
[15:15] <hallyn> d'oh, sorry, http://paste.ubuntu.com/15931102/
[15:15] <hallyn> i pasted the same file twice
[15:15] <cjwatson> that's a mismatch on debs, rather than on indexes
[15:15] <cjwatson> which suggests apt-cacher-ng has cached corrupt data

[15:15] <hallyn> ok
[15:15] <cjwatson> you may shrug but it's important!
[15:16] <cjwatson> I would probably rm -rf the relevant bit of apt-cacher-ng's cache and start again
[15:16] <cjwatson> it's clearly got itself hopelessly lost
[15:16] <rbasak> There was an apt bug causing deb download corruption.
[15:16] <hallyn> ok, lemme rm -rf its cache
[15:16]  * rbasak looks
[15:16] <cjwatson> those files don't change content without changing URL and never have
[15:17] <hallyn> so it seems to me this should be self-healing
[15:17] <cjwatson> I've seen acng corrupting data in the past, but not for a while
[15:17] <rbasak> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=810796
[15:17] <hallyn> i'm on the road,  there's a good chance acng isn't entirely to blame,
[15:17] <rbasak> Should be fixed in the archive.
[15:17] <cjwatson> it can probably only be self-healing with cooperation from acng
[15:18] <rbasak> But if it's regressed or soemthing, then turning off HTTP pipelining may help.
[15:18] <cjwatson> if it's cached lies and persistently continues to serve them, there's not a whole lot apt can do
[15:18] <hallyn> cjwatson: as a naive user, seems like it should be able to tell acng "that doesn't seem right, try again"
[15:19] <cjwatson> hallyn: that still requires cooperation from acng ...
[15:19] <hallyn> of course
[15:19] <hallyn> why is that bad?
[15:19] <cjwatson> it's not, but it's what I said above and you appeared to be contradicting me?
[15:20] <hallyn> hm, no, wasn't contradicting you
[15:20] <cjwatson> AFAICS apt-cacher-ng does not implement the relevant cache-busting headers at all
[15:20] <hallyn> there are such headers?
[15:20] <cjwatson> it just entirely ignores stuff like Pragma: no-cache and Cache-Control
[15:21] <hallyn> might be something i could look into this spring
[15:22] <cjwatson> https://tools.ietf.org/html/rfc2616#section-14.9
[15:24] <cjwatson> the thing that's needed would be for it to implement Cache-Control: max-age=<seconds>, I think
[15:25] <hallyn> is apt sending that now?
[15:25] <cjwatson> no, but it's the basic mechanism that would be necessary to recover from this sort of thing
[15:26] <hallyn> seems like 'fetch url1;  hash some mismatch; fetch url1?refetch' would more directly fix it
[15:26] <cjwatson> apt could at least conceivably send it as an attempt to recover from a hash mismatch on a package
[15:26] <hallyn> but i guess that doesn't fit into the spec
[15:26] <cjwatson> hallyn: the "refetch" step in your pseudocode would need to be implemented by adding the Cache-Control: max-age=0 header
[15:26] <hallyn> right
[15:27] <hallyn> ok, maybe i'll look into that, thx
[15:27] <cjwatson> np
[15:27] <cjwatson> just for clarity, this is unrelated to any of the stuff I changed recently
[15:27] <hallyn> cjwatson: right,
[15:30] <hallyn> and i think i know wha thappened - damned internet provider a few days ago redirected requests to their signin page and corrupted apt-cache-ng.  so yeah i want to code the automatic fix for that
[15:31] <cjwatson> right, captive portals are the work of the devil
[15:31] <cjwatson> apt itself is a lot better at dealing with those than it used to be
[15:31] <cjwatson> i.e. it doesn't save stuff that doesn't validate
[15:31] <cjwatson> but I don't think acng is clever enough for that :-/
[15:32] <cjwatson> so that's a separate fix, if acng understood the current state of the archive it's trying to fetch well enough, it could just not cache resources that can't possibly fit into it.  I don't know if that's feasible within acng's design
[15:32] <hallyn> and then once google chrome gets redirected it caches that value, and send sme back to the portal every time until i go to settings to clear all cached pages :)
[15:32] <hallyn> hm, yeah, that could be simpler
[15:32] <hallyn> and good enough for me
[15:33] <cjwatson> I suspect that right now it doesn't parse the archive's index files in enough detail to be able to do that
[15:34] <cjwatson> probably something to discuss with upstream before thinking about implementing it
[15:36] <cyphermox> hallyn: NM can help you distinguish if you're behind a captive portal, if it helps
[15:36] <hallyn> cyphermox: NM can't even find my mr3020 hotspot half the time
[15:37] <cyphermox> o.O?
[15:37] <hallyn> cyphermox: but the problem is captive portals which randomly and frequently recet
[15:37] <hallyn> (crappy-ass tengo internet in particular)
[15:37] <hallyn> reset even
[15:38] <cyphermox> yeah, but that's what I'm saying, it can poll some website of your choosing, look for a string, every $interval
[15:38] <hallyn> so it's not at connect time - apt is going along fine, then it resends me to the portal
[15:38] <hallyn> right but interval isn't actually regular.  sometimes it's every day, sometimes every 2 minutes (at the same location)
[15:38] <cyphermox> and flip a key available in DBus that tells whether you have local or global connectivity (global meaning said website got the string)
[15:38] <hallyn> they really are broken...
[15:38] <cyphermox> ok
[15:38] <hallyn> i had a script doing it by hand, every 5 minutes - still not good enough :)
[15:39] <cyphermox> ok
[15:39] <cyphermox> threaten them with less money?
[15:39] <hallyn> cyphermox: now maybe i should be doing something like keeping a connection open and detecting when it's hung
[15:39] <hallyn> hah, the curse of free
[15:39] <cyphermox> oh ;)
[15:39] <hallyn> i *should* get satelite internet.  but $$
[15:39] <cyphermox> hallyn: what kind of internet right now?
[15:40] <hallyn> now meanwhile, yes, i shoudl file a bug on NM and my hotspot.  soemtimes it just doesn't find it
[15:40] <cyphermox> maybe you could do some keepalive magic.
[15:40] <hallyn> cyphermox: at this very moemnt, it's tengo internet at an rv park in austin.
[15:40] <cyphermox> right, but that's wifi?
[15:40] <cyphermox> or dialup?
[15:40] <hallyn> oh, yeah.
[15:41] <hallyn> so a ubiquity m.2 rocket connected to tengo internet, with tp-link mr-3020 serving that to other devices
[15:41] <hallyn> sometimes NM doesn't find th emr-3020, so i use scripts manually using wpa-supplicant :(
[15:41] <hallyn> 'manually'
[15:41] <hallyn> what kind of logs can i provide for a bug report?
[15:42] <cyphermox> pretty much just syslog would have everything
[15:42] <hallyn> 'sudo dmesg', or journalctl -u network-manager or something?
[15:42] <cyphermox> NM just gets whatever wpasupplicant returns, but it has some issues in wily, and different issues in xenial
[15:42] <cyphermox> nah, /var/log/syslog
[15:42] <hallyn> i'm on xenial atm,
[15:43] <hallyn> ok, i'll switch back to n-m after a meeting and file a bug when it happens
[15:43] <hallyn> thx
[15:43] <hallyn> i should see if nmcli usage has changed recently too....
[15:59] <nacc> slangasek: fyi, debian testing may just remove php-horde-mongo; not sure if we'd want to follow suit (it's one of our two remaining known-broken packages). Only has reverse-recommends in the archive, and will probably need to add a new package (https://github.com/mongodb/mongo-php-library) which Debian is not planning on adding
[16:00] <slangasek> nacc: yes, removal is fine/appropriate; file a bug?
[16:01] <nacc> slangasek: ack, will do
[16:03] <bdmurray> pitti: Will you be testing the SRUs in bug 1560797? If not I can do it.
[16:12] <Ajith> Hi
[16:20] <Ajith> Hi my name is Ajith kumar, I am a newbie to the world of Linux environment. I started working with Ubuntu for the past few weeks and i am eager to contribute to the the vibrant community and i have absolutely no idea how to get started.Can some Guide me what to do?  P.S:I am a Computer science student and interested to work in coding part.
[16:23] <Pici> !contribute | Ajith there are some good links here
[16:28] <Ajith> Thank you for your help ubottu and Pici
[16:54] <jtaylor> doko: fyi a numpy delta and the fftw delta could now be dropped due to build depends on universe for main being allowed now
[16:55] <jtaylor> numpy is just for plots in the docs and fftw is an mpi library which can stay in universe
[17:17] <slangasek> nacc: archive removals, ~ubuntu-archive should be subscribed (done for bug #1564103)
[17:19] <nacc> slangasek: ack, was just about to, sorry
[17:24] <slangasek> nacc: ok - figured that might be the case, but you subscribed me first so I interfered ;)
[17:24] <nacc> slangasek: absolutely, appreciate it :)
[17:32] <pitti> bdmurray: I'll do some tests, but if you have a setup ready for doing upgrade tests with that, that'd be appreicated of course
[17:33] <bdmurray> pitti: I did wily already
[17:33] <pitti> bdmurray: oh wow, thanks
[18:21] <tkamppeter> infinity, hi
[18:25] <infinity> tkamppeter: I'm getting there.
[18:25] <infinity> tkamppeter: You're in a queue.
[18:26] <sarnold> .. all alike
[18:27] <tkamppeter> OK
[18:27] <infinity> pitti: You still around?
[19:00] <pitti> infinity: I am now (for another hour or so)
[19:00] <Laney> pitti: did you do anything to fix lxd before?
[19:00] <pitti> Laney: sorry, before what?
[19:00] <infinity> pitti:
[19:00] <infinity> Apr 19 12:24:20 nosferatu systemd-fsck[574]: /dev/sda1: 7 files, 7094/489976 clusters
[19:01] <infinity> pitti: ^-- That line's hitting the console on boot.   lolwut.
[19:01] <Laney> It had some proxy / network problem, but then started passing
[19:01] <Laney> The latest upload is failing again
[19:01] <Laney> Wondering if you did some magic or if it's a real bug
[19:01] <infinity> pitti: Purely cosmetic, but between that and 1 line from the kernel, we're close to a completely quiet boot.
[19:02] <pitti> Laney: hm, no; my first reaction was that it might depend on whether it runs on lcy01 (standard cloud images) vs. lgw01 (minimized adt images), but we purge lxd on lcy01 too
[19:02] <pitti> infinity: oh dear, I smell some plymouth ordering/race again
[19:03] <pitti> Laney: not sure what you mean, http://autopkgtest.ubuntu.com/packages/l/lxd/xenial/amd64/ looks pretty good?
[19:03] <pitti> Laney: or do you mean lxc?
[19:03] <Laney> pitti: oh, whoops, brain fart, I mean snapd
[19:03] <Laney> s/lxd/snapd/g
[19:04] <pitti> Laney: don't do that :)
[19:04] <pitti> infinity: oh, wait, yeah -- that's initramfs
[19:05] <pitti> infinity: when we merged that from debian the last time, fsck and r/w mount of / moved into initramfs
[19:05] <infinity> pitti: Oh, right.
[19:05] <infinity> pitti: So, would be nice to figure out how to shut that up on !error.
[19:05] <pitti> back then I mentinoed that this will give us non-pretty fsck for root fs, but we didn't seem overly concerned
[19:05] <pitti> infinity: well, fsck might take several minutes, you do want to see this
[19:06] <infinity> If there's an actual fsck, that's a different case than the mount-time fake fsck.
[19:07] <pitti> infinity: yeah, if it's quick it would be nice to hide indeed
[19:08] <pitti> infinity: ah, the thing you quoted above is a "short" one?
[19:08] <infinity> pitti: Yeah, that wasn't a "real" fsck, that's the "you asked me to fsck a clean filesystem, so I didn nothing" fsck.
[19:08] <infinity> pitti: ie: I see it on every boot.
[19:09] <infinity> Oh!
[19:09] <infinity> That's not even my root.
[19:09] <infinity> That's the EFI filesystem.
[19:09] <infinity> Hence having "7 files". :P
[19:11] <pitti> ah ok, so that should be under the control of the real root then
[19:12] <infinity> Indeed.
[19:12] <infinity> Hence why it's systemd-fsck, and in the journal.
[19:12] <pitti> Laney: I interpreted http://autopkgtest.ubuntu.com/packages/s/snapd/xenial/amd64/ as "1.9.3 was broken", 1.9.4 fixed, and 2.0.2 introduced another failure
[19:13] <infinity> But maybe the one we saw was from the initramfs.
[19:13] <pitti> Laney: and the first and second result both ran on lgw (i. e. on a minimized adt image), so not much infra difference there
[19:14] <infinity> pitti: We're going to have another look before blaming systemd.  I think your theory makes more sense.
[19:14] <pitti> Laney: did you already try running this locally?
[19:14] <Laney> pitti: I'm suspicious because the failures look the same (i.e. what we created a debug instance for mvo to mess around on the other day)
[19:14] <pitti> infinity: I'm trying to reproduce with a fake fsck which takes very long
[19:14] <Laney> Didn't run it myself, will do.
[19:15] <pitti> infinity: it wouldn't surprise me at all if any of this regressed :/
[19:15] <pitti> Laney: the "error: no snaps found for "hello-world"
[19:15] <pitti> ...thingy?
[19:15] <Laney> pitti: Yeah
[19:16]  * Laney runs it
[19:17] <mvo> pitti, Laney: I think its a store issue, I work on this with the store team as we speak
[19:17] <Laney> hey mvo!
[19:17] <Laney> you mean a real bug?
[19:17] <Laney> is that what you found out the other day?
[19:19] <mvo> pitti, Laney: I am waiting for a new rollout, I think this will fix it
[19:19] <mvo> pitti, Laney: however there might be yet another issue, but we fixed the http proxy thing so that should be ok
[19:19] <mvo> the store also moved to a cdn but that should be ok with the proxy fix we did
[19:20] <pitti> infinity: just FAOD, this is with "splash", right?
[19:21] <mvo> Laney, pitti: so hopefulyl in ~1h we have a new store rollout and I will retrigger the tests (I hope I can actually do that)
[19:21] <Laney> yeah, you can if you can upload it
[19:22] <Laney> Ah yeah, this fails locally
[19:22] <pitti> mvo: you can test the retry button now on http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd (the machinery is mostly idle, so no harm)
[19:23] <mvo> pitti: excellent, thanks. will do as soon as the store is updated
[19:23] <infinity> pitti: With splash, yes (though you only catch it for a brief flickery moment), shows without too, obviously.
[19:25] <pitti> infinity: hmm, I created a partition for /mnt in fstab, and I get plymouth-y pretty fsck
[19:25] <pitti> (with a fake fsck that takes long)
[19:26]  * pitti runs update-initramfs to get that into the initrd
[19:27] <pitti> for the root fs I seem to have the opposite problem: I *don't* get the fsck output in initramfs
[19:27] <pitti> oh, I see -- it uses bash, and that's not in the initrd
[19:29] <infinity> And shouldn't be...
[19:29] <pitti> right, I just need to change the mock to use sh
[19:35] <infinity> pitti: What have we decided WRT snapd?
[19:35] <pitti> infinity: AFAICT, wait for the store to get fixed (< 1 h) and retrigger the tests?
[19:35] <pitti> that's what mvo asked above, at least
[19:36] <pitti> otherwise I'm fine to hint it in if it blocks stuff
[19:37] <infinity> pitti: Well, it sort of blocks some world rebuilds slightly.
[19:38] <mvo> go and hint if it blocks stuff
[19:38]  * pitti goes and hints
[19:39] <pitti> I went and I hinted :)
[19:41] <cyphermox> !regression-alert
[19:41] <cyphermox> https://launchpad.net/ubuntu/+source/samba/2:3.6.25-0ubuntu0.12.04.2
[19:41] <cyphermox> https://bugs.launchpad.net/ubuntu/+source/samba/+bug/1572122
[19:41] <cyphermox> ^ someone pointed me to this
[19:42] <cyphermox> mdeslaur: ^
[19:42] <cyphermox> fwiw; I have two more links about the issue: http://serverfault.com/questions/771388/how-can-i-fix-samba-3-6-25-the-trust-relationship-between-this-workstation-and   http://askubuntu.com/questions/759123/samba-23-6-25-0ubuntu0-12-04-2-as-pdc-samba3-nt4-domain-windows-machines-lost
[19:43] <teward> cyphermox: I should point out this sounds like a known issue in Microsoft's recent patches
[19:43] <teward> (not entirely related, but lots of domain auth issues on w7 after recent patches)
[19:43] <mdeslaur> cyphermox: yeah, it's broken
[19:43] <teward> ^ thats what i guessed though
[19:43] <cyphermox> teward: no idea, I don't know Samba well enough to know, and don't typically run any Windows machines here
[19:43] <mdeslaur> have to wait for fixes from upstream/redhat
[19:43] <cyphermox> mdeslaur: ok
[19:44] <infinity> cyphermox: stgraber and I already yelled at mdeslaur about it.
[19:44] <infinity> (After stgraber's mom yelled at him)
[19:44] <mdeslaur> infinity: unrelated issue
[19:44] <cyphermox> infinity: sorry, I scrolled back and didn't see.
[19:44] <infinity> mdeslaur: Oh.  Two similar breakages?
[19:45] <cyphermox> what's the other issue?
[19:45] <slangasek> cyphermox: can you remind me where that regression-alert is documented? because I'd really like to deprecate it :)  we ought to just use the regression-updates tag on bugs
[19:45] <infinity> Forcing TLS unconditionally.
[19:45] <mdeslaur> infinity: the other one isn't similar, it's that the whole point of the samba update was to disable plain text ldap
[19:45] <infinity> mdeslaur: Well, similar from the bug subject, I didn't click and read it. :P
[19:45] <rbasak> slangasek: https://wiki.ubuntu.com/StableReleaseUpdates#Regressions
[19:46] <cyphermox> slangasek: https://wiki.ubuntu.com/StableReleaseUpdates#Regressions
[19:46] <mdeslaur> there are currently 4 different regression from the samba badlock updates
[19:46] <slangasek> infinity: ^^ can I rip !regression-alert out of there? :)
[19:46] <infinity> slangasek: Go nuts.
[19:46] <Unit193> slangasek: Want the trigger gone from ubottu?
[19:47] <rbasak> It is useful to be able to be heard on occasion, as opposed to wondering if somebody's about for something one things is important.
[19:47] <rbasak> (and time-critical)
[19:47] <rbasak> I mean not for any old regression, but one that is actively breaking users and might be worth suspending.
[19:49] <slangasek> rbasak: well, the trigger in question also has a somewhat stale list of people to highlight
[19:49] <rbasak> That's true.
[19:49] <Unit193> Could update it.
[19:50] <rbasak> I suggest updating it and updating the docs to suggest that it be used only in more restricted circumstances.
[19:50] <mdeslaur> feel free to add me to that list
[19:51] <cyphermox> I wouldn't mind seeing those pings either
[19:51] <Odd_Bloke> Yeah, the one time I used it it was massive overkill.
[19:51] <Odd_Bloke> Had I realised what it would do, I would just have mentioned it in here and seen what happened.
[19:51] <rbasak> (by an Ubuntu dev perhaps, if not ask for an Ubuntu dev to check on the same channel, and only if suspending the update would be helpful)
[19:53] <pitti> infinity: I finally have an initramfs compatible mock fsck, but when I  boot (the VM) with the default quiet splash $vt_handoff, I just keep the slightly purple plymouth screen and the initrd's fsck happens on VT7
[19:53] <pitti> meh
[19:53] <cyphermox> rbasak: I don't think it's used that often anyway
[19:53] <cyphermox> and not for just any regression either
[19:53] <pitti> I see it being used once a month or less
[19:53] <cyphermox> right
[19:54] <cyphermox> I certainly wouldn't go nuts for a NM regression ;)
[19:54] <cyphermox> shim/grub/boot stuff, maybe more.
[19:54] <infinity> pitti: S'ok.  I'll sort this one out with Andy, lay blame, and fix it in an SRU.  Perfectly pretty boot isn't RC, it's just nice to have. :P
[19:54] <pitti> infinity: did we actually ever manage that?
[19:54] <rbasak> Well, an NM regression in an SRU I'd say is important. Depending on what it is. Since it could break users from updating to a regression fix.
[19:55]  * pitti still remembers some lonesome kernel driver message in quiet mode
[19:55] <cyphermox> rbasak: you can usually still get wired, and the big bad regressions we do catch ahead of time
[19:56] <pitti> infinity: http://people.canonical.com/~pitti/scripts/fsck-mock-initrd is the mock I replaced /sbin/fsck with, FTR
[19:56] <ogra_> pitti, until u upgraded to xenial my XPS13 never showed me anything but plymouth til lightdm (now i have two  lines of fsck output since the upgrade)
[19:56] <ogra_> so yes, at least on preinstalled OEM hardware we achieved it :)
[19:57] <pitti> we merged initramfs-tools like three months ago, this can hardly be a new thing?
[19:57] <rbasak> cyphermox: not everyone can get wired. This laptop I'm on cannot, and I don't have a dongle that'll work handy.
[19:57] <pitti> so seeing fsck output was actually known; the bit that's not known is *not* seeing it, i. e. hiding it behind plymouth if fsck happens in the initrd
[19:57] <infinity> pitti: Probabaly not new, I think I was blaming the kernel unti lnow.
[19:57] <pitti> actually, we did know that too
[19:57] <infinity> pitti: Don't worry about it.
[19:57] <infinity> pitti: I'll worry for both of us. :P
[19:58] <rbasak> Anyway, my point is that some regressions are bad, and I'd like to shout (and have a good chance of being heard) about time critical ones. That's all.
[19:58] <pitti> infinity: okay :) I guess bedtime then
[19:58] <cyphermox> rbasak: don't upgrade for my next upload then, we started dropping wifi, it was too broken ;P
[19:58] <cyphermox> just kidding, of course
[19:58] <rbasak> :)
[19:59] <pitti> cyphermox: actually, NM 1.2 landed remarkably quietly, well done
[19:59] <rbasak> "wifi support removed due to unreliability issues"
[19:59] <slangasek> yeah, only joking, we've been dropping wifi forever
[19:59] <cyphermox> pitti: so you say.
[19:59] <cyphermox> slangasek: ah ah only serious
[19:59] <rbasak> "tinfoil DoS vulnerability" (cover the aerial)
[19:59] <slangasek> pitti: a little too quietly, right cyphermox?
[20:00]  * slangasek looks at his empty logs
[20:00] <cyphermox> it's not a murder, but it's not as pretty as it seems either
[20:00] <pitti> well, it's not like I'm reading NM bugs, but I didn't hear any complaints
[20:00] <cyphermox> slangasek: on that subject, would you mind bringing up logging in wpasupplicant to 11 and looking if the logging gets better?
[20:00] <slangasek> cyphermox: if you give me directions how
[20:01] <Odd_Bloke> slangasek: It's one louder.
[20:01] <slangasek> Odd_Bloke: look over there, it's a cloud shaped like a velociraptor
[20:01] <pitti> xnox: http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#qemu seems to make nova unhappy (uninstallable), can you have a look?
[20:02] <cyphermox> slangasek: add many -d 's to the Exec line in /usr/share/dbus-1/system-services/fi.w1.wpa_supplicant1.service
[20:02] <cyphermox> -dd or -ddd would be good
[20:03] <cyphermox> it *will* log a lot more though
[20:04] <pitti> meh, what's up with s390x tests
[20:04] <slangasek> cyphermox: ok.  also the wireless hasn't dropped since yesterday so now it's teasing us
[20:04] <Unit193> cyphermox: So that'd be add you and md, drop Riddell, Scott, skaet, and SpamapS?
[20:04] <cyphermox> why do I always get the heisenbugs?
[20:04] <cyphermox> Unit193: I suppose yeah, unless slangasek really wants to drop it completely
[20:04] <infinity> pitti: I see no reason that should actually be true.
[20:05] <slangasek> cyphermox, Unit193: I honestly don't think it's useful; I think rbasak knows how to get ahold of SRU team members without it, and generally it renders for me as a contentless highlight well after I've read the bug in email (if the bug is tagged appropriately)
[20:05] <slangasek> if you want to omit me from the highlight list that is also ok ;)
[20:06] <cyphermox> if it's not documented, why bother keeping it?
[20:08]  * rbasak shrugs
[20:08] <slangasek> if someone who knows about it wants it there and wants to use it, I don't mind it being there and won't tell other people how to run their bot
[20:08] <rbasak> I don't particularly mind either way.
[20:08] <rbasak> Since I can always highlight people manually if I feel the need as you point out I suppose.
[20:09] <infinity> I don't read mid-line highlights anyway.
[20:09] <rbasak> As long as it doesn't result in some additional delay for some serious could-have-acted regression.
[20:09] <infinity> So lists don't work for me.
[20:10] <rbasak> (I only recall having found one or two since I started Ubuntu development in 2011)
[20:10] <Unit193> So I can talk about infinity all I want and he'd not see it?  Awesome. :D
[20:10]  * Unit193 ducks.
[20:11] <rbasak> I don't particularly mind either way> I suppose that's different to what I said earlier. I'm weakening my objection.
[20:15] <Unit193> !forget regression-alert
[20:15] <Unit193> cyphermox: There you go.
[20:22] <rbasak> Does reverse-depends tell me about the release pocket or the proposed pocket?
[20:22] <tumbleweed> release
[20:22] <rbasak> OK, thanks
[20:33] <pitti> The following packages have unmet dependencies:
[20:33] <pitti>  qemu-system : Depends: qemu-system-s390x
[20:33] <pitti> infinity: ^ my xenial-proposed schroot says there is a problem -- maybe just publisher delay from binNEW or so?
[20:33] <pitti>  qemu-system-s390x | 1:2.5+dfsg-5ubuntu9 | xenial-proposed | s390x
[20:33] <pitti> it doesn't exist on any arch but s390x
[20:33] <pitti> but all arches depend on it
[20:34] <pitti> xnox: ^
[20:34] <infinity> pitti: Oh.
[20:34] <infinity> pitti: Yeahp, that's a bug.
[20:34] <slangasek> infinity, pitti: shall I fix?
[20:34] <infinity> slangasek: Go nuts, if you know how.
[20:34] <Laney> Three uploads the charm
[20:34] <infinity> slangasek: The qemu packaging is whack, yo.
[20:34] <pitti> is it meant to exist on all arches, or is the dep only meant to exist on s390x?
[20:34] <infinity> No, it's meant to only exist on s390x due to not having system emulation.
[20:34]  * pitti guesses/hopes the former, would be nice :)
[20:34] <slangasek> it's a kvm implementation, should not exist on other archs
[20:34] <infinity> qemu-system shouldn't depend on it.
[20:34] <pitti> ah, ok
[20:35] <infinity> Note qemu-system doesn't depend on qemu-system-aarch64 for the same reason, so there should be precedence in the packaging.
[20:38] <Unit193> Alright, I'm confused how seed blacklists are supposed to work then, it doesn't appear to as in the manpage.  If I blacklist !foo, and it's in an inherited seed, the manpage says it should still be blacklisted and I see in the output '* Blacklisting foo from bar' but it still ends up in the bar-recommends-arch.  What gives?
[20:40] <pitti> infinity: would you prefer when I fakesync python-virtualenv -3 (to fix the regression in -proposed) now, or wait until tomorrow when it published in Debian and gets imported into LP?
[20:40] <pitti> (see barry's email)
[20:40] <pitti> although, this change looks strange, just saw the diff
[20:41] <infinity> pitti: It's not seeded, don't care about timing.
[20:41] <pitti> ack
[20:43] <slangasek> pitti, infinity: qemu uploaded to fix the bug introduced by that old engineer who refuses to recognize non-mainframes are real architectures
[20:43] <pitti> "old"? :-)
[20:44] <pitti> isn't he like the youngest of us all? :-)
[20:44] <slangasek> pitti: he aged 50 years instantaneously the first time he connected to z/VM
[20:44] <pitti> oh, right -- time acceleration near super-fast machines
[20:45] <pitti> am I glad that this doesn't affect ssh connections
[20:49] <cyphermox> ssh going too fast?
[21:00] <Unit193> cjwatson: Perhaps you can tell me what I'm doing wrong, re: above?
[21:10] <seb128> slangasek, Laney, infinity, /etc/X11/Xsession.d/60x11-common_xdg_path do "XDG_DATA_DIRS=/usr/share/"$DESKTOP_SESSION":"$XDG_DATA_DIRS"", and worth case if that would be missing it would only means the override doesn't work so not break much, also the Name= translations are stripped by dh_translations in favor of using gettext so we can langpacks
[21:11] <slangasek> Unit193: blacklist doesn't cause the package to be un-seeded; instead it causes the seed as a whole to be considered buggy and invalid if a package is in the seed and matches the blacklist
[21:12] <seb128> slangasek, oh, and please tell me what is wrong with my sed use so I do the correct thing next time :-)
[21:13] <slangasek> seb128: two sed commands operating on the same file, so you're repeating the filename... you can pass multiple commands to sed, either as multiple '-e' arguments or just as commands separated by semicolons
[21:13] <Unit193> slangasek: Dang, I knew it didn't prevent installation, but from the manpage it seemed like it at least prevented from explicitly being selcted. :/
[21:13] <seb128> slangasek, oh, good point, I didn't think much when doing that :-/
[21:13] <slangasek> Unit193: it will cause an image build to fail, which is a bit late in the process
[21:13] <slangasek> seb128: and it wasn't a critical blocker ;)
[21:13] <seb128> slangasek, I'm going to change it with the next upload
[21:13] <Unit193> ...Wow, that's near useless.
[21:13] <Unit193> slangasek: Thanks for the info.
[21:14] <seb128> right, was just curious why you meant by "non-DRY"
[21:14] <slangasek> seb128: DRY == Dont Repeat Yourself :-)
[21:15] <seb128> ooh, gotcha!
[21:15] <roaksoax> win 8
[21:16] <seb128> slangasek, also I'm pondering doing another upload tomorrow (if we get a respin) to include some translations, we could strip the X-Gettext-Domain= for release and put Name[locale]=<translations> entries in the new desktop
[21:16] <seb128> then go back to langpacks in a SRU when we get a new langpack export which contains translations for the string
[21:17] <slangasek> infinity: ^^
[23:30] <doko> cyphermox, console-setup ftbfs
[23:46] <cyphermox> wat