=== mup_ is now known as mup [02:56] PR snapcraft#1480 closed: beta [02:59] PR snapcraft#1497 closed: ci: release snap to a branch for every PR === chihchun_afk is now known as chihchun [04:19] Bug #1687079 changed: cannot change profile for the next exec call: No such file or directory [06:26] PR snapd#4071 opened: release: merge 2.29~rc1 changelog [06:27] ogra_: thanks for your suggestion from yesterday, with -^ the changelogs in edge should be sensible again [06:34] Hello need to install ubuntu core 16 on dell edge gateway === kira is now known as Guest79466 [06:34] http://www.dell.com/support/manuals/in/en/indhs1/dell-edge-gateway-5000/dell-edge-gateway-5000_users_guide/factory-os-recovery-image?guid=guid-0506c333-601f-413c-bc47-90bc656d27eb&lang=en-us [06:35] Using the below link which suggest 15.04 [06:36] http://www.dell.com/support/manuals/in/en/indhs1/dell-edge-gateway-5000/dell-edge-gateway-5000_users_guide/flashing-new-ubuntu-os-image?guid=guid-e9835159-7baf-4a32-9b2a-a3fe1a027224&lang=en-us [06:41] Hello need to install ubuntu core 16 on dell edge gateway [06:58] snappy-m-o autopkgtest 1630 xenial:amd64:integration [06:58] elopio1: I've just triggered your test. [07:04] PR snapd#4072 opened: daemon: use newChange() in changeAliases for consistency === JoshStrobl is now known as JoshStrobl|zzz [07:28] o/ [09:21] core 16-2.28.5+ppa9 3304 canonical core [09:21] HMMMM [09:22] mvo: thanks for the golang fixery, sorry for being slack [09:23] mvo: is this a new 'make edge version better'? [09:23] mwhudson: hey [09:23] Chipaca: hello [09:24] mvo: hey, I assume you know about listing/main, is the version change intended and we should change the test or should we put a new RC build with different version string? [09:25] mwhudson: no worries [09:25] mvo: i think zyga-ubuntu's quesiton and mine are the same [09:25] mwhudson: you did the hard work by pointing me to the right fix :) [09:26] Chipaca, zyga-ubuntu sorry, let me quickly rebuild hte core and see if that fixes things. there was a leftover package in the edge ppa which is fixed since [09:27] aha, thanks! :) [09:27] Chipaca, zyga-ubuntu please give it ~30min or so that is hopefully enough, if not we need to whitelist "~" in the listing version [09:28] mvo: should we do that anyway? or is it good as a safety net? [09:28] Chipaca: in this case it was a good safety net, it choked on the "+" in there, right? [09:28] yes [09:29] + MATCH '^core .* [0-9]{2}-[0-9.]+(~[a-z0-9]+)?(\+git[0-9]+\.[0-9a-f]+)? +[0-9]+ +canonical +core *$' [09:29] core 16-2.28.5+ppa9 3301 canonical core [09:29] yep, looks like it [09:29] yeah, I think that is ok, it should die on that, thats wrong content in our ppa [09:30] “Your server, "finley", has been scheduled to be upgraded to the newest version of Ubuntu! You will receive an email notification when the process begins. Please see the Knowledge Base article below for any possible changes that may affect you” [09:30] wooo [09:30] … except it's upgrading to 14.04 [09:30] (from 12.04, so yay i guess?) === morphis__ is now known as morphis [10:16] * zyga-ubuntu works on overlayfs-free variant of layout [10:16] * ogra_ hugs zyga-ubuntu [10:18] * Chipaca -> physio [10:19] zyga-ubuntu: is that because we can't go ahead with the overlayfs one? traversal issues? [10:19] or is it a fallback? [10:19] Chipaca: as a fallback [10:19] cool [10:19] ok [10:19] Chipaca: I want to at least have a plan B that works [10:19] Chipaca: overlay is much nicer and easier to work with but if we cannot do it (see the forum discussion) or it's unsafe, I need a fallback [10:20] zyga-ubuntu: people on the dusty long tail say thank you [10:20] fallback is also easy but undo is tricky [10:20] Chipaca: that's what we're here for :) [10:20] :-) [10:20] * Chipaca -> really, physio [10:27] mvo: do you know if spread-cron PR 49 python code is for python3 or python2? [10:27] PR #49: allow (optional) snappy update $pkgname [10:29] zyga-ubuntu: I don't know I would assume py3 [10:30] zyga-ubuntu: actually looking at this its probably pretty old [10:30] zyga-ubuntu: so might be written for py2, but we can/could moderinize it [10:30] aha [10:31] mvo: yeah, I'm a bit of a junkie for statically typed python [10:31] mvo: I could ... you know, ... improve it :) [10:32] PR snapd#4073 opened: snap: add io.snapcraft.Settings to proxy to xdg-settings [10:44] I asked this in #ubuntu but I figure I'll ask in here too: Is there an easy way to install an Ubuntu Core image from PXE? [10:46] MuffinPimp[m]: I don't think we support that yet but technically if you have a working image you can use any PXE bootable automated installer that will simply copy it and reboot [10:46] MuffinPimp[m]: but note that the first-boot on ubuntu core is special and requires interaction [10:47] MuffinPimp[m]: or special assertion that will complete the setup [10:47] Yeah I was thinking of something like that but I don't know of such a tool. [10:48] And yeah, I have access to a console so that wouldn't be a problem. [10:50] PR core#62 opened: create xdg-settings inside the core snap [10:51] I'm considering just caving and running Ubuntu Server instead since googling hasn't led me anywhere, but I figured I would ask first. [10:53] MuffinPimp[m]: I forget how PXE worked, does it work to boot an image, or does it need something bootable with a size limit? [10:53] last time i played with pxe was to boot some hppa box [10:53] Chipaca: it's a pice of code that boots over LAN, then cna pull in (you are in control) other stuff [10:55] i mean, you can boot iso images with pxe, so you should be able to boot a core image [10:56] Yeah, but I want to install it. [10:56] I agree with Chipaca, it's possible and once someone glues all the bits together, should be a generic solution [10:57] Hello - my snaps are broken, and reinstalling like answers suggest isn't helping: https://hastebin.com/aqewojiseh.sql [10:57] What can I do? [10:57] vadi: hello [10:58] vadi: can you run "snap version" pleaes? [10:58] *please [10:59] MuffinPimp[m]: clonezilla? [10:59] Hrmm [10:59] Sure, here is the output: https://hastebin.com/oxomogivil.rb [10:59] MuffinPimp[m]: AIUI that lets you PXE boot and then image a local drive with a network image [11:00] vadi: I see [11:00] vadi: what's that kernel? [11:00] vadi: you are running a mainline kernel, [11:00] ah :-) [11:01] vadi: your kernel has probably caused us not to load apparmor support code for snap-confine [11:01] I have to use the mainline kernel because the Ubuntu kernel does not let me unlock the encryption on the laptop anymore [11:01] Chipaca: Lol I can't believe I didn't think of clonezilla before, thanks! [11:01] vadi: unfortunately those kernels are not supported yet, I think 2.29 should be better in that regard but you need to wait for a nightly build in the edge channel [11:02] vadi: what encryption is that? sounds like a regression we'd want to know about? [11:02] we == ubuntu people, not just snapd [11:03] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1724564, I can't type the password in for the crypt setup. Either nothing appears or my password starts getting printed top-left of the screen... [11:03] Bug #1724564: Cannot enter password to unlock encryption in 4.10

[11:03] vadi: gah [11:03] Luckily I had a mainline kernel installed for something else that still lets me use my work laptop [11:03] vadi: try booting without the splash screen [11:03] How can I do that? [11:03] vadi: that is, change "splash" to "nosplash" in grub [11:03] vadi: or, boot in rescue mode and then continue the normal boot [11:04] I'll try the rescue and normal. [11:12] It took my password but it got stuck on this: https://photos.app.goo.gl/5QcAeGxOKj3RwTzQ2 [11:14] Hi guys, anyone who can help me with this? https://forum.snapcraft.io/t/issue-with-ubuntu-image-panic-runtime-error-slice-bounds-out-of-range/2571 [11:15] Issue with ubuntu-image: panic: runtime error: slice bounds out of range [11:18] niice [11:19] vadi: it said your password was ok? [11:19] skjensen: hey [11:19] Hey [11:20] skjensen: hmmm, no idea [11:20] Yeah, I think it took it in and it went further. At least it scrolled off the screen rather quick. [11:20] skjensen: zyga-ubuntu: that's a bug, no matter what it is [11:20] i'll look into it [11:20] Great thanks.. :) If you need any help to replicate or see the files I used please let me know. [11:21] skjensen: to be clear: the bug is that instead of returning an error, it panics [11:21] skjensen: the distinction probably doesn't make much difference to you unfortunately [11:22] Okay.. Hopefully the new error message will help me get my problem fixed.. [11:23] Gives you hope that it's not a blocker! [11:23] absolutely [11:24] skjensen: the error is because it looks for two zero bytes in a boot file, and doesn't find it [11:24] in the header [11:24] Chipaca: what does that mean? [11:25] mvo: you remember ubootenv? [11:25] skjensen: i'm not familiar with this bit of the code to give you the proper context, but mvo might remember (but it's lunchtime for him) [11:26] skjensen: what i see in the code is that we get a 'payload': payload := contentWithHeader[headerSize:] [11:26] skjensen: then we check the CRC on it, and that passes [11:26] skjensen: then we look for two null bytes in the header, and that fails, but we don't check it before using it as an index [11:26] and that panics [11:27] "in the header" -> in the payload i mean [11:27] *not* the header [11:27] that is, we skip the header, d'oh :-) [11:27] _which_ file it is, is what i hope mvo can tell me (because the panic doesn't) [11:28] ogra_: is the uboot env file a binary file? [11:29] Chipaca, yes, it gets created by mkenvimage from the uboot tree, out of uboot.env.in [11:29] it has to have a fixed size and format [11:29] guys, i'm not feeling well today, got flu or something, gonna call it a day [11:29] o/ [11:29] ogra_: and it uses two null bytes as an EOF marker or something? [11:30] I'm using this device-tree: tegra124-apalis but no extra uboot.env.in file in my gadget.. Can that be the reason? [11:31] Chipaca, not sure, mvo played with hexedit on it ... but we have a fixed commend that needs to be used to create it, if you use that as required it will be the correct format [11:31] mkenvimage -r -s 131072 -o uboot.env uboot.env.in [11:32] skjensen: if the file were missing you would've seen an explicit error about that [11:32] this is what you have to use (and what all our reference snapcraft.yaml's have) [11:32] this is: the file exists, the payload CRC is alright, but it's missing an end-of-payload marker [11:32] skjensen, yes, thats definitely the reason [11:33] you need to have a uboot.env.in as input for mkenvimage [11:33] I shall write a PR to make this a nice error instead of a panic [11:33] Okay thanks ogra_ [11:34] skjensen, there needs to also be the uboot.conf link pointing to uboot.env in yur gadget source [11:34] But following your blog post about uboot I can't really figure out what to put into the uboot.env.in file? [11:34] ubuntu-image reads the link, it does not directly use uboot.env [11:35] skjensen, boot with the created uboot once (by manually setting up an SD as your board docs require) ... then run "printenv" in an attached serial terminal from the uboot commend prompt ... [11:35] copy/paste the output into a text file you call uboot.env.in ... [11:36] thats your base for it [11:36] then you add the snap and snappy vars to it [11:36] * zyga-ubuntu -> Lunch [11:37] Thanks ogra_ I will give that a go... :) [11:39] ogra_: missing the \0\0, would it be better to error out, or to consume the rest of the file? [11:40] Chipaca, well, it smells like the file is missing completely there ... [11:40] yes, here yes [11:40] bah [11:40] it's not missing, otherwise it wouldn't've panic'ed [11:41] it exists, has the right header, but is missing the eof marker [11:41] end-of-payload marker [11:41] which might actually just be "fill with nul bytes until the given size" [11:41] i'll wait for mvo's advice, i think [11:41] so yes ... then it should print a proper error ... but we should also make sure that mkenvimage doesnt even create such a file if no uboot.env.in exists [11:42] i wonder why it didnt error during build for the gadget [11:42] ¯\_(ツ)_/¯ [11:42] * Chipaca afk for a bit [11:44] ogra@styx:~$ mkenvimage -r -s 131072 -o uboot.foo uboot.foo.in [11:44] Can't open "uboot.foo.in": No such file or directory [11:44] hmm, it should definitely have errored without input file [11:47] Another couple of questions, how do I prevent Ubuntu Core from rebooting automatically? If I wanted to use ZFS would installing TH"classic" [11:47] (and even if the build moved on, the uboot.conf link would point nowhere, so i wonder how it got into that state) [11:47] MuffinPimp[m], you cant currently ... (prevent the reboot) ... and there is no ZFS suppport for core [11:47] well [11:47] ZFS for / that is [11:48] for attached removable devices it might perhaps work (depends on the kernel) [11:49] I CAN'T SEEM TO STOP TYPING IN CAPS, I REALLY NEED TO SEND THIS COMPUTER IN FOR REPAIRS SORRY [11:49] IT JUST STARTED HAPPENING, NOT AN UBUNTU ISSUE JUST A REALLY INCONVENIENT TIME [11:50] no worries, we'll all just plug our ears while you talk :P [11:50] I might have completely skipped the mkenvimage part of the process.. and that's why ubuntu-image is throwing a panic.. Just in case you want to look into improving the error messages.. [11:50] YEAH, I KNOW I WAS THINKING FOR NON ROOT PARTITIONS [11:50] LET ME TRY RESTARTING :/ [11:51] MuffinPimp[m], well, that then depends on the kernel (i'm not super familiar with ZFS, do you also need a userspace part ? thats probably missing as well) [11:51] ogra@dragonboard:~$ grep ZFS /snap/dragonboard-kernel/current/config-4.4.0-1078-snapdragon [11:51] ogra@dragonboard:~$ [11:52] i definitely dont see it in an arm64 kernel of our supported set [11:52] That was annoying [11:55] Yeah, the userspace tools aren't installed so I'm thinking the best way to install them would be "classic mode" idk if that has any gotchas though. [11:56] that or just repackage the deb as a snap [11:56] classic mode cant run any daemons [11:57] it is really just for building stuff on the device [11:57] so if your userspace tools require any service or systemd units it cant work in classic [11:58] Hrm [11:58] i guess a snap would be best though it would likely have to be unconfined / devmode or some such, i doubt there is an interface that could provide such a deep system level access [11:58] (i could be wrong though) [11:59] mvo, can you advise on https://forum.snapcraft.io/t/call-for-testing-chromium-62-0-3202-62/2569/6 ? Looks like snapd is being overly strict [12:03] oSoMoN: sure, let me check [12:05] oSoMoN: meh, yeah, snapd got stricter and now you are bitten by this :/ let me check in more detail [12:07] mvo, I've fixed the incorrect entries in the desktop file and pushed a new revision out to the candidate channel, but the problem is that snapd refuses to upgrade from the revision currently installed because of the incorrect entries === chihchun is now known as chihchun_afk [12:14] mvo: is that a change in 2.29? [12:14] PR snapd#4065 closed: servicestate: use taskset [12:17] oSoMoN, it is funny that snapcraft didnt error the same way, afaik it checks all executables and binaries that get called from the apps section and from shipped .desktop files [12:21] ogra_, I didn't check the snapcraft output, maybe it simply issues a warning instead of erroring out? [12:24] that might be ... [12:26] ogra_, hey [12:26] hey [12:26] (morning ... i guess :) ) [12:27] ogra_, tx, good afternoon for you, I got disconnected, did you see what I wrote? [12:27] nope [12:27] yesterday I was diving in all the building infrastructure :) [12:27] why the core snap is not automatically built by launchpad? [12:27] it is [12:28] lp-build-core is just the trigger script, see my last comments on the forum thread [12:28] but it is possible to setup in launchpad to do what the python script is doing, right? [12:28] no [12:29] there is no cron support in LP itself [12:29] so you need something that "clicks" the request builds button [12:29] (and feeds the info requred by the form this button brings up) [12:30] ogra_, ah, ok, so the reason is to be able to schedule the builds and not do it with any change in the repo, right? [12:30] (arches, archives and such) [12:31] the reason we use cron is because that was enough back when i implemented it ... but when this setup was designed it was designed with the ability in mind to be able to use other PPAs or other triggers [12:31] there are just none yet :) [12:33] ogra_, I am trying to understand :) [12:33] (we were still running 15.04-snappy when i did the original implementation and had not even switched to github ) [12:33] (so the setup was similar to how we roll isos ... simply once a day by cron ... ) [12:33] ogra_, could we on here https://code.launchpad.net/~snappy-dev/+snap/core/+edit to set "Automatically build when branch changes" and point it to the edge ppa? [12:34] cachio, the "branch" is not snapd but the build scripts ... [12:35] cachio, so yes, you could do that but that would only re-build when the build env changes, as i understand you want a rebuild when snapd changes though [12:36] ogra_, but if in the "Source archive for automatic builds:" we add the snappy-edge ppa [12:36] cachio, so what i'd do is to create a "watcher" tool that monitors the edge PPA ... (which as i understand has been set up by elopio1 and federico to always build a new deb when the snapd tree changes) [12:36] and simply replace the cron part with that [12:36] *and* point to the edge PPA [12:36] ogra_, but launchpad is offering to watch a ppa [12:37] as additional build source [12:37] ah [12:37] well, if thats possible, tnen do that [12:37] *then [12:37] i didnt know that ... [12:38] you need to make sure the PPA is also used alongside with the image PPA and xenial-updates though [12:38] not sure how you can do that without using lp-lib ... since there is no such feature in the snap form of LP [12:38] ogra_, I would use this ppa https://code.launchpad.net/~snappy-dev/+archive/ubuntu/edge [12:39] yes [12:39] ackk: Reviewed #3916 again [12:39] PR #3916: snap,wrappers: add support for socket activation [12:40] ackk: A few more notes, probably the last ones [12:40] niemeyer, thanks! [12:40] ackk: If you can go through these quickly, I'm happy to re-review before I'm off [12:40] * ackk takes a look [12:41] ogra_, I sent you an email with the configuration that we could try [12:41] cachio, what i dont see is how you define a PPA as trigger on https://code.launchpad.net/~snappy-dev/+snap/core or on https://code.launchpad.net/~snappy-dev/+snap/core/+request-builds [12:42] and there is no way to set up two PPAs as build source on the second page [12:42] this is why i use that lp-build-core script, because lp-lib is the only way to do this [12:42] (or has been, if there are other ways then i simply dont know about them) [12:43] ogra_, you mean, to trigger when there is a change in the core project itself? [12:44] cachio, ah, i see what you mean .. you should read the text under "Automatically build when branch changes" [12:44] ogra_, yes [12:44] that does not refer to the PPA, it refers only to the git branch [12:45] and the git branch is not snapd but https://github.com/snapcore/core (which contains the whole build env) [12:45] so it would only auto-build if the build tools change, not if snapd changes [12:45] ogra_, ah, ok, and we don't have snapcraft.yaml in the edge ppa [12:46] a PPA is a package archive for debs [12:46] no, there is no snapcraft.yaml in the PPA [12:46] f [12:47] ogra_, I know, but I would use it just as the trigger [12:47] cachio, what we have (what federico and elopio1 did set up once) is an auto-build of the snapd deb in the edge PPA ... the core build scripts use debs to create the core snap ... so what you actually want to watch is when the snapd deb in the edge PPA is getting refreshed ... [12:48] then you want to trigger a new build of core and actually use that deb (by adding the additional edge PPA to the snap build) [12:48] right [12:48] you can use it as trigger but you cant do that without some lp-lib coding [12:48] there is no way to use a PPA as trigger for a snap build automatically [12:49] ogra_, agree [12:50] the way i described in my last forum post on that topic should work with the existing setup ... which doesnt mean there isnt perhaps a better way i dont know about though [12:50] ogra_, I already updated the python code [12:50] good [12:51] PR snapd#4074 opened: partition/ubootenv: don't panic when uboot.env is missing the eof marker [12:54] cachio, the trickiest part here is to hide the credentials from the rest of the world ... since they give 100% access to all team stuff, which is why i'd recommend to do it all from your home people.canonical.com or from some other machine in the datacenter that outsiders can not browse [12:55] (people.c.c is the easiest though ... ) [12:55] ogra_, well, so far I just have access to that machine [12:56] ogra_, I just have the certs needed [12:56] ogra_, the launchpad credentials saved are just for that machine, right? [12:57] i think so [12:58] yeah, looking at the credentials file in my home on lillipilly i see: [12:58] consumer_key = System-wide: Ubuntu (lillypilly) [12:58] as the first line [12:58] so it creates a system token when you run it for the first time [12:58] ogra_, yes [12:59] ogra_, and in launchpad you can define how to use it, just once, until you disable it, etc [12:59] yeah [13:00] you dont want the access_secret public from that file though [13:01] (not sure if thats any valuable without the token but i wouldnt want to try it either :) ) [13:03] cachio, oh, and note that lillipilly is a 12.04 machine ... the default python is 2 ... (i just noticed zyga-ubuntu's complaint on your PR for lp-build-core) [13:05] oSoMoN: I put it on my list to investigate today [13:20] * kalikiana going for lunch [13:22] niemeyer, so, to confirm, we only want to accept $SNAP_DATA and $SNAP_COMMON as path prefixes for listen-stream, no absolute paths [13:32] mvo, thanks! [13:32] Chipaca: will you mention your PR in https://forum.snapcraft.io/t/issue-with-ubuntu-image-panic-runtime-error-slice-bounds-out-of-range/2571 ? [13:33] mvo: done [13:43] niemeyer, addressed all your comments, but I have a question on the last one (on the PR) [13:45] how can i add to a path variable of a snappy package I have installed [13:46] JonelethIrenicus: what do you mean? [13:47] $PATH [13:47] i want to add a directory to the path [13:50] PR snapd#4066 closed: overlord/snapstate: support completion for command aliases [13:50] JonelethIrenicus: what for? [13:51] Chipaca: because I want to [13:52] JonelethIrenicus: is this a regular binary app in the snap, or a service? [13:53] its pycharm [14:03] http://markshuttleworth.com/archives/1518 [14:03] * ogra_ hugs sabdfl [14:04] thanks for giving the child a name :) [14:07] woot. bionic beaver is a name I did not expect. I love it :-D [14:07] ackk: Shoot [14:08] mvo: Updated the core opts doc to include the proxy.* options [14:08] niemeyer, see my last comment on the PR [14:08] niemeyer, I'm not sure what you're referring to wrt systemd creating paths [14:08] niemeyer: thank you [14:10] ackk: I see, it's fine to keep the MkdirAll [14:10] jdstrand: hey [14:10] ackk: I don't quite recall whether we remap into /etc or whether we're using /etc/systemd elsewhere in core devices [14:10] niemeyer, I think I had it there because the older implamentation had it [14:10] niemeyer, but as said, /etc/systemd/system should always be there [14:10] ackk: Yeah, and that might be the reason.. it's fine to keep it [14:10] ackk: Thanks for the changes.. I'll re-review after lunch [14:10] zyga-ubuntu: hey. actively looking at 4008 [14:10] mvo: np! [14:11] niemeyer, ok, then the branch should be good [14:11] niemeyer, ty for looking at it [14:11] jdstrand: not sure how your commitments look like [14:11] jdstrand: aha, thank you! :) [14:11] jdstrand: then I'll get out of your way :) [14:14] mvo, about the user assertion, any update on that? [14:16] cachio: meh, not yet [14:16] sorry [14:17] mvo, can I help? [14:17] cachio: yes, you could create it via a json input file or by looking how we do those nowdays in the other tests. but I need to dig into that myself a bit to be more helpful :/ [14:20] oSoMoN: if chromium has access to xdg-settings, will that be used to make itself the default browser? [14:36] davidcalle: I see people still referring to https://insights.ubuntu.com/2017/01/28/ubuntu-core-how-to-enable-aliases-for-your-snaps-commands/ , it probably needs updating to reflect the changes happened to how aliases work [14:42] Anyone used the content interface? [14:43] gokr: hey, what do you need? [14:43] I have been battling this but... I think I now may know what the problem is. [14:44] We are making a proof of concept - with one snap being a kind of web server, that serves other snaps. And those others are exposed via content interface. [14:47] Unfortunately... I am not sure its a viable approach - since... I don't know if they will autoconnect unless both are from the same publisher. And... that feels like a restriction in this case. [14:47] pedronis: hmm, thanks, you are right [14:49] zyga-ubuntu: I make the connection, but I am having a hard time knowing where the content is supposed to be mounted. [14:50] It would be nice if I somehow could use some snap command or something that shows the actual mounts. [14:52] elopio1, the ruby autopkgtest doesn't seem to work on armhf either [14:52] Hi. Can someone point me to some documentation on launchpad build farm for snaps? [14:53] Woa, it worked. So... ok, the mount point must exist. [14:53] sborovkov, hmm, i dont think there is much actual documentation, if you have a branch in LP you get a "create snap package" button, that takes you a form which is pretty self explaining ... not sure if cjwatson can point to something more detailed [14:53] Ok understood [14:54] sborovkov, ogra_ this is still mostly up-to-date: https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way [14:54] ah, perfect ! [14:54] thanks [14:54] Some of the UI has changed since I took the screenshots, but it'll get you there [14:55] yeah, it is really self explaining after all ... [14:55] gokr: re [14:55] (i personally found it harder to set up the git tree import from GH to LP than to create the snap package from it afterwards) [14:55] davidcalle: yes, I had this in mind and forgot a couple of times to ping you, let me know if I can help somehow [14:55] gokr: yes, that's a limitation in 2.28.5, in 2.29 or 2.30 the target won't have to exist [14:55] davidcalle: thanks [14:56] gokr: you can see the actual mounts using a little trick but I agree it's not easy to find [14:56] zyga-ubuntu: Ok, followup question. I want to mount into $SNAP_DATA/apps - but... oh? Hmmm, what version do I have... [14:56] gokr: you can run "sudo nsenter -m/run/snapd/ns/nameofthesnap.mnt" [14:56] 2.28.5, right [14:56] gokr: then you can run mount or look at /proc/self/mountinfo [14:57] great, thanks. [14:57] gokr: in 2.29.2 (perhaps) or 2.03 you will have the benefit of this pull request: [14:57] https://github.com/snapcore/snapd/pull/4008 [14:57] PR #4008: cmd/snap-update-ns: create missing mount points automatically [14:57]