=== JanC_ is now known as JanC === mup_ is now known as mup === chihchun_afk is now known as chihchun [02:21] PR snapd#3477 opened: tests: fix snap create-key by restarting automatically rng-tools [02:33] hello, looking for support to get i2c enabled for snappy [02:33] is it possible, if so, how do I go about enabling it? thanjs [03:08] welp [06:38] good morning === zyga is now known as zyga-ubuntu [07:42] Bug #1697880 opened: Add "search" as an alias for "find" in snap command [07:59] niemeyer: feedback on bug 1697880 appreciated [07:59] Bug #1697880: Add "search" as an alias for "find" in snap command [07:59] good morning all [07:59] o/ [08:00] hey [08:30] what's the expected state of a change after an "abort" succeeds? [09:06] didn't we mark the interfaces-openvswitch spread test as manual? I see it failing again a numer of times today [09:10] fgimenez: ^^ [09:12] morphis: afaik the PR for marking it as manual was finally closed because other fixes seemed to solve the openvswitch flakyness, sergio knows the details better [09:12] fgimenez: hm, whatever was changed I still see it timing out [09:23] Hey all. Question. I'd like to deploy a python application as a snap, for our clients. I want to host X instances of each, per server. They're all the SAME application, but different client and different config. Is it possible to install a single snap multiple times (presumably with different names)? [09:24] zyga-ubuntu, zyga-fedora: snap-confine in the bind mount magic sets up /var/lib as a symlink, correct? [09:34] mvo: not quite [09:34] mvo: /var/lib is a tmpfs and there's a symlink farm to the core snap and to (on classic) one specific location in hostfs [09:34] mvo: why? anything broken? [09:46] zyga-ubuntu: mostly wondering about the permissions, they are quite permissive 1777 === rumble is now known as grumble [10:10] pedronis: you around? [10:12] Chipaca: yessish, had a bit of hard time sleeping last night [10:12] pedronis: ouh :-( [10:13] pedronis: I don't know how to properly abort a task it seems, as its change either ends up in Done or in Error [10:13] pedronis: but it's not urgent if that's too ish-y [10:13] Chipaca: abort in which sense ? [10:13] i've got plenty of other things to work on :-) [10:13] pedronis: 'snap abort nn' [10:13] what do you expect ? [10:14] pedronis: shouldn't it say something other than Done or Error in snap changes if you've successfully aborted it? [10:15] no, you get the abort, cannot finish, return error -> Undo the rest -> Error [10:16] at least that's how hook do this for example [10:18] koza, did you get anywhere yet ? btw ... http://people.canonical.com/~ogra/hummingboard-gate-serial.jpg [10:18] Chipaca: AbortStatus is not a final status, is just a marker status afaiu [10:19] yeap, it's Abort not Aborted [10:21] ogra, hey, nowhere near; replaced hdmi cable and microSD card; tried images, etc.. notning new [10:21] damn ... [10:23] Chipaca: this are ready states: DoneStatus, UndoneStatus, HoldStatus, ErrorStatus [10:24] koza, there seems to be a difference between revisions. mine has "REV1.2" printed next to the name on the PCB [10:25] ogra, rev1.2 is here too [10:26] koza, do you know if solid run offers any reference images ... and did you try one yet to make sure it isnt a HW issue ? [10:27] ogra, no I did not and I do not know of any. Trying to get this info from Linaro folks who - I have been told - are using this board. [10:27] koza, seems there are https://wiki.solid-run.com/doku.php?id=products:imx6:software:os:debian [10:27] https://images.solid-build.xyz/IMX6/Debian/ [10:28] ogra, are you sure about tX and RX, here http://download.solid-run.com/pub/solidrun/HummingBoard%202/HummingBoard2%20Schematics%20rev%201.2.pdf They say TX is in the middle (Page 2, search for J25) and you marked RX there [10:28] koza, yes, i am ... i got it wired like this here [10:29] ogra, ok, just double checking [10:29] yes, good idea try this debian img [10:30] white is definitely in the middle ... i had initially mixed up gnd and green, that works but doesnt recognize input (obviously ... if TX is wrong :P ) [10:30] so i'm 100% sure thats the correct wiring [10:31] got it [10:35] PR snapd#3478 opened: tests: extend upower-observe test to cover snaps providing slots [10:36] pedronis: should this manager auto-abort things when it's told to stop? [10:58] Chipaca: that should happens automatically [10:58] pedronis: it doesn't seem to [10:58] task runner kills on the tombs [10:58] s/on the/all the tombs/ [10:58] pedronis: i'll push code in a bit to see if i'm doing something wrong [11:33] ppisati, is there any reason why our linux-generic armhf build doesnt enable any allwinner SoCs ? [11:34] (seems there are many upstreamed already, but not enbled) [11:36] *enabled [11:47] * zyga-ubuntu finally groks async/await python [11:47] pedronis: i'm definitely doing something wrong :-) if you could take a look at https://github.com/snapcore/snapd/compare/master...chipaca:oddjob it'd be helpful [11:47] pedronis: the failing test is the one with printlns in it; it never gets past the "before stop" line [11:48] i thought it was waiting for the exec to finish (as i had a "sleep 1h" in there originally), but it's not that [11:48] wait maybe it's the lock [11:49] dammit [11:51] * zyga-ubuntu hugs Chipaca [11:56] pedronis: fixed the lock issue, pushed, still have questions (TestExecStop fails, with the change still in Doing) [12:05] fgimenez: another failure of the openvswitch test: https://travis-ci.org/snapcore/snapd/builds/242746311 [12:07] morphis: does this happen only on debian? we could disable it only on that system if that's the case [12:07] fgimenez: I saw it on ubuntu and debian today [12:08] so doesn't seem to be specific to a system [12:08] morphis: ok, i'll propose a PR for marking it as manual [12:08] thanks [12:12] PR snapd#3479 opened: tests: mark interfaces-openvswitch as manual due to prepare errors [12:15] Chipaca: just a heads up, I think there are some thing the that don't follow naming conventions [12:15] that's ok, i can change the conventions :-P [12:17] Chipaca: EnsureBefore doesn't do anything interesting if you don't use overlord.Loop or Settle fwiw [12:18] I might have just copied that from my testing code in api.go (not committed) [12:22] morphis: I need to skip our call today [12:28] Chipaca: you are hitting the new code that make sure we retry downloads across stopping of snapd [12:29] Chipaca: Stop provoked errors are turned into Retry [12:29] ahh [12:29] let me give you a pointer [12:29] yes i saw that code but it didn't click [12:30] zyga-ubuntu: ok [12:30] Chipaca: here, https://github.com/snapcore/snapd/blob/master/overlord/state/taskrunner.go#L168 [12:30] ogra: hello, you said you were doing something about splash screen support so wanted to ask you if you saw this linker error? (I added #define CONFIG_SPLASH_SCREEN to include/configs/rpi.h) /build/snaps/pi3-gadget/u-boot/common/splash.c:94: undefined reference to `bmp_display' [12:30] pedronis: easiest approach is to just document them as retried on stop, then :-) [12:31] sborovkov, nope, did you set CONFIG_CMD_BMP in your config ? [12:31] Chipaca: Stop != Abort basically [12:31] not sure it makes sense for all potential uses of Exec [12:32] but that's the current state of things [12:33] ogra: yeah that fixed that error. I did not add that define because wiki page said that by enabling splash screen bmp support would be enabled automatically [12:33] the internet is full of lies ;) [12:34] pedronis: agreed on that [12:34] pedronis: wrt naming conventions, you meant about Manager/NewManager vs OddJobManager/Manager, or something more than that? [12:34] yes [12:35] that sort of stuff [12:35] and oddjob vs oddjobstate [12:35] ah [12:35] and splitting oddjob.go into two [12:35] files [12:35] does it deserve the "state" ending? [12:36] well it makes manager, all the things with one have that name [12:37] and yes everything now has *state/*state.go vs *state/*mgr.go [12:37] afaict [12:41] ok [12:43] Chipaca: and *mgr has manager and handlers (unless and there's a lot and then we have handlers.go) and *state has things making Tasks/Tasksets and query function helper taking state.State [12:44] ogra: after rebuilding uboot, the only binary I should replace in the gadget snap should be uboot.bin? I see that there is a bunch of other binaries but I am not sure where they are coming from [12:44] jdstrand, hi! do you have a moment to take a look at https://github.com/snapcore/snapd/pull/3476 ? it's a small change [12:44] PR snapd#3476: snap-confine: validate SNAP_NAME against security tag [12:45] sborovkov, yeah ... i usually do my development on a running install and just replace it on the system-boot partition ... [12:45] ogra: thanks [12:46] only uboot.bin should be fine (make sure you have the uboot.ppatch in use though, else it wont find uboot.env) [13:00] ogra: no real reason, we just didn't have any hw to test it [13:00] pedronis: would it be reasonable to have a helper in oddjobstate that did an NewChange and the whole dance? [13:01] Chipaca: we don't do that usually [13:02] ppisati, but it wouldnt break any existing stuff to enabled it, would it ? [13:02] * ogra is just rebuilding a test deb here with just allwinner SoC turned on in the config [13:05] (i have a banana pro here that i never booted, and orange pi and nano pi ordered ... ) [13:10] ogra: are you on a board spree? :) [13:10] ogra: if it's multiplatform, it should be ok [13:10] ppisati, kind of ... i'm waiting for some 96boards to get delivered ... and since that takes so long i boredly start to add other boards :) [13:11] ogra: nonetheless, when you have something that works for you, we'll test on all the supported hw [13:11] cool [13:11] i'll let you know [13:40] Hi! I am a trying to install ubuntu core on Raspberry pi 3. I am facing an error during the installation in that, it is not accepting my email address. This is the error I am facing [13:41] Creating user failed: error: while creating user: cannot create user "email ID": Get https://login.ubuntu.com/api/v2/keys/emailID: dial tcp: lookup login.ubuntu.com on 10.58.194.16:53: no such host [13:41] Vamsi_: this looks like DNS issue [13:41] Vamsi_: are you using the wifi connection? [13:41] nope. I am using a wired internet connection. [13:44] zyga-fedora: What could be the possible error? Becuase the error was reported the 1st time after it took a while to contact the server. [13:45] no such host indicates that this is a DNS issue and that login.ubuntu.com is the domain that cannot be resolved [13:46] Okay. Please don't mind me asking, but I am what I call as a noob_level developer. So could you please guide me as to how to solve this issue? [13:47] Vamsi_: I don't know, try checking your network [13:49] okay. thank you. [13:50] yeah, sounds like a network issue [13:50] PR snapd#3480 opened: overlord/oddjobstate: new package for running commands as tasks [13:50] Vamsi_, the network config worked without any error on the page before ? [13:51] pedronis: ^ PR up [13:52] ogra: yup. No error on page. [13:53] thats weird ... it should work (surely does for me, i do regular test installs of the pi ... though using the daily edge image) [13:54] Vamsi, is 10.58.194.16 a properly working nameserver in your LAN usually ? [13:55] seems that is what your board gets as DNS entry (judging by the error message) [13:57] yup. It is a properly working name server [13:58] well, the error looks like it can not resolve "login.ubuntu.com" [13:58] do you have another machine that uses this DNS server where you could check if you can reach login.ubuntu.com ? [14:00] Yes I have another machine. Although... um... How do I check this? [14:00] just try "ping login.ubuntu.com" or if you have a desktop/UI on thereand a browser, go to login.ubuntu.com in there [14:01] tried this on another linux machine and this is what I got: [14:02] --- login.ubuntu.com ping statistics --- [14:02] 10 packets transmitted, 0 received, 100% packet loss, time 9198ms [14:03] hmm [14:03] * ogra just notices that he cant ping that either ... but a browser works [14:04] seems the login.ubuntu.com machine simply denies pings ... so a ping wont help as test [14:04] Vamsi, better try: wget http://login.ubuntu.com/ [14:05] that should download an index.html file [14:05] and you should see "200 OK" somewhere in the output when you run this [14:06] Yup I see 200 OK. [14:10] ok, then it isnt the DNS server [14:10] hmm [14:12] Okay! I realised the mistake I was doing. [14:12] Vamsi, oh, wait, did you literally type "emailID" into the user field in the setup screen ? [14:12] * ogra just noticed the url :) [14:14] I was using a different network for my notebook as compared to the one for the raspbery pi [14:15] ah [14:15] The network I was using for the raspberry pi was one with a number of restrictions. [14:15] yeah [14:17] ogra: After you suggested the wget http://login.ubuntu.com/ i noticed that the address was different and that's when I realised that I was using a different network. [14:17] :) [14:18] Thanks mate! [14:18] * ogra crosses fingers that it works with the new network [14:18] pstolowski: yes === chihchun is now known as chihchun_afk [14:29] PR snapd#3481 opened: tests: add avahi-observe interface test [14:30] ogra: Okay. Now I am stuck at another place. The installation is now stuck in the page that lists all the host key fingerprints [14:32] Vamsi, that isnt stuck, it means you are finished ... there should be an ssh command in the output that you can use to connect to your board [14:34] oh okay. Thanks. I actually did connect to my board now. I was expecting to automatically to restart or omething. [14:34] Thanks :) [14:34] enjoy :) [14:43] PR snapd#3482 opened: asserts: support timestamp and optional disabled header on repair [14:43] mvo: Chipaca: ^ [14:43] pedronis: thanks [14:43] pedronis: I check it in a wee bit, still wrestling with seccomp and snap-confine :/ [14:45] Chipaca: will we still need snapd#3462 ? [14:45] PR snapd#3462: systemd: refactor service ops to also be exposed more directly === koza is now known as koza|away [14:54] PR snapd#3462 closed: systemd: refactor service ops to also be exposed more directly [14:54] pedronis: maybe not, but I might pull some of the commits into a new pr instead [14:54] ok [14:55] hurra for being more careful with my commits \o/ [15:00] ogra: how do you even get into autoboot console on the rpi? at least for me even though it says press any key to cancel autoboot it just goes on with booting no matter what I am pressing on my keyboard [15:00] sborovkov, is it actually counting down ? [15:01] might be we did set bootdelay=0 because it causes issues with addon boards [15:01] ogra: i even tried increasing it to 15 seconds... but nothing happens [15:01] so you would need to set bootdelay to something higher ... on the running pi you can use "fw_printenv/fw_setenv" [15:02] hmm [15:02] * ogra has no pi wired up atm ... [15:02] https://github.com/snapcore/pi3-gadget/blob/master/prebuilt/uboot.env.in says we default to bootdelay=2 though [15:03] sborovkov, and you are sure your serial is wired up correctly ? [15:04] ogra: I set it to 15 in the boot settings :-) Ok I guess something wrong with my setup [15:04] check if you accidentially flipped TX and GND wires [15:13] PR snapd#2592 closed: many: add support for session dbus services via snaps [15:14] zyga-fedora, zyga-ubuntu, mvo: can you guys review and approve https://github.com/snapcore/snapd/pull/3479 ? [15:14] PR snapd#3479: tests: mark interfaces-openvswitch as manual due to prepare errors [15:14] looking [15:14] merged [15:15] PR snapd#3479 closed: tests: mark interfaces-openvswitch as manual due to prepare errors [15:16] PR snapd#3460 closed: ifacestate: only re-generate all security profiles if the system-key changes [15:17] PR snapd#3468 closed: debian: add missing Type=notify in 14.04 packaging [15:17] PR snapd#3469 closed: many: add "release.BuildStamp" to identify the current build [15:17] PR snapd#3471 closed: snap: make `snap run` look at the system-key for security profiles [15:18] Chipaca: do we need timeout support for those Exec tasks, like we have for hooks ? [15:18] hmmm [15:18] pedronis: I don't think we do right now [16:00] Chipaca: ok, I'll do the actual full reviewing tomorrow [16:00] pedronis: no worries [16:00] pedronis: try to get some sleep [16:51] PR snapcraft#1183 closed: First step; ruby support [16:53] zyga, out of the blue (no core refresh) 'snap try' stopped working again [16:53] and snap install [16:54] (cannot setup mount for snap "core": cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented) followed by (cannot update mount namespace of snap "core": cannot update preserved namespace of snap "core": cannot update snap namespace: not implemented) [16:54] zyga-fedora: zyga-ubuntu ^ [16:54] how did i fix this? [16:54] Haha, no suse today eh? [16:58] * Chipaca purges snapd and starts over [17:00] gah, that didn't work [17:06] kyrofa, elopio: I have a strawman here https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c [17:06] how can I test this? [17:07] kyrofa, elopio: any insight there would be appreciated [17:08] I'm thinking I need to use the cmake plugin though [17:11] bdx, have you tried using it just as a local plugin? [17:11] what would my snapcraft.yaml need to look like to do that? [17:12] I would have a ruby part, with `plugin: x_ruby` ? [17:12] bdx, take this plugin and put it in snap/plugins/x-ruby.py [17:13] bdx, then in snap/snapcraft.yaml, you can use it like `plugin: ruby` [17:13] got it ... not `plugin: x_ruby`? [17:13] or `x-ruby` [17:15] ahh, ok, x_ruby [17:17] No, snapcraft has (flawed, IMO) logic to look for x-ruby.py if you just use "ruby" [17:27] PR snapcraft#1258 closed: python-plugin: support pip list columns mode [17:37] kyrofa: here is what I'm experiencing http://paste.ubuntu.com/24858016/ [17:39] bdx, what did you name your plugin file? [17:39] x_ruby.py or x-ruby.py? [17:40] x_ruby.py [17:40] Use a hyphen [17:40] Take heed of that warning, though-- refer to the cmake plugin (or another in-tree plugin) for a more up-to-date __init__ [17:41] oohok [17:41] thx [17:46] PR snapd#3483 opened: tests: dependency packages installed during project prepare [18:10] https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md#initializing-a-plugin [18:10] "DEPRECATED: the plugin used by part 'ruby' needs to be updated to accept project options in its initializer. See https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md#initializing-a-plugin for more information" [18:10] that link doesn't seem to exist :( [18:12] I can't create a issue on snapcore/snapcraft for this either [18:13] there is no issues tab [18:16] * zyga-fedora is mentally drained and takes a break/walk [18:39] bdx, whoope [18:40] bdx, bugs at https://bugs.launchpad.net/snapcraft, please [18:40] That's definitely one [18:41] bdx, but just copy the __init__ declaration from cmake, or another plugin in snapcraft [18:41] (you're just missing a parameter there) [18:43] kyrofa: ok, done [18:44] kyrofa: so I backed of a bit [18:44] http://paste.ubuntu.com/24858444/ [18:45] the issue I seem to be hitting ... http://paste.ubuntu.com/24858448/ [18:46] apt needs an update before the build_packages install [18:46] bdx, you mean if you run `apt update` before this that works? [18:47] kyrofa: well trying these commands in a fresh lxd [18:47] bdx, no, it's libxslt1-dev [18:48] bdx, but is that just for building ruby? [18:48] kyrofa: yeah ... if I launch a fresh instance, and try to `apt install libxslt1-dev`, it fails [18:48] kyrofa: if I `apt update`, `apt install libxslt1-dev` succeeds [18:48] bdx, yes that makes sense. But snapcraft runs apt update, you're just using the wrong name there [18:49] oh my - [18:49] thanks [18:50] that got me going [18:50] thanks for bearing with me [18:50] bdx, you're doing awesome man, no bearing needed [18:52] bdx, where are you getting that list of deps for ruby, out of curiosity? That's quite a bit more than I typically use [18:52] kyrofa: https://github.com/battlemidget/juju-layer-ruby/blob/master/lib/rubylib.py#L51,L54 [18:54] Are you sure they're all required? [18:55] kyrofa: I just now tried spinning up a lxd and pulled down a ruby tar [18:55] Ruby builds with just gcc g++ make libz-dev libssl-dev libreadline-dev, I think [18:55] oh reall [18:55] let me give that a try [18:56] You might be missing features that way though, but we should know for sure [18:56] (when I deploy my rails projects, that's what I use to build ruby) [19:03] kyrofa: that is all that was needed [19:03] I'll swap those deps out [19:03] Nice. A little lighter [19:23] kyrofa: now I'm getting http://paste.ubuntu.com/24858731/ [19:27] bdx, ah, try zlib1g-dev [19:28] libz-dev jus installed for me on a fresh lxd though ... grrr [19:28] Virtual packages... [19:28] lol ... whatever that means [19:28] elopio, that's ringing a bell for me. Is there a reason those don't work? [19:28] I remember hearing you talk about that [19:29] bdx, yeah, I think this is a bug [19:31] kyrofa: where can I find the issue tracker for snapcraft? [19:31] bdx, https://bugs.launchpad.net/snapcraft [19:31] ahh nice, thx [19:32] bdx, yeah: https://bugs.launchpad.net/snapcraft/+bug/1660666 [19:32] Bug #1660666: build-packages fails on pure virtual packages [19:32] ahh nice [19:32] well, nice thats its being tracked already [19:32] Knew it sounded familiar [19:34] bdx: can you install the snapcraft snap from the edge channel? [19:34] kyrofa: what is this telling me http://paste.ubuntu.com/24858783/? [19:34] do I need to pass some init values to the call to super or something [19:34] yeah [19:35] bdx, that you need a better definition of __init__. Refer to any other plugin snapcraft [19:35] plugin in, rather [19:36] https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L95 [19:36] Huh... yeah wait [19:36] I grabbed it exactly as it is there [19:37] if I comment out pull() I don't get the error [19:37] ooh [19:37] scratch that [19:37] http://paste.ubuntu.com/24858822/ [19:38] ^ that will build [19:38] Wut [19:39] Yeah something is busted here... let me poke at it [19:41] http://paste.ubuntu.com/24858839/ - uncommenting either of the declarations in init will cause that error to surface [19:44] I wonder if the importing is breaking things [19:48] ooh, my bad [19:48] uncommenting self._ruby_dir = join(self.partdir, 'ruby') [19:48] works [19:49] its only the self._ruby_tar that breaks it [19:49] ooh, possibly I'm missing an arg to Tar() [19:49] I am [19:50] geeeeh! [19:51] Oh jeez, I just find that too [19:51] The deprecation warning is a little trigger happy, and masks the real issue [19:52] You're just missing source_dir [19:52] I say log another bug [19:52] :P [19:53] You're on a roll today! [19:56] once `snapcraft` succeeds, I end up with a ruby-test_0.1_amd64.snap file [19:56] I install the snap with `sudo snap install --devmode ruby-test_0.1_amd64.snap` [19:57] how can I introspect the snap now that it is installed? [19:57] bdx, well first of all, none of the plugins I've seen so far from you actually builds ruby [19:57] Right? [19:58] kyrofa: correct, I'm just trying to poke around to make sure what I've done so far produces the expected results [19:58] bdx, the short answer is: look in the prime/ dir, that represents what goes into the final snap [19:58] Sounds good [19:59] Once the prime step ends, all the snap step does is mksquashfs prime [19:59] ahh [20:09] kyrofa: alright, I'm going to take a shot at the pull and build steps [20:19] kyrofa: this seems to be building successfully https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c [20:20] kyrofa: should I use a chdir context manager to chdir into the directory created from untaring the ruby tar, and run the `./configure`, `make`, `make install` commands? [20:22] bdx, no, snapcraft gives you a few tools you can use [20:22] Let me find you an example [20:23] bdx, yeah, check out the nodejs plugin [20:23] bdx, you'll see `self.run([...] cwd=blah)` [20:40]