| === StoneTable is now known as aisrael | ||
| === ueberall is now known as uebera|| | ||
| mwhudson | hm | 01:40 |
|---|---|---|
| mwhudson | i get the classic confinement requires the core_dynamic_linker to be set message trying to build a classic confinment snap on launchpad | 01:40 |
| mwhudson | apparently that's code for "you need the core snap installed" | 01:40 |
| mwhudson | but how do i get the builder to install the snap? | 01:40 |
| mup | PR snapcraft#1040 closed: Run the rust test in armhf <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1040> | 05:21 |
| mup | PR snapcraft#1041 closed: Document `notify` daemon type <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1041> | 05:27 |
| mup | PR snapcraft#1042 closed: Add documentation for hooks <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1042> | 05:27 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| mup | PR snapd#2590 closed: interfaces: miscellaneous policy updates for network-control, unity7, pulseaudio, default and home <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2590> | 06:37 |
| mup | PR snapd#2591 opened: wrappers: add DBusActivatable to the allowed values for desktop files <Created by mvo5> <https://github.com/snapcore/snapd/pull/2591> | 07:13 |
| zyga | o/ | 07:23 |
| longsleep | Is the gadget snap actually installed on the device? I am wondering where i find the hooks or how to debug a prepare-device hook. | 08:07 |
| zyga | longsleep: it is, but it is not updated in the same way as other snaps | 08:08 |
| zyga | longsleep: look at /snap/$SNAP_NAME/current, as usual | 08:08 |
| palasso | Hey there, sorry for the newbie question but by reading the docs in snapcraft.io I am confused on the types of snaps that exist | 08:08 |
| longsleep | zyga: /snap/ is emtpy | 08:08 |
| zyga | longsleep: empty? | 08:08 |
| palasso | So I understand there's a focus in app and gadget snaps but there's more types being mentioned | 08:08 |
| zyga | longsleep: that's odd | 08:08 |
| zyga | palasso: there are kerenl snaps, gadget snaps and app snaps | 08:09 |
| longsleep | zyga: i only see the stuff from the gadget snap in /boot/uboot | 08:09 |
| palasso | There's a mention of kernel and OS snaps and also in the snap store I can see there's OEM and framework snaps | 08:09 |
| zyga | palasso: and there's the one os/core snap | 08:09 |
| zyga | palasso: framework snaps are no more, oem snap is no more | 08:09 |
| zyga | longsleep: did the device finish booting? | 08:09 |
| zyga | longsleep: snapd installs snaps on first boot | 08:09 |
| palasso | alright ty zyga :) | 08:09 |
| longsleep | zyga: yes it boots and works just fine | 08:10 |
| longsleep | zyga: i finished the stup via serial console subiquity prompts and sshd in | 08:10 |
| zyga | longsleep: no idea then, maybe ogra_ has some ideas? | 08:10 |
| palasso | zyga: so the OEM and framework snaps in the store are there for archival purposes or being used from devices having old versions of snapd? | 08:10 |
| longsleep | zyga: if i install hello-world snap then it also first downloads the core snap which i find odd too | 08:11 |
| longsleep | zyga: and then of course the hello-world snap does not work because of the mount aa deny | 08:11 |
| palasso | zyga: also I'm wondering, since it seems docker was the reason for the framework snaps, is there some inherent difficulty in snapping docker as an app snap? And if it goes away is there some suggestion of having a way to use docker in an all-snap distro? | 08:12 |
| zyga | palasso: those are 15.04 concepts, they are gone in 16.04 | 08:12 |
| zyga | longsleep: that looks like a bug | 08:12 |
| zyga | longsleep: can you please report this | 08:13 |
| palasso | zyga: also I'm wondering whether the proper name for the software that does the confinement is "snapd-confine" or "snap-confine" | 08:13 |
| zyga | palasso: framework snaps had more permissions, in 16.04 permissions are based on interfaces so any snap can get additional permissions by using appropriate interface | 08:13 |
| zyga | palasso: snapd defines confinemenet, snap-confine applies it | 08:14 |
| palasso | Ok thank you zyga I think there's a typo in the docs because it mentions it as snapd-confine | 08:14 |
| longsleep | zyga: sure | 08:14 |
| longsleep | zyga: after i install hello-world, i now have bin, core and hello-world in /snap - before it was empty | 08:14 |
| zyga | palasso: can you point me to it | 08:14 |
| palasso | zyga: core/snapd | 08:15 |
| longsleep | zyga: and it scheduled a reboot because it updated core? | 08:15 |
| zyga | longsleep: sanity check, this is not a classic system, this is a core system? | 08:15 |
| longsleep | zyga: yeah, created by ubuntu-image with UBUNTU_IMAGE_SKIP_COPY_UNVERIFIED_MODEL=1 ubuntu-image -c stable --image-size 2G --extra-snaps pine64_16.04-2_arm64.snap --extra-snaps kernel/pine64-kernel_3.10.104-2_arm64.snap -o test2.img pine64.model --debug | 08:16 |
| longsleep | except that this boot i used edge channel | 08:16 |
| palasso | zyga: also in the same page there seems to have been a mistake in bullet points. Read part "A store where developers can easily make their" I think it shouldn't be a sub bullet point | 08:16 |
| zyga | palasso: sorry, can you give me a URL please? | 08:17 |
| palasso | http://snapcraft.io/docs/core/snapd | 08:17 |
| longsleep | zyga: where should i file that bug - https://launchpad.net/ubuntu-image sounds good? | 08:18 |
| longsleep | zyga: i got ubuntu-image 0.12+real1 | 08:19 |
| zyga | longsleep: how did you install ubuntu-image? | 08:19 |
| zyga | longsleep: AFAIK today it is only installable as a snap | 08:19 |
| zyga | longsleep: I don't know how well it supports other platforms, apart from what we can build officially | 08:20 |
| longsleep | zyga: yes installed as snap on my xenial dev system - ubuntu-image 0.12+real1 44 canonical devmode | 08:20 |
| mup | Bug #1655262 opened: driver doesn't support ap mode <Snappy:New> <https://launchpad.net/bugs/1655262> | 08:21 |
| palasso | zyga: also a few more typos, not important but I happened to notice: In http://snapcraft.io/docs/core/install correction of branding: OpenSuse --> openSUSE (also notice it'll be consistent with the URL of the repo that's been specified in the command) | 08:29 |
| palasso | zyga: and I think in http://snapcraft.io/docs/core/updates "Snapd systems employ a method of transactional update" shall have a plural for "update" thus being replaced with "updates" | 08:30 |
| palasso | zyga: Here's a pastebin for the typos: https://paste.ubuntu.com/23775246/ | 08:36 |
| zyga | palasso: thanks! | 08:36 |
| palasso | you're welcome :) | 08:36 |
| palasso | btw and sorry for bugging you the old OEM snaps have been replaced functionality-wise with the kernel snaps or the OS snap or is it more complicated than that? | 08:39 |
| zyga | palasso: I'm not sure what the OEM snaps were doing, I think it is now the (single) core snap | 08:44 |
| palasso | I'm still in the reading process so it's not like I understand everything. I also noticed Lennart talking about Portable system services within systemd and using squashfs images (seems very similar to the snap format) https://lwn.net/Articles/706025/ | 08:45 |
| zyga | yes, it seems that this is a clone from the idea of snaps | 08:46 |
| palasso | He said if he were to create systemd today, he would have started with portable system services being the norm but since it's been there for so long he has to keep compatibility by keeping the "native" type | 08:47 |
| palasso | And here's the talk: https://www.youtube.com/watch?v=DUUbFGNZ1vI | 08:49 |
| palasso | zyga: I have no idea what the OEM snaps are, I barely read in the past the old documents that weren't in the snapcraft.io domain name (those that were in the ubuntu.com domain name before the launch of snapcraft.io) but looking at the OEM snaps I think they're custom images for ARM boards. | 08:52 |
| zyga | palasso: hey, I just realized that snapcraft.io is a github project, can you please try to fix those typos directly? https://github.com/ubuntudesign/snapcraft.io/ | 08:52 |
| zyga | palasso: I think OEM may have been just current kernel snaps | 08:53 |
| palasso | zyga: yeah sure I'll make a PR :) | 08:53 |
| zyga | palasso: awesome, thank you :) | 08:53 |
| davidcalle | palasso: over here https://github.com/CanonicalLtd/snappy-docs/ :) | 08:59 |
| palasso | davidcalle: thnx I just found it myself by looking at the code :P | 08:59 |
| davidcalle | palasso: also, thank you | 08:59 |
| palasso | this part helped me find it: https://github.com/ubuntudesign/snapcraft.io/blob/master/import-docs.sh | 08:59 |
| davidcalle | palasso, zyga: OEM snaps -> Gadget snaps | 09:01 |
| * zyga nods | 09:02 | |
| mup | PR snapd#2592 opened: many: add support for session dbus services via snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/2592> | 09:10 |
| vigo | ogra_, ping | 09:31 |
| mup | PR snapd#2593 opened: Mount backend <Created by zyga> <https://github.com/snapcore/snapd/pull/2593> | 09:41 |
| ogra_ | vigo, yes ? | 09:50 |
| vigo | ogra_, I'm following the steps you told me but when I try to connect to my wifi it is not listed | 09:51 |
| vigo | I mean I can see other wlans listed but not mine :S | 09:51 |
| ogra_ | weird, works here | 09:51 |
| ogra_ | oh | 09:51 |
| ogra_ | i thought you cant see the device | 09:51 |
| ogra_ | hmm | 09:52 |
| vigo | makes me wonder about wifi compatibility, I scan for new networks and give it time to show me a complet list | 09:53 |
| vigo | but my network is still missing while dragonboard workd great | 09:53 |
| ogra_ | longsleep, this sounds a bit like the old rtc issues we used to have does your cmdline have fixrtc set ? the device setup doesnt work if the clock is completely off | 09:55 |
| vigo | I'll change the wifi channel and try | 09:55 |
| vigo | again | 09:55 |
| ogra_ | vigo, well, probably a driver bug, not sure ... i never had probs here, WPA2 and channel 12 | 09:56 |
| ogra_ | (thats what my network uses) | 09:56 |
| vigo | ogra_, it was the channel | 10:01 |
| ogra_ | ah | 10:01 |
| vigo | I was using channel 13 | 10:01 |
| vigo | eheh | 10:01 |
| ogra_ | so the pi driver rspects regulations and the dragonboard doesnt i guess :) | 10:01 |
| vigo | now I see my wifi printer too | 10:01 |
| ogra_ | cool | 10:01 |
| mup | Issue snapd#2594 opened: Please add "install" hook <Created by jacekn> <https://github.com/snapcore/snapd/issue/2594> | 10:02 |
| longsleep | ogra_: yes i have fixrtc in cmdline | 10:14 |
| ogra_ | longsleep, well, check your syslog and dmesg ... i'm sure there is an error somewhere with the firstboot setup | 10:15 |
| longsleep | ogra_: ok, will do - preparing a new image now | 10:15 |
| ogra_ | (if it is not the clock it must be something else ... but there should be a log entry for it in any case) | 10:15 |
| longsleep | ogra_: any chance you can point me to some docs how i can make it load an extra kernel module on boot? | 10:16 |
| ogra_ | you should eb able to ship /etc/modules in the gadget ... i know there are plans for a core config interface to set this but i'm not sure where this stands | 10:17 |
| ogra_ | beyond this, /etc/modules.d is writable so you can dump a file in there | 10:17 |
| ogra_ | er | 10:18 |
| ogra_ | nowadays it is /etc/modules-load.d | 10:18 |
| longsleep | ogra_: ok cool will try that thanks | 10:19 |
| vigo | ogra_, pi3 has wifi n only | 10:38 |
| vigo | and db b/g/n | 10:38 |
| ogra_ | ah, right | 10:38 |
| vigo | that's why 12 and 13 won't work | 10:39 |
| vigo | so it's legal :) | 10:39 |
| ogra_ | yeah | 10:39 |
| ogra_ | thanks for researching that :) | 10:39 |
| vigo | ogra_, np, I like it :) | 10:40 |
| longsleep | ogra_: there are plenty of errors in syslog but nothing really obvious to me - http://paste.ubuntu.com/23775585/ has the full syslog after the first boot | 10:41 |
| longsleep | ogra_: i guess everything related to /usr/bin/snap is relevant | 10:42 |
| ogra_ | longsleep, and dmesg output ? | 10:43 |
| ogra_ | (the bit before rsyslogd starts is interesting too) | 10:43 |
| longsleep | ogra_: http://paste.ubuntu.com/23775592/ has the dmesg | 10:44 |
| ogra_ | long term you also want to drop "rootfstype=ext4 rootwait" | 10:44 |
| longsleep | ogra_: sure i can easily remove those, copied some u-boot stuff from classic ubuntu | 10:44 |
| ogra_ | hmm, no failed messages there | 10:48 |
| ogra_ | do you see any systemd errors in the serial console when booting ? | 10:48 |
| longsleep | ogra_: yeah all systemd units report fine | 10:48 |
| longsleep | ogra_: none | 10:48 |
| ogra_ | strange | 10:48 |
| ogra_ | Jan 10 10:34:53 localhost /usr/lib/snapd/snapd[1171]: booted.go:81: cannot get info for "pine64-kernel": cannot find snap "pine64-kernel" | 10:49 |
| ogra_ | Jan 10 10:34:53 localhost /usr/lib/snapd/snapd[1171]: booted.go:81: cannot get info for "core": cannot find snap "core" | 10:49 |
| longsleep | yeah - those snaps are not there | 10:49 |
| ogra_ | it is definitely this ... but there should be a more descritive error above ... | 10:49 |
| ogra_ | how did you build the image ?? do you use a properly signed model assertion with a valid key ? | 10:50 |
| longsleep | ogra_: so the question is where do those snaps go / why are they not found - i mean ubuntu-image should use/install them during imafge creation | 10:50 |
| longsleep | ogra_: no model assertion is not signed | 10:50 |
| ogra_ | ah | 10:51 |
| ogra_ | well, thats your issue then | 10:51 |
| longsleep | really, i thought it still would be fully functional without it except that i cannot update | 10:51 |
| ogra_ | nope | 10:51 |
| longsleep | ogra_: i still cannot sign anything as i cannot register the key with the store | 10:51 |
| ogra_ | though ubuntu-image should still have put the snaps into /var/lib/snapd/snaps/ | 10:52 |
| ogra_ | and you should eb able to find them | 10:52 |
| longsleep | ogra_: nope, that folder is empty on the device | 10:52 |
| longsleep | ogra_: so how do i get the "The account-key-request assertion is not valid." error fixed, so far nobody has been able to help me with that | 10:54 |
| longsleep | i unfortunately cannot sign anything as i cannot register a key with my account :/ | 10:54 |
| ogra_ | your assertion needs to be signed | 10:54 |
| ogra_ | i dont think there is a way around ... | 10:54 |
| ogra_ | https://docs.ubuntu.com/core/en/guides/build-device/image-building | 10:55 |
| ogra_ | point 2 and 3 | 10:56 |
| longsleep | ogra_: ok let me try to use a signed assertion without having the key registered with my account | 10:56 |
| ogra_ | well, i think ubuntu-image checks the key ... so that might not work either | 10:56 |
| longsleep | ogra_: because step 2 of these instructions fail for me - http://paste.ubuntu.com/23770867/ | 10:56 |
| ogra_ | well, thats a question for the store people i fear | 10:57 |
| longsleep | ogra_: you are right, i cannot build with the signed assertion unless the key is registered | 10:57 |
| longsleep | ogra_: error: cannot fetch and check prerequisites for the model assertion: account-key (BBZk-RcyZ-tJN9eRJTW-pwcHg7r2ME-Bm9kUn5qOKyRQMJ9SPyrham_UHoSNnrAJ) not found | 10:58 |
| longsleep | :( | 10:58 |
| ogra_ | yep | 10:58 |
| longsleep | so i already asked about this here in december - so far no luck in getting anyone from the store people :/ | 10:58 |
| ogra_ | zyga, do you know whom longsleep could poke to get this working ? | 10:59 |
| mvo | longsleep: what version of snapcraft are you using? | 10:59 |
| longsleep | mvo: 2.24 | 10:59 |
| zyga | mmm | 11:00 |
| zyga | no idea | 11:00 |
| mvo | longsleep: that should be ok - maybe pedronis has an idea about the error in http://paste.ubuntu.com/23770867/ "Key registration failed: The account-key-request assertion is not valid." ? | 11:00 |
| mvo | longsleep: he is at lunch right now though | 11:00 |
| ogra_ | iirc key management starts working after 2.17 ... so this should be fine | 11:00 |
| longsleep | ogra_: i thought so, its the version from xenial-updates repository | 11:01 |
| longsleep | mvo: ok thanks, lets hope to get a reply from pedronis when he is back | 11:01 |
| ogra_ | yeah, 2.24 is definitely good | 11:01 |
| longsleep | i also tried with a new key, same error - so i think something is wrong with my account - it is very old and has probably gone through some migrations | 11:02 |
| ogra_ | try creating a longsleep-test account ;) | 11:03 |
| longsleep | ogra_: yeah i might do that as last resort, but its kind of shitty to use two different accounts | 11:04 |
| ogra_ | just for this test indeed | 11:04 |
| longsleep | ogra_: yeah let me setup an lxd container for that | 11:05 |
| longsleep | ogra_: right, new account worked instantly :/ Done. The key "longsleep-test1" (KWRSCGwv7tVtZW8GpAHajvBIuWr0lfBBjmi4VPj6amYeeyzSmmG4Rf6uDrHT--Yc) may be used to sign your assertions. | 11:18 |
| ogra_ | well, now roll an image with it ;) | 11:18 |
| longsleep | ogra_: currently building :) | 11:19 |
| longsleep | or not .. | 11:20 |
| longsleep | i guess the snaps are signed too or something? | 11:20 |
| longsleep | error: cannot fetch and check prerequisites for the model assertion: cannot add assertion model (pine64; series:16 brand-id:IcQdq5akLGfjzZ15kmONNRvA8ORuNbAa): error finding matching public key for signature: found public key "KWRSCGwv7tVtZW8GpAHajvBIuWr0lfBBjmi4VPj6amYeeyzSmmG4Rf6uDrHT--Yc" from "d0VlBe971cyBTYMdulEfu4cyzUgJWiva" but expected it from: IcQdq5akLGfjzZ15kmONNRvA8ORuNbAa | 11:20 |
| ogra_ | the store snaps are ... is your gadget/kernel local or in the store ? | 11:22 |
| longsleep | local | 11:22 |
| ogra_ | if they are local you should use them in --extra-snaps | 11:22 |
| longsleep | yes thats what i am doing | 11:22 |
| ogra_ | hmm | 11:22 |
| mup | PR snapd#2595 opened: daemon: re-enable reexec <Created by mvo5> <https://github.com/snapcore/snapd/pull/2595> | 11:23 |
| ogra_ | i thought they only get signed when you upload ... seemingly not ... | 11:23 |
| longsleep | ogra_: http://paste.ubuntu.com/23775798/ is what i am doing, and the model assertion is signed with the new key which is registered to longsleep-test store account via snapcraft | 11:26 |
| pedronis | mvo: longsleep: I have no idea tbh, cjwatson might be a better bet | 11:27 |
| ogra_ | longsleep, and you run this in the same container you created the key in ? | 11:28 |
| ogra_ | (the key must indeed be available to ubuntu-image) | 11:28 |
| longsleep | ogra_: ah this is my fauilt, i need to change the key ids in the model json | 11:29 |
| longsleep | then it should work | 11:29 |
| mup | PR snapd#2596 opened: tests: parameterize kernel snap channel <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2596> | 11:29 |
| ogra_ | yeah | 11:29 |
| longsleep | ogra_: this is really picky, timestamp outside of signing key validity | 11:31 |
| ogra_ | oh my | 11:31 |
| ogra_ | date -Iseconds --utc | 11:32 |
| longsleep | ogra_: now it builds | 11:32 |
| ogra_ | and replace it with the output | 11:32 |
| ogra_ | yay | 11:32 |
| longsleep | pedronis: would you mind poking them so i can use my real ubuntu account to sign snaps | 11:33 |
| pedronis | longsleep: do you have the LP bug you submitted at hand | 11:35 |
| pedronis | found it | 11:40 |
| longsleep | pedronis: sorry i had to switch location, https://bugs.launchpad.net/snapcraft/+bug/1652302 is the one you found i suppose? | 11:42 |
| mup | Bug #1652302: Key registration failed: The account-key-request assertion is not valid. <Snapcraft:New> <https://launchpad.net/bugs/1652302> | 11:42 |
| cjwatson | longsleep: digging | 12:00 |
| longsleep | ogra_: looks much better with the signed model - now snaps are how they should be after first boot | 12:03 |
| cjwatson | longsleep: could you modify your local version of snapcraft something like http://paste.ubuntu.com/23775926/ and send me the output when you try again? Please try with your non-test account. | 12:10 |
| longsleep | cjwatson: sure hold on | 12:10 |
| cjwatson | longsleep: I don't think the output should be *very* private, but maybe send it in a private message just in case | 12:10 |
| ogra_ | longsleep, YAY ! | 12:16 |
| ogra_ | \o/ | 12:16 |
| longsleep | ogra_: ah and now i also see the mount aa denies on boot, i guess thats why the hooks do not run - now it finds the snaps at least | 12:23 |
| longsleep | ogra_: Jan 10 11:48:02 localhost kernel: [ 65.153519] type=1400 audit(1484048882.620:9): apparmor="DENIED" operation="mount" info="failed mntpnt match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/pine64.mnt/" pid=1640 comm="snap-confine" srcname="/" flags="rw, bind" | 12:23 |
| longsleep | ogra_: so i guess i am down to one issue now with snappy, the key problem seems to be a problem with my account | 12:24 |
| ogra_ | longsleep, hmm, never seen that one | 12:47 |
| longsleep | ogra_: yeah, its the same i reported earlyier - happens for any command run through snap-confine - i am waiting on zyga for feedback | 12:48 |
| ogra_ | might be a kernel issue | 12:49 |
| ogra_ | (something missing in the namespace config ? ) | 12:49 |
| longsleep | ogra_: yeah, though i have looked and i seem to have all the aa patches | 12:49 |
| ogra_ | well, might not be the patches but just a config option | 12:50 |
| longsleep | ogra_: might be, though lxd works with this kernel (thats why i backported the stuff in the first place) | 12:50 |
| longsleep | ogra_: yes, any suggestions how to find out which? | 12:50 |
| ogra_ | apart from comparing to a working config ? not really | 12:51 |
| longsleep | ogra_: could you pastebin a working /proc/config.gz | 12:51 |
| ogra_ | http://paste.ubuntu.com/23776040/ | 12:52 |
| ogra_ | thats what i get for NS | 12:52 |
| ogra_ | plus CONFIG_NAMESPACES indeed | 12:52 |
| zyga | longsleep: I didn't have time to inspect this yet | 12:55 |
| zyga | longsleep: sorry :/ | 12:55 |
| longsleep | ogra_: looks different for me - http://paste.ubuntu.com/23776045/ | 12:55 |
| longsleep | zyga: no problem, i continue to investigate myself - but any pointers would be helpful | 12:55 |
| zyga | longsleep: try to edit the apparmor profile of snap confine | 12:56 |
| zyga | you can copy it from /etc/ | 12:56 |
| zyga | and edit it | 12:56 |
| zyga | and recopile it with apparmor_parser -r | 12:56 |
| zyga | try to add some rules related to the capture of the bind mount | 12:56 |
| zyga | that would be in the hat-profile, at the bottom of that file | 12:56 |
| zyga | (the name is /etc/apparmor.d/usr.lib.snapd.snap-confine) | 12:57 |
| zyga | there are comments there | 12:57 |
| zyga | if you have questions, ask | 12:57 |
| zyga | but I cannot reproduce that here and you stand a better chance | 12:57 |
| longsleep | zyga: yes i looked into that before, it has mount options=(rw bind) / -> /run/snapd/ns/*.mnt, | 12:58 |
| longsleep | zyga: which should match this | 12:58 |
| zyga | looks like a bug in apparmor | 12:58 |
| longsleep | zyga: but i have no idea on what to change | 12:58 |
| zyga | technically that's not what we are doing | 12:58 |
| mup | PR snapd#2597 opened: vet: fix for unkeyed fields error on aliases_test.go <Created by stolowski> <https://github.com/snapcore/snapd/pull/2597> | 12:58 |
| zyga | try to change the initial / | 12:58 |
| zyga | the file we bind is /proc/self/ns/mnt | 12:59 |
| zyga | but ... bugs bugs bugs | 12:59 |
| zyga | and thank you! | 12:59 |
| longsleep | zyga: yes it has # NOTE: the source name is / even though we map /proc/123/ns/mnt as comment | 12:59 |
| zyga | :D | 12:59 |
| longsleep | i have not much a clue about what aa is doing or why this might be like the NOTE says | 13:00 |
| zyga | longsleep: looks like a bug to me, try a super broad rule like | 13:11 |
| zyga | longsleep: mount options (rw, bind) | 13:11 |
| zyga | longsleep: mount options (rw, bind), # <- don't miss the comma | 13:11 |
| zyga | longsleep: try with one or both arguments on either side of the -> "bind" mount arrow | 13:11 |
| longsleep | zyga: adding a broad rule "mount options=(rw, bind)." just works | 13:38 |
| longsleep | zyga: mount options=(rw, bind) /, works as well while mount options=(rw, bind) / -> /run/snapd/ns/*.mnt, does not | 13:41 |
| longsleep | zyga: mount options=(rw, bind) / -> /run/snapd/ns/hello-world.mnt, does not work either | 13:43 |
| ogra_ | longsleep, any chance that you could use some newer kernel ? | 13:44 |
| ogra_ | might be that 3.10 simply misses namespace features there | 13:45 |
| longsleep | ogra_: well, mainline is under way for that board but is not ready | 13:45 |
| ogra_ | hmph | 13:45 |
| longsleep | ogra_: i can backport stuff if i would know which | 13:45 |
| longsleep | ogra_: i did backport some fixes already to get lxd running | 13:46 |
| mup | PR snapd#2597 closed: vet: fix for unkeyed fields error on aliases_test.go <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2597> | 13:58 |
| === ben_r_ is now known as ben_r | ||
| Kaleo | what's the difference between the core snap and the ubuntu-core snap? | 14:34 |
| ogra_ | Kaleo, the name | 14:36 |
| Kaleo | ogra_, I see | 14:36 |
| === anewman__ is now known as anewman | ||
| ogra_ | (not sure if snapd reacts any different based on the name but i think it doesnt) | 14:37 |
| Kaleo | ogra_, when trying to use the classic confinement mode it needs to have the core snap installed; the ubuntu-core snap won't do; unpractical (especially that it's hard to install the core one when the ubuntu-core snap is installed) | 14:37 |
| ogra_ | eventually ubuntu-core will go away | 14:37 |
| Kaleo | ogra_, thanks | 14:37 |
| mup | PR snapd#2593 closed: Mount backend <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2593> | 14:38 |
| ogra_ | zyga, mvo ^^^ do we really still need that differntiation now that the content is identical ? | 14:38 |
| ogra_ | (classic snaps refused) | 14:38 |
| Kaleo | ogra_, the differentiation is in snapcraft (at build time) | 14:40 |
| ogra_ | ah, k | 14:40 |
| Kaleo | snapcraft/internal/project_loader.py | 14:40 |
| ogra_ | the prob is that we currenbtly have no proper upgrade path from the obsolete ubuntu-core to core | 14:40 |
| ogra_ | the only thing that works is to remove everything and re-install snapd afterwards ... then core will be the default | 14:41 |
| ogra_ | but that would make you lose all existing snaps | 14:41 |
| Kaleo | not great | 14:41 |
| mhall119 | sergiusens: does the latest snapcraft in xenial support hooks? | 14:42 |
| cjwatson | longsleep: can you retry register-key? should work for you now thanks to nessita | 14:52 |
| nessita | \o/ | 14:52 |
| * cjwatson repurposes https://bugs.launchpad.net/software-center-agent/+bug/1652302 for this | 14:54 | |
| mup | Bug #1652302: Unhelpful error from AccountKeyHandler if account assertion does not exist <Software Center Agent:New> <https://launchpad.net/bugs/1652302> | 14:54 |
| Kaleo | ogra_, ever seen that? http://pastebin.ubuntu.com/23776495/ | 14:54 |
| zyga | ogra_: yes | 14:55 |
| zyga | ogra_: blame linker | 14:55 |
| * ogra_ blames linker | 14:56 | |
| ogra_ | Kaleo, hmm, nope | 14:57 |
| ogra_ | (specifically the french :P ) | 14:57 |
| ogra_ | Kaleo, did you manually tinker with it ? | 14:58 |
| Kaleo | ogra_, nah, and I'm starting to figure that it has to do with plugs being defined | 14:58 |
| ogra_ | or slots you dont have for the plugs ... yeah | 14:59 |
| Kaleo | ogra_, the classic environment has slots? | 15:01 |
| ogra_ | dunno, i'm just learning about it too | 15:01 |
| * ogra_ hasnt used classic yet ... just starting to look at it for the classic mode | 15:02 | |
| Kaleo | ogra_, I had to remove network, network-bind, and platform | 15:03 |
| Kaleo | ogra_, https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1655369 | 15:08 |
| mup | Bug #1655369: cannot use the platform plug with a snap in 'classic' confinement <snapd (Ubuntu):New> <https://launchpad.net/bugs/1655369> | 15:08 |
| ogra_ | Kaleo, that might be on purpose though | 15:08 |
| Kaleo | ogra_, perhaps | 15:08 |
| Kaleo | ogra_, I was excited to use classic confinement for the terminal :) | 15:09 |
| ogra_ | well, it will be pretty much like a deb as i understand it | 15:09 |
| ogra_ | but only in context with core, not with other snaps | 15:09 |
| pmcgowan | Kaleo, although classic is supposed to be short term solution I thought? | 15:10 |
| Kaleo | pmcgowan, no idea | 15:10 |
| zyga | jdstrand: hey | 15:20 |
| zyga | jdstrand: do you have a moment | 15:20 |
| jdstrand | zyga: hey, what's up? | 15:20 |
| zyga | jdstrand: remember when we talked about new style interfaces | 15:21 |
| zyga | jdstrand: well, they are happening | 15:21 |
| zyga | jdstrand: I wanted to show you how things look like now | 15:21 |
| zyga | jdstrand: I didn't get a review from gustavo yet so take it with a pinch of salt | 15:21 |
| zyga | (perhaps some go-ness can be made nicer) | 15:21 |
| mup | Bug #1655376 opened: Add support for android/touch type images <personal> <Snappy:New for ogra> <https://launchpad.net/bugs/1655376> | 15:21 |
| zyga | jdstrand: I ported mount backend and the content interface over | 15:21 |
| jdstrand | zyga: can you add something simple, like 'network' too? if you give me the PR then I can take a look | 15:23 |
| jdstrand | likely today, possibly tomorrow | 15:23 |
| zyga | jdstrand: not before gustavo acks the design | 15:23 |
| zyga | jdstrand: network would require me to do apparmor which is by far the most complex one | 15:23 |
| longsleep | cjwatson, nessita: yay thanks a lot - confirmed working! | 15:25 |
| ogra_ | yay | 15:26 |
| jdstrand | zyga: can you show me what you are asking Gustavo to review? | 15:26 |
| zyga | jdstrand: yup, just a second | 15:26 |
| cjwatson | longsleep: \o/ | 15:26 |
| cjwatson | pedronis: ^- | 15:26 |
| longsleep | \o/ | 15:26 |
| pedronis | cjwatson: thanks | 15:26 |
| mup | PR snapd#2598 opened: snap-confine: allow snap-confine to re-exec too <Created by mvo5> <https://github.com/snapcore/snapd/pull/2598> | 15:45 |
| === Guest31134 is now known as mac_nibblet | ||
| mup | PR snapd#2599 opened: interfaces: add new-style interfaces <Created by zyga> <https://github.com/snapcore/snapd/pull/2599> | 16:03 |
| zyga | jdstrand: ^^ | 16:06 |
| zyga | jdstrand: that thing | 16:06 |
| zyga | jdstrand: note that this is just a proposal | 16:06 |
| * jdstrand nods | 16:06 | |
| * jdstrand adds to list | 16:06 | |
| zyga | jdstrand: so both the implementation and design are just an example | 16:06 |
| jdstrand | thanks | 16:06 |
| stokachu | anyone know what this means: | 16:12 |
| stokachu | [adam:~/Code/conjure-up/snapcraft] master(+15/-23) ± sudo snap install ./conjure-up_2.1.0_amd64.snap | 16:12 |
| stokachu | error: cannot find signatures with metadata for snap "./conjure-up_2.1.0_amd64.snap" | 16:12 |
| zyga | stokachu: you are installing a snap but snapd knows nothing about it | 16:12 |
| zyga | stokachu: try --dangerous | 16:12 |
| stokachu | ok | 16:12 |
| stokachu | zyga, thanks that worked | 16:13 |
| zyga | stokachu: I assume you are hacking on this snap | 16:13 |
| zyga | stokachu: normally this should never happen | 16:13 |
| stokachu | yea i want to update it in the store | 16:13 |
| stokachu | once i work out some kinks | 16:13 |
| zyga | stokachu: and assertions are coming from the store :) | 16:13 |
| stokachu | zyga, nice, i haven't gotten there yet | 16:14 |
| stokachu | ran into this again though http://paste.ubuntu.com/23776803/ | 16:15 |
| stokachu | i dont remember what i did awhile ago to get around it | 16:15 |
| zyga | mmm, no idea :/ | 16:16 |
| zyga | maybe set locale to C.UTF-8 | 16:16 |
| zyga | all snaps should have that | 16:16 |
| stokachu | ok | 16:16 |
| mup | PR snapd#2598 closed: snap-confine: allow snap-confine to re-exec too <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2598> | 16:19 |
| popey | sergiusens: bug 1654721 is odd. It doesn't seem to copy to populate the build dir at all.. | 16:23 |
| mup | Bug #1654721: build directory empty with rust plugin <Snapcraft:Incomplete by sergiusens> <https://launchpad.net/bugs/1654721> | 16:23 |
| mup | Bug #1655394 opened: First snap install of a local snap with devmode doesn't actually use devmode <Snappy:New> <https://launchpad.net/bugs/1655394> | 16:24 |
| nuclearbob | how do I add a new user on ubuntu core? adduser fails when trying to create a group | 16:25 |
| mup | PR snapd#2600 opened: tests: remove the snapd dirs last (should fix error on ppc64el) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2600> | 16:36 |
| jdstrand | roadmr: hi! sorry, I have one more trivial fix (for iio and i2c path attribute) in the tools. can you pull r817? | 16:38 |
| roadmr | jdstrand: sure! I'm doing my best to rall all this out this week | 16:56 |
| roadmr | s/rall/roll/ | 16:56 |
| mup | Bug #1655394 changed: First snap install of a local snap with devmode doesn't actually use devmode <Snappy:Invalid> <https://launchpad.net/bugs/1655394> | 17:04 |
| === JanC_ is now known as JanC | ||
| mup | PR snapd#2601 opened: overlord, store: move confinement filtering to the overlord (from The Store) <Created by chipaca> <https://github.com/snapcore/snapd/pull/2601> | 17:42 |
| jdstrand | roadmr: cool, thanks! I don't have anything else planned. just fixing bugs as they come in :) | 18:32 |
| zyga | jdstrand: I pushed to the new-interfaces branch with 2nd backend converted | 19:21 |
| zyga | jdstrand: I have some (one) doubt left but I really love how this is progressing | 19:22 |
| zyga | jdstrand: I'll look for a way to do a stab at seccomp/apparmor tomorrow that would not require a tedious flag day | 19:22 |
| zyga | jdstrand: I want to be sure that what I did can model per-app/hook interfaces | 19:22 |
| jdstrand | zyga: ack | 19:48 |
| pmcgowan | zyga, jdstrand where can I read about install hooks | 19:48 |
| jdstrand | pmcgowan: I didn't implement these and haven't used them myself. https://github.com/snapcore/snapd/wiki/Snap-format#hooks is supposed to document it, but it says TODO. I don't know if install hooks have been implemented yet (I know the configure hook is implemented). I'll point you at kyrofa | 19:51 |
| jdstrand | I'm not sure if kyrofa is doing anything with install hooks, but he implemented configure hooks | 19:51 |
| pmcgowan | jdstrand, maybe configure would do | 19:51 |
| pmcgowan | when does it run? | 19:51 |
| kyrofa | jdstrand, pmcgowan an install hook has been nixed, at least for now, since configure runs at all the times necessary | 19:52 |
| pmcgowan | kyrofa, great then need ptr to docs | 19:52 |
| kyrofa | pmcgowan, https://github.com/snapcore/snapd/wiki/hooks still seems to say that `configure` only runs with snap set, so it looks like it hasn't been updated in a while | 19:53 |
| kyrofa | pmcgowan, but I can walk you through it, if you like | 19:54 |
| pmcgowan | kyrofa, I am looking for a way to conditionally set an export | 19:54 |
| kyrofa | pmcgowan, an export == environment variable? | 19:55 |
| kyrofa | pmcgowan, what is the condition? | 19:55 |
| pmcgowan | yes | 19:55 |
| pmcgowan | we want to tell qtubuntu what environment it is in | 19:55 |
| pmcgowan | and set its backend | 19:56 |
| kyrofa | (jdstrand, I'm back on snapcraft nowadays, but hooks haven't changed too much since I was involved) | 19:56 |
| pmcgowan | probably based on which snaps are on the system | 19:56 |
| pmcgowan | kyrofa, for exmaple, I am either in a kiosk tye environment with just mir or a full personal with unity8 | 19:57 |
| jdstrand | kyrofa: thanks. I came to you cause of the docs. it seems that there are some issues with the wiki. let me try to fix them since that page isn't in the TOC | 19:57 |
| kyrofa | pmcgowan, does the snap in question have permission to list the snaps installed, first of all? | 19:57 |
| pmcgowan | kyrofa, prolly not | 19:57 |
| kyrofa | jdstrand, yeah, not sure what the deal is there | 19:57 |
| kyrofa | jdstrand, I wrote that hooks doc before the wiki existed | 19:57 |
| kyrofa | pmcgowan, so the first thing we need to figure out is how to determine this | 19:58 |
| kyrofa | pmcgowan, if you need to change the environment somehow, can I assume you've got content sharing going on? | 19:58 |
| kyrofa | pmcgowan, can you determine what you need to determine using that? | 19:58 |
| pmcgowan | kyrofa, could do that | 19:59 |
| pmcgowan | hmm | 19:59 |
| kyrofa | See if there are contents in this directory, or crawl it if necessary | 19:59 |
| pmcgowan | kyrofa, right and if its not there then I default otherwise set the export | 19:59 |
| kyrofa | Exactly. Think that'll work? | 20:00 |
| pmcgowan | think so | 20:00 |
| kyrofa | Okay let's go with that for now | 20:00 |
| pmcgowan | I still want to lean about configure hooks :) | 20:00 |
| jdstrand | kyrofa: ok https://github.com/snapcore/snapd/wiki/Snap-format is in the TOC and lists https://github.com/snapcore/snapd/wiki/Snap-format#hooks. I updated https://github.com/snapcore/snapd/wiki/Snap-format#hooks to refer to https://github.com/snapcore/snapd/wiki/hooks | 20:00 |
| kyrofa | pmcgowan, so now the question is: are you sure this is something you only want to determine at install time? | 20:01 |
| kyrofa | pmcgowan, because interfaces can be disconnected | 20:01 |
| pmcgowan | kyrofa, in this case I think checking at runtime is ok | 20:02 |
| kyrofa | pmcgowan, you might consider putting such a check in the app itself | 20:02 |
| kyrofa | Yeah, okay | 20:02 |
| kyrofa | So it sounds like your problem can be solved outside of hooks? I'm of course happy to show you hooks anyway | 20:02 |
| pmcgowan | I am interested, you implied configure hooks run at other times? | 20:02 |
| kyrofa | pmcgowan, indeed, this might be helpful: https://kyrofa.com/posts/snap-updates-automatic-rollbacks | 20:04 |
| kyrofa | pmcgowan, the configure hook runs at install time, upon upgrades, and of course with `snap set` (to change the configuration) | 20:04 |
| pmcgowan | gotcha | 20:05 |
| kyrofa | pmcgowan, the difficulty comes when trying to determine why the hook is running | 20:06 |
| kyrofa | Which is why I'd still like standalone install/upgrade hooks, but I digress | 20:06 |
| pmcgowan | kyrofa, ok I think I grok it, not sure that works in this case though | 20:07 |
| pmcgowan | as the hook wont be able to figure things out | 20:07 |
| kyrofa | Well it would, but then it would have to have some way to tell apps what it learned | 20:08 |
| kyrofa | In which case... you might as well just have the apps figure it out | 20:08 |
| kyrofa | Especially considering that the outcome depends upon interfaces which can be disconnected/connected at any time | 20:09 |
| pmcgowan | kyrofa, does a snap know if an interface is connected? | 20:14 |
| kyrofa | pmcgowan, not right now, though last I heard there was ongoing work on interface hooks (i.e. run this hook when the interface is connected, that one when it's disconnected, etc.) | 20:15 |
| pmcgowan | right | 20:15 |
| pmcgowan | ok we already have a content interface here which will be there or not so still think I am set | 20:16 |
| pmcgowan | hmm kyrofa is the content iterface available to the wraper script that runs the app? | 20:16 |
| mwhudson | hello | 20:19 |
| mwhudson | can you build classic confinement snaps on launchpad? | 20:19 |
| kyrofa | pmcgowan, you mean is the shared content bind-mounted by the time the wrapper runs? | 20:21 |
| kyrofa | pmcgowan, as long as the wrapper is called by something exported in the YAML as an app, yes | 20:21 |
| kyrofa | (or if it's an app itself) | 20:21 |
| pmcgowan | ok cool | 20:21 |
| kyrofa | pmcgowan, ignoring bug #1645731, of course | 20:22 |
| mup | Bug #1645731: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:Confirmed for zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731> | 20:22 |
| kyrofa | mwhudson, I assume so-- are you running into issues? | 20:23 |
| pmcgowan | kyrofa, yeah like to get that fixed | 20:24 |
| pmcgowan | bites me always | 20:24 |
| kyrofa | pmcgowan, same here, every time | 20:24 |
| mwhudson | kyrofa: yeah, i get the message from bug 1650946 | 20:24 |
| 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> | 20:24 |
| kyrofa | pmcgowan, I haven't been able to recommend it to anyone as a result | 20:24 |
| mwhudson | per https://launchpadlibrarian.net/301869726/buildlog_snap_ubuntu_xenial_amd64_go-17-mwhudson_BUILDING.txt.gz | 20:24 |
| kyrofa | mwhudson, oh interesting-- they must have ubuntu-core installed instead of core? | 20:25 |
| mwhudson | kyrofa: apparently i need the core snap to be installed while building but i don't know how to do that | 20:25 |
| mwhudson | kyrofa: oh, so maybe it's a lp-side problem? | 20:25 |
| kyrofa | mwhudson, oh wait-- they probably don't have _any_ snaps, eh? | 20:26 |
| kyrofa | mwhudson, yeah, they need the core snap | 20:26 |
| mwhudson | kyrofa: i don't really see why they would | 20:26 |
| mwhudson | cjwatson: hey, if you're around, do you know anything about building classic confinement snaps on launchpad? | 20:28 |
| mwhudson | cjwatson: it seems they need the core snap to be installed | 20:28 |
| mwhudson | kyrofa: there's no way for a snap to depend on snaps for building? | 20:29 |
| kyrofa | mwhudson, not in snapcraft anyway | 20:30 |
| mwhudson | hm | 20:32 |
| mwhudson | hard to believe i'm the first person to try this... | 20:32 |
| kyrofa | mwhudson, to be fair, it was just released | 20:33 |
| mwhudson | true | 20:33 |
| kyrofa | And I'm not sure how many people use LP just yet | 20:33 |
| cjwatson | mwhudson: even at build time? anyway, I know nothing | 20:53 |
| kyrofa | cjwatson, mwhudson I sent out an email involving concerned parties | 21:09 |
| cjwatson | feel free to try to fix it in launchpad-buildd if you get to it before me | 21:10 |
| cjwatson | assuming that it's even possible to do in a chroot | 21:10 |
| kyrofa | cjwatson, ooo, that might be problematic indeed | 21:11 |
| cjwatson | all builds happen in a chroot | 21:11 |
| kyrofa | cjwatson, I haven't tried snaps in a chroot before, but I'd be willing to bet they don't work | 21:11 |
| kyrofa | jdstrand, do you know anything about snaps in a chroot? | 21:14 |
| mwhudson | ah yeah i bet that's fun | 21:15 |
| mwhudson | iirc it only reads something fairly simple out of the core snap, maybe we can just hard code that on ubuntu | 21:15 |
| mwhudson | er | 21:15 |
| mwhudson | on launchpad | 21:15 |
| kyrofa | mwhudson, or snapcraft could just download it and use what it needs out of it, like building a kernel | 21:16 |
| mwhudson | oh eh | 21:17 |
| mwhudson | it's not very simple | 21:17 |
| mwhudson | but pedantically i don't think it needs the core snap to be installed | 21:18 |
| mwhudson | just present on disk | 21:18 |
| kyrofa | Agreed | 21:18 |
| cjwatson | where's the code that uses it? | 21:18 |
| mwhudson | i.e. you could download it and unsquashfs it to /snap/core/current | 21:18 |
| kyrofa | cjwatson, https://github.com/snapcore/snapcraft/blob/master/snapcraft/_options.py#L170 | 21:19 |
| mwhudson | cjwatson: https://github.com/snapcore/snapcraft/blob/master/snapcraft/internal/project_loader.py#L328-L349 | 21:19 |
| cjwatson | right, so quite a few things | 21:20 |
| cjwatson | and conceivably more as time goes on | 21:20 |
| kyrofa | Possibly | 21:21 |
| mwhudson | hmm | 21:21 |
| mwhudson | this also points to the fact that classic confinement isn't quite working for the thing i am snapping :) | 21:21 |
| mwhudson | (go) | 21:21 |
| mwhudson | $ readelf -d /snap/go-17-mwhudson/current/bin/go | grep -e 'RPATH|RUNPATH' | 21:22 |
| mwhudson | -> nothing | 21:22 |
| mwhudson | also the interpreter is the host one, etc | 21:23 |
| jdstrand | kyrofa: snaps in a chroot? depending on what you are asking, I suspect there will be a number of policy issues | 21:24 |
| cjwatson | if anyone wants to find out if it works in a chroot, you could try using https://jujucharms.com/u/launchpad/launchpad-buildd/ (you need to log in to see that, for some reason) | 21:24 |
| cjwatson | jdstrand: just installing the core snap | 21:25 |
| cjwatson | we don't actually use that charm in production as such, but it's a quick way to run up a builder node for testing | 21:25 |
| cjwatson | if you're using the lxd provider then you also get to test whether it works with snap in chroot in lxd :-) | 21:26 |
| jdstrand | I suspect that there are going to be quite a few issues for snap-confine and running snaps. snapd itself might start | 21:26 |
| cjwatson | jdstrand: it doesn't really have to run anything meaningful, just put the files in /snap/core/current/ | 21:26 |
| cjwatson | we could do that by hand as suggested above, but I'd really prefer not to have to reimplement the acquisition code by hand | 21:27 |
| jdstrand | ok, I am missing a lot of context | 21:27 |
| * jdstrand tries to read backscroll | 21:27 | |
| mwhudson | if i tried to upload a snap to the store that contained binaries that did not use the right elf interpreter, would something shout at me about it? | 21:27 |
| kyrofa | mwhudson, I doubt it | 21:27 |
| mwhudson | kyrofa: sadface | 21:28 |
| cjwatson | jdstrand: tl;dr: in order to build classic snaps on LP, the core snap has to be installed so that snapcraft can poke about in /snap/core/current/ at build time. All LP builds (snap or not) take place in a chroot | 21:28 |
| cjwatson | the base system outside the chroot is guaranteed to be at least xenial, but will not necessarily match the release of the chroot | 21:28 |
| mwhudson | kyrofa: actually i guess it's only classic snaps that need this check | 21:28 |
| kyrofa | mwhudson, indeed | 21:28 |
| jdstrand | cjwatson: if snapcraft only needs the files, then an unsquashfs in the right place (or a mount) should work fine | 21:30 |
| cjwatson | jdstrand: will "snap install core" work? | 21:30 |
| jdstrand | maybe? | 21:30 |
| cjwatson | heh | 21:30 |
| cjwatson | of course snap install has its own issues in this context | 21:31 |
| cjwatson | we'd have to clean up at the end of the build | 21:31 |
| jdstrand | I mean, snapd needs to be running. it isn't confined. installing core won't trigger snap-confine or anything | 21:31 |
| kyrofa | cjwatson, you don't just toast the chroot? | 21:31 |
| cjwatson | kyrofa: we do, but we have to unmount everything inside it first which snapd might not totally like | 21:31 |
| euodeionomedeusu | hello, world! | 21:31 |
| kyrofa | Ah, sure | 21:31 |
| cjwatson | jdstrand: running ... inside the chroot or outside? | 21:31 |
| jdstrand | so snapd might start in the chroot. snapd is usually started via systemd | 21:31 |
| jdstrand | inside | 21:32 |
| cjwatson | will snap do that on demand or do we need to do it separately? | 21:32 |
| cjwatson | also that implies we need to make sure it stops, which is also possibly a little complex | 21:32 |
| kyrofa | cjwatson, it's socket activated | 21:32 |
| cjwatson | kyrofa: that won't help, systemd will be listening to the socket outside the chroot | 21:32 |
| kyrofa | Hmm, indeed | 21:32 |
| jdstrand | you might be able to just start it manually (but again, yeah, you'd have to start it | 21:33 |
| cjwatson | maybe a manual mount would be easier than all that | 21:33 |
| jdstrand | if you were going to do a start and stop command, you might just do an unsquashfs and rm command | 21:33 |
| cjwatson | "snap download core" into a tmpdir, mount core_*.snap /snap/core/current | 21:33 |
| cjwatson | we already clean up mounts | 21:33 |
| jdstrand | or that | 21:33 |
| kyrofa | Alright I'll update the email thread so sergio knows where it stands, we'll make this work one way or another | 21:34 |
| kyrofa | Sorry for the wall mwhudson :) | 21:34 |
| cjwatson | oh, "snap download core" will require snapd to be running, right? | 21:35 |
| kyrofa | cjwatson, yeah, but snapcraft has code to talk to the store too | 21:35 |
| cjwatson | does it have a download command? | 21:35 |
| cjwatson | I don't see one | 21:35 |
| mwhudson | kyrofa: it's ok, i can ignore hundreds of emails a day :) | 21:35 |
| kyrofa | cjwatson, oh, do you think the ideal fix is in the builder? | 21:36 |
| kyrofa | cjwatson, I was thinking snapcraft needed to do this | 21:36 |
| cjwatson | hmm | 21:36 |
| cjwatson | so I won't be sad if snapcraft does it, but I wasn't sure you'd be up for the "snapd can't be assumed to be running" constraint | 21:37 |
| kyrofa | cjwatson, although now that I think about it, I don't think it's using anonymous access | 21:37 |
| kyrofa | cjwatson, yeah I think that's okay, but sergio will know better | 21:38 |
| cjwatson | and presumably if snapd *is* running then you don't want to just go mounting stuff under its feet | 21:38 |
| cjwatson | also, anonymous access raises another question, did we ever actually settle on "core snap will never require authentication to download"? | 21:38 |
| kyrofa | cjwatson, great question, and I suspect not | 21:38 |
| cjwatson | I was pushing for that but I have a vague memory that I may have lost | 21:38 |
| kyrofa | cjwatson, me too, but I lost track of the discussion | 21:38 |
| cjwatson | so um that would be really sad for builders | 21:39 |
| kyrofa | Hmm... | 21:39 |
| kyrofa | All of the people who know are likely at the sprint :P | 21:39 |
| cjwatson | quite | 21:39 |
| cjwatson | OTOH this is a great argument for the core snap not to require auth :P | 21:40 |
| kyrofa | Hahaha | 21:41 |
| cjwatson | and it's easy to imagine that we might end up needing some other snaps for classic builds - something to do with build-dependencies perhaps? | 21:42 |
| kyrofa | cjwatson, yeah, I'm not quite up to speed on the classic snap stuff | 21:44 |
| kyrofa | Hmm... looking closer at how snapcraft uses it, it seems it would indeed have to be mounted to /snap/core, since it injects rpaths | 21:48 |
| kyrofa | Which makes me waffle a little on snapcraft doing it, since in most scenarios it wouldn't have permission | 21:48 |
| kyrofa | Yuck. | 21:49 |
| mwhudson | i don't suppose anyone would like to do the rpath injection by providing wrappers for gcc/ld rather than environment variables? :) | 21:50 |
| mwhudson | bash quoting is eating my head | 21:51 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!