| richtera | Does sudo snap install snap-codelabs no longer work or do I have something setup incorrectly. | 02:51 |
|---|---|---|
| === mup_ is now known as mup | ||
| hangun | hi | 04:53 |
| hangun | I am porting snappy to bubblegum96 board, the Soc has a fixed layout that the bootloader.bin ’s offset is at 2097664 and the u-boot is at 3145728.It works when I use https://github.com/uCRDev/Bubblegum96-Snappy/blob/master/gadget/gadget/meta/gadget.yaml and ubuntu-image version 0.10. | 04:53 |
| hangun | Since the ubuntu-image is updated to version 0.12, it may cause the error like this: | 04:54 |
| hangun | sudo /snap/bin/ubuntu-image --channel stable --image-size 2G --extra-snaps bubblegum96-gadget_16.04-1.1_arm64.snap --extra-snaps bubblegum96-kernel_3.10.0_arm64.snap -o bubblegum96.img bubblegum96.model | 04:54 |
| hangun | Fetching core | 04:54 |
| hangun | Copying "bubblegum96-kernel_3.10.0_arm64.snap" (bubblegum96-kernel) | 04:54 |
| hangun | Copying "bubblegum96-gadget_16.04-1.1_arm64.snap" (bubblegum96-gadget) | 04:54 |
| hangun | bubblegum96-gadget already prepared, skipping | 04:54 |
| hangun | bubblegum96-kernel already prepared, skipping | 04:54 |
| hangun | gadget.yaml parse error: mbr structures cannot be larger than 446 bytes. | 04:54 |
| hangun | Use --debug for more information | 04:54 |
| hangun | ubuntu-image had fixed a bug so that causes my issue https://bugs.launchpad.net/ubuntu-image/+bug/1630769 | 04:55 |
| mup | Bug #1630769: part with role='mbr' should be stricter about its parameters <Ubuntu Image:Fix Released by barry> <https://launchpad.net/bugs/1630769> | 04:55 |
| === chihchun_afk is now known as chihchun | ||
| zyga | good morning | 08:29 |
| mup | PR snapd#2602 opened: overlord/snapstate: remove restriction on ResetAliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2602> | 08:47 |
| mup | Issue snapd#2603 opened: Disk free space left check <Created by cyberb> <https://github.com/snapcore/snapd/issue/2603> | 09:04 |
| mup | PR snapd#2604 opened: interfaces: add classic-dimension interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2604> | 09:12 |
| mup | PR snapd#2605 opened: overlord,overlord/snapstate: have UpdateMany retire/enable auto-aliases even without new revision <Created by pedronis> <https://github.com/snapcore/snapd/pull/2605> | 09:16 |
| mup | PR snapd#2498 closed: interfaces: add new upower-control interface <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/2498> | 09:30 |
| mup | Issue snapd#2557 closed: interfaces: connect tun-based serial port <Created by mrsinghgit> <Closed by niemeyer> <https://github.com/snapcore/snapd/issue/2557> | 09:38 |
| mup | Issue snapd#2503 closed: chattr code (tests/main/chattr/task.yaml) fails on ppc64el <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/issue/2503> | 09:52 |
| mup | Issue snapd#2504 closed: interfaces-upower-observe snap test fails on ppc64el <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/issue/2504> | 09:52 |
| mup | Bug #1655592 opened: interfaces-upower-observe snap test fails on ppc64el <Snappy:Triaged> <https://launchpad.net/bugs/1655592> | 09:52 |
| mup | Bug #1655593 opened: chattr code (tests/main/chattr/task.yaml) fails on ppc64el <Snappy:New> <https://launchpad.net/bugs/1655593> | 09:52 |
| mup | Bug #1655594 opened: expect based tests fails on ppc64el <Snappy:New> <https://launchpad.net/bugs/1655594> | 09:52 |
| mup | Issue snapd#2502 closed: expect based tests fails on ppc64el <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/issue/2502> | 09:53 |
| icey | sergiusens: trying to do my classic snap, I added the .desktop file to the snap and suddenly snapcraft hates me again with: 'classic confinement requires the core_dynamic_linker to be set' | 09:54 |
| liuxg | ogra_, ping | 09:56 |
| ogra_ | hey | 09:56 |
| liuxg | ogra_, yesterday, thanks for answering my question regarding the slow build. do you mean to replace all of strings "http://ports.ubuntu.com/ubuntu-ports/ " in the source.list to " http://localhost:9999/ubuntu-ports"? | 09:57 |
| liuxg | ogra_, currently the sources.list file is like http://paste.ubuntu.com/23780838/ | 09:58 |
| ogra_ | liuxg, yep ... then you need to use apt update once to initialize the proxy db ... | 09:58 |
| ogra_ | hmm | 09:59 |
| * zyga feels spring in the air :) | 09:59 | |
| liuxg | ogra_, how to initialize the proxy db? once it is installed, it is initialized? | 09:59 |
| ogra_ | that sources.list misses all basic entries | 09:59 |
| ogra_ | no, it is initialized with the first apt-get update | 10:00 |
| ogra_ | (just means it downloads the index files once from the archive) | 10:00 |
| mup | Bug #1639284 changed: Cant start any snap application on Xenial <snapd:Incomplete by zyga> <https://launchpad.net/bugs/1639284> | 10:01 |
| liuxg | ogra_, ok.. thanks. this is the default sources.list file in my pi device. http://paste.ubuntu.com/23780856/ do you mean I need to add more stuff there? | 10:02 |
| Odd_Bloke | I'm trying to remove the ubuntu-core snap (so I can install the core snap), and I can't work out how to do so. `sudo snap remove ubuntu-core` gives "error: cannot remove "ubuntu-core": snap "ubuntu-core" is not removable". | 10:03 |
| ogra_ | liuxg, no, that one looks fine .,.. your first one was missing the top part | 10:03 |
| Odd_Bloke | https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1589210 suggests that running snap disable first allows removal, but that also doesn't work. | 10:03 |
| mup | Bug #1589210: snap remove failed ubuntu-core snap package <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1589210> | 10:03 |
| liuxg | ogra_, I think your solution is very useful since a lot of developers could not compile their target due to the slaggish network on-site. | 10:03 |
| stub | Odd_Bloke: Just doing that myself. I think you are stuck 'apt purge snapd', trashing all your snaps and their data, then 'apt install snapd' | 10:03 |
| liuxg | ogra_, yeah, I just cut some of part of it, it is my fault. thanks for clarification. | 10:04 |
| icey | why is snapcraft.io not served with SSL? | 10:06 |
| stokachu | sergiusens, this python encodings error makes me sad | 10:06 |
| Odd_Bloke | stub: Aha, fair enough; I knew I'd have to trash all snaps, didn't realise snapd itself had to go. Thanks! | 10:07 |
| sergiusens | stokachu we can skip lunch and fix it :-) Have you tried removing the stage/prime entries in your parts? | 10:08 |
| icey | sergiusens: see my ping above? | 10:08 |
| icey | also, can classic snaps access the system clipboard? | 10:08 |
| stokachu | sergiusens, yea i cleared those out | 10:09 |
| sergiusens | icey nope, just logged on to irc after 6 days | 10:09 |
| stokachu | sergiusens, we can look after lunch :) | 10:09 |
| icey | sergiusens: it was 10 minutes ago :-P | 10:09 |
| icey | how about this: sergiusens: trying to do my classic snap, I added the .desktop file to the snap and suddenly snapcraft hates me again with: 'classic confinement requires the core_dynamic_linker to be set' | 10:09 |
| sergiusens | icey you need the core snap installed | 10:09 |
| icey | rather than the ubuntu-core snap, I'm going to have to do that uninstall dance aren't I? | 10:09 |
| sergiusens | icey yeah | 10:10 |
| stub | I just filed https://bugs.launchpad.net/snappy/+bug/1655599 since this is technically a dataloss bug (if people have production data in their snap containment) | 10:10 |
| mup | Bug #1655599: No migration of ubuntu-core to core <Snappy:New> <https://launchpad.net/bugs/1655599> | 10:10 |
| icey | sergiusens: after removing everything, how do I replace ububtu-core with core | 10:11 |
| mup | Bug #1655599 opened: No migration of ubuntu-core to core <Snappy:New> <https://launchpad.net/bugs/1655599> | 10:11 |
| icey | oh really, uninstall snapd!? | 10:11 |
| stub | https://bugs.launchpad.net/snapcraft/+bug/1650946 | 10:11 |
| mup | Bug #1650946: unhelpful error when building a classic snap: classic confinement requires the core_dynamic_linker to be set <Snapcraft:Fix Committed by sergiusens> <https://launchpad.net/bugs/1650946> | 10:12 |
| liuxg | ogra_, one more question, do I need to change the sources.list in the ubuntu core snap or in the classic snap? sorry | 10:14 |
| ogra_ | in classic, i dont think it is even writable in the core side | 10:15 |
| icey | sergiusens: :-/ '[Errno 2] No such file or directory: '/mnt/Media/projects/alacritty/parts/desktop/install/meta/gui'' | 10:15 |
| liuxg | ogra_, ok. I got it.. yeah, that is currently what I am doing now :) | 10:15 |
| sergiusens | icey wait, let me get back to you on this, this is not how setup/gui works | 10:16 |
| liuxg | ogra_, this is currently how sources.list looks like in my classic snap http://paste.ubuntu.com/23780885/ | 10:17 |
| icey | sergiusens: sure, I'll grab you in a bit, copying the original source on it :) | 10:17 |
| ogra_ | that shoudl work fine | 10:17 |
| liuxg | ogra_, thanks. I am now trying to apt-get, it is still slow. the first time apt update is slow, right? after that, it should be fine. | 10:18 |
| stokachu | how do you clean a specific part again? | 10:19 |
| stokachu | thought it was snapcraft clean pull | 10:19 |
| ogra_ | liuxg, yeah, it only pays off the second time you access a package indeed | 10:19 |
| ogra_ | liuxg, but from then on it will only download packages that are newer in the archive | 10:19 |
| icey | stokachu: `snapcraft clean {STAGE}` just worked for me | 10:19 |
| stokachu | ah stage | 10:20 |
| stokachu | icey, thanks | 10:20 |
| liuxg | ogra_, this is awesome. You saved the world:) | 10:21 |
| ogra_ | :) | 10:21 |
| ogra_ | liuxg, under http://localhost:9999/ you can also see some very basic statistics | 10:22 |
| ogra_ | (or rather http://<ip-address>:9999/ since you need a browser fro this indeed) | 10:23 |
| liuxg | ogra_, this is what I am building now http://imgur.com/a/6UqDY, is it downloading some new packages? I have already done the apt-get update. | 10:25 |
| ogra_ | liuxg, it will have to download the index files every time to compare if something was updated | 10:27 |
| ogra_ | also, if it is your first build it indeed has to download the packages once, like i said above | 10:27 |
| liuxg | ogra_, ok. thanks. I will check it. yeah, the first time build seems to be slow anyway. now, it says 30 mins | 10:28 |
| ogra_ | it needs to pull all debs into the proxy once indeed ... | 10:29 |
| liuxg | ogra_, still, I think this is cool. for hackathon event, it is very needed. sometimes a single line change takes the build for 20 mins, basically, it makes the event useless. | 10:33 |
| ogra_ | well, on a hackathin i'D set up a dedicated machine and have everyone else point to it | 10:34 |
| ogra_ | *hackathon | 10:34 |
| ogra_ | and if you knwo what you are building you can do one build in advance and fill the proxy cache ahead of time | 10:34 |
| liuxg | ogra_, but for developers, they may not know what are needed. Last time, I saw a developer using nodejs, the package took years to get downloaded. | 10:35 |
| ogra_ | yeah | 10:36 |
| liuxg | ogra_, do you know how to set up a machine like what you said so that everyone can point to the machine? | 10:38 |
| ogra_ | you just do the same you just did above ;) and have people use the ip instead of localhost | 10:38 |
| liuxg | ogra_, oh, you mean a Pi device? so everyone changes the sources.list to point to the same pi device? | 10:40 |
| ogra_ | or a laptop | 10:40 |
| liuxg | ogra_, but a laptop is x86, right? most people work on arm. | 10:40 |
| ogra_ | whatever you have around ... the point is to use one central machine instead of everyone having his own proxy | 10:41 |
| liuxg | ogra_, I got it. May I will have a try | 10:41 |
| ogra_ | the underlying arch doesnt matter ... packageproxy works on all arches ;) | 10:41 |
| ogra_ | and for all arches ... i.e. for x86 packages you would simply point to http://localhost:9999/ubuntu ... instead of /ubuntu-ports | 10:42 |
| liuxg | ogra_, how does a x86 provides the debian packages for the arm architecture. | 10:44 |
| ogra_ | you are aware that the ubuntu archive is just a webserver ? | 10:44 |
| liuxg | ogra_, yeah | 10:44 |
| ogra_ | the packageproxy just copies the content ... doesnt matter what arch | 10:45 |
| liuxg | ogra_, ok. I got it. so it archives all of the debian packages whenever it is used to download from the archieve | 10:45 |
| ogra_ | for the main archive it serves them under /ubuntu ... for poirts.ubuntu.com it serves them under /ubuntu-ports | 10:46 |
| liuxg | ogra_, so the proxy snap should be installed on the laptop machine, right? | 10:46 |
| ogra_ | yep | 10:46 |
| ogra_ | or on a central rpi if you have one spare ... or on a PC at home if you have proper bandwith to serve the archive from there ... | 10:47 |
| ogra_ | (or in the office if you have an external IP for the machine) | 10:47 |
| ogra_ | wherever you like ;) | 10:48 |
| === chihchun is now known as chihchun_afk | ||
| liuxg | ogra_, thanks. I got what you mean. this is truly useful for events. I had headaches to let developers develop onsite.. most of the time, they go home to finish the work. | 10:48 |
| mup | PR snapd#2606 opened: overlord/snapstate: share code between Update and UpdateMany, so that it deals with auto-aliases correctly <Created by pedronis> <https://github.com/snapcore/snapd/pull/2606> | 10:49 |
| foxrider83 | hello all | 10:56 |
| rvr | ogra_: I'm building an image with edge, and I get snap 2.20.1, is that equivalent to 2.21? | 10:56 |
| ogra_ | obviously not | 10:56 |
| ogra_ | 2.20.1ubuntu1 is the latest release | 10:57 |
| rvr | ogra_: I see | 10:57 |
| rvr | ogra_: So when 2.21 is available, will it be in both edge and candidate channels? | 10:59 |
| ogra_ | yep | 10:59 |
| ogra_ | well, edge first, but it will move to candidate eventually indeed | 11:00 |
| rvr | Ok | 11:01 |
| mup | PR snapd#2607 opened: many: move interface test helpers to ifacetest package <Created by zyga> <https://github.com/snapcore/snapd/pull/2607> | 11:06 |
| zyga | ogasawara: hey, do you remember the conversation about putting kernel snap projects on github.com/snapcore/snapd similar to how the gadget snaps are there now? | 11:12 |
| zyga | ogasawara: did you have a chance to discuss that in the kernel team? | 11:12 |
| ogasawara | zyga: yep, did you not see the email I sent you about it? | 11:14 |
| * ogasawara will resend | 11:14 | |
| ogasawara | zyga: sent | 11:16 |
| mup | PR snapd#2608 opened: don't install govendor each time <Created by zyga> <https://github.com/snapcore/snapd/pull/2608> | 11:16 |
| zyga | ogasawara: thanks, I got it now | 11:17 |
| mup | PR snapd#2555 closed: many: implement 'snap aliases' <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2555> | 11:38 |
| === didrocks1 is now known as didrocks | ||
| liuxg | ogra_, when I build my project for the second time, I get the error like http://paste.ubuntu.com/23781469/, what could be the reason for it? thanks | 12:11 |
| popey | sergiusens: elopio the "build dir is empty" bug.. I'm seeing similar with nodejs plugin, not just rust. Plausibly same bug or new one? | 12:12 |
| ogra_ | hmm | 12:12 |
| ogra_ | liuxg, can you ping localhost ? | 12:13 |
| liuxg | ogra_, yes http://paste.ubuntu.com/23781476/ | 12:14 |
| ogra_ | weird, works fine here | 12:16 |
| liuxg | ogra_, inside classic http://paste.ubuntu.com/23781481/ | 12:16 |
| ogra_ | and if you just call apt update in classic ? | 12:17 |
| ogra_ | does it update ? | 12:17 |
| mup | PR snapd#2608 closed: don't install govendor each time <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2608> | 12:17 |
| ogra_ | or install a random package | 12:18 |
| liuxg | ogra_, the snap is there | 12:18 |
| ogra_ | that wasnt my question | 12:18 |
| ogra_ | does apt update inside the classic env work | 12:18 |
| ogra_ | or can you apt install some random package | 12:18 |
| liuxg | ogra_, it is like http://paste.ubuntu.com/23781493/ | 12:19 |
| ogra_ | looks like the proxy isnt running ... could it be that you ran out of diskspace or some such ? | 12:19 |
| liuxg | ogra_, http://paste.ubuntu.com/23781496/ | 12:19 |
| liuxg | ogra_, http://paste.ubuntu.com/23781501/, I have a 16G disk | 12:20 |
| ogra_ | systemctl status snap.packageproxy.approx.service | 12:22 |
| ogra_ | ? | 12:22 |
| ogra_ | (outside of classic obviously) | 12:22 |
| liuxg | ogra_, http://paste.ubuntu.com/23781511/, it is running. I just disable and enable it again. | 12:24 |
| ogra_ | well, i have never seen it not work and i use it since about two years on various machines ... pretty weird | 12:25 |
| liuxg | ogra_, http://paste.ubuntu.com/23781527/ | 12:26 |
| ogra_ | anything in syslog about why it fails ? | 12:27 |
| ogra_ | (thats an extremely dumb app, it can not fail, this is super strange) | 12:27 |
| mup | PR snapd#2609 opened: store: request no CDN via a header using SNAPPY_STORE_NO_CDN envvar <Created by pedronis> <https://github.com/snapcore/snapd/pull/2609> | 12:27 |
| ogra_ | is 9999 taken by anything else ? | 12:30 |
| liuxg | ogra_, no, I do not think it is taken. no other software uses the port | 12:31 |
| ogra_ | do you perhaps have a stale lockfile in /var/snap/packageproxy/3/lockfile.lock ? | 12:33 |
| liuxg | ogra_, I am now doing it again. | 12:34 |
| ogra_ | doing what again ? | 12:34 |
| liuxg | ogra_, http://paste.ubuntu.com/23781554/ | 12:35 |
| liuxg | ogra_, you are right. | 12:35 |
| ogra_ | remove it | 12:35 |
| ogra_ | thought this is extremely odd ... it is really a very dumb script, i havent seen it fail in years | 12:35 |
| ogra_ | the only thing i could imagine is that you either run out of diskspace (which you dont) or ram to make it fall over | 12:36 |
| liuxg | ogra_, how could that happen? I must win the first prize :) | 12:36 |
| liuxg | ogra_, now, it seems to be right. it starts to snap ... | 12:37 |
| liuxg | ogra_, thanks.. this time, the build is really fast :) | 12:40 |
| liuxg | ogra_, we should let the rest of the developers know this trick! | 12:40 |
| ogra_ | are you building something that could use a lot of ram during the build process? | 12:41 |
| liuxg | ogra_, I do not think so. it is just dump plugin and compile some c files. | 12:42 |
| ogra_ | liuxg, well, if you see anything like the above again, please let me know | 12:42 |
| liuxg | ogra_, by the way, if someday I do not want to have the cached files, how can I remove them? | 12:42 |
| liuxg | ogra_, sure, I will observe it. | 12:42 |
| ogra_ | either snap remove packageproxy ... or just rm -rf /var/snap/packageproxy/3/var/cache/approx/* | 12:43 |
| liuxg | ogra_, alright. many thanks | 12:43 |
| ogra_ | if you want to toggle it dynamically, just use a default sources.list and copy them back and forth as you need | 12:43 |
| liuxg | ogra_, yeah, that makes sense. In fact, i did not keep the old one :) I will find it back. | 12:45 |
| ogra_ | it is in the core env ... if you exit classic | 12:45 |
| ogra_ | remember ? it is readonly there | 12:45 |
| didrocks | ogra_: is there any kind of autoclean of the cache? | 12:46 |
| liuxg | ogra_, yeah, it is the same. | 12:46 |
| ogra_ | ogra@pi3:~$ cp /etc/apt/sources.list . | 12:46 |
| ogra_ | ogra@pi3:~$ sudo classic | 12:46 |
| ogra_ | (classic)ogra@pi3:~$ sudo cp sources.list /etc/apt/ | 12:46 |
| ogra_ | and you are back on the default sources.list ;) | 12:46 |
| ogra_ | didrocks, there is /var/snap/packageproxy/3/config.yaml ... you can adjust such stuff if needed | 12:48 |
| didrocks | nice! | 12:48 |
| liuxg | ogra_, right. I got it. thanks | 12:48 |
| ogra_ | didrocks, i didnt port all config options yet but largely http://manpages.ubuntu.com/manpages/xenial/man5/approx.conf.5.html applies | 12:49 |
| didrocks | ogra_: good work! thanks for the reference :) | 12:51 |
| ogra_ | old stuff ... i need to update it again so that snap set and get work ;) | 12:51 |
| ogra_ | i created it in 15.04 snappy originally ... :) | 12:52 |
| ogra_ | adjusted it for newer changes) | 12:52 |
| ogra_ | *(only adjusted it... | 12:52 |
| mup | PR snapd#2607 closed: many: move interface test helpers to ifacetest package <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2607> | 12:52 |
| mup | PR snapd#2601 closed: overlord, store: move confinement filtering to the overlord (from The Store) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2601> | 13:13 |
| rvr | fgimenez: ping | 13:17 |
| rvr | fgimenez: Hey. Do you have a doc/spec or any good description about re-exec? It's planned for 2.21, want to be prepared to check it. | 13:18 |
| mvo | rvr: give me some minutes and I send you something | 13:23 |
| rvr | mvo: Thanks | 13:23 |
| fgimenez | hey rvr, nope sorry, none that i know, thx mvo! | 13:24 |
| === hikiko is now known as hikiko|ln | ||
| mup | PR snapd#2610 opened: interfaces/browser-support: add @{PROC}/@{pid}/fd/[0-9] w and misc /run/udev <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2610> | 13:29 |
| mup | PR snapd#2599 closed: interfaces: add new-style interfaces <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2599> | 13:46 |
| === ben_r_ is now known as ben_r | ||
| mup | PR snapd#2602 closed: overlord/snapstate: remove restrictions on ResetAliases <Created by pedronis> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2602> | 14:09 |
| === hikiko|ln is now known as hikiko | ||
| === andyrock_ is now known as andyrock | ||
| mup | PR snapd#2611 opened: interfaces: use fewer dot imports <Created by zyga> <https://github.com/snapcore/snapd/pull/2611> | 14:16 |
| === ben_r_ is now known as ben_r | ||
| elopio | popey: can you share your nodejs snapcraft.yaml ? | 14:42 |
| elopio | I've been playing a lot with nodejs and haven't seen anything like the error on the rust one. | 14:42 |
| popey | elopio: it's super basic. http://paste.ubuntu.com/23782053/ - output http://paste.ubuntu.com/23782054/ | 14:47 |
| === ben_r_ is now known as ben_r | ||
| elopio | popey: agh, seems like exactly the same rust issue :( Can you please report a bug? I'll fix it for tomorrow's release. | 14:53 |
| ryebot | is the snap store accepting classic confinement snaps, yet? | 15:01 |
| zyga | ryebot: I believe it should but I heard that people had some issues | 15:02 |
| ryebot | zyga: ack, thanks | 15:02 |
| popey | elopio: ok | 15:02 |
| mup | PR snapd#2612 opened: cmd/snap, daemon, overlord/snapstate: tests and fixes for "snap refresh" of a classic snap <Created by chipaca> <https://github.com/snapcore/snapd/pull/2612> | 15:04 |
| popey | elopio: https://bugs.launchpad.net/snapcraft/+bug/1655678 | 15:15 |
| mup | Bug #1655678: nodejs plugin fails to build - empty build dir <Snapcraft:New> <https://launchpad.net/bugs/1655678> | 15:15 |
| elopio | thank you. | 15:16 |
| mup | PR snapd#2611 closed: interfaces: use fewer dot imports <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2611> | 15:22 |
| mup | PR snapd#2613 opened: interfaces: add new interface API <Created by zyga> <https://github.com/snapcore/snapd/pull/2613> | 15:23 |
| zyga | jdstrand: ^^ | 15:27 |
| zyga | jdstrand: take two on the idea | 15:27 |
| zyga | jdstrand: hey | 15:47 |
| zyga | jdstrand: debugging those i386 seccomp failures on xenial (for the old tests) | 15:49 |
| zyga | jdstrand: I get killed by lack of 201, looking at libseccomp source code that is geteuid32 | 15:49 |
| zyga | jdstrand: what was that tool that resolves syscalls to numbers? | 15:49 |
| zyga | jdstrand: I'm asking because this cannot be right, we allow that specific syscall in the common.sh profile | 15:50 |
| zyga | ah | 15:50 |
| zyga | found it | 15:50 |
| zyga | sorry :) | 15:50 |
| morphis | kyrofa, sergiusens: somehow the dependency handling for my snap is really different when using snapcraft to build and switching between classic and devmode confinement | 15:52 |
| morphis | kyrofa, sergiusens: my app depends on libboost which I pull in a build-depends via libboost-system-dev for example but with classic confinement libboost-system doesn't end up in prime | 15:53 |
| morphis | with devmode or strict it does | 15:53 |
| morphis | is there some fundamental difference other than that confinement is disabled with classic? | 15:53 |
| kyrofa | morphis, hmm... there is a difference, but I wouldn't expect it to cause that | 15:58 |
| kyrofa | morphis, it uses the linker of the core snap and uses rpaths to the libs within, but that shouldn't stop boost from getting in | 15:59 |
| morphis | kyrofa: so classic snaps are still running against the core snap or not? | 15:59 |
| zyga | and fixed it :) | 16:00 |
| kyrofa | morphis, you're on the verge of my knowledge here, but zyga will know more | 16:00 |
| morphis | zyga: any ideas? | 16:01 |
| kyrofa | I suspect that since snapcraft uses the rpaths, all those bind mounts don't happen | 16:01 |
| kyrofa | So while the core snap is not its execution context, it still runs reliably | 16:01 |
| kyrofa | But I'm making stuff up | 16:01 |
| morphis | kyrofa: possible, lets see what zyga says | 16:03 |
| zyga | morphis: classic and devmode are not just confinement, the snap is built entirely differently | 16:03 |
| zyga | morphis: all the code in your snap needs to be built from source | 16:04 |
| zyga | morphis: and it is built against what is in the core snap | 16:04 |
| morphis | zyga: means if I use boost, I have to build boost on my own? | 16:04 |
| zyga | morphis: all the executables are linked with stuff from /snap/core/current | 16:04 |
| zyga | morphis: yes | 16:04 |
| morphis | so I can't reuse any deb packages? | 16:04 |
| zyga | morphis: the dynamic linker is also used from the core snap | 16:04 |
| zyga | morphis: not that I know of | 16:05 |
| morphis | so if I have a app which depends on mesa, sdl, boost, protobuf, sdl, alsa, ... I have to build all of them manually? | 16:05 |
| zyga | yes | 16:05 |
| morphis | wow | 16:05 |
| morphis | that makes it a knockout thing | 16:06 |
| zyga | I don't think anyone tried it against gui apps | 16:06 |
| zyga | since core doesn't contain anything GUI-ish it is a difficult task I think | 16:06 |
| morphis | so what is the reason for this? | 16:06 |
| zyga | what is the reason for what? | 16:06 |
| zyga | that they need to be built? | 16:07 |
| zyga | because they are linked against the core snap | 16:07 |
| morphis | zyga: when I don't use classic confinement I use the linker from the core snap too, correct? | 16:07 |
| zyga | morphis: no | 16:08 |
| zyga | morphis: not directly | 16:08 |
| zyga | morphis: it depends on where you run | 16:08 |
| morphis | true | 16:08 |
| morphis | so on Ubuntu Core I do but on desktop I don't | 16:08 |
| zyga | morphis: if you want to understand the details I can discuss this with you but believe me when I say this is the only way it can work | 16:08 |
| zyga | morphis: you have to build it | 16:08 |
| morphis | zyga: I believe you, just trying to understand | 16:08 |
| zyga | morphis: ok | 16:08 |
| zyga | morphis: build this and ldd it | 16:08 |
| zyga | https://git.launchpad.net/checkbox-converged/tree/build-me | 16:09 |
| zyga | hmm | 16:09 |
| zyga | wrong link | 16:09 |
| zyga | https://github.com/zyga/hello-classic | 16:09 |
| zyga | morphis: ^^ | 16:09 |
| zyga | morphis: ldd this and look at what the elf file contains | 16:09 |
| zyga | morphis: this is the only way to make it work without controling the mount namespace | 16:10 |
| morphis | hm | 16:10 |
| morphis | I see | 16:10 |
| zyga | morphis: yeah, I bet it is going to be tough; I would love to see better support in snapcraft where one can lessen the cost of those builds | 16:11 |
| zyga | morphis: smarter caching | 16:11 |
| zyga | morphis: distcc/ccache | 16:11 |
| zyga | morphis: and working complex examples | 16:11 |
| morphis | zyga: its quite of useless if you have to rebuild everything and add it to your snapcraft.yaml | 16:11 |
| morphis | which makes it kind of complex for not tiny applications | 16:11 |
| zyga | morphis: well, not useless | 16:12 |
| zyga | morphis: just time consuming | 16:12 |
| zyga | morphis: sergio built a lot of nice things (git, vim) this way | 16:12 |
| zyga | morphis: and this is not a design choice, just technical challenge | 16:12 |
| zyga | morphis: this is a hard problem | 16:12 |
| zyga | morphis: you can cheat | 16:13 |
| morphis | yeah it is | 16:13 |
| zyga | morphis: you can build it to look for big libraries in /usr/lib | 16:13 |
| zyga | morphis: but that's not guaranteed to work | 16:13 |
| zyga | morphis: only /snap/core is guaranteed | 16:13 |
| zyga | morphis: btw, I could use a review on the new interface API if you have some time | 16:20 |
| morphis | zyga: sure! | 16:20 |
| morphis | zyga: but not today | 16:20 |
| mup | PR snapd#2587 closed: interfaces/mount: add snippet types <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2587> | 16:33 |
| elopio | popey: could you try with snapcraft from master? | 16:34 |
| popey | elopio: uhm, where's that? | 16:45 |
| elopio | popey: git clone https://github.com/snapcore/snapcraft | 16:46 |
| elopio | and then instead of running just snapcraft, use the full to the bin/snapcraft that you cloned from that repo. | 16:47 |
| popey | ok | 16:48 |
| popey | elopio: ok, fails differently now :) | 16:50 |
| elopio | popey: let me see... | 16:51 |
| popey | elopio: http://paste.ubuntu.com/23782441/ | 16:52 |
| mup | PR snapd#2573 closed: snap: add information about tracking channel (not just actual channel) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2573> | 16:52 |
| stokachu | trying to get around a apparmor issue: http://paste.ubuntu.com/23782447/ | 16:53 |
| stokachu | wanting to systemctl start my custom bridge | 16:53 |
| elopio | popey: ok, I think you should use cleanbuild, because it might be having a conflict with your local npm stuff. | 16:53 |
| popey | ah | 16:54 |
| stokachu | heres my snapcraft http://paste.ubuntu.com/23782451/ | 16:54 |
| popey | elopio: trying.. | 16:54 |
| roadmr | jdstrand: hello! so the store is updated to tools r817 finally \o/ (also heads up - the controls for plugs/slots, classic and others have moved to the snap level (rather than upload level). Let me know if you have any trouble finding them now | 16:55 |
| popey | elopio: fails in the old way in cleanbuild... http://paste.ubuntu.com/23782468/ | 16:56 |
| stokachu | also ubuntu-core doesn't seem to have the firewall-control anymore | 16:56 |
| stokachu | nm was called core | 16:56 |
| elopio | oh, right, cleanbuild installs the released one. | 16:57 |
| elopio | so, hum, I don't think there's a way for you to test it. | 16:57 |
| popey | i can just make a deb | 16:57 |
| elopio | instead of a snap? :) | 16:58 |
| popey | lulz | 16:58 |
| elopio | popey: no, you can get a lxc container, or a clean vm. Clone snapcraft, and try there. | 16:58 |
| mup | PR snapd#2609 closed: store: request no CDN via a header using SNAPPY_STORE_NO_CDN envvar <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2609> | 16:58 |
| popey | making a deb is quicker | 16:59 |
| elopio | or delete your local npm stuff. | 16:59 |
| popey | hm, might do that too | 16:59 |
| elopio | popey: hum, but you need to install that deb in a clean environment. | 17:00 |
| popey | yeah, just realised that :D | 17:00 |
| elopio | we have a few bugs about using unclean containers for cleanbuild. That would make testing easier, despite the contradiction. | 17:00 |
| elopio | and it might be a bug that npm fails if you have some local stuff. I'm not sure about that, npm is confusing altogether. | 17:01 |
| popey | yeah, nuking my ~/.npm helped | 17:02 |
| mup | Bug #1655711 opened: typo in Ubuntu Core documentation - Ubuntu Core Images <Snappy:New> <https://launchpad.net/bugs/1655711> | 17:05 |
| popey | elopio: built! :D | 17:05 |
| pstolowski | ratliff, hello! I noticed you were looking at my notes re per-snap context implementation; just a heads up, I | 17:06 |
| pstolowski | ratliff, I've added two sentences regarding the use of snap-confine and the behavior on missing context | 17:07 |
| elopio | popey: yay! so the bad news is that I spent a couple of hours trying to fix a bug that was already fixed, wondering why I couldn't reproduce it here. | 17:08 |
| zyga | jdstrand: can you please +1 https://github.com/snapcore/snapd/pull/2433 | 17:10 |
| mup | PR snapd#2433: tests: run all snap-confine tests in c-unit-tests task <Created by zyga> <https://github.com/snapcore/snapd/pull/2433> | 17:10 |
| zyga | jdstrand: it's tiny and I wanted to land it when green | 17:10 |
| zyga | jdstrand: the tests were okay, just common.sh needed more i386 specific syscalls | 17:10 |
| popey | hah, sorry el | 17:11 |
| popey | *elopio | 17:11 |
| elopio | popey: no, thanks a lot for your help. I also found a couple of things that are not nice, and a mistake in my rust PR. | 17:12 |
| popey | sweet! good to hear | 17:12 |
| mup | Issue snapd#2559 closed: seccomp tests fail on Ubuntu 16.04 in when running in qemu or linode <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/issue/2559> | 17:43 |
| mup | PR snapd#2521 closed: interfaces: allow read/write access of real-time clock with time-control interface <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2521> | 18:09 |
| jdstrand | zyga: I'll add it to my list | 18:47 |
| jdstrand | roadmr: thanks! | 18:47 |
| jdstrand | stokachu: I think that may be bug #1655369. if you have time, it would be great if you could comment in the bug and provide more info | 18:49 |
| mup | Bug #1655369: cannot use the platform plug with a snap in 'classic' confinement <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1655369> | 18:49 |
| jdstrand | zyga: the tool that resolves syscalls both ways is scmp_sys_resolver | 18:50 |
| lazyPower | so, i know that snapcraft has a daemon key you can set to have snapcraft generate a systemd unit file. Say i want to deliver a custom systemd unit file + defaults with my daemon, would the proper path forward be to write a wrapper that does the systemd unit install + configuration, and invoke that bash script manually, or is there a tuneable unit file template syntax? | 18:53 |
| lazyPower | Sorry if this has been covered elsewhere, i've been in/out of this conundrum for a few days now and have been split-attention with it, so any pointers are welcome. | 18:53 |
| kyleN | I'd like to include a LOCAL (non-published) gadget snap in a model assertion for use with ubuntu-image. I tried the full gadget snap file name in the model assertion ("gadget": "pi2kyle_16.04-0.17_armhf.snap",) but the ubuntu-image command does not find it. is there a way to do this? | 19:20 |
| kyleN | put another way, is it a requirement that the gadget snap is published to stable for ubuntu-image to find it? | 19:27 |
| mup | PR snapd#2614 opened: interfaces: allow getsockopt by default since it is so commonly used <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2614> | 19:42 |
| mup | PR snapd#2615 opened: make patch4 robust against in-progress install changes <Created by pedronis> <https://github.com/snapcore/snapd/pull/2615> | 19:57 |
| pedronis | kyleN: no, the model assertion just needs the name, you pass the local snap to ubuntu-image with --extra-snaps | 20:00 |
| kyleN | pedronis, thanks. I did not know you could do that with the gadget snap. | 20:03 |
| pedronis | kyleN: the option name is a bit unclear but is both extra or local overrides | 20:04 |
| kyleN | ack | 20:06 |
| mup | PR snapd#2612 closed: cmd/snap, daemon, overlord/snapstate: tests and fixes for "snap refresh" of a classic snap <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2612> | 20:16 |
| mup | PR snapd#2614 closed: interfaces: allow getsockopt by default since it is so commonly used <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2614> | 20:19 |
| stokachu | jdstrand, yea i can provide my snapcraft etc to that bug | 20:31 |
| ryebot | As part of my snapcraft.yaml, I'm pulling a binary from an upstream source and using the dump plugin. Problem is, the binary isn't marked executable. Is there a pattern for dealing with this? | 20:37 |
| ryebot | I tried writing a wrapper that sets the executable bit, but of course the fs is readonly, so. | 20:37 |
| stokachu | jdstrand, updated that bug #1655369 | 20:37 |
| mup | Bug #1655369: cannot use the platform plug with a snap in 'classic' confinement <snapd (Ubuntu):New> <https://launchpad.net/bugs/1655369> | 20:37 |
| Skuggen | ryebot: Newer snapcraft have keywords for parts that let you execute shell statements as part of the build process. Maybe you can use that to set the executable bit during the build? | 20:40 |
| ryebot | Skuggen: excellent, thanks, I'll take a look | 20:41 |
| Skuggen | Can't actually find it in the online docs, but if you run snapcraft help plugins it's mentioned, I think. I've used the prepare: keyword to run a script that stages files to use in the build | 20:43 |
| mup | Bug #1655369 opened: cannot use content interface with a snap in 'classic' confinement <Snappy:Triaged> <https://launchpad.net/bugs/1655369> | 20:48 |
| jdstrand | stokachu: I responded in the bug | 20:51 |
| stokachu | jdstrand, thank you! testing now | 20:51 |
| stokachu | jdstrand, in theory if i do a classic snap can i just include other binaries i need to run my app? | 20:52 |
| stokachu | i realize it isn't confined and im interested in getting updates out quicker than a ppa | 20:52 |
| mup | PR snapd#2424 closed: interfaces/builtin: add physical-memory-* and io-ports-control <Created by tonyespy> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2424> | 20:52 |
| jdstrand | stokachu: you can put whatever you want in your snap | 20:53 |
| stokachu | plus i want to eventually control the versions of juju/lxd that go into it | 20:53 |
| stokachu | at least until there is a sense of snap dependencies i guess | 20:54 |
| jdstrand | stokachu: note that if this is going to be officially supported by Canonical, you'll want to talk to ratliff and tyhicks about best practices and tracking. this is work that is being discussed at the sprint | 20:54 |
| stokachu | jdstrand, ok yea ive spoke to tyhicks today, i wanted to get this at least running so he could see what im trying to accomplish | 20:54 |
| jdstrand | but in terms of what is possible with snapd, you can put anything in your snap | 20:54 |
| stokachu | then iterate from there | 20:54 |
| jdstrand | cool | 20:54 |
| lazyPower | OP: :so, i know that snapcraft has a daemon key you can set to have snapcraft generate a systemd unit file. Say i want to deliver a custom systemd unit file + defaults with my daemon. The generated unit file clearly states at the top its auto-generated, and editing is highly discouraged. How can I provide these extra bits to my daemon? | 20:56 |
| jdstrand | stokachu: also, I'll be adding a check to the review tools to alert when specifying 'confinement: classic' with 'plugs' (in general, there is one possible use case with the content interface) | 20:56 |
| stokachu | jdstrand, ok awesome | 20:56 |
| stokachu | lazyPower, i think you can do like templating in the yaml | 20:56 |
| stokachu | lazyPower, believe i saw it in some of the openstack snaps jamespage was writing | 20:57 |
| lazyPower | stokachu ah good info, thanks for the pointer | 20:58 |
| lazyPower | stokachu - i think this is what i was looking for under config | 21:00 |
| lazyPower | https://github.com/javacruft/snap-openstack-compute-controller/blob/master/snapcraft.yaml | 21:00 |
| mup | Bug #1594919 changed: Require a method to ship udev rules independent of apps and slots <snapd-interface> <Snappy:Won't Fix> <https://launchpad.net/bugs/1594919> | 21:24 |
| mup | PR snapd#2615 closed: make patch4 robust against in-progress install changes <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2615> | 21:26 |
| kyrofa | jdstrand, do the review tools break on _any_ symlinks pointing outside of the snap? | 21:37 |
| jdstrand | kyrofa: no. there are exceptions based on snapcraft and one other for symlinks from the SNAP dir into SNAP_DATA | 21:47 |
| jdstrand | well, /var/snap/SNAP_NAME/... | 21:47 |
| kyrofa | jdstrand, alright, I just noticed that snapcraft leaves dangling symlinks if they're pointing to libs contained in libc | 21:47 |
| kyrofa | I didn't realize that was ever done on purpose | 21:47 |
| jdstrand | kyrofa: yes. that is intentional and the review tools make exceptions for those | 21:48 |
| mup | PR snapd#2610 closed: interfaces/browser-support: add @{PROC}/@{pid}/fd/[0-9] w and misc /run/udev <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2610> | 21:51 |
| kyrofa | jdstrand, can you imagine any downside to snapcraft simply deleting those links and letting the snap use the one directly from core? | 21:52 |
| jdstrand | kyrofa: I don't recall the details, but sergiusens left those on purpose cause things were crashing if they used a different libc than what was on core | 21:53 |
| kyrofa | jdstrand, but the libs they link to (/lib/<arch>/blah) _come_ from core, do they not? | 21:53 |
| kyrofa | Ever since snap-confine reversed the mounts I've not been able to keep track of what's mounted where :P | 21:55 |
| jdstrand | kyrofa: I'm not sure they are guaranteed to. Like I said, I sergiusens did this very specifically. probably best to ask him cause the details are foggy for me | 21:56 |
| kyrofa | jdstrand, alright will do, thanks :) | 21:56 |
| jdstrand | sure thing | 21:56 |
| stokachu | is there a way in --classic to run the systemctl command to start a service i need within my snap? | 22:06 |
| stokachu | automatically after snap install | 22:06 |
| stokachu | similar to the postinst in a deb package | 22:06 |
| kyrofa | You might be able to do that in the configure hook | 22:07 |
| seshu | kyrofa: Do you have any references to configure hook? documentation or example? | 22:08 |
| kyrofa | seshu, https://github.com/snapcore/snapd/wiki/hooks | 22:10 |
| seshu | kyrofa: Thanks much! | 22:10 |
| stokachu | where would i put this in snapcraft? | 22:12 |
| kyrofa | stokachu, https://github.com/snapcore/snapcraft/blob/master/docs/hooks.md but note that what's documented there has not yet been released | 22:14 |
| kyrofa | You can run out of master if you need it | 22:14 |
| stokachu | cool thanks, yea i run master | 22:15 |
| seshu | kyrofa: I don't see snap get <snapname> <key> example. Is it still under development? | 22:19 |
| kyrofa | seshu, `snap get` should work | 22:21 |
| kyrofa | Does it not? | 22:21 |
| seshu | kyrofa: it works, kind of... | 22:23 |
| kyrofa | seshu, what's wrong? | 22:23 |
| snappy_irc | We are trying to build kernel snap from a binary .deb, it's not working, want to know if it is supported. We get the following error after executing '$ snapcraft' | 22:23 |
| seshu | kyrofa: two things. 1. I'm trying to see how I can implement get and set for my snap | 22:23 |
| snappy_irc | $ snapcraft | 22:23 |
| snappy_irc | "confinement" property not specified: defaulting to "strict" | 22:23 |
| snappy_irc | "grade" property not specified: defaulting to "stable" | 22:23 |
| snappy_irc | Use of build-properties in the schema is deprecated. | 22:23 |
| snappy_irc | Plugins should now implement get_build_properties | 22:23 |
| snappy_irc | Skipping pull kernel (already ran) | 22:23 |
| snappy_irc | Preparing to build kernel | 22:23 |
| snappy_irc | Building kernel | 22:23 |
| snappy_irc | make -j1 defconfig | 22:23 |
| snappy_irc | make: *** No rule to make target 'defconfig'. Stop. | 22:23 |
| snappy_irc | Command '['/bin/sh', '/tmp/tmp_gqzcokn', 'make', '-j1', 'defconfig']' returned non-zero exit status 2 | 22:23 |
| kyrofa | snappy_irc, please utilize http://pastebin.ubuntu.com/ | 22:24 |
| seshu | kyrofa: 2. Trying to get key:value pairs network-manager supports...apparently, without knowing key there is no way to use snap get command | 22:24 |
| kyrofa | seshu, you don't have to do anything special to support `snap get/set` | 22:26 |
| kyrofa | seshu, as for trying to obtain all keys, or defining a schema, indeed that functionality doesn't exist today | 22:27 |
| seshu | kyrofa: got it. Thanks for clarification. | 22:27 |
| kyrofa | seshu, `snap set` will result in your configure hook being called (if you wrote one), where you can handle the configuration change. `snap get` doesn't use your hook at all, it just returns whatever was previously set (either by snap set or by snapctl set, in your hook) | 22:28 |
| seshu | kyrofa: ah! okay! | 22:29 |
| stokachu | someone mind looking at https://github.com/conjure-up/conjure-up/blob/snapcraft-updates/snapcraft.yaml and why my conjure-up.sh script isn't replacing the conjure-up command? | 22:29 |
| nacc | stokachu: is conjure-up.sh correctly placed in the snap's squashfs? | 22:32 |
| stokachu | nacc, do i use like snapcraft try to see that? | 22:33 |
| nacc | stokachu: i tend to use `unsquashfs -l /path/to/whatever.snap` | 22:33 |
| stokachu | ah nice | 22:33 |
| nacc | stokachu: there might be a more 'official' snapcraft way , though :) | 22:33 |
| stokachu | here's the output squashfs-root/bin/conjure-up.sh | 22:34 |
| stokachu | err | 22:34 |
| stokachu | http://paste.ubuntu.com/23783977/ | 22:34 |
| stokachu | looks like both are there | 22:35 |
| nacc | stokachu: the other thing to look at, might be to see if you can add a shell app (I don't know if that has been added as default boilerplate or not), so you can drop to a shell in the snap and see what's where | 22:35 |
| nacc | stokachu: and in this case, I guess, what is pointing to where :) | 22:35 |
| stokachu | ah ok, ill add bash toit and see | 22:35 |
| nacc | stokachu: ah there is 'snap run --shell <app>` | 22:36 |
| nacc | stokachu: that *might* be all you need | 22:36 |
| stokachu | lemme try that | 22:36 |
| nacc | stokachu: sorry for the vagueness, i'm not a snapping expert by any means :) | 22:41 |
| stokachu | all good, the tips help :) | 22:42 |
| stokachu | bah need to sleep, sergiusens im needing some help tomorrow :) | 22:48 |
| mup | PR snapcraft#1035 closed: rust plugin: use the part source path <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1035> | 22:53 |
| kyrofa | stokachu, what do you mean "replacing" ? | 22:54 |
| kyrofa | nacc, note that whatever is in `prime` will end up in the snap, so it's easier to just look in there | 22:55 |
| stokachu | kyrofa, so i have a conjure-up.sh file and i want that to be used instead | 22:55 |
| kyrofa | stokachu, instead of what? | 22:55 |
| stokachu | instead of the conjure-up script that gets created from the python setuptools | 22:56 |
| stokachu | i need to pass in some custom snap paths | 22:56 |
| kyrofa | stokachu, ah, is the one from python the bin/conjure-up (no .sh) ? | 22:56 |
| stokachu | yea | 22:57 |
| kyrofa | stokachu, it's not replacing it because it's named `conjure-up.sh` | 22:57 |
| kyrofa | What are you expecting exactly? | 22:57 |
| kyrofa | stokachu, do you want to exclude bin/conjure-up completely? | 22:58 |
| stokachu | so i want conjure-up.sh to be called from the cli as 'conjure-up' but that script is just a wrapper around the real 'conjure-up' with some additional options | 22:58 |
| kyrofa | Ah, then you should be fine on all counts | 22:58 |
| kyrofa | You don't want bin/conjure-up replaced | 22:58 |
| kyrofa | You just want it callable via `conjure-up`, which is should be thanks to your app | 22:58 |
| stokachu | ah ok | 22:59 |
| kyrofa | stokachu, if bin/conjure-up.sh replaced bin/conjure-up... you wouldn't be wrapping anything! | 22:59 |
| stokachu | so the error i get is fatal: could not create work tree dir '/snap/conjure-up/x8/spells': Read-only file system | 22:59 |
| kyrofa | stokachu, might I recommend a better naming convention though | 22:59 |
| stokachu | should i not be using $SNAP/spells | 22:59 |
| stokachu | kyrofa, yea ill take all the help i can get | 23:00 |
| kyrofa | stokachu, just name the wrapper something more obvious, like conjure-up-wrapper.sh, or run-conjure-up.sh, etc | 23:00 |
| kyrofa | (note that you don't even need the .sh if you don't want it) | 23:00 |
| stokachu | ah ok | 23:00 |
| kyrofa | stokachu, is that error at runtime, then? | 23:00 |
| stokachu | kyrofa, yea | 23:01 |
| kyrofa | Yeah, $SNAP is the squashfs image, which is always read-only | 23:01 |
| kyrofa | You'll want to use one of the writable areas | 23:01 |
| stokachu | SNAP_USER_DATA persists through upgrades, is that the best place to put it? | 23:01 |
| stokachu | or i think it used too | 23:02 |
| kyrofa | stokachu, all writable areas persist through upgrades, but do so slightly differently | 23:02 |
| kyrofa | stokachu, see https://askubuntu.com/questions/762354/where-can-ubuntu-snaps-write-data for more information | 23:02 |
| stokachu | thanks will take a look | 23:02 |
| stokachu | kyrofa, \o/ yay that worked | 23:06 |
| stokachu | now i can just bug sergiusens about the hooks tomorrow :D | 23:06 |
| stokachu | kyrofa, thanks again | 23:06 |
| kyrofa | stokachu, sure thing. Note that sergiusens is sprinting this week and likely won't be very responsive | 23:07 |
| stokachu | kyrofa, yea im at the same sprint :D | 23:07 |
| kyrofa | Ah :) | 23:07 |
| stokachu | i tend to stalk him, he's popular at these things | 23:08 |
| kyrofa | stokachu, yeah he's a popular dude. I can help you with the hooks if you need some pointers | 23:09 |
| stokachu | ok cool, i read the snapcraft hook doc it wants me to place the hooks in a snap dir, should i just put everything inside there? | 23:10 |
| stokachu | ive been keeping it all in snapcraft dir | 23:10 |
| kyrofa | stokachu, "everything" meaning what, exactly? | 23:11 |
| stokachu | oh i see the demo | 23:11 |
| stokachu | i create a part for the hook and then manually copy over a script I need to run after an install into $SNAPCRAFT_PART_INSTALL/snap/hooks? | 23:11 |
| stokachu | i guess $SNAPCRAFT_PART_INSTALL/snap/hooks/<trigger> | 23:12 |
| kyrofa | stokachu, that's the second of the two supported methods | 23:12 |
| kyrofa | stokachu, if your hook is coming from a part, you do it that way. If instead your hook is maintained in the repo along with the snapcraft.yaml, you can put it in the snap directory | 23:13 |
| kyrofa | (like the other demo) | 23:13 |
| stokachu | ah | 23:13 |
| stokachu | kyrofa, is configure the write hook to use? | 23:14 |
| kyrofa | stokachu, for what? | 23:14 |
| kyrofa | stokachu, note that, according to the snapd docs, that's really the ONLY hook to use | 23:14 |
| stokachu | ok | 23:15 |
| stokachu | it's just for installing a network bridge and doing it via systemd once | 23:15 |
| stokachu | and on any reboots | 23:15 |
| kyrofa | stokachu, it won't run on reboot, just install, upgrade, and `snap set` | 23:15 |
| kyrofa | stokachu, so you might want to do it from the wrapper itself | 23:15 |
| stokachu | ah ok just check before hand for the interface and bring it up that way | 23:16 |
| kyrofa | Yeah | 23:17 |
| stokachu | yea that makes sense as the app isn't running a long standing process | 23:17 |
| stokachu | so my snap contains lxd daemon, does that get started at all prior to me running the actual conjure-up script? | 23:18 |
| kyrofa | stokachu, yes, daemons contained within the snap are fired up as part of the installation | 23:18 |
| stokachu | kyrofa, what happens on reboot will they be started again? | 23:19 |
| kyrofa | stokachu, indeed, they're systemd units (check /etc/systemd/system) | 23:19 |
| stokachu | ah nice | 23:19 |
| stokachu | kyrofa, i think that covers everything then :D | 23:20 |
| stokachu | ill give this a run in the morning | 23:20 |
| kyrofa | stokachu, very good | 23:20 |
| stokachu | cya | 23:21 |
| mup | PR snapcraft#1043 opened: [DO NOT MERGE] check the cla exception <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1043> | 23:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!