[07:54] good mornig [08:08] good morning [09:14] hello, the maven plugin assumes that in a target directory there have to be a jar or war after mvn package. Is there a way I can circumvent this check? [09:14] (in snapcraft) [09:19] opny, you could use https://github.com/ubuntu-core/snapcraft/blob/master/docs/plugins.md and copy the maven plugin to remove the check just to see if that makes it work [09:19] opny, maybe this should be an option in the maven plugin? [09:25] dholbach, hello, yes having it optional may be a good start. I try to add the option in the "overidden" plugin. Actually a property allowing to move custom dir/files like the filesets one would complete the loop [09:26] maybe you can bring up the idea on the mailing list? [09:26] it'd be interesting to hear what others think and how the idea could be generalised [09:27] dholbach, sure, which one? [09:27] snappy-app-devel@lists.ubuntu.com? [09:27] dholbach, ok [09:27] awesome :) [09:41] Good morning all! Happy Wednesday, and happy Plimsoll Day! 😃 [10:09] HI does somebody knows how I can solve this? u"!#$%&'*+-.^_`|~:").encode('ascii') [10:09] LookupError: no codec search functions registered: can't find encoding [10:10] it is with werkzeug that i have this error [11:23] Is there a method to force snapcraft to update the apt repository as listed in sources.list ? [11:26] opny, maybe you'd need to talk to sergiusens about reopening https://bugs.launchpad.net/snapcraft/+bug/1493081 (or https://github.com/ubuntu-core/snapcraft/issues/19) [11:26] Launchpad bug 1493081 in Snapcraft "Ubuntu plugin: allow downloading of binary packages from PPAs" [Medium,Invalid] [11:27] kyrofa, ^ do you have any idea if there was any additional discussion about this? [11:31] dholbach, thanks.. again :) I'm plagued with Hash mismatch errors which block me for hours [11:37] opny, I'm afraid I don't know how to work around that [11:37] maybe when sergiusens and kyrofa come online you can ask them [11:38] a quick search in the code didn't let me find anything yet === ant_ is now known as Guest40019 [12:18] Good morning [12:19] dholbach, I'm afraid that was before my time-- I've not heard anything about it [12:22] kyrofa HI does somebody knows how I can solve this? u"!#$%&'*+-.^_`|~:").encode('ascii') [12:22] LookupError: no codec search functions registered: can't find encoding [12:22] it is with werkzeug that i have this error [12:26] noizer, I'm sorry no, I don't know anything about that one [12:26] noizer, you might consider asking in #python [12:29] ok [12:52] hey sergiusens [12:52] dholbach, hello [12:53] sergiusens, is there a way for snapcraft users to provide their own sources.list... or add PPAs or use different mirrors and stuff? [12:53] dholbach, not currently; but soon we will remove just use local sources by default so it is whatever you have on your system [12:54] opny, ^ [12:54] ok cool [12:54] sergiusens, dholbach thanks [12:54] opny, dholbach for now there is a hidden USE_LOCAL_SOURCES you can export [12:55] sergiusens, dholbach seems like sources.list is took once and then not updated anymore.. [12:55] ah, nice one... I saw that in the source and wondered how it'd work === alecu-natholiday is now known as alecu [13:00] sergiusens, dholbach is it like `USE_LOCAL_SOURCES=1 snapcraft` ? I cannot find it in the snapcraft source, maybe a python/apt thing [13:01] sergiusens, or _PLUGIN_STAGE_SOURCES? [13:02] opny, dholbach sorry, it is SNAPCRAFT_LOCAL_SOURCES [13:03] sergiusens, dholbach works, perfect! Thank you :) [13:03] :-D [13:03] brilliant! [13:07] Anyone else having stability problems with the dragonboard? [13:07] kyrofa, on what image ? [13:07] ogra_, actually on the linaro Ubuntu image, so not really an Ubuntu Core question. But I find if I push it very hard for very long, it just gives up [13:08] * ogra_ is about to finish an all-snaps one that should be stable .... my 15.04 one is clearly hacked up enough to expose instability [13:08] ah [13:08] ogra_, ah, I'll definitely give that a shot when it's available. I'm just worried it's a heating problem or something [13:10] Can't build any good-sized snaps on it [13:44] hi, how can I generate an oem snap? Do I need to use snapcraft? [13:44] i dont think we have oem plugins yet ... [13:45] also note that oem snaps are 15..04 only ... we switched to a different setup with "gadget" snaps in 16.04 [13:45] type: oem does not seem to work indeed it tells me "you need either app or framework" [13:45] oh [13:45] I'm following the documentation for "how to port snappy to your platform" [13:45] yeah, thats still 15.04 [13:45] https://developer.ubuntu.com/en/snappy/guides/porting/ [13:45] ok [13:46] 16.04 is to much in flux still .... we're in the middle of switching the whole image design to a "all snaps" setup [13:46] It seems I need the oem snap in order to do the ubuntu-device-flash command to generate the image [13:46] oh [13:46] interesting [13:46] right [13:47] so, how am I supposed to generate the oem snap? [13:51] ysionneau, we store the official code for the oem/gadget snaps at https://code.launchpad.net/~snappy-dev/snappy-hub/snappy-systems ... for 15.04 you would have to go a bunch of revisions backwards in the commits though [13:53] oh right, there are the snap.yaml files in there [13:53] type: gadget [13:53] hmmm [13:54] yeah, you will have to go back through the history to get to package.yaml and 15.04 setup [13:54] ah, if I go back in time indeed I get the package.yaml files [13:55] I'm especially interested in the arm64 stuff, so dragon I guess [13:55] rev 18 seems interesting [13:56] since rev 19 renamed package.yaml to snap.yaml [13:56] ysionneau, http://people.canonical.com/~ogra/snappy/dragonboard/ [13:56] thats a very hackish 15.04 image [13:57] thanks! [13:58] thogh 15.04 has issues that will likely not get fixed [13:58] (on the dragonboard specifically) [13:59] focus is on 16.04 only [13:59] hmmm ok [13:59] maybe I should switch to 16.04 then [13:59] yeah [13:59] I'm wondering, now that I have that package.yaml [13:59] I still don't understand how to generate the oem.snap :p [13:59] i'm waiting for a final kernel build and should have some test image ready later today [13:59] snapcraft is searching for snapcrafy.yaml [13:59] -y [14:00] ah good news! [14:00] yeah, we dont use snapcraft for oem/gadget ... but "snappy build" directly [14:00] ah great, it worked :) [14:00] thanks [14:02] now I get "Signature verification failed" :' [14:02] while doing the ubuntu-device-flash [14:02] you need to use --developer-mode [14:02] btw, 16.04 is devel ? devel-proposed ? [14:02] else it wont allow your own oem/gadget [14:02] 16.04 is rolling/edge [14:03] (release is rolling, channel is edge) [14:12] ogra_: did you ever tried to run your dragon snappy system on qemu? [14:12] try* [14:12] does qemu support arm64 yet ? [14:12] yes [14:12] (and does it emulate the dragon ?) [14:12] no, i never tried [14:12] it does not emulate the dragon specifically [14:12] I cannot see any arm64 emulated boards [14:13] but you can do something like -M virt -cpu cortex-a53 [14:13] and such [14:13] well, i doubt that works with the dragonboard specific kernel [14:13] http://www.bennee.com/~alex/blog/2014/05/09/running-linux-in-qemus-aarch64-system-emulation-mode/ < like this [14:13] but you don't need to compile your own qemu [14:14] it worked on my debian testing with official debian qemu package [14:14] with a dragonboard kernel ? [14:14] nop [14:15] I don't even know how this guy generated his kernel (with which config) [14:15] right, most likely just some generic arm64 thing [14:16] yeah I guess [14:18] maybe I can just use the dragon snappy image, but use my generic aarch64 kernel [14:18] so that it can run in qemu [14:20] or I should just generate my own system image [14:21] hmm. i have a rolling all-snaps image from the 8th january ... do i need to reinstall to get back on latest rolling lane? [14:21] my image doesnt update [14:23] * asac just goes and installs latest https://people.canonical.com/~mvo/all-snaps/rpi2-all-snap.img.xz [14:23] asac, yeah, i dont think they update yet [14:24] guess they changed names : [14:24] ) [14:24] of snaps like ubuntu-core [14:24] (and we have no auto-builds that would submit the snaps to the sotre yet .... all manual) [14:24] will see once its booted [14:24] hmm [14:24] ok [14:24] well, thats fine. let me see what i find here on the 4th feb image i guess [14:24] interesting that bbb is 40M igger than pi2 image [14:24] guess pi2 isnt a full blown kernel? [14:25] it is [14:25] but a smaller initrd [14:25] hmm. ok. different config? [14:25] or how did this end up being different? [14:26] anyhopw, i am on pi2 anyway so dont mind smaller footprint [14:26] simply doesnt pull in as many modules [14:26] is there online documentation about the new "all-snaps" architecture? [14:26] (and yeah, i guess there are less built ... effectively you mostly only want USB stuff that you can plug in) [14:31] kyrofa, elopio be there in 2 [14:31] sergiusens, sounds good [14:34] ysionneau: i dont think there is... buut summary is that everything is now snaps. anything specific you want to know? [14:35] dholbach: think good clinic topic would be to make overview of all-snaps when mvo is back [14:35] jdstrand, is access to /proc//statm a risk? (denied in 15.04) [14:35] fgimenez: my deploy got stuck stoping jenkins-master-service. Did you do one? [14:35] nothing specific, it's just that I'm very beginner with ubuntu snappy stuff [14:35] so I feel more confortable using something documented [14:35] asac, yes - that's noted down and requested already [14:35] root@imperium:/home/yann/dev/snappy# ls -l my-snappy.img [14:35] ls: cannot access my-snappy.img: No such file or directory [14:35] oops [14:35] kyrofa: looks fine to me [14:35] dholbach: cool! [14:35] * jdstrand adds it [14:36] asac, niemeyer and mvo just seemed very busy lately - so I didn't get a date from them yet [14:36] http://pastebin.com/0u4f92Xc < any idea why this fails? [14:36] dholbach: fine [14:36] just keep nagging... guess after sprint might be better time [14:36] kyrofa: what is requesting the access (trying to decide if in default or a cap) [14:37] ysionneau: you cannot use tarballs as device parts anymore... needs to be snap. check with ogra [14:38] oh, status is basically the same info [14:38] ok, default profile [14:38] plars: http://pad.ubuntu.com/spi I started updating the stuff, with a little bit of problems. [14:40] elopio: oh, I've done none of that yet on my side [14:40] ysionneau, right, like asac says, all-snap means that everything is a snap .... rootfs, kernel, gadget (oem) [14:40] ysionneau, the 15.04 setup still uses the phone based tarball system-image setup [14:41] elopio: for authorization stuff, you'll need to contact ev's team I think [14:43] plars: yes, I'll be talking to them today. [14:43] plars: from your side, we need to be able to call the all-snaps udf. [14:43] ysionneau, try using the oem snap from my image ... [14:44] ogra_: ok thanks [14:44] plars: maybe if we include the binary name, not just "udf-params" [14:44] oh, annd the dragonboard setup has a very specific partitioning for the bootloader ... that requires the very latest ubunu-device-flash from xenial [14:44] 15:37 < asac> ysionneau: you cannot use tarballs as device parts anymore... needs to be snap. check with ogra < which means the documentation is wrong? :o [14:44] ysionneau, the documentation refers to 15.04 [14:44] right [14:44] yes, which is what I'm using right now [14:44] it will be changed once all-snaps is the default [14:45] ysionneau: i would suggest to stick to 15.04 for now [14:45] if you are new [14:45] if you build for 15.04 you can indeed use tarballs [14:45] bc there is lots of stuff landing as we speak on trunk [14:45] so if you are not yet deep in this topic it will be rough at best :P [14:45] but i dont think you will get a dragon image to work with 15.04 [14:45] so since I'm targeting 15.04 in my pastebin, any idea why it does not work? [14:45] there are various issues with that [14:45] ah [14:45] (as i said earlier) [14:46] elopio: is there a cheat sheet for how to build all the all-snaps images using the all-snaps udf? [14:46] what you say about "dragon image" is also true for any arm64 image? [14:47] the fact that it would not work for 15.04 [14:47] no [14:47] elopio: and can you confirm if I really need to be on xenial to build all-snaps images or not? I remember you mentioned that before, but I thought it was unconfirmed at the time [14:47] generic arm64 might work or not [14:47] the specific dragnboard setup will definitely not work though [14:48] ok [14:48] so you can try a aemu arm64 image based on a generic kernel ... but YMMV ... i dont thinnk anyone actually tested arm64 on 15.04 [14:48] *qemu [14:48] hmm hmm ok [14:48] understood [14:50] elopio, nope, your's finished after all [14:50] Hi how can I force delete an application. Because when I'm trying. it says read only permission or something [14:59] kyrofa: I'm going to upload this in a few minutes, but I don't know when the next image will be spun. I believe one is undergoing testing to pull in security updates, so the next one may not have this unless they respin (or you ask them to respin) [15:00] jdstrand, woo! Excellent news, thank you :) [15:00] hmm. snappy search command doesnt exist right now on 16.04? [15:01] * asac installs bluez5 out of the blue [15:01] asac: snap find foo [15:01] I don't know the reasoning behind that, but came across it [15:02] fgimenez: no, it's missing one slave. [15:02] good... i looked at snap command [15:02] I'll retry. [15:02] but missed that find thingy [15:02] thanks jdstrand [15:02] np [15:02] snap find bluez5 yields nothing [15:02] guess store is borked? [15:03] snap find bluez [15:03] error: no snaps found for "bluez" [15:03] ubuntu@localhost:~$ snap find bluez5 [15:03] error: no snaps found for "bluez5" [15:03] ubuntu@localhost:~$ snap find hello [15:03] error: no snaps found for "hello" [15:03] ok let me find a bt dongle ... /me hopes he can find those mini things [15:05] asac, 90% of the store snaps cant run on 16.04 anyway ... until they are converted to squashfs [15:05] might be that the store now finally filters them [15:06] (snappy install falls over on the click legacy during install for most of them) [15:07] ok this is not looking good [15:07] let me order a new one [15:07] no beer before 5 ! [15:15] hehe [15:15] i wish [15:15] so what cool BLE device could i buy? guess just a dongle wont make it [15:22] asac, http://www.amazon.de/Satechi%C2%AE-Bluetooth-Button-Kompatibel-Cortana/dp/B012OWC5NQ/ref=sr_1_4?ie=UTF8&qid=1455117712&sr=8-4&keywords=BLE+bluetooth [15:23] or http://www.amazon.de/Satechi%C2%AE-Bluetooth-Button-Series-Samsung/dp/B00RM75NOW/ref=pd_cp_23_2?ie=UTF8&refRID=0SA6C938R1PRR0S634S7 [15:29] lol [15:29] a bt button [15:29] always wanted that :0 [15:29] ok ordered :) [15:29] lol [15:30] kyrofa: 15.04.12~ppa17 uploaded to the ppa [15:30] (ubuntu-core-security) [15:31] jdstrand, awesome, thanks [15:37] ppisati, FYI ... boots perfect with the new DT [15:37] thanks a lot [15:37] ! [15:38] ogra_: yeaaaaaaahhh! :) [15:38] ogra_: as soon as i have some time, i'll try to debug what was going on with the old dtb [15:38] yeah [15:38] it is weird that we dont see it everywhere [15:38] yes it is [16:04] kyrofa: and ubuntu-core-security 16.04.15 uploaded to xenial [16:05] Thanks jdstrand! [16:12] elopio, kyrofa reviewzzzz :-) [16:13] elopio, did you say the maven PR was good? [16:14] kyrofa: I did, yes. But sergiusens changed everything. I'm looking again. [16:27] zyga: dumb question-- I'd like to review the entire PR as it stands now (ie, with all of your changes) in github. how do I do that? [16:28] I feel like I found it yesterday, but I can't seem to today [16:29] oh, Files changed [16:29] ok [16:29] zyga: nm [16:29] ev: noise][: can you help me today with spi? [16:30] jdstrand: hey [16:30] jdstrand: :D [16:30] jdstrand: ping me if there are tests missing [16:30] jdstrand: I think you asked for one more but I'm not sure [16:34] elopio: hi, we're making some good progress on running the snappy tests from checkbox [16:34] joc__: awesome! [16:34] elopio: last few failing tests are printing "Error: aa_change_onexec failed with -1. errmsg: Permission denied [16:35] elopio: hey, what’s up? [16:35] elopio: are they expecting to be run with sudo? [16:35] zyga: I think we are good (gave +1) [16:35] zyga: thanks! [16:35] joc__: they should have permission to run sudo, but the scripts themselfs add the sudo command when required. That's more likely that you have an outdated allsnaps image. [16:36] sergiusens, any idea why all-snaps doesn't have /etc/protocols? [16:36] joc__: I was looking at this yesterday: http://bec-systems.com/site/942/running-a-reboot-cycle-test-shell-script-with-systemd [16:36] we could use it to test reboots without adt-run. It would be a lot more complex than what we have now, though. [16:37] seems easier to do adt-run with the nil testbed, so it runs in the same host. [16:37] elopio: i wrote some stress-tests that do almost exactly that in checkbox [16:37] ev: hey. I got two errors here: http://pad.ubuntu.com/spi [16:37] In the current section. [16:38] elopio: they arent great though as you can't receonnect to them from a user session [16:38] elopio: but they allowed us to atleast set up warm boot / cold boot stress tests [16:38] elopio: did you see my questions earlier about building images? in particular, for x86? [16:39] in ubuntu-device-flash , the --oem is supposed to be the path to the .snap ? or the path to the source of the oem package (the directory containing the meta directory)? [16:39] kyrofa, should I name it 2.1.2? I already have, but seem to regret it a bit [16:39] elopio: also, how much concern do you have for testing older pre-allsnaps images across supported platforms? I'm tempted to just move everything to the new tool except for specific platforms that generally need the older image [16:39] plars: sorry, I didn't. zyga said he's writing a cheat sheet for all snaps, or that's what I understood. [16:39] kyrofa, no idea; but why should it be there for you? [16:40] elopio: ack [16:40] need to resolve a proto name? [16:40] plars: and it doesn't need to be xenial. What I said is that the new ubuntu-image will be xenial only. [16:40] sergiusens, for getprotobyname and associated calls [16:40] elopio: I found what to do for rpi2, and I can see from your pastebin how to do it for bbb, but I'm interested in db410c and x86 too [16:40] kyrofa, so I bet netbase is installed; ogra_ clues? [16:40] sergiusens, regarding the version, wouldn't 2.2 be more correct since you have the --output feature? [16:40] jdstrand: perfect, thank you :) [16:41] plars: for db ask ogra_. For x86, maybe he'll know too. [16:41] kyrofa, there [16:41] elopio: hey, missed your ping earlier, what can I help with? [16:41] kyrofa, netbase is not in the manifest http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ [16:41] kyrofa, you can ask ogra to seed it I guess [16:41] plars: and if it makes things easier, just don't worry at all about 15.04 images. Our main focus is 16.04. [16:42] sergiusens, thanks :) . ogra_ how would you feel about that? [16:42] hey noise][. Pasting the message again: I got two errors here: http://pad.ubuntu.com/spi [16:42] In the current section. [16:43] ogra_, it was in 15.04... was it removed for a reason? [16:43] elopio: authorisation is keyed on permissions to snaps now, rather than organisation keys: https://spi.canonical.com/assets/tutorial.html#creating-a-product [16:43] https://spi.canonical.com/assets/tutorial.html#testing explains how to set up that gold master test [16:45] kyrofa, i didnt explicitly remove it ... weird ... yeah, we can add it bacjk [16:45] kyrofa, btw, see my dragonboard mails ... image is up [16:45] ogra_, maybe related to the 'one seed to rule them all' thread? [16:46] ogra_, I saw that, thank you :) [16:46] sergiusens, i dont think anything changed yet [16:46] though i might be wrong, seems severakl teams now tinker with that, could be that slangasek already started with some changes that i missedf [16:48] plars, i only heard this week that x86 will be a supported target, i'll work on it alongside with enabling the arm64 builds for the db [16:48] elopio: checking.. [16:51] ogra_, hmm... should we talk to some about adding it back, then? Or do you think it's safe? [16:52] kyrofa, lets wait for slangasek, i dont want to mess up anything he is currently fiddling with ... apart from that, yeah, i think we should add it back [16:52] ogra_, alright sounds good. Thank you! [16:53] /etc/services and /etc/protocols is definitely something we should have :) [16:53] Agreed [16:53] Took me a while to trace my segfault back to that [16:54] http://paste.ubuntu.com/15009577/ any idea? ( I'm using the bzr rev12 of snappy-systems for the oem package of beagleblack) [16:59] Do you know where the webdm code is? I would have expected it to be on https://github.com/ubuntu-core [17:01] didrocks, m,ost likely on launchpad [17:01] didrocks, only snappy and snapcraft moved to github [17:01] oh right, for some reasons, I thought https://code.launchpad.net/~snappy-dev/webdm/trunk was old [17:01] didrocks, https://code.launchpad.net/webdm [17:01] afaik [17:01] yeah, thanks ogra_ & dholbach :) [17:03] interesting, it doesn't use snapcraft (yet ;)) [17:06] elopio, pushed now, I had addCleanup which took care of os.environ afaik, but since you love fixtures, it is there now [17:06] didrocks, because of multi arch [17:06] didrocks, now that that is there it can migrate [17:06] excellent! [17:06] elopio: i'm able to repro that error, digging now to see why [17:07] sergiusens: ah, I didn't see that and it was just one line above :) But yes, I prefer fixtures. [17:07] sergiusens: missed one: os.environ['SNAPCRAFT_SETUP_PROXIES'] = '1' [17:08] strange [17:08] that's twice actually. [17:09] elopio, oh, I didn't push :-p [17:09] well, I didn't commit to be precise [17:10] done [17:11] noise][: do we have to specify a primary snap to base the "product" around? What if we just want to test the base image by itself? [17:13] as I understood, that's just for authentication. So I used a dummy snap of mine. [17:13] I might be wrong, of course. [17:13] right, the primary snap is for authz [17:13] sergiusens: just the two os.environ['SNAPCRAFT_SETUP_PROXIES'] = '1', and then you are free to go. [17:14] noise][: elopio: so to test the image, I have to create a dummy snap that I have no intention (or desire) of actually installing, and everything is dependent on updating that snap? [17:14] I wonder if useFixture works on a @classmethod. umm... [17:14] elopio, oh, right [17:15] ogra_: hi, I don't think I have context for these highlights [17:15] plars: no, it is dependent on the list of snaps you use. Which don't need to be yours. [17:15] slangasek, snappy seeds ... did you cahnge anything for them yet ? [17:16] elopio: but one of them does, right? [17:16] ogra_: no, what are you expecting to be changed? [17:16] elopio, is this needed at all http://paste.ubuntu.com/15009708/ ? [17:16] elopio, and will that work? [17:16] slangasek, well, there was some discussion to base them on lxc seeds ort some such ... [17:16] *or [17:17] plars: primary_snap needs to be owned or shared with you [17:17] sergiusens: to be safe, I would put it in the SetUp. [17:17] ogra_: I'm not sure I was part of any concrete discussion about this [17:17] slangasek, natbase seems to be gone from snappy in 16.04, i was asked to put it back, i just wanted to make sure i'm not stepping on your toes here [17:17] *netbase [17:17] we certainly shouldn't have lots of different parallel seed definitions, but I'm not driving anything here currently, no [17:17] ok, good [17:18] sergiusens: and maybe it's not needed to clean it up, as all the examples tests will need the proxy. But I've gone mad a couple of times because of environment variables that I'm not sure where are set. That's why I started liking fixtures. [17:18] elopio, yeah, that's why I didn't worry about cleanup here [17:18] elopio, in anycase, pushed [17:19] sergiusens: thanks. Land whenever you want. [17:19] elopio, when testing finishes of course ;-) [17:20] fgimenez: the sync has been here for a long long time: https://paste.ubuntu.com/15009722/ [17:20] is it normal? [17:20] elopio: aha! s/rolling/rolling-core in your "release" [17:21] noise][: what? I didn't know rolling-core was a thing. [17:21] I'll update it. [17:21] elopio: I'm just going by what data is actually in the store/CPI [17:21] for those snaps you list it's rolling-core [17:22] noise][: thanks for digging it out. [17:22] y, sorry that error message isn't very good [17:23] elopio, i don't think so, that should be the final step, after all the files has been copied right? [17:24] fgimenez: I don't know. The jenkins page is down. [17:25] if I ctrl+c and sync again would I just break it all? [17:30] elopio, :) i think that it would be better to try to restart the docker service, it seems to be broken somehow, anyway compose will simplify this (that's my moto) [17:30] fgimenez: killing and retrying is my motto :p [17:32] restarted. I can't even run docker ps. [17:32] I'll do it all over again. [17:34] elopio, wait, docker ps is working [17:34] elopio, np :) [17:34] fgimenez: yeah, too late. [17:35] ogra_, just read the scrollback. netbase sounds okay to add back then, it seems? [17:36] kyrofa, yeah, i'll update that tomorrow if thats sufficient [17:36]