[00:48] <Epx998> its too bad i cannot pxe boot my pi3
[00:53] <TJ-> Epx998: you can do network boot
[00:53] <TJ-> Epx998: see https://www.raspberrypi.org/documentation/hardware/raspberrypi/bootmodes/net_tutorial.md
[01:02] <Epx998> think my pi is broken
[01:02] <Epx998> there is no standard pw for ub16 arm if you dont preseed is there?
[01:07] <TJ-> Epx998: I don't think so, it's either blank or 'ubuntu' I think
[01:08] <Epx998> hmm ill try ubuntu
[01:08] <Epx998> this arm64 box is wonky
[01:11] <Epx998> hmm nope
[01:12] <Epx998> aha ubuntu/ubuntu
[01:29] <Epx998> heh restarting the network after adding interfaces hung the system
[01:29] <sarnold> did you do /etc/init.d/networking restart or its moral equivalent?
[01:30] <Epx998> service networking restart in the console, this hardware is bad - its not ubuntu at all
[01:30] <Epx998> im not a fan of this qualcomm eval
[01:30] <sarnold> at least ubuntu doesn't handle "service networking restart" real well. I'm guessing debian doesn't handle it well either.
[01:38] <Epx998> ill do it the proper way going forward
[01:38] <Epx998> this server takes 5 minutes to restart
[01:41] <Epx998> heh its just spamming Ubuntu 16.04, guessing thats the prompt who knows -> https://gist.github.com/anonymous/309b9d3c30ea565b3af4c9fa49489d5a
[01:42] <sarnold> crazy
[01:44] <Epx998> its doing it again
[01:48] <TJ-> is that via a serial console or something else?
[01:51] <Epx998> yeah
[01:51] <Epx998> it came up eventually
[01:52] <Epx998> ipmi
[05:55] <cryptodan> anyone running Dovecot, Postfix, and SASL successfully on Ubuntu Server 16.04?
[06:49] <cpaelzer> good morning
[07:06] <lordievader> Good morning
[07:07] <cpaelzer> hiho lordievader
[07:08] <lordievader> Hey cpaelzer How are  you doing?
[07:08] <cpaelzer> fine, and you?
[07:08] <lordievader> Doing good here, spitting through puppet emails -.-
[09:47] <jamespage> coreycb: hmm we're starting to trip on debhelper >= 11~ for the queens UCA
[10:30] <jamespage> cpaelzer: hi - this was the qemu-block-extras  thingmy right?
[10:33] <jamespage> cpaelzer: replied to your email
[10:34] <cpaelzer> hi jamespage
[10:34] <cpaelzer> no this is "another one"
[10:35] <cpaelzer> but in a simimlar spirit I'd say
[10:35] <cpaelzer> jamespage: think of it as "the qemu-block-extra" thing but for libvirt storage support
[10:35] <cpaelzer> jamespage: I discussed with coreycb yesterday and started as we did on qemu-block-extra
[10:36] <cpaelzer> with making the suggest a recommend (for now)
[10:36]  * cpaelzer reading mail ...
[10:36] <jamespage> cpaelzer: +1
[10:37] <jamespage> that's basically what I said :-)
[12:58] <DammitJim> what does this do? Unattended-Upgrade::Allowed-Origins {
[12:58] <DammitJim>         "${distro_id}:${distro_codename}";
[12:58] <DammitJim> I don't want anything to be updated automatically on my servers
[12:59] <coreycb> jamespage: saw that with debhelper, need to figure that out. maybe we can move those packages back to 10.
[13:00] <coreycb> jamespage: most of b3 is uploaded.  keystone has 1 test failure i'm trying to figure out and i'm creating a heat-dashboard package since that's been split from horizon. i left you gnocchi.
[13:10] <rbasak> DammitJim: "I don't want anything to be updated automatically" -> "I want to keep my servers insecure"
[13:10] <rbasak> You should install security updates.
[13:10] <rbasak> 99% of people who disable updates do not.
[13:10] <rbasak> But if you insist, you can remove the unattended-upgrades package. That's probably the easiest way.
[13:10] <rbasak> Alternatively, disable unattended-upgrades in /etc/apt/apt.conf.d/20auto-upgrades
[13:11] <rbasak> Then the Allowed-Origins setting won't matter.
[13:21] <jamespage> coreycb: ta (for gnocchi)  I'll do that work PM today and re-introduce the py2 gnocchi package for tobasco
[13:21] <DammitJim> rbasak, I have to test them before I roll them out
[13:22] <DammitJim> rbasak, how do I disable unattended-upgrades in /etc/apt/apt.conf.d/20auto-upgrades ? comment everything out?
[13:42] <rbasak> DammitJim: as long as you do roll them out promptly, every time. What I'm saying is that I get the impression that 99% of the people who disable for this reason actually end up neglecting the roll out and leave everything vulnerable, which is also quite hostile to others on the Internet too.
[13:42] <rbasak> DammitJim: APT::Periodic::Unattended-Upgrade "0"; presumably
[13:43] <DammitJim> rbasak, that is very true!
[13:43] <DammitJim> we are on a schedule... it's weird
[13:44] <DammitJim> when something really critical comes out, I have to manually go through stuff
[13:44] <rbasak> DammitJim: you should have it all automated
[13:44] <rbasak> DammitJim: automated deployment tests, and automatic rollout of security updates if green.
[13:44] <DammitJim> the problem is that some of those updates will fill up your /boot partition also
[13:45] <rbasak> DammitJim: "apt autoremove" (optionally with --purge) should work well nowadays.
[13:45] <rbasak> (to clean /boot)
[13:45] <DammitJim> what is the configuration for that to be done automatically when it runs the critical update?
[13:45] <rbasak> For what to be done automatically?
[13:45] <DammitJim> autoremove
[13:46] <DammitJim> because your /boot partition will get full otherwise
[13:46] <rbasak> Unattended-Upgrade::Remove-Unused-Dependencies
[13:46] <rbasak> See 50unattended-upgrades
[13:46] <rbasak> But test that first.
[13:46] <rbasak> Depending on how you've deployed, autoremove may remove extra stuff (if you don't have what you need marked as manual)
[13:46] <rbasak> Because many people deploy in non-standard, unsupported ways.
[13:46] <DammitJim> I had that set on a server I tested this on and it never cleaned up /boot
[13:47] <rbasak> Did "apt autoremove" do it?
[13:47] <DammitJim> but maybe I need to do more testing
[13:47] <rbasak> How was the server installed?
[13:47] <DammitJim> so, you might be right and I have a weird setting
[13:47] <DammitJim> it's from a template
[13:48] <rbasak> Depends on what you mean by "template". Users often hack up their own deployment systems which are subtly broken in some way.
[13:48] <DammitJim> I could have possibly done that
[14:43] <jamespage> coreycb: my head is still a bit fuzzy so going to work through the bom failures for queens pm today
[14:44] <coreycb> jamespage: great, thanks
[14:44] <coreycb> jamespage: keystone's uploaded. just working through heat-dashboard.
[14:45] <jamespage> coreycb: awesome
[14:49] <rh10> guys, how can i find out - what processes exactly in buffer/cache?
[14:53] <Ussat> I 100% disagree with automated updates, I have that off on all systems
[15:09] <dpb1> I used to feel that way.  But, I found that the vast majority of upgrades worked great for me on ubuntu, and taking the stance of security first helped me get over that hump.
[15:13] <Ussat> I have monthly a monthly main downtime for my systems...
[15:13] <Ussat> maint
[15:13] <dpb1> fair enough, good discipline to have
[15:14] <Ussat> Ya, I know I am lucky that way, I basically built our Linux infra from zero, so built that in from the start
[15:14] <Ussat> Said "this is how it is" and my director backed me up
[15:16] <dpb1> msft set the model with it's patch tuesday.  But, what do you do about the out of band hot security items?  just wait?
[15:17] <Ussat> dpb1, depends on the vuln and how me and the sec team here determine how bad we are effected.
[15:18] <Ussat> if it requires an immediate patch/reboot, well, we do that. TBH in this env not a lot does, 99% of my systems are not public facing and are VERY locked down
[15:18] <Ussat> or I may sechedule a week out, it really depends on the issue it addresses
[15:20] <Neo4> what is crontab?
[15:21] <Neo4> for example I want create scraper and put there data using php, can I do it?
[15:21] <Neo4> * * * * * wget -q -O - http://google.com  >/dev/null 2>&1
[15:24] <jamespage> coreycb: hmm after fixing three debehlper downgrades, going todo a backport
[15:24] <jamespage> debian have something in bpo which is close enough
[15:24] <rbasak> Ussat: sounds like you're part of the 1% that actually follows through :)
[15:25] <coreycb> jamespage: ok
[15:25] <Ussat> rbasak, I work in healthcare/edu we are pretty regulated....
[15:26] <Neo4> does exist difference  between curl and wget?
[15:26] <Neo4> why we install curl if we can use wget?
[15:26] <rbasak> Here in the UK, healthcare is also pretty regulated but they still run tons of XP and the NHS were infected by that ransomware not long ago. I'm not sure regulation and security are correlated :)
[15:27] <rbasak> Neo4: relatively little difference from a user point of view. Use whichever you prefer.
[15:27] <Ussat> rbasak, true, but at least here we try to keep a tight grip on things
[15:28] <Neo4> rbasak: I try bread down php code there however used exec function and installed crontab and this wget
[15:28] <Neo4> code is very complicated, can't understand how it works...
[15:29] <Neo4> it seems use wget for get ulrs from internet
[15:29] <rbasak> I wouldn't use exec from PHP to call wget or curl. That's pretty dangerous.
[15:29] <Neo4> rbasak: do you know what is crontab?
[15:29] <rbasak> Does PHP have a built in function to do that?
[15:29] <rbasak> Neo4: I do, but please try Google first.
[15:29] <Neo4> rbasak: it has exec() function
[15:30] <rbasak> Neo4: which is dangerous to use from a web app.
[15:30] <Neo4> we can do exec('pwd', $output, $result); and in result should be path to our current dirrectory where is file
[15:30] <Neo4> rbasak: php can run shell commands
[15:32] <Neo4> rbasak: what is dengerous? wget?
[15:32] <Neo4> crontab is dangerous?
[15:35] <rbasak> Neo4: calling exec from a PHP script is dangerous if based on unvalidated input
[15:35] <rbasak> Neo4: search "input validation"
[15:35] <rbasak> Since otherwise an attacker can inject arbitrary shell commands.
[15:45] <Neo4> rbasak: ok
[16:06] <cpaelzer> FYI - Server Team Office hours started - https://wiki.ubuntu.com/ServerTeam/Meeting
[16:07] <cpaelzer> we actually don't mind when questions are asked, but if - for whatever reason - you held back questions, now is the time
[16:07] <cpaelzer> around should be atm rbasak, nacc, dpb1, ahasenack, powersj and myself
[16:07] <ahasenack> o/
[16:09] <ahasenack> cpaelzer: hm, I missed a universe dependency in the new bind9 package
[16:09] <ahasenack> lmdb
[16:09] <ahasenack> I'll check
[16:14] <cpaelzer> sure I saw it in excuses
[16:15] <cpaelzer> but libvirt also complains and it is a false positive
[16:15] <cpaelzer> so I wanted to give britney a chance to overthink things
[16:23] <nacc> o/ as well
[16:25] <ahasenack> cpaelzer: you mean about lmdb?
[16:25] <ahasenack> ah, no, your case is glusterfs
[16:32] <|\n> hello, i was looking for some channel where i could possibly ask a stupid hardware-related question, any hints are appreciated sincerely
[16:33] <nacc> |\n: #hardware?
[16:33] <nacc> !alis | |\n
[16:33] <|\n> ah, thanks nacc
[16:33] <nacc> |\n: can't remember if it's #hardware or ##hardware
[16:33] <|\n> will try both, thanks, i'm slow =)
[16:47] <jamespage> coreycb, beisner: https://www.percona.com/doc/percona-xtradb-cluster/LATEST/howtos/upgrade_guide.html
[16:51] <coreycb> jamespage: seems simple enough. does the package need to run the upgrade commands or can that be left to the user?
[16:51] <jamespage> coreycb: well... I think I see why this is not part of the pkg upgrade
[17:27] <tdb> hi! the xenial daily images here http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/ - when will they start using the newer 4.13 HWE kernel for the installer? I notice 4.13 kernel packages in the install media, but not for running the installer itself
[17:28] <nacc> iirc, isn't that a menu choice?
[17:28] <nacc> powersj: --^
[17:29] <tdb> it is, but the hwe option still uses the older 4.10 kernel
[17:29] <tdb> (as opposed to 4.4, for non-hwe)
[17:29] <nacc> tdb: hrm, i'm not sure how that's decided, powersj would know
[17:30] <tdb> I heard the 16.04.4 release has been put back, which is totally understandable, but I thought the daily builds might be ready for some testing
[17:30] <powersj> looks like the udeb are all still 4.10
[17:32] <powersj> basically those udeb (listed in the list file) need to be updated
[17:33] <powersj> oh wait, I see 4.13 as well :) http://cdimage.ubuntu.com/ubuntu-server/xenial/daily/current/xenial-server-amd64.list
[17:33] <tdb> yeah :)
[17:34] <tdb> that's what made me think the installer itself might be using the newer kernel too
[17:34] <powersj> sure enough uname -a shows 4.10 still
[17:35] <tdb> I have new hardware which won't work with 4.10 :/
[17:41] <powersj> not sure what project makes sense for a bug
[17:41] <dpb1> I'm looking for the same
[17:41] <powersj> ubiquity? syslinux?
[17:42] <dpb1> powersj: https://bugs.launchpad.net/ubuntu-cdimage
[17:42] <powersj> Since the kernel is already there I don't think hwe-linux
[17:42] <dpb1> ?
[17:42] <powersj> yeah
[17:42] <dpb1> tdb: could you please file a bug there and report back?
[17:43] <tdb> I wasn't sure if it was a bug, or just a "not yet done" thing
[17:43] <powersj> it is worth filing to track it in either case
[17:43] <dpb1> +1
[17:43] <tdb> ok
[17:44] <powersj> tdb: and please let us know the bug #
[17:51] <tdb> powersj: 1746304
[17:51] <powersj> tdb: great thanks!
[17:52] <tdb> thanks for your help :)
[18:05] <rlangford77> Where can I find out if ubuntu/canonical has an SNS topic for ami publish events?  Trying to keep things updated response to spectre/meltdown. I'm aware of the cloud image tracker, but we're looking to automate things like we're currently doing for amazon linux
[18:07] <nacc> Odd_Bloke: --^ ?
[19:00] <nacc> rbasak: grr, think i found a bug in debian_support.py's Version regex :/ upstream_version for e.g. 57ubuntu1 gets set to '57ubuntu1'
[19:00] <nacc> :)
[20:08] <Pinkamena_D> I have been using x2go+xfce4 for remote desktop connections but sometimes it is very slow, esp with internet browsers / any transitions. Is there any faster remote desktop software you would recommend? I like evrything about x2go except for the performance issues.
[20:09] <sarnold> how does x2go compare to plain old ssh -X ?
[20:14] <dpb1> Xrdp is an option.
[22:27] <rbasak> nacc: that's a native package. It it supposed to be a debian version only in that case? I don't recall the spec.
[22:27] <nacc> rbasak: yeah, see my MP, i'lll try to find the docs
[22:29] <nacc> rbasak: i guess i should clarify here and there
[22:29] <nacc> rbasak: it is 'correct' by the spec
[22:29] <nacc> but is not at all what anyone wants :)
[22:29] <nacc> since the point is to compare between ubuntu and debian packages
[22:31] <rbasak> nacc: which MP please?
[22:31] <nacc> rbasak: one moment
[22:31] <rbasak> https://code.launchpad.net/~usd-import-team/usd-importer/+git/usd-importer/+ref/master/+activereviews is rather crowded right now :-/
[22:31] <nacc> rbasak: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/336870
[22:31] <rbasak> nacc: or actually, which MP do you want me to look at first right now?
[22:32] <nacc> rbasak: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/336645 is the one i need the most help with
[22:32] <nacc> rbasak: and is probably chronologically the most urgent (so we cann start phasing main)
[22:32] <rbasak> OK
[22:33] <nacc> rbasak: iiuc, you're under the weather, though, so take care of yoursellf first :)
[22:33] <dpb1> nacc: +1
[22:33] <rbasak> I'm wide awake and alert right now
[22:33] <nacc> loll
[22:33] <rbasak> So I might as well look :)
[22:34] <nacc> rbasak: if you want to chat about it, just let me know
[22:34] <rbasak> ack
[22:34] <dpb1> rbasak: :)
[22:40] <nacc> rbasak: if you are around, though, I did have one question for you that is probably easiest to do in a HO
[22:43] <rbasak> I'm around but not really in a position to join a HO
[22:44] <rbasak> IYSWIM :)
[22:44] <nacc> rbasak: i do :)
[22:44] <nacc> not urgent, so that's fine
[22:44] <rbasak> nacc: for that MP, +1 up to and including 4c6e3c7de1
[22:44] <rbasak> That all looks reasonable, so please put that in a separate MP and land it to avoid another mega MP
[22:45] <nacc> rbasak: oh sure, i can do that
[22:45] <nacc> yeah those were cleanups i pulled up the stack as i went
[22:45] <nacc> rbasak: i'll do that now?
[22:45] <rbasak> sURE
[22:46] <rbasak> nacc: next, in 4c6e3c7de1, what's the reasoning to not use pytest exactly? I don't mind but it feels inconsistent. We're already using pytest when we need to parameterise.
[22:46] <nacc> rbasak: it was from my discussion with powersj
[22:46] <rbasak> (IOW, we have exactly one pattern for parameterisation right now)
[22:46] <nacc> on getting to one model for our testing
[22:47] <nacc> i think he suggested unittest over pytest, but i might be misremembering
[22:47] <nacc> also this way we don't need pytest in the snap..
[22:47] <nacc> but i can switch it back
[22:47] <powersj> heh I've had separate conversations with each of you, but think we reached different conclusions.
[22:47] <nacc> heh
[22:47] <rbasak> I'm open to discussion on this
[22:48] <rbasak> If we can replace everything we're doing with pytest I'm happy to lose pytest entirely.
[22:48] <powersj> when I talked to rbasak last fall it was pytest, as it was very handy, even though other projects were using unittests/nose/etc.
[22:48] <nacc> rbasak: (and i assume you meant a differenrt hash, as that's the one you just hacked)?
[22:48] <nacc> *acked
[22:48] <rbasak> nacc: sorry, 23729b3
[22:49] <rbasak> ...but if we can't drop pytest, then it would be nice to have a consistent set of patterns to use for the different test needs we have in the project.
[22:49] <rbasak> eg. "need parameterisation? Use _this_ pattern"
[22:49] <nacc> right
[22:49] <nacc> to be clear the subTest thing is newer in unittest
[22:49] <nacc> so maybe it wasn't there when you looked before
[22:50] <nacc> and i thnk we could abstract it up one level so it isn't so nest-y/indented
[22:51] <rbasak> In any case, perhaps that's a discussion we need to have.
[22:51] <nacc> yeah
[22:51] <nacc> i guess i preempted it with code :)
[22:51] <rbasak> If we do decide to switch the parameterisation pattern, we'll need to change all the other occurances.
[22:51] <nacc> i also, for whatever reason, found unittest easier to understand then pytest
[22:51] <rbasak> So how about, for now, we keep the existing pattern?
[22:51] <rbasak> Rather than have two in the codebase at once.
[22:52] <rbasak> If we decide to switch patterns, then we can have a single commit switching them all over
[22:52] <rbasak> And the subsequently not use the old pattern again
[22:52] <rbasak> Introducing a second pattern forces a future fix regardless of which way we go
[22:52] <nacc> rbasak: ok, the other thing i found handy is that unittest can do test discovery, perhaps pytest can as well
[22:53] <rbasak> pytest does test discovery by default. So I'm not sure what you mean
[22:53] <nacc> rbasak: right now we have to pass files to pytest
[22:53] <nacc> rbasak: unittest can find them from the modulel
[22:53] <rbasak> You can just give it a directory
[22:54] <nacc> rbasak: https://code.launchpad.net/~nacc/usd-importer/+git/usd-importer/+merge/336877 cleanups only
[22:54] <rbasak> nacc: +1'd
[22:54] <nacc> rbasak: and resubmitted the fixes as dependent o that one
[22:59] <nacc> rbasak: i'll land it once CI passes (I expect it to)
[23:01] <rbasak> OK
[23:13] <nacc> powersj: can i tell tox to use a particular version of python3?
[23:14] <nacc> powersj: i think the CI env (xenial?) has 3.5.1-3, while we use 3.6.3 in the snap, so there might issues
[23:14] <nacc> e.g https://jenkins.ubuntu.com/server/job/git-ubuntu-ci/274/console which passes locally on bionic
[23:15] <rbasak> nacc: for testing the Sources file downloads, verification, etc, I'd either get some small files from the archive (eg. restricted?) and put them in a test directory and use those instead of HTTP, or I'd prepare my own minimal ones, sign them with a test key and adjust the code to verify with the test public key. The test keys would want to be text in the repo though, so there'd have to be a test
[23:15] <rbasak> fixture to import them into a keyring.
[23:15] <rbasak> The latter is cleaner but possibly more work.
[23:15] <powersj> nacc: my understanding is the version of python you want to use has to be installed
[23:16] <nacc> rbasak: ah that's a good idea
[23:16] <powersj> so even if you add a py34 (for 3.4) or py36 in your case, if that version of python is not already installed it will fail trying to find that version of the interpreter
[23:16] <nacc> powersj: so how should i do this? :)
[23:18] <powersj> well do we know for a fact that 3.5 fails? or has consequences for running with it?
[23:19] <powersj> of course testing on the version you are using is probably more important :)
[23:19] <powersj> so we could run tox in bionic a container
[23:19] <nacc> powersj: right, the latter is the relevant point, but let me spin up a xenial
[23:19] <nacc> powersj: right, but that doesnt' really solve the problem, it just punts it furhter into the future?
[23:19]  * powersj thinks he messed up the word order there
[23:20] <powersj> nacc: how so?
[23:20] <nacc> powersj: let's say we envetually move ahead of the bionic python3
[23:20] <nacc> the bionic container doesn't help us :)
[23:20] <powersj> true - we could still use a container and install the version that you are using
[23:21] <nacc> powersj: we build it from source, though, meaning it might not be available as a package
[23:23] <powersj> nacc: I guess I don't see that as an issue we can do the same thing, it only makes testing longer and more complicated
[23:23] <nacc> powersj: ok, i just didn't wannt to have to have our testing infra build python3 every time
[23:23] <nacc> it's not exactly fast
[23:23] <powersj> yeah :\
[23:23] <powersj> I guess the other alternative is install from something close? or try to get your own development stuck to a specific version and if you move we have to move testing as well?
[23:24] <nacc> yep
[23:24] <nacc> powersj: confirmed xenial's python3 does not work
[23:25] <nacc> and there is no python3.6 in xeniall
[23:25] <nacc> hrm
[23:26] <nacc> rbasak: --^ thoughts?
[23:26] <nacc> (i think the big thing is it looks like NamedTuple support is either different or missing)
[23:26] <nacc> possibly in pylint3
[23:26] <nacc> i wondner
[23:26] <rbasak> We should develop and test against whatever version the snap uses
[23:26] <rbasak> Right?
[23:27] <nacc> that would be ideal
[23:27] <nacc> but that wouldl mean every CI job needs to buildl the snap's env
[23:27] <powersj> we could try using pyenv maybe? I haven't played much with it
[23:27] <nacc> outside of the snap
[23:27] <rbasak> Could it be cached somehow?
[23:27] <rbasak> Feels like a fundamental issue with developing a project deploying with snaps
[23:27] <rbasak> Snap upstream should have a solution for us on this
[23:28] <nacc> i'll ask
[23:28] <rbasak> Thanks
[23:29] <nacc> meanwhile, do we want to bump our tox env?
[23:29] <nacc> artful would be sufficient for now
[23:30] <powersj> nacc: when you said didn't work on xenial? was that using python3.6 because it doesn't exist? or something else?
[23:30] <nacc> powersj: tox itself fails on xenial with the branch referred to above
[23:31] <nacc> powersj: because it's using 3.6 features and only 3.5 is available to run
[23:31] <nacc> (we currently just call python3)
[23:31] <nacc> rbasak: if we were to add pylint to our snap, i thinnk we can run the tests as an app
[23:31] <nacc> possiblly using tox itself
[23:32] <rbasak> I have no objection to that
[23:32] <nacc> powersj: if we did that, we'd change the jenkins to something like git-ubuntu.self-test
[23:32] <rbasak> We might need to add pytest though
[23:32] <nacc> yeah
[23:32] <nacc> rbasak: true, if we were to lift up all of CI, that's true
[23:33] <nacc> i was initially just suggesting the bit we know is broken
[23:33] <nacc> but might as well fix it rigth :)
[23:33] <nacc> powersj: if i get you a branch with the corresponding changes, wouldl you be able to do a test CI run with it?
[23:33] <nacc> not sure how easy it is to do a one-off pipelline
[23:36] <powersj> nacc: branch changing the CI?
[23:36]  * powersj is also confused why you are changing how you call tox
[23:37] <nacc> powersj: have a moment for a quick HO?
[23:37] <powersj> yeah
[23:38] <nacc> powersj: i think i can expllain it better that way :) standup-server
[23:52] <nacc> powersj: do you have a link to your script running pytest3?
[23:53] <powersj> nacc: https://github.com/canonical-server/jenkins-jobs/blob/master/git-ubuntu/jobs-ci.yaml
[23:53] <nacc> powersj: ta