| === JanC_ is now known as JanC | ||
| === mup_ is now known as mup | ||
| === chihchun_afk is now known as chihchun | ||
| mup | PR snapd#3477 opened: tests: fix snap create-key by restarting automatically rng-tools <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3477> | 02:21 |
|---|---|---|
| chrisblazek | hello, looking for support to get i2c enabled for snappy | 02:33 |
| chrisblazek | is it possible, if so, how do I go about enabling it? thanjs | 02:33 |
| chrisblazek | welp | 03:08 |
| zyga-suse | good morning | 06:38 |
| === zyga is now known as zyga-ubuntu | ||
| mup | Bug #1697880 opened: Add "search" as an alias for "find" in snap command <Snappy:New> <https://launchpad.net/bugs/1697880> | 07:42 |
| Chipaca | niemeyer: feedback on bug 1697880 appreciated | 07:59 |
| mup | Bug #1697880: Add "search" as an alias for "find" in snap command <Snappy:Confirmed> <https://launchpad.net/bugs/1697880> | 07:59 |
| Chipaca | good morning all | 07:59 |
| pstolowski | o/ | 07:59 |
| zyga-ubuntu | hey | 08:00 |
| Chipaca | what's the expected state of a change after an "abort" succeeds? | 08:30 |
| morphis | didn't we mark the interfaces-openvswitch spread test as manual? I see it failing again a numer of times today | 09:06 |
| morphis | fgimenez: ^^ | 09:10 |
| fgimenez | 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 |
| morphis | fgimenez: hm, whatever was changed I still see it timing out | 09:12 |
| fallentree | 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:23 |
| mvo | zyga-ubuntu, zyga-fedora: snap-confine in the bind mount magic sets up /var/lib as a symlink, correct? | 09:24 |
| zyga-ubuntu | mvo: not quite | 09:34 |
| zyga-ubuntu | 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 |
| zyga-ubuntu | mvo: why? anything broken? | 09:34 |
| mvo | zyga-ubuntu: mostly wondering about the permissions, they are quite permissive 1777 | 09:46 |
| === rumble is now known as grumble | ||
| Chipaca | pedronis: you around? | 10:10 |
| pedronis | Chipaca: yessish, had a bit of hard time sleeping last night | 10:12 |
| Chipaca | pedronis: ouh :-( | 10:12 |
| Chipaca | 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 |
| Chipaca | pedronis: but it's not urgent if that's too ish-y | 10:13 |
| pedronis | Chipaca: abort in which sense ? | 10:13 |
| Chipaca | i've got plenty of other things to work on :-) | 10:13 |
| Chipaca | pedronis: 'snap abort nn' | 10:13 |
| pedronis | what do you expect ? | 10:13 |
| Chipaca | pedronis: shouldn't it say something other than Done or Error in snap changes if you've successfully aborted it? | 10:14 |
| pedronis | no, you get the abort, cannot finish, return error -> Undo the rest -> Error | 10:15 |
| pedronis | at least that's how hook do this for example | 10:16 |
| ogra | koza, did you get anywhere yet ? btw ... http://people.canonical.com/~ogra/hummingboard-gate-serial.jpg | 10:18 |
| pedronis | Chipaca: AbortStatus is not a final status, is just a marker status afaiu | 10:18 |
| Chipaca | yeap, it's Abort not Aborted | 10:19 |
| koza | ogra, hey, nowhere near; replaced hdmi cable and microSD card; tried images, etc.. notning new | 10:21 |
| ogra | damn ... | 10:21 |
| pedronis | Chipaca: this are ready states: DoneStatus, UndoneStatus, HoldStatus, ErrorStatus | 10:23 |
| ogra | koza, there seems to be a difference between revisions. mine has "REV1.2" printed next to the name on the PCB | 10:24 |
| koza | ogra, rev1.2 is here too | 10:25 |
| ogra | 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:26 |
| koza | 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 |
| ogra | koza, seems there are https://wiki.solid-run.com/doku.php?id=products:imx6:software:os:debian | 10:27 |
| ogra | https://images.solid-build.xyz/IMX6/Debian/ | 10:27 |
| koza | 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 |
| ogra | koza, yes, i am ... i got it wired like this here | 10:28 |
| koza | ogra, ok, just double checking | 10:29 |
| koza | yes, good idea try this debian img | 10:29 |
| ogra | 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 |
| ogra | so i'm 100% sure thats the correct wiring | 10:30 |
| koza | got it | 10:31 |
| mup | PR snapd#3478 opened: tests: extend upower-observe test to cover snaps providing slots <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3478> | 10:35 |
| Chipaca | pedronis: should this manager auto-abort things when it's told to stop? | 10:36 |
| pedronis | Chipaca: that should happens automatically | 10:58 |
| Chipaca | pedronis: it doesn't seem to | 10:58 |
| pedronis | task runner kills on the tombs | 10:58 |
| pedronis | s/on the/all the tombs/ | 10:58 |
| Chipaca | pedronis: i'll push code in a bit to see if i'm doing something wrong | 10:58 |
| ogra | ppisati, is there any reason why our linux-generic armhf build doesnt enable any allwinner SoCs ? | 11:33 |
| ogra | (seems there are many upstreamed already, but not enbled) | 11:34 |
| ogra | *enabled | 11:36 |
| * zyga-ubuntu finally groks async/await python | 11:47 | |
| Chipaca | 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 |
| Chipaca | pedronis: the failing test is the one with printlns in it; it never gets past the "before stop" line | 11:47 |
| Chipaca | 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 |
| Chipaca | wait maybe it's the lock | 11:48 |
| Chipaca | dammit | 11:49 |
| * zyga-ubuntu hugs Chipaca | 11:51 | |
| Chipaca | pedronis: fixed the lock issue, pushed, still have questions (TestExecStop fails, with the change still in Doing) | 11:56 |
| morphis | fgimenez: another failure of the openvswitch test: https://travis-ci.org/snapcore/snapd/builds/242746311 | 12:05 |
| fgimenez | morphis: does this happen only on debian? we could disable it only on that system if that's the case | 12:07 |
| morphis | fgimenez: I saw it on ubuntu and debian today | 12:07 |
| morphis | so doesn't seem to be specific to a system | 12:08 |
| fgimenez | morphis: ok, i'll propose a PR for marking it as manual | 12:08 |
| morphis | thanks | 12:08 |
| mup | PR snapd#3479 opened: tests: mark interfaces-openvswitch as manual due to prepare errors <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3479> | 12:12 |
| pedronis | Chipaca: just a heads up, I think there are some thing the that don't follow naming conventions | 12:15 |
| Chipaca | that's ok, i can change the conventions :-P | 12:15 |
| pedronis | Chipaca: EnsureBefore doesn't do anything interesting if you don't use overlord.Loop or Settle fwiw | 12:17 |
| Chipaca | I might have just copied that from my testing code in api.go (not committed) | 12:18 |
| zyga-ubuntu | morphis: I need to skip our call today | 12:22 |
| pedronis | Chipaca: you are hitting the new code that make sure we retry downloads across stopping of snapd | 12:28 |
| pedronis | Chipaca: Stop provoked errors are turned into Retry | 12:29 |
| Chipaca | ahh | 12:29 |
| pedronis | let me give you a pointer | 12:29 |
| Chipaca | yes i saw that code but it didn't click | 12:29 |
| morphis | zyga-ubuntu: ok | 12:30 |
| pedronis | Chipaca: here, https://github.com/snapcore/snapd/blob/master/overlord/state/taskrunner.go#L168 | 12:30 |
| sborovkov | 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 |
| Chipaca | pedronis: easiest approach is to just document them as retried on stop, then :-) | 12:30 |
| ogra | sborovkov, nope, did you set CONFIG_CMD_BMP in your config ? | 12:31 |
| pedronis | Chipaca: Stop != Abort basically | 12:31 |
| pedronis | not sure it makes sense for all potential uses of Exec | 12:31 |
| pedronis | but that's the current state of things | 12:32 |
| sborovkov | 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 |
| ogra | the internet is full of lies ;) | 12:33 |
| Chipaca | pedronis: agreed on that | 12:34 |
| Chipaca | pedronis: wrt naming conventions, you meant about Manager/NewManager vs OddJobManager/Manager, or something more than that? | 12:34 |
| pedronis | yes | 12:34 |
| pedronis | that sort of stuff | 12:35 |
| pedronis | and oddjob vs oddjobstate | 12:35 |
| Chipaca | ah | 12:35 |
| pedronis | and splitting oddjob.go into two | 12:35 |
| pedronis | files | 12:35 |
| Chipaca | does it deserve the "state" ending? | 12:35 |
| pedronis | well it makes manager, all the things with one have that name | 12:36 |
| pedronis | and yes everything now has *state/*state.go vs *state/*mgr.go | 12:37 |
| pedronis | afaict | 12:37 |
| Chipaca | ok | 12:41 |
| pedronis | 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:43 |
| sborovkov | 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 |
| pstolowski | 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 |
| mup | PR snapd#3476: snap-confine: validate SNAP_NAME against security tag <Created by stolowski> <https://github.com/snapcore/snapd/pull/3476> | 12:44 |
| ogra | sborovkov, yeah ... i usually do my development on a running install and just replace it on the system-boot partition ... | 12:45 |
| sborovkov | ogra: thanks | 12:45 |
| ogra | only uboot.bin should be fine (make sure you have the uboot.ppatch in use though, else it wont find uboot.env) | 12:46 |
| ppisati | ogra: no real reason, we just didn't have any hw to test it | 13:00 |
| Chipaca | pedronis: would it be reasonable to have a helper in oddjobstate that did an NewChange and the whole dance? | 13:00 |
| pedronis | Chipaca: we don't do that usually | 13:01 |
| ogra | 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:02 | |
| ogra | (i have a banana pro here that i never booted, and orange pi and nano pi ordered ... ) | 13:05 |
| ppisati | ogra: are you on a board spree? :) | 13:10 |
| ppisati | ogra: if it's multiplatform, it should be ok | 13:10 |
| ogra | 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:10 |
| ppisati | ogra: nonetheless, when you have something that works for you, we'll test on all the supported hw | 13:11 |
| ogra | cool | 13:11 |
| ogra | i'll let you know | 13:11 |
| Vamsi_ | 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:40 |
| Vamsi_ | 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 |
| zyga-fedora | Vamsi_: this looks like DNS issue | 13:41 |
| zyga-fedora | Vamsi_: are you using the wifi connection? | 13:41 |
| Vamsi_ | nope. I am using a wired internet connection. | 13:41 |
| Vamsi_ | 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:44 |
| zyga-fedora | no such host indicates that this is a DNS issue and that login.ubuntu.com is the domain that cannot be resolved | 13:45 |
| Vamsi_ | 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:46 |
| zyga-fedora | Vamsi_: I don't know, try checking your network | 13:47 |
| Vamsi_ | okay. thank you. | 13:49 |
| ogra | yeah, sounds like a network issue | 13:50 |
| mup | PR snapd#3480 opened: overlord/oddjobstate: new package for running commands as tasks <Created by chipaca> <https://github.com/snapcore/snapd/pull/3480> | 13:50 |
| ogra | Vamsi_, the network config worked without any error on the page before ? | 13:50 |
| Chipaca | pedronis: ^ PR up | 13:51 |
| Vamsi | ogra: yup. No error on page. | 13:52 |
| ogra | thats weird ... it should work (surely does for me, i do regular test installs of the pi ... though using the daily edge image) | 13:53 |
| ogra | Vamsi, is 10.58.194.16 a properly working nameserver in your LAN usually ? | 13:54 |
| ogra | seems that is what your board gets as DNS entry (judging by the error message) | 13:55 |
| Vamsi | yup. It is a properly working name server | 13:57 |
| ogra | well, the error looks like it can not resolve "login.ubuntu.com" | 13:58 |
| ogra | do you have another machine that uses this DNS server where you could check if you can reach login.ubuntu.com ? | 13:58 |
| Vamsi | Yes I have another machine. Although... um... How do I check this? | 14:00 |
| ogra | 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:00 |
| Vamsi | tried this on another linux machine and this is what I got: | 14:01 |
| Vamsi | --- login.ubuntu.com ping statistics --- | 14:02 |
| Vamsi | 10 packets transmitted, 0 received, 100% packet loss, time 9198ms | 14:02 |
| ogra | hmm | 14:03 |
| * ogra just notices that he cant ping that either ... but a browser works | 14:03 | |
| ogra | seems the login.ubuntu.com machine simply denies pings ... so a ping wont help as test | 14:04 |
| ogra | Vamsi, better try: wget http://login.ubuntu.com/ | 14:04 |
| ogra | that should download an index.html file | 14:05 |
| ogra | and you should see "200 OK" somewhere in the output when you run this | 14:05 |
| Vamsi | Yup I see 200 OK. | 14:06 |
| ogra | ok, then it isnt the DNS server | 14:10 |
| ogra | hmm | 14:10 |
| Vamsi | Okay! I realised the mistake I was doing. | 14:12 |
| ogra | Vamsi, oh, wait, did you literally type "emailID" into the user field in the setup screen ? | 14:12 |
| * ogra just noticed the url :) | 14:12 | |
| Vamsi | I was using a different network for my notebook as compared to the one for the raspbery pi | 14:14 |
| ogra | ah | 14:15 |
| Vamsi | The network I was using for the raspberry pi was one with a number of restrictions. | 14:15 |
| ogra | yeah | 14:15 |
| Vamsi | 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 |
| ogra | :) | 14:17 |
| Vamsi | Thanks mate! | 14:18 |
| * ogra crosses fingers that it works with the new network | 14:18 | |
| jdstrand | pstolowski: yes | 14:18 |
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#3481 opened: tests: add avahi-observe interface test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3481> | 14:29 |
| Vamsi | 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:30 |
| ogra | 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:32 |
| Vamsi | oh okay. Thanks. I actually did connect to my board now. I was expecting to automatically to restart or omething. | 14:34 |
| Vamsi | Thanks :) | 14:34 |
| ogra | enjoy :) | 14:34 |
| mup | PR snapd#3482 opened: asserts: support timestamp and optional disabled header on repair <Created by pedronis> <https://github.com/snapcore/snapd/pull/3482> | 14:43 |
| pedronis | mvo: Chipaca: ^ | 14:43 |
| mvo | pedronis: thanks | 14:43 |
| mvo | pedronis: I check it in a wee bit, still wrestling with seccomp and snap-confine :/ | 14:43 |
| pedronis | Chipaca: will we still need snapd#3462 ? | 14:45 |
| mup | PR snapd#3462: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <https://github.com/snapcore/snapd/pull/3462> | 14:45 |
| === koza is now known as koza|away | ||
| mup | PR snapd#3462 closed: systemd: refactor service ops to also be exposed more directly <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/3462> | 14:54 |
| Chipaca | pedronis: maybe not, but I might pull some of the commits into a new pr instead | 14:54 |
| pedronis | ok | 14:54 |
| Chipaca | hurra for being more careful with my commits \o/ | 14:55 |
| sborovkov | 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 |
| ogra | sborovkov, is it actually counting down ? | 15:00 |
| ogra | might be we did set bootdelay=0 because it causes issues with addon boards | 15:01 |
| sborovkov | ogra: i even tried increasing it to 15 seconds... but nothing happens | 15:01 |
| ogra | so you would need to set bootdelay to something higher ... on the running pi you can use "fw_printenv/fw_setenv" | 15:01 |
| ogra | hmm | 15:02 |
| * ogra has no pi wired up atm ... | 15:02 | |
| ogra | https://github.com/snapcore/pi3-gadget/blob/master/prebuilt/uboot.env.in says we default to bootdelay=2 though | 15:02 |
| ogra | sborovkov, and you are sure your serial is wired up correctly ? | 15:03 |
| sborovkov | ogra: I set it to 15 in the boot settings :-) Ok I guess something wrong with my setup | 15:04 |
| ogra | check if you accidentially flipped TX and GND wires | 15:04 |
| mup | PR snapd#2592 closed: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592> | 15:13 |
| morphis | zyga-fedora, zyga-ubuntu, mvo: can you guys review and approve https://github.com/snapcore/snapd/pull/3479 ? | 15:14 |
| mup | PR snapd#3479: tests: mark interfaces-openvswitch as manual due to prepare errors <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3479> | 15:14 |
| zyga-fedora | looking | 15:14 |
| zyga-fedora | merged | 15:14 |
| mup | PR snapd#3479 closed: tests: mark interfaces-openvswitch as manual due to prepare errors <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3479> | 15:15 |
| mup | PR snapd#3460 closed: ifacestate: only re-generate all security profiles if the system-key changes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3460> | 15:16 |
| mup | PR snapd#3468 closed: debian: add missing Type=notify in 14.04 packaging <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3468> | 15:17 |
| mup | PR snapd#3469 closed: many: add "release.BuildStamp" to identify the current build <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3469> | 15:17 |
| mup | PR snapd#3471 closed: snap: make `snap run` look at the system-key for security profiles <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3471> | 15:17 |
| pedronis | Chipaca: do we need timeout support for those Exec tasks, like we have for hooks ? | 15:18 |
| Chipaca | hmmm | 15:18 |
| Chipaca | pedronis: I don't think we do right now | 15:18 |
| pedronis | Chipaca: ok, I'll do the actual full reviewing tomorrow | 16:00 |
| Chipaca | pedronis: no worries | 16:00 |
| Chipaca | pedronis: try to get some sleep | 16:00 |
| mup | PR snapcraft#1183 closed: First step; ruby support <Created by justincan> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1183> | 16:51 |
| Chipaca | zyga, out of the blue (no core refresh) 'snap try' stopped working again | 16:53 |
| Chipaca | and snap install | 16:53 |
| Chipaca | (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 |
| Chipaca | zyga-fedora: zyga-ubuntu ^ | 16:54 |
| Chipaca | how did i fix this? | 16:54 |
| kyrofa | Haha, no suse today eh? | 16:54 |
| * Chipaca purges snapd and starts over | 16:58 | |
| Chipaca | gah, that didn't work | 17:00 |
| bdx | kyrofa, elopio: I have a strawman here https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c | 17:06 |
| bdx | how can I test this? | 17:06 |
| bdx | kyrofa, elopio: any insight there would be appreciated | 17:07 |
| bdx | I'm thinking I need to use the cmake plugin though | 17:08 |
| kyrofa | bdx, have you tried using it just as a local plugin? | 17:11 |
| bdx | what would my snapcraft.yaml need to look like to do that? | 17:11 |
| bdx | I would have a ruby part, with `plugin: x_ruby` ? | 17:12 |
| kyrofa | bdx, take this plugin and put it in snap/plugins/x-ruby.py | 17:12 |
| kyrofa | bdx, then in snap/snapcraft.yaml, you can use it like `plugin: ruby` | 17:13 |
| bdx | got it ... not `plugin: x_ruby`? | 17:13 |
| bdx | or `x-ruby` | 17:13 |
| bdx | ahh, ok, x_ruby | 17:15 |
| kyrofa | No, snapcraft has (flawed, IMO) logic to look for x-ruby.py if you just use "ruby" | 17:17 |
| mup | PR snapcraft#1258 closed: python-plugin: support pip list columns mode <Created by sdeancos> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1258> | 17:27 |
| bdx | kyrofa: here is what I'm experiencing http://paste.ubuntu.com/24858016/ | 17:37 |
| kyrofa | bdx, what did you name your plugin file? | 17:39 |
| kyrofa | x_ruby.py or x-ruby.py? | 17:39 |
| bdx | x_ruby.py | 17:40 |
| kyrofa | Use a hyphen | 17:40 |
| kyrofa | Take heed of that warning, though-- refer to the cmake plugin (or another in-tree plugin) for a more up-to-date __init__ | 17:40 |
| bdx | oohok | 17:41 |
| bdx | thx | 17:41 |
| mup | PR snapd#3483 opened: tests: dependency packages installed during project prepare <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/3483> | 17:46 |
| bdx | https://github.com/snapcore/snapcraft/blob/master/docs/plugins.md#initializing-a-plugin | 18:10 |
| bdx | "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 |
| bdx | that link doesn't seem to exist :( | 18:10 |
| bdx | I can't create a issue on snapcore/snapcraft for this either | 18:12 |
| bdx | there is no issues tab | 18:13 |
| * zyga-fedora is mentally drained and takes a break/walk | 18:16 | |
| kyrofa | bdx, whoope | 18:39 |
| kyrofa | bdx, bugs at https://bugs.launchpad.net/snapcraft, please | 18:40 |
| kyrofa | That's definitely one | 18:40 |
| kyrofa | bdx, but just copy the __init__ declaration from cmake, or another plugin in snapcraft | 18:41 |
| kyrofa | (you're just missing a parameter there) | 18:41 |
| bdx | kyrofa: ok, done | 18:43 |
| bdx | kyrofa: so I backed of a bit | 18:44 |
| bdx | http://paste.ubuntu.com/24858444/ | 18:44 |
| bdx | the issue I seem to be hitting ... http://paste.ubuntu.com/24858448/ | 18:45 |
| bdx | apt needs an update before the build_packages install | 18:46 |
| kyrofa | bdx, you mean if you run `apt update` before this that works? | 18:46 |
| bdx | kyrofa: well trying these commands in a fresh lxd | 18:47 |
| kyrofa | bdx, no, it's libxslt1-dev | 18:47 |
| kyrofa | bdx, but is that just for building ruby? | 18:48 |
| bdx | kyrofa: yeah ... if I launch a fresh instance, and try to `apt install libxslt1-dev`, it fails | 18:48 |
| bdx | kyrofa: if I `apt update`, `apt install libxslt1-dev` succeeds | 18:48 |
| kyrofa | bdx, yes that makes sense. But snapcraft runs apt update, you're just using the wrong name there | 18:48 |
| bdx | oh my - | 18:49 |
| bdx | thanks | 18:49 |
| bdx | that got me going | 18:50 |
| bdx | thanks for bearing with me | 18:50 |
| kyrofa | bdx, you're doing awesome man, no bearing needed | 18:50 |
| kyrofa | 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 |
| bdx | kyrofa: https://github.com/battlemidget/juju-layer-ruby/blob/master/lib/rubylib.py#L51,L54 | 18:52 |
| kyrofa | Are you sure they're all required? | 18:54 |
| bdx | kyrofa: I just now tried spinning up a lxd and pulled down a ruby tar | 18:55 |
| kyrofa | Ruby builds with just gcc g++ make libz-dev libssl-dev libreadline-dev, I think | 18:55 |
| bdx | oh reall | 18:55 |
| bdx | let me give that a try | 18:55 |
| kyrofa | You might be missing features that way though, but we should know for sure | 18:56 |
| kyrofa | (when I deploy my rails projects, that's what I use to build ruby) | 18:56 |
| bdx | kyrofa: that is all that was needed | 19:03 |
| bdx | I'll swap those deps out | 19:03 |
| kyrofa | Nice. A little lighter | 19:03 |
| bdx | kyrofa: now I'm getting http://paste.ubuntu.com/24858731/ | 19:23 |
| kyrofa | bdx, ah, try zlib1g-dev | 19:27 |
| bdx | libz-dev jus installed for me on a fresh lxd though ... grrr | 19:28 |
| kyrofa | Virtual packages... | 19:28 |
| bdx | lol ... whatever that means | 19:28 |
| kyrofa | elopio, that's ringing a bell for me. Is there a reason those don't work? | 19:28 |
| kyrofa | I remember hearing you talk about that | 19:28 |
| kyrofa | bdx, yeah, I think this is a bug | 19:29 |
| bdx | kyrofa: where can I find the issue tracker for snapcraft? | 19:31 |
| kyrofa | bdx, https://bugs.launchpad.net/snapcraft | 19:31 |
| bdx | ahh nice, thx | 19:31 |
| kyrofa | bdx, yeah: https://bugs.launchpad.net/snapcraft/+bug/1660666 | 19:32 |
| mup | Bug #1660666: build-packages fails on pure virtual packages <Snapcraft:Confirmed> <https://launchpad.net/bugs/1660666> | 19:32 |
| bdx | ahh nice | 19:32 |
| bdx | well, nice thats its being tracked already | 19:32 |
| kyrofa | Knew it sounded familiar | 19:32 |
| elopio | bdx: can you install the snapcraft snap from the edge channel? | 19:34 |
| bdx | kyrofa: what is this telling me http://paste.ubuntu.com/24858783/? | 19:34 |
| bdx | do I need to pass some init values to the call to super or something | 19:34 |
| bdx | yeah | 19:34 |
| kyrofa | bdx, that you need a better definition of __init__. Refer to any other plugin snapcraft | 19:35 |
| kyrofa | plugin in, rather | 19:35 |
| bdx | https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L95 | 19:36 |
| kyrofa | Huh... yeah wait | 19:36 |
| bdx | I grabbed it exactly as it is there | 19:36 |
| bdx | if I comment out pull() I don't get the error | 19:37 |
| bdx | ooh | 19:37 |
| bdx | scratch that | 19:37 |
| bdx | http://paste.ubuntu.com/24858822/ | 19:37 |
| bdx | ^ that will build | 19:38 |
| kyrofa | Wut | 19:38 |
| kyrofa | Yeah something is busted here... let me poke at it | 19:39 |
| bdx | http://paste.ubuntu.com/24858839/ - uncommenting either of the declarations in init will cause that error to surface | 19:41 |
| kyrofa | I wonder if the importing is breaking things | 19:44 |
| bdx | ooh, my bad | 19:48 |
| bdx | uncommenting self._ruby_dir = join(self.partdir, 'ruby') | 19:48 |
| bdx | works | 19:48 |
| bdx | its only the self._ruby_tar that breaks it | 19:49 |
| bdx | ooh, possibly I'm missing an arg to Tar() | 19:49 |
| bdx | I am | 19:49 |
| bdx | geeeeh! | 19:50 |
| kyrofa | Oh jeez, I just find that too | 19:51 |
| kyrofa | The deprecation warning is a little trigger happy, and masks the real issue | 19:51 |
| kyrofa | You're just missing source_dir | 19:52 |
| kyrofa | I say log another bug | 19:52 |
| kyrofa | :P | 19:52 |
| kyrofa | You're on a roll today! | 19:53 |
| bdx | once `snapcraft` succeeds, I end up with a ruby-test_0.1_amd64.snap file | 19:56 |
| bdx | I install the snap with `sudo snap install --devmode ruby-test_0.1_amd64.snap` | 19:56 |
| bdx | how can I introspect the snap now that it is installed? | 19:57 |
| kyrofa | bdx, well first of all, none of the plugins I've seen so far from you actually builds ruby | 19:57 |
| kyrofa | Right? | 19:57 |
| bdx | kyrofa: correct, I'm just trying to poke around to make sure what I've done so far produces the expected results | 19:58 |
| kyrofa | bdx, the short answer is: look in the prime/ dir, that represents what goes into the final snap | 19:58 |
| kyrofa | Sounds good | 19:58 |
| kyrofa | Once the prime step ends, all the snap step does is mksquashfs prime | 19:59 |
| bdx | ahh | 19:59 |
| bdx | kyrofa: alright, I'm going to take a shot at the pull and build steps | 20:09 |
| bdx | kyrofa: this seems to be building successfully https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c | 20:19 |
| bdx | 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:20 |
| kyrofa | bdx, no, snapcraft gives you a few tools you can use | 20:22 |
| kyrofa | Let me find you an example | 20:22 |
| kyrofa | bdx, yeah, check out the nodejs plugin | 20:23 |
| kyrofa | bdx, you'll see `self.run([...] cwd=blah)` | 20:23 |
| bdx | kyrofa: so I need to define the dir rootdir/<extracted ruby dir> to use with the run() function then right | 20:40 |
| kyrofa | You got it | 20:40 |
| bdx | `install_dir = join(installdir, "ruby-{version}".format(version=self.options.ruby_version) | 20:43 |
| bdx | self.run(['./configure'], cwd=install_dir) | 20:43 |
| bdx | ` | 20:43 |
| bdx | like that? | 20:44 |
| kyrofa | Assuming the ruby tarball is unpacked into install_dir, yeah (more like a build_dir in my mind) | 20:44 |
| bdx | yeah, totally ... so the tar gets unpacked into `join(self.partdir, 'ruby')` | 20:45 |
| bdx | so I would want that dir | 20:45 |
| bdx | ok | 20:45 |
| bdx | got it | 20:45 |
| mup | PR snapcraft#1342 closed: nodejs: run install and commands in source-subdir <Created by Saviq> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1342> | 20:51 |
| bdx | kyrofa: I think I'm on the right track here, mind having another look https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c | 20:55 |
| kyrofa | bdx, yeah that's getting there, although I suggest always using lists for `self.run()` (you're mixing lists with strings) | 20:58 |
| bdx | ahh, gotcha, fixed now https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c | 20:59 |
| kyrofa | Yes, much better | 21:00 |
| bdx | so next I need to symlink the binary? something similar to this https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L112,L117 ? | 21:00 |
| kyrofa | Right, this will build ruby, but as it is right now it'll install it _on the host_ instead of into the snap | 21:01 |
| kyrofa | (and fail unless you're using sudo, of course) | 21:01 |
| kyrofa | So you'll want to either install it with DESTDIR, or configure a prefix. I'd try destdir first | 21:01 |
| bdx | kyrofa: I'm having a hard time connecting the dots on how that is done | 21:05 |
| kyrofa | bdx, you want ruby to end up in `self.installdir` | 21:05 |
| bdx | oh I do? | 21:05 |
| bdx | ok | 21:05 |
| kyrofa | bdx, yeah let's back up a bit. Do you have much experience using snapcraft? | 21:06 |
| kyrofa | I want to fill some of the holes for you, just need to know where to start | 21:06 |
| bdx | kyrofa: outside of following the tutorials, no | 21:06 |
| bdx | none | 21:07 |
| kyrofa | bdx, so you probably know that every part in snapcraft goes through a lifecycle of steps | 21:07 |
| bdx | yes | 21:07 |
| kyrofa | pull -> build -> stage -> prime | 21:07 |
| kyrofa | Then once all the parts go through that lifecycle, the "snap" step runs | 21:07 |
| bdx | 10-4 | 21:08 |
| kyrofa | The plugins are responsible for the first two steps: pull and build | 21:08 |
| bdx | ok | 21:08 |
| kyrofa | Everything else is part of snapcraft core | 21:08 |
| bdx | ok | 21:08 |
| kyrofa | There's a very simple agreement between plugins and snapcraft to do the handoff between build and stage | 21:09 |
| kyrofa | That is: anything in parts/<partname>/install will end up in stage | 21:09 |
| bdx | ok, and the stage gets mounted? | 21:09 |
| bdx | or stage is the last step executed before snap | 21:10 |
| kyrofa | Nope. The stage step takes everything in every part's install dir and combines them into a single stage/ dir | 21:10 |
| bdx | ok | 21:10 |
| kyrofa | Sometimes you'll run into conflicts when that happens if multiple parts provide the same file, etc. | 21:10 |
| bdx | got it | 21:10 |
| kyrofa | Once stage has happened, the prime step takes stuff from each part's installdir AGAIN and combines it into the prime dir | 21:11 |
| kyrofa | Once that has happened for all parts, the snap step runs mksquashfs on the prime dir and you're done | 21:11 |
| kyrofa | So, bringing this full circle: ruby needs to end up in the part's installdir, or it won't end up in the snap | 21:11 |
| bdx | https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c#file-ruby-x-py-L32 | 21:12 |
| kyrofa | The plugin knows where the installdir is via `self.installdir` | 21:12 |
| bdx | needs to be `self._ruby_dir = join(self.installdir, 'ruby') | 21:12 |
| kyrofa | No, because then all the ruby SOURCE will end up in the snap-- you don't want that either | 21:12 |
| kyrofa | You're fetching/unpacking/building ruby off to the side, I like that | 21:13 |
| kyrofa | But you need to INSTALL it into the installdir | 21:13 |
| bdx | ahh | 21:13 |
| bdx | not the same dir where I built it | 21:13 |
| kyrofa | Take a look at the make plugin, how it uses DESTDIR | 21:13 |
| kyrofa | Indeed | 21:13 |
| bdx | otherwise it would just get discarded too | 21:13 |
| bdx | ok | 21:13 |
| kyrofa | That wouldn't happen anyway: by default ruby will install onto the system | 21:13 |
| bdx | yeah so I'm really confused about that lol | 21:13 |
| bdx | self._ruby_dir = join(self.partdir, 'ruby') | 21:13 |
| bdx | oops | 21:14 |
| bdx | https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/make.py#L72,L74 | 21:14 |
| kyrofa | Oh yeah.. not the simplest example. The cmake plugin then! | 21:14 |
| kyrofa | :P | 21:14 |
| bdx | so, self.sourcedir in cmake then? | 21:16 |
| bdx | https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/cmake.py#L73 | 21:17 |
| kyrofa | self.sourcedir is where the project your plugin will be building will be fetched | 21:17 |
| bdx | I need something similar to the _build_environment() then? | 21:17 |
| kyrofa | Oh darn, no, cmake inherits from make, so still confusing | 21:17 |
| bdx | yeah... | 21:18 |
| kyrofa | Scratch that plan. So by default, when you run ./configure, it prepares itself to install into /usr/bin, or /usr/local/bin, etc. | 21:18 |
| * bdx sobs uncontrollably | 21:19 | |
| kyrofa | :P | 21:19 |
| bdx | totally | 21:19 |
| kyrofa | If you want it elsewhere, you have two options: either ./configure --prefix=elsewhere, and then `make install` puts it elsewhere | 21:19 |
| kyrofa | Or ./configure like normal, and when running `make install` actually run `make install DESTDIR=elsewhere` | 21:19 |
| kyrofa | I suggest trying the latter option first | 21:20 |
| bdx | yea, ok | 21:20 |
| kyrofa | Where "elsewhere" is self.installdir | 21:20 |
| bdx | ok, yeah this makes sense | 21:20 |
| kyrofa | So now we're fetching and building ruby in a disposable place, but installing it into the snap so we can use it at build AND runtime | 21:21 |
| bdx | yes, I see that now | 21:21 |
| bdx | kyrofa: I've implemented those bits here https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c | 21:26 |
| kyrofa | Yeah give that a shot, see if ruby ends up in prime | 21:26 |
| kyrofa | Oh wait | 21:27 |
| kyrofa | I suggest moving -j arg to the `make`, `make install` probably doesn't need it | 21:27 |
| kyrofa | It'll be slow | 21:27 |
| bdx | entirely | 21:27 |
| bdx | kyrofa: great progress | 21:40 |
| bdx | kyrofa: here is `$ snapcraft` <- http://paste.ubuntu.com/, here is what my directory tree looks like http://paste.ubuntu.com/24859583/ | 21:42 |
| bdx | https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c | 21:46 |
| bdx | I'm not seeing the ruby binary anywhere | 21:46 |
| kyrofa | bdx, testing... | 21:49 |
| kyrofa | bdx, the DESTDIR line needs to be a `make install` | 21:53 |
| bdx | ooho whooops | 21:54 |
| kyrofa | That'll fix things. Although it looks like it uses usr/local. I suggest trying prefix=/ in the configure step to see if things end up in bin | 21:59 |
| bdx | yeah | 22:08 |
| bdx | kyrofa: https://gist.github.com/jamesbeedy/3a8b4de1d3f38be4e551ef028df0ba9c - getting close | 22:16 |
| kyrofa | Looking good! | 22:16 |
| bdx | http://paste.ubuntu.com/24860014/ | 22:17 |
| kyrofa | Is that prime/bin/ ? | 22:17 |
| bdx | yea | 22:17 |
| kyrofa | Nice, now for the challenging part: gems | 22:18 |
| bdx | kyrofa: after I run `sudo snap install --devmode ruby-test_0.1_amd64.snap` | 22:21 |
| bdx | shouldn't my new ruby bin from the snap show up when I run `whereis ruby` | 22:21 |
| kyrofa | bdx, no, you need to declare it as an app if you want to just be able to run ruby out of it | 22:22 |
| kyrofa | It won't work anyway though, as the environment isn't setup for it | 22:22 |
| bdx | kyrofa: I see, ok | 22:22 |
| bdx | kyrofa: I just want to make use of that ruby bin from within a snap | 22:23 |
| bdx | so I don't need to expose it as an app | 22:23 |
| bdx | that is the idea I take it | 22:24 |
| kyrofa | Indeed: the goal of this plugin is not to package RUBY as a snap, but a ruby APPLICATION | 22:25 |
| bdx | I should make another function to call after _ruby_install() in the build step then? | 22:28 |
| bdx | possibly `_gem_install()' and `_bundler_install()`? | 22:29 |
| kyrofa | Exactly what I was thinking | 22:29 |
| kyrofa | Start with gems, just a list | 22:29 |
| bdx | I want bundler installed by default | 22:30 |
| bdx | should I hard code that? | 22:30 |
| kyrofa | You only need bundler if there's a Gamefile, right? | 22:30 |
| bdx | yeah | 22:30 |
| kyrofa | Wow, sorry, getting tired | 22:30 |
| kyrofa | Gemfile | 22:30 |
| bdx | yeah | 22:30 |
| kyrofa | So yes, but bundler will be a little harder than just gems | 22:30 |
| bdx | so check for that first, if exists then use the _gem_install() helper | 22:30 |
| bdx | to install bundler | 22:31 |
| bdx | then call `bundle install` | 22:31 |
| kyrofa | Well, I see two classes of people who might want to use this plugin. Those who have a quick Ruby script and no Gemfile, but knows they need gems, and larger projects that have an established Gemfile | 22:31 |
| kyrofa | I think it'd be pretty easy to support both, don't you think? | 22:31 |
| bdx | yeah | 22:31 |
| kyrofa | So I'd start by adding a new option to the schema called "gems" that accepts a list of gem names, and then use your compiled ruby to install them | 22:32 |
| bdx | ok | 22:32 |
| kyrofa | After we get that working, we can move to bundler | 22:32 |
| kyrofa | You're going to need an env() function, by the way. Make sure you define at least RUBYLIB, GEM_HOME, and GEM_PATH | 22:33 |
| bdx | ok | 22:34 |
| bdx | something along the lines of https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/cmake.py#L84 | 22:35 |
| kyrofa | bdx, no, that's build-time only, you'll want it at runtime as well. Something like this: https://github.com/snapcore/snapcraft/blob/master/snapcraft/plugins/catkin.py#L206 | 22:36 |
| kyrofa | But not as complicated | 22:36 |
| kyrofa | That function is part of the plugin API | 22:37 |
| kyrofa | Just return a list of environment variable definitions | 22:37 |
| kyrofa | bdx, I'm sorry to desert you, but I've got to run for the day. I'll be back tomorrow, though :) | 22:37 |
| bdx | np | 22:38 |
| kyrofa | Good work! | 22:38 |
| bdx | thank you for all your help today | 22:38 |
| kyrofa | Any time | 22:39 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
