#snappy 2016-03-07
<dholbach> good morning
<didrocks> good morning dholbach :)
<dholbach> salut didrocks
<sergiusens> ogra_, hey do you know what vmlinuz-4.2.0-2014-generic-dragon410c is?
<noizer> Good morning
<ysionneau> morning !
<sergiusens> ricmm, http://paste.ubuntu.com/15319880/
<noizer> zyga-phone Hi is the update done for the interfaces etc?
<noizer> zyga-phone Hi is the update done for the interfaces etc?
<zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/591/files
<zyga-phone> noise][1: hey, no, we haven't released yet AFAIK, I will see what the state of the stack is and then we'll probably release
<zyga-phone> noise][1: but it is certainly on our plan today
<noizer> zyga-phone: ok :D
<mvo> ogra_: will you be able to test my new uploads of the os and kernel snaps for arm64? I uploaded to rolling/edge
<mvo> ogra_: i.e. if it boots :)
 * zyga-phone can test as well
<zyga-phone> mvo: on dragon
<mvo> zyga-phone: yes, updating to them is enough, so sed /channel: stable/channel: edge/ might be the easiest way (in /var/lib/snappy/meta/*.manifest
<zyga-phone> k, one sec
<mvo> zyga-phone: no problem, the review task is still running so its not published yet anyway
<zyga-phone> did the sed
<zyga-phone> rebooting to see if snappy picks it up
<zyga-phone> mvo: that didn't make snappy see any updates, am I missing something?
<zyga-phone> all the *.manifest files say channel: edge
<zyga-phone> canonical-dragon       2016-02-12 0.7.1                         canonical
<zyga-phone> canonical-dragon-linux 2016-02-19 4.2.0-2014-generic-dragon410c canonical
<zyga-phone> mvo: ^^
<ricmm> ppisati: hey
<ppisati> ricmm: hey
<ricmm> having some pain here
<ppisati> ricmm: ???
<ricmm> ppisati: how do I fire off a build for your ubuntu kernel tree for 96b?
<ppisati> ricmm: hold on
<mvo> zyga-phone: its now updated
<zyga-phone> mvo: still nothing?
<ppisati> ricmm: export ARCH=arm64; export $(dpkg-architecture -aarm64); export CROSS_COMPILE=aarch64-linux-gnu-
<mvo> zyga-phone: in /edge ?
<ppisati> ricmm: if you are trying to build the 4.2.0 dragon410c branch:
<zyga-phone> mvo: I did the sed, in /var/lib/snappy/meta, anything else I should change?
<zyga-phone> (and I rebooted to reset snapd memory state)
<ppisati> ricmm: fdrc && debian/rules build && fdr binary-generic-dragon410c
<ppisati> ricmm: if you are trying to build the 4.4 snapdragon/96boards tree:
<ppisati> ricmm: fdrc && debian/rules build && fdr binary-[snapdragon|96boards]
<mvo> zyga-phone: I investigate
<ppisati> ricmm: fdr = fakeroot debian/rules / fdc = fdr clean
<ricmm> ppisati: thanks
<ricmm> ppisati: just to confirm, for arm64 your scripts still copy to vmlinuz right
<ricmm> even tho its not really compressing
<ppisati> ricmm: yes, it creates the vmlinuz image file
<ricmm> ok
<ricmm> slightly misleading to have vmlinuz if its not compressed
<ricmm> but unrelated to today anyways
<ricmm> ppisati: how about getting the tree in a state where I can issue a final make command
<ricmm> as if it was a normal tree
<ricmm> as-in get the right config built, then CROSS_COMPILE, ARCH, make Image
<ricmm> can I do that starting with an ubuntu source package tree?
<ppisati> ricmm: when i need to do that, i issue:
<ppisati> ricmm: fdr prepare-[generirc-dragon410c|snapdragon|96boards]; cp debian/build/build-.../.config .; make ...
<ppisati> ricmm: what are you doing over there? why are you compiling kernels?
<ricmm> im with sergio, we are looking at the kernel plugin
<mvo> ogra_: is your script to build the arm64 kernel snap somewhere?
<ricmm> mvo: last I asked him that question he said he uses your script
<ricmm> so probably you are the answer
<ricmm> ppisati: make: *** No rule to make target 'prepare-generic-96boards'. Stop.
<ppisati> ricmm: oh, that tree was renamed
<ppisati> ricmm: fdr prepare-96boards
<ricmm> im at the tip of your x-96boards branch
<sergiusens> ricmm, hey
<ysionneau> funny that snappy list tells me to reboot to use ubuntu-core-xxxx-13 but if I do ls -l /writable/system-data/snaps/ubuntu-core.canonical/
<ysionneau> then current already points to -13 and not -12
<mvo> ricmm: I wonder where he gets the kernel from, but I will talk to him once he is around
<ricmm> mvo: for which device?
<ricmm> short answer is ubuntu packages
<mvo> ricmm: the dragonboard
<ricmm> paolo's ppa
<mvo> ta
<ogra_> mvo, will test ... and what ricmm said, i use your script with a lot of manual dpkg -x'ing and a depmod call
<ogra_> i'll trun that into proper code (to merge it into livecd-rootfs)
<mvo> ogra_: aha, ok. I had hoped to upload a new kernel, but there are manual steps I leave it to you :)
<ogra_> ok
<ogra_> ricmm, note that you need the patched devicetree file when usinh ppisati's build ...
<ogra_> there is one called -touch ...
<ogra_> err
<ogra_> sorry
<ogra_> -snappy
<noizer> Hi, I have a question about daemons in snappy. Is it possible to set a variable so the daemon don't start at startup?
<zyga-phone> not at present; I don't think this is something you can do
<zyga-phone> noizer: what's the use case?
<noizer> zyga-phone A service needed only running when they tabbing on something. But first i tought i will do that with starting an other snap(execute a wrapper from an other snap) but that isn't possible but starting a service is possible out of the REST API
<noizer> Sorry for service but its a bacground app I mean
<ricmm> ogra_: about that manual depmod, did you have more info on that somewhere?
<ricmm> 2.6G of modules is intense ;)
<noizer> zyga-phone So at this moment a daemon will always start at startup?
<ricmm> ppisati: lots of modules build automatically :(
<ppisati> ricmm: we build as many modules as possible
<zyga-phone> noizer: yes
<noizer> hmmm ok
<ricmm> ppisati: sure, how do we then select which ones to package?
<ricmm> I'm assuming this is the depmod magic that ogra is talking about
<ogra_>  depmod -ea -F unpack-19022016/boot/System.map-4.2.0-2014-generic-dragon410c -b xenial-chroot/snap/ 4.2.0-2014-generic-dragon410c
<ogra_> that's from my shell history
<ogra_> for the last build
<ogra_> -F is the part to System.map, -b is your target dir
<ogra_> s/part/path
<ogra_> instead of -a you can also give a list of .ko files
<ogra_> (at the end of the line then)
<ricmm> ogra_: thanks
<ogra_> ricmm, the depmod "magic" is only to create the modules.dep files, nothing more ... else modprobe wouldnt work
<ogra_> it doesnt make any selection about what gets installed
<ricmm> ok, and in your snap what are you making about the 2.6G of modules?
<ogra_> i dont have 2.6G of modules
<ogra_> :)
<ogra_> i use the binary deb and unpack it ...
<ricmm> right, so maybe a q for paolo
<ricmm> ppisati: I see 2.6G of modules if I build manually, but only 400MB in the package
<ogra_> linux-image-* is 52MB big (the deb(
<ogra_> unless ppisati invented an awesome new comoression method and will get very rich with that i guess you are building to much or counting it wrong :)
<ogra_> *compression
<ogra_> 400MB ? thats cerazy
<ricmm> ok, 200
<ricmm> ;)
<ppisati> -rw-r--r-- 1 ppisati ppisati 55214720 Mar  1 10:18 linux-image-4.4.0-1012-96boards_4.4.0-1012.12_arm64.deb
<ogra_> mvo, i was wondering if we should not consider to mount the vfat not async anymore and instead make a few sync calls in the code that copies the kernel in place
<ogra_> mvo, my last dragonboard update took ages
<ogra_> from the uboot env POV we should be fine
<ogra_> and mounting sync wont gain us much for kernel and initrd copying
<ogra_> (weather it gets corrupt while doing a sync call with power loss or while syncing due to the mount option doesnt really matter(
<mvo> ogra_: yeah, +1
<noizer> I try to make a socket but I gets always a permission error. this are my skill that I uses: uses:
<noizer>   listener:
<noizer>     type : migration-skill
<noizer>     caps:
<noizer>        - network-client
<noizer>        - network-listener
<mvo> ogra_: just go ahead and change it
<noizer> Somebody nows more about it?
<ogra_> mvo, great, will do
<mvo> ta
<mvo> ogra_: do you happen to have any idea why only two amd64 builders are online right now?
<ogra_> nops
<ogra_> i guess thats a colin/adam question
 * ogra_ bets doko has eaten them ;)
<mvo> I go and ask on #launchpad
<mvo> thanks
<ogra_> mvo, hmm, what about the efi dir, that is currently also mounted with "sync"
<ogra_> (not sure if firmware requires that)
<mvo> ogra_: its the same filesystem/partiton iirc . I don't think we actually write anything to it
<mvo> ogra_: we just need it for the efi binaries
<ogra_> well, its a different code path, thats why i ask
 * ogra_ switches it to "defaults" from "sync" as well
<mvo> yeah, lets do it and see what breaks
<zyga-phone> noizer: s/type: migration-skill/interface: old-security/
<noizer> zyga-phone snapcraft doesn't support it for now so I wait for today so that i can have a new snapcraft
<zyga-phone> noizer: yeah, I know :-(
<noizer> zyga-phone I want it so bad xD
<zyga-phone> noizer: we're working on a release, you just have to wait a little longer
<noizer> zyga-phone what is a little longer?
<zyga-phone> noizer: we still plan to release today
<zyga-phone> noizer: no further ETA
<noizer> zyga-phone owkay
<ppisati> ricmm: if you want to put your kernel/modules on diet , turn off this option in the .config
<ogra_> mvo, hmm, i see you tried to upload a 4.4 dragonboard kernel to the store, where does that come from ? i see no deb anywhere for it
<ppisati> ricmm: CONFIG_DEBUG_INFO=y
<ppisati> ricmm: to # CONFIG_DEBUG_INFO is disabled
<mvo> ogra_: its the generic arm64 kernel, but I removed that version from the publishing history
<ppisati> ricmm: this will greatly reduce the size of kernel / modules.ko
<ogra_> ah, k
<ogra_> mvo,  what makes you think that would boot ? :)
<mvo> ogra_: hopeless optimism ;)
<ogra_> haha
<mvo> ogra_: but seriously, after uploading I remembered it would probably not work and immediately removed it from the channels
<ogra_> ppisati, do we have any newerr dragonboard kernel than your linux-dragon410c - 4.2.0-2014.14  yet ?
<mvo> ogra_: I need to test the beaglebone though, that should work with the stock kernel
<ogra_> i know you were working on something 4.4ish
<ogra_> mvo, yeah
<ogra_> GRRRR !
<ogra_> Installing ubuntu-core.canonical_16.04.0-9.arm64_arm64.snap
<ogra_> WARNING: could not unmap partitions
<ogra_> WARNING: unexpected issue: remove /tmp/diskimage493904108/system/apps: read-only file system
<ogra_> ...
<ogra_> i wish u-d-f would still work on trusty
 * ogra_ goes and builds on a wily system 
<ricmm> ppisati: well im basically trying to replicate the module list from your kernel package
<Rinsan> Will Snappy Core support Raspberry PI 3?
<ogra_> Rinsan, at some point, yes
<ogra_> i was looking at that on the weekend, but it seems u-boot isnt fully there yet for the Pi3 ... and snappy needs u-boot
<Rinsan> ogra_, Ok thanks for the quick reply!
<ogra_> if thats ready i'll surely try to integrate it
<Rinsan> So it
<Rinsan> Sorry... cat :)
<ppisati> ricmm: by default our config has the debug info built-in, and then we strip the symbols out for the vanilla linux-image deb package
<ppisati> ricmm: this way from the same config we build debug version and (after stripping) the non debug version
<ppisati> ricmm: so either you keep the config as is, and then strip out the symbols
<ppisati> ricmm: or disable that option
<ogra_> ppisati, while we talk about options ... can we trun off that scary kernel message on boot about trace_printk()  ? http://paste.ubuntu.com/15320455/
<ogra_> doesnt really seem appropriate for release
<ppisati> ogra_: i agree, last week i tried to disable that but i couldn't figure out
<ogra_> ah, k
<ppisati> ogra_: like, even turning off that debug option the message was still there
<ppisati> ogra_: but yeah, i'll turn it off
<ppisati> ogra_: about 4.4
<ppisati> ogra_: i have two trees
<ogra_> but only one deb :)
<ppisati> ogra_: one is the qualcomm-only and the other is the merged qualcomm+hikey
<ppisati> ogra_: hold on
<ysionneau> This means syscall number 289 has been called? http://pastebin.com/uE4tGQCA
<ogra_> ysionneau, exactly
<ysionneau> not sure how to know which one it is
<ysionneau> I'm browsing the kernel sources ...
<ogra_> ysionneau, scmp_sys_resolver 289
<ppisati> ogra_: https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+files/linux-image-4.4.0-1006-snapdragon_4.4.0-1006.6_arm64.deb
<ogra_> that prints the name
<ppisati> ogra_: it's a couple of weeks old, i'm waiting for qualcomm to announce their support period for that kernel this week @ connect
<ogra_> ppisati, ah, thanks ... do you think thats stable enough to switch to it ?
<ysionneau> nice! it's send()
<ysionneau> thx
<ppisati> ogra_: it's stable, but don't switcj until we hit the archive
<ogra_> ok
<ysionneau> send is forbidden by default?
<ogra_> you need the network-client "capability^Wskill^Wslot^Wplug"
<ysionneau> ahahah
<ogra_> or just "network" not sure ... try them out
<ysionneau> the name bikeshedding is going crazy
<ogra_> there are a few
<ysionneau> this really needs to be documented somewhere
<ogra_> it is in total flux ... but i think there are docs (dont as me where though)
<ysionneau> I'll try what Michael Vogt sent on march the 1st "snap.yaml skill->interface change"
<ysionneau> or maybe it's not yet effective
<ogra_> only half
<ogra_> slots and plugs have been flipped around
<ogra_> or was ist s/slots/sockets/ ?
<ogra_> "things"
<ogra_> :P
<ysionneau> yes and followed by emails about changing the names again
<ogra_> thats what i mean
<zyga-phone> ysionneau: it's not released, just wait for the release
<ogra_> there is a pending os snap (in testing atm) that should have the final implementations
<zyga-phone> ysionneau: all the docs have been updated but the bit relase is in the making
<ysionneau> if you have a link to all the security/caps/overrides stuff doc' :')
<ysionneau> please do share :)
<zyga-phone> ysionneau: we'll release public docs soon
<ysionneau> \o/
<ysionneau> lots of interesting documentation in here: https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md
<ysionneau> don't know if you are aware of that but snappy-debug.security crashes: http://pastebin.com/ekxwPREL
<ogra_> mvo, new os snap boots on arm64 ... i still see it trying to run grub migration (and fail), beyond that it seems fine
<mvo> ogra_: great, thanks!
<ogra_> mvo, any package in the sotre that i should try to make sure the changes work ?
<ogra_> *store
<ogra_> wow, gross ... so installing a package from the store succeeds, the services dont start though and there is no error message at all
<ogra_> Chipaca, ^^^ snappy install should really spill an error for that
<ogra_> (syslog is full of denials at least ... but there was no idication at all that anything failed when using snappy install)
<ogra_> mvo, i also still see bug 1543764
<ubottu> bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] https://launchpad.net/bugs/1543764
<ogra_> (i.e. no classic mode at all on arm64)
<mvo> ogra_: I know :(
<elopio> iahmad: I'm just seeing the meeting now. Are you guys still around?
<noizer> does somebody used seccomp filters before in snappy?
<ysionneau> any idea why I get this error message ? http://pastebin.com/LawTNuDi
<ysionneau> I'm using latest commit from master of snapcraft (github)
<jdstrand> zyga-phone: that's awesome
<jdstrand> zyga-phone: (https://github.com/ubuntu-core/snappy/pull/591/files)
<zyga-phone> jdstrand: I'll fan out with more of those later today, they should be easy to maintain for anyone on the security team
<jdstrand> zyga-phone: cool, thanks
<zyga-phone> jdstrand: I'll also move the base apparmor template
<zyga-phone> jdstrand: so that there's no dependency on the base security templates anywhere and it's all self-contained
<jdstrand> zyga-phone: sure-- I thought of another case where all of it in the go code is painful but I understand why you are doing it this way. I look forward to working through this after 16.04 some time
<zyga-phone> jdstrand: with all the bits in snappy we can at least consistently push new test snapd over, I know it's not like editing files manually but they are on squashfs anyway now
<zyga-phone> jdstrand: do you know my devtools scripts?
<iahmad> elopio, I have rescheduled it for later today, let me know if that works for you?
<elopio> iahmad: yes, it works. We can make it 30 minutes earlier also, so you don't stay so late.
<iahmad> elopio, ok, let me check with jibel
<iahmad> elopio, scheduled time is fine
<elopio> alright.
<ysionneau> hmm that does not sound right https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/common.py#L35
<ysionneau> what if you install by doing python3 setup.py develop --user
<ysionneau> ?
<ysionneau> then it will still try to fetch the schema from /usr/share/snapcraft
<ysionneau> even though it should look in the source dir
<jdstrand> mvo: http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/common.py#L39
<jdstrand> mvo: basically, the review tools, snapcraft (and now I learned) snappy build need to use the same options to mksquashfs otherwise the resquash test in the store will fail
 * jdstrand didn't realize snappy build was still around (that's fine, it's just I would have communicated this ooner)
<jdstrand> sooner*
<mvo> jdstrand: cool, fixing now
<jdstrand> thanks
<ysionneau> sorry I missed that: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/dirs.py#L30
<ysionneau> so there is no issue :p
<noizer> Hi is it possible to do some changes on the apparmor? in an app?
<mvo> jdstrand: I pushed a branch for --no-xattrs
<mvo> jdstrand: I can not do --all-root, this breaks the OS snap which has various files that are not owned by root
<mvo> jdstrand: like /var/mail
<jdstrand> mvo: can you do --all-root when 'type: app' or 'type: framework'?
<noizer> mvo what are the possibilities of changing the apparmor of your snap?
<mvo> jdstrand: yeah, that would be ok
<mvo> jdstrand: essentially !os -> all-root
<jdstrand> mvo: I think that sounds like a fine start
<jdstrand> this does mean I'll probably not be able to do a resquash test for the os snap though
<jdstrand> I think that is ok considering it will always come from a trusted source
<noizer> is snapcraft already updated?
<ogra_> kyrofa,   https://plus.google.com/+DrewFustini/posts/1Z5iPDsYaXy perhaps you might like to chime into the ROS discussion here
<zyga> ogra_: hey
<ogra_> yo
<zyga> ogra_: FYI, we're changing some stuff around ubuntu-core-launcher
<zyga> ogra_: I'll simplify it to take less arguments and just be smarter as to what it is doing
<ogra_> hmm
<zyga> ogra_: and I'm killing/changing some of the environment as well
<zyga> ogra_: all TMP* bits are now gone from the generated wrapper (the launcher handles that)
<ogra_> i havent seen any snap yet that actually used the launcher directly
<zyga> ogra_: I've dropped SNAP_FULLNAME
<zyga> ogra_: none of them do, it's just FYI
<ogra_> ah
<zyga> ogra_: and SNAP_ORIGIN becomes SNAP_DEVELOPER with actual developer bits inside
 * ogra_ has never used either :)
<ogra_> thanks for the info though :)
<enoch85> kyrofa: hey there
<enoch85> kyrofa: sorry, been busy the last weeks
<enoch85> kyrofa: I felt confident in your work, it felt like I was only slowing things down :)
<enoch85> kyrofa: anything I can help you with?
<zyga> jdstrand: hey
<zyga> jdstrand: aroudn?
<jdstrand> zyga: hey, I have a little time before my next meeting
<zyga> jdstrand: hey, I'm changing ubuntu-core-launcher a little
<zyga> jdstrand: I'll make it take just 'snap.[app]' + command to execute as input
<zyga> jdstrand: and derive all the security tokens from snap.[app]
<zyga> jdstrand: this affects aa profile, seccomp and the udev tag
<zyga> jdstrand: I wanted to let you know that this is happening
<zyga> jdstrand: also the launcher will change the name of the executable but that's less important
<zyga> jdstrand: (I mean that the launcher will be renamed, not that the launched application will think it got renamed)
<jdstrand> zyga: so, you are going to be touching the privileged part of the code then. this will also need changes to the systemd unit generation and the scripts generation
<jdstrand> zyga: how are you going to derive all security tokens from snap.[app]?
<zyga> jdstrand: I know, I'll handle both changes
<jdstrand> each command has a different profile and how will you determine the version?
<zyga> jdstrand: I plan to rename the aa profile to snap-$snapName.$appName
<zyga> jdstrand: we'll drop the version
<jdstrand> these are big changes
<zyga> jdstrand: various files will be hard-coded (location is /snappy/$snapName/current/ + $command
<jdstrand> have they been discussed anywhere else?
<zyga> jdstrand: we've just brainstormed this on telegram a little with niemeyer and Chipaca
<jdstrand> I wish I was part of that conversation
<niemeyer> jdstrand: Sorry, this has been talked about literally an hour ago
<niemeyer> jdstrand: I can provide the full background to it
<jdstrand> unfortunately this is a difficult day to participate in these conversations because I have a ton of meetings
<niemeyer> jdstrand: and this is still a strawman, so please don't feel like we have decided without you.. chipaca and mvogt haven't even seen that conversation yet, so these changes are being made in an attempt to improve the status quo, if it passes through reviews
<jdstrand> is there a doc or something I can look at/think about/respond to?
<jdstrand> I see
<jdstrand> it sounded more concrete a moment ago :)
<niemeyer> jdstrand: No, but I can either: a) Explain here; or b) Write an email and send to the list
<niemeyer> jdstrand: The proposal is concrete
<jdstrand> I don't mind changing stuff, I just want to understand why we are changing and the changes themselves
<niemeyer> jdstrand: But it's not done until we say so
<niemeyer> jdstrand: Okay, do you prefer a or b?
<niemeyer> To be clear, this is my proposal.. Chipaca hasn't seen it yet as it's too late there
<jdstrand> I am not going to have time for 'a' today. I will have time for 'a' tomorrow. I could even do a hangout
<jdstrand> if that doesn't work, 'b'
<jdstrand> maybe a hangout with the 5 of us?
<niemeyer> jdstrand: Ok, let me shoot an email to the list first then, since people will see the proposals earlier than that, and we can get together in a hangout to decide on ripples from that
<jdstrand> tomorrow at 1500 UTC-ish
<jdstrand> ok, that's fine too
<zyga> +1, thanks everyone :)
<niemeyer> Indeed, thanks to you both
<jdstrand> np
#snappy 2016-03-08
<zyga-phone> good morning
<didrocks> hey zyga-phone
<zyga-phone> hey :)
<dholbach> good morning
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/598/files
<didrocks> good morning dholbach
<zyga-phone> hey dholbach :)
<sergiusens> ogra_, you around?
<dholbach> salut didrocks, hey zyga-phone
<zyga-phone> :)
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/600 (more confusing names fixed)
<noizer> good morning
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/601
<noizer> is it possible to update snapcraft? zyga-phone
<sergiusens> mvo, on kernel snap install, are you doing something similar to snap.kernel.split('-')[1] ?
<mvo> sergiusens: I don't think so, I think grub even only looks for vmlinuz and nothing else (and initrd.img) so best to have symlink to those
<mvo> sergiusens: gustavo was also keen to move this to a convention based install instead of having keys in snap.yaml for the kernel/initrd
<zyga-phone> noizer: yes, you can always use the bleeding edge version from source
<noizer> zyga-phone https://github.com/ubuntu-core/snapcraft
<sergiusens> mvo, I'm doing hard links; the layout of partition 8 is really weird
<noizer> zyga-phone thats this one?
<noizer> zyga-phone but what branche then?
<sergiusens> mvo, also, I'm not doing the crazy vmlinuz rename when building for arm64 since it is an uncompressed 'Image' target
<sergiusens> the debbuild for some crazy legacy reason does a blind rename to vmlinuz
<zyga-phone> noizer: master, if you don't feel confident in using it then please just wait
<zyga-phone> we're all working on the release
<zyga-phone> so you will have fresh debs and images soon
<noizer> zyga-phone I will just try it if it don't work for me I will wait for the deb packages
<mvo> sergiusens: for amd64/i386 right now we hardcode vmlinuz unfortuantely but that is probably a bug. uboot should actually be flexible
<sergiusens> mvo, http://paste.ubuntu.com/15326741/
<sergiusens> mvo, http://paste.ubuntu.com/15326751/
<sergiusens> mvo, so I'm not sure what is going on
<sergiusens> mvo, reason I ask if there is some sort of "cut" iin the code
<mvo> sergiusens: this looks good, except of course that it does not work
<mvo> Bad Linux ARM64 Image magic!
<sergiusens> mvo, well if you look in the `find mnt` there's a plain 'Image' file
<sergiusens> mvo, that plainly does not exist in anything I provide
<sergiusens> I provide Image-something
<mvo> sergiusens: indeed, I think there is a split on "-" in the code somewhere
<mvo> sergiusens: that explains where it comes from
<sergiusens> mvo, yeah, we should not do that :-) I'm trying to do `kernel: vmlinuz` now
<sergiusens> mvo, although these arm kernels are not gz'ed
<mvo> sergiusens: yeah, we need to fix this
<sergiusens> mvo, also I noticed the dtbs are missing
<mvo> oh?
<sergiusens> mvo, in the released kernel snap on the store as well
<mvo> sergiusens: did you list them in snap.yaml?
<sergiusens> mvo, so the <packagename>.snap/dtbs is there, but in the root there's a 'dtbs' dir that is empty
<sergiusens> mvo, yeah, check the pastebin :-)
<sergiusens> mvo, doh
<sergiusens> mvo, no I didn't
<mvo> sergiusens: I did check the pastebin first ;)
<mvo> sergiusens: this is why I asked
<sergiusens> mvo, I need to fix this in my snapcraft as I'm manually adding (I don't want users to do this as it might just go away)
<mvo> sergiusens: it will probably go away
<sergiusens> mvo, I hope so :-)
<sergiusens> ppisati, hey, building the kernel for dragon board gets me 2.6GB of kernel modules; how is the one in the snap so small?
<ppisati> sergiusens: we normally build with debug symbols built-in
<ppisati> sergiusens: and then strip kernel and modules when creating the .deb
<ppisati> sergiusens: this way from sthe same build we get the debug .deb and the normal .deb
<ppisati> sergiusens: so either your build that way and later strip
<ppisati> sergiusens: or simply turn off DEBUG_INFO
<ppisati> sergiusens: and thus don't build the debug symbols
<sergiusens> ppisati, ah so it is a config?
 * sergiusens looks
<sergiusens> ppisati, this does make sense
<ppisati> sergiusens: CONFIG_DEBUG_INFO=y
<sergiusens> ppisati, yeah I see, thanks
<ppisati> sergiusens: turn that off and your kernel / .ko will go on diet
<sergiusens> ppisati, being on a diet is harsh though, now I don't want to do it :-)
<sergiusens> I'll leave it on as I'm enabling
<ppisati> sergiusens: +1
<sergiusens> but thanks for the tip :-)
<ppisati> sergiusens: any time
<sergiusens> mvo, it boots!
<mvo> sergiusens: OMG!
<sergiusens> sadly it seems the resize code is active
<sergiusens> mvo, http://paste.ubuntu.com/15326840/
<sergiusens> I need the ogra_ :-)
<sergiusens> I'll see if I have a smaller sdcard here
<mvo> sergiusens: very impressive
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/602
<ogra_> sergiusens, did you pick the right dtb ? we need a patched one (in paolos deb it has a -snappy.dtb suffix
<ogra_> sergiusens, the resize code is moot, parted fails
<ogra_> mvo, sergiusens thats bug 1553110 ... the resize tools are missing all libs
<ubottu> bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110
<ogra_> so what it prints is a lie currently ...
<ogra_> your last paste shows you are missing the modules though
<ogra_> (no squashfs)
<sergiusens> ogra_, oh, is squashfs a module in the default kernel build?
<ogra_> yeah
<sergiusens> darn!
<sergiusens> well at least I can go back to my fast sdcard :-)
<ogra_> if the resize code would kick in you would only notice it at next boot
<ogra_> (it wipes the bootloader partition types)
<ogra_> the current boot would just go on
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/603
<sergiusens> ogra_, what about now http://paste.ubuntu.com/15326926/ ?
<ogra_> sergiusens, still missing squashfs
<sergiusens> ogra_, but it says it loaded right there
<ogra_> ?
<ogra_> where
<sergiusens> ogra_, sorry, should of copied more above http://paste.ubuntu.com/15326932/
<ogra_> mvo, how about we grep through /proc/filesystems and exiot with a proper error message when we cant find squashfs support in the initrd
<sergiusens> ogra_, line 19 there
<ogra_> "unsupported RELA relocation: 275"
<mvo> ogra_: who would say NO to this suggestion  :-D ? +1
<ogra_> no idea what that means, but sounds like you are missing features
<sergiusens> ogra_, seems more like a bug https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1533009
<ubottu> Launchpad bug 1533009 in gcc-5 (Ubuntu Wily) "arm64: "unsupported RELA relocation"" [Undecided,New]
<ogra_> sergiusens, ah, yeah
<ogra_> in any case it seems to prevent the module from loading
<ogra_> sergiusens, if you build the kernel yourself anyway, just compile it in ;)
<sergiusens> ogra_, hah, but I want the module xp
<sergiusens> I can try going to gcc 4.8
<sergiusens> ppisati, do you know about "unsupported RELA relocation: 275" ?
<sergiusens> I'm using gcc-aarch64-linux-gnu
<sergiusens> ricmm, http://paste.ubuntu.com/15327015/
<ppisati> sergiusens: you mean the qemu warning? in case yes, i saw it, but that didn't stop from building working images using qemu
<sergiusens> ppisati, no, I'm doing cross compilation (ARCH=arm64 CROSS_COMPILE=aarch64-linux-gnu-)
<ppisati> sergiusens: are youusing a recent xenial chroot?
<sergiusens> ppisati, and during boot I get http://paste.ubuntu.com/15326932/
<sergiusens> [   13.207166] module squashfs: unsupported RELA relocation: 275
<sergiusens> ppisati, no chroots, just my regular xenial system
<ppisati> sergiusens: i thought we fixed that
<ppisati> sergiusens: it was a regression in the xenial toolchain
<ppisati> sergiusens: but now is fixed
<sergiusens> ppisati, heh, not for me; fixed in gcc?
<ppisati> sergiusens: fixed in our toolchain
<ppisati> sergiusens: not sure about upstream
<sergiusens> ppisati, I have http://paste.ubuntu.com/15326932/
<sergiusens> ppisati, I also see  KBUILD_CFLAGS_MODULE += -mcmodel=large -mpc-relative-literal-loads in the arm64 Makefile
<ppisati> sergiusens: we are carrying a patch too for that
<sergiusens> ppisati, err, I have 1:5.3.1-8ubuntu2cross2
<ppisati> sergiusens: hold on
<ppisati> sergiusens: if you see KBUILD_CFLAGS_MODULE += -mcmodel=large -mpc-relative-literal-loads then you have the two patches
<ppisati> sergiusens: is that my tree?
<ppisati> sergiusens: if you cross compile my tree, do you get that too?
<sergiusens> ppisati, no, it's the 96boards one
<ppisati> sergiusens: try my tree
<ppisati> sergiusens: if it works, then they are missing some patch
<ppisati> sergiusens: if you keep getting that, than it's your toolchain
<sergiusens> ppisati, in arch/arm64/Makefile I miss that line completely, not sure what I saw before
<ppisati> sergiusens: you need
<ppisati> sergiusens: b6dd8e0719c0d2d01429639a11b7bc2677de240c
<ppisati> sergiusens: and
<ppisati> sergiusens: 6113222fa5386433645c7707b4239a9eba444523\
<ppisati> without the traliing \
<sergiusens> thanks, I iwll try
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/604
 * zyga-phone is killing SNAP_FULLNAME 
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/605
 * zyga-phone is renaming SNAP_ORIGIN to SNAP_DEVELOPER
<noizer> zyga-phone where can i find the last snapcraft version?
<ogra_> in xenial
<noizer> ogra_ but i want to build with some slots but for now it doesn't work (snapcraft 2.3.2)
<ogra_> you might have to wait a little more, the image and snapcraft are supposed to be released together
<ogra_> (not sure where we stand with the image release)
<noizer> ogra_ Ok i heard about it but will it release today for the raspberry pi?
<ogra_> no idea
<ogra_> (i only tested the arm64 rootfs yesterday ... perhaps mvo can tell when the new stuff gets out)
<noizer> is he online at this moment? because I think he is very busy at the moment
<zyga-phone> noizer: on github.com/ubuntu-core/snapcraft
<didrocks> noizer: just run from ^ using bin/snapcraft, it will import the correct files
<noizer> didrocks does not work :s
<didrocks> noizer: logs? I'm doing that daily, so I highly doubt it doesn't take the right snapcraft version :p
<dholbach> davidcalle, didrocks, I put up a branch which has all the relevant bits for a demo (https://code.launchpad.net/~dholbach/developer-ubuntu-com/hero-tour-changes/+merge/287765) - maybe we can merge the template into it?
<noizer> didrocks my snapcraft is 2.3.2
<dholbach> let me re-push it to the developer site dev team namespace
<noizer> didrocks when I do /usr/bin/snapcraft clean i get the error where he don't find slots
<didrocks> noizer: why are you using /usr/bin/snapcraft? I told you to use the github repo that zyga-phone pointed out and run bin/snapcraft
<noizer> didrocks
<noizer> thx i will test that
<dholbach> https://code.launchpad.net/~developer-ubuntu-com-dev/developer-ubuntu-com/hero-tour-changes/+merge/288400
<dholbach> sorry, https://code.launchpad.net/~developer-ubuntu-com-dev/developer-ubuntu-com/hero-tour-changes/+merge/288401
<didrocks> dholbach: excellent! should we try to assemble something with davidcalle's current work? That way we can have a first result and see how it goes?
<didrocks> dholbach: want that we catch up? (I've the first markdown pages written)
<dholbach> didrocks, that's why I pushed to the team namespace
<dholbach> let's wait for the template - at that point it'll make sense to get together and figure out what's still missing :)
<didrocks> sure!
<dholbach> great :)
<didrocks> nice work :)
<niemeyer> jdstrand: ping
<noizer> didrocks it works fine :D is security polity available there?
<noizer> *security-policy
<didrocks> noizer: no idea TBH, I can just tell you it's the freshest and latest :p
<noizer> didrocks ok thx a lot :D
<didrocks> yw ;)
<zyga-phone> jdstrand: hey, please ping me when you're around
<zyga-phone> jdstrand: we'd like to have a call with you today
<mvo> ogra_: I uploaded a new arm64 edge OS snap juts today
<ogra_> mvo, ok, will test later ... btw ... http://paste.ubuntu.com/15327686/
<ogra_> i'm about to push that to the PPA and do some test builds ... if it works i'll upload it
<ogra_> (and if it works for the os snap, it should be easy to do the same for the kernel tarballs too)
<mvo> ogra_: nice
<mvo> ogra_: I think you can drop readme.md and package.yaml now
<ogra_> mvo, do you need the buildds today ?
<noizer> is it possible to use security-override? mvo zyga-phone
<noizer> in snapcraft
<ogra_> i dont want to get in your way with a potentially broken livecd-rootfs in case you need to re-build something
<mvo> ogra_: probably not, I think I did enough
<ogra_> ok
<ogra_> will drop the package.yaml ...
<mvo> ogra_: i.e. the current edge OS is good so far
<ogra_> mvo, what about the gadget dir ?
<mvo> ogra_: if it works on amd64 as well I push to rolling/stable
<mvo> ogra_: we don't need that anymore too
<zyga-phone> noizer: yes
<zyga-phone> noizer: through old-security
<mvo> ogra_: its all under /snaps now
<ogra_> cool, dropping that as well
<zyga-phone> noizer: as soon as the new release is out
<mvo> ogra_: yeah, that should work. nice to see this btw
<noizer> but i got now the new snapcraft
<noizer> but it don't works on my snappy OS probably
<ogra_> i'm a bit worried about the apt-get install ... not sure if that works
<ogra_> but i dont really want to make snappy a hard dep of livecd-rootfs
<noizer> zyga-phone
<ysionneau> Hi, how do I allow a syscall in my snapcraft.yaml for an app ?
<ysionneau> an if the app command is a shell script doing an exec, is the syscall autorization OK for the binary which is executed?
<zyga-phone> noizer: I'm sorry I cannot help you today, we can either implement snappy or help everyone on the channel trying things out but not both; in a few days I will have more time and things will be in better shape for you to try them out; please wait for the release for now.
<ysionneau> (and say the exec'ed binary is also a shell script doing an exec, etc)
<ysionneau> and if the app*
<ogra_> ysionneau, there are ways to make syscall exceptions via snapcraft.yaml ... but ask jdstrand which ones will actually be allowed by the store ... (i think fchown is one of the allowed ones, not sure there are others)
<ysionneau> oh, so I cannot do syscalls: [send] ?
<jdstrand> no
<ysionneau> fyi I get this : Mar  8 13:55:33 localhost kernel: [  794.318819] audit: type=1326 audit(1457445333.541:13): auid=1000 uid=1000 gid=1000 ses=2 pid=1229 comm="ld-linux-armhf." exe="/snaps/wifid.sideload/LSTDgDnSXTSF/lib/ld-linux-armhf.so.3" sig=31 arch=40000028 syscall=289 compat=0 ip=0x76e9a4d6 code=0x0
<ysionneau> and 289 seems to be "send"
<jdstrand> use 'snappy-debug.security scanlog'
<jdstrand> that will tell you what syscall 289 is on your system
<jdstrand> and will suggest a 'cap' to use
<ysionneau> this tool fails with a permission denied error
<jdstrand> ysionneau: is this on 16.04 or 15.04?
<ysionneau> 16.04
<ysionneau> http://pastebin.com/nakZUZ6Y
<jdstrand> yeah, developing on 16.04 now is difficult-- all of this is in flux
<jdstrand> it hasn't been converted to the new interfaces yet
<ysionneau> ok
<ysionneau> so what can I do then?
<rtg> ogra_, did you ever get the generic initrd package working ?
<jdstrand> ysionneau: do scmp_sys_resolver 289
<jdstrand> on the machine that has the error
<ysionneau> 15:24 < jdstrand> ysionneau: do scmp_sys_resolver 289 < yes, it prints send
<ogra_> rtg, yes, but only half way, there are bugs in fakechroot that are kond of blocking atm
<jdstrand> send is part of 'network-client'
<ysionneau> I also already give the network-client caps
<jdstrand> you don't need an override
<ogra_> rtg, bug 1553110
<ubottu> bug 1553110 in fakechroot (Ubuntu) "weird output of ldd on arm64" [Undecided,New] https://launchpad.net/bugs/1553110
<jdstrand> your yaml is probably not right for the new interfaces stuff
<ysionneau> so maybe the right question was : is the capability kept by the process if it does exec ?
<zyga-phone> josepht: hey :-)
<zyga-phone> er
<zyga-phone> jdstrand: hey :)
<ysionneau> I would say yes since the usual snappy way is to wrap binary calls to export env vars and do 'exec'
<jdstrand> zyga-phone: hey
<jdstrand> ysionneau: yes
<zyga-phone> jdstrand: please check out telegram if you can
<ysionneau> but I don't understand here why my capability network-client doesn't allow me to use "send"
<ogra_> rtg, beyon that the iinitrd should be usable ... it is just that some features like resize do not work atm ... you can just grab ubuntu-core-generic-initrd and pull the img from /usr/lib/ubuntu-core-generic-initrd (and then add modules and stuff)
<jdstrand> ysionneau: I bet it is because your yaml is wrong for the new interfaces work
<jdstrand> it is just using the default policy and ignoring everything else
<rtg> ogra_, what package produces the generic initrd ? initramfs-tools-ubuntu-core ?
<ysionneau> hmm at least the yaml does pass the parsing of snapcraft :o
<jdstrand> I think that is what jibel and mvo were talking about earlier
<ysionneau> so it seems OK according to the schema
<ogra_> rtg, yep
<ysionneau> and it seems OK with the examples I see in snapcraft/examples
<zyga-phone> ysionneau: it will only work with unreleased snapcraft + snappy
<zyga-phone> so wait :)
<jdstrand> zyga-phone: so, there is an email and tg. I will get to it, but it will be a little bit
<ysionneau> zyga-phone: yes, I'm using unreleased snapcraft :)
<zyga-phone> jdstrand: thanks
<zyga-phone> ysionneau: and unreleased snappy?
<ysionneau> I'm using snapcraft from git
<ysionneau> but I'm indeed using the "devel" channel of snappy for rpi2
<ysionneau> ubuntu-core 2016-03-08 16.04.0-15.armhf
<zyga-phone> ysionneau: that's not enough
<zyga-phone> ysionneau: you have to wait for snappy release (today)
<jdstrand> pindonga: can you pull the review tools if you haven't already-- seems the interface rename is all landing
<ysionneau> allright, thanks!
<pindonga> jdstrand, ack, no I haven't (so good you reminded me)
<jdstrand> pindonga: thanks!
<niemeyer> jdstrand: Do you have a moment for a call?
<mvo> I pushed a new stable OS update with the most recent change described in https://lists.ubuntu.com/archives/snappy-devel/2016-March/001567.html
<mvo> sergiusens: you have a stable OS update now with the plugs: changes
<zyga-phone> \o/
 * zyga-phone hugs mvo
<zyga-phone> ysionneau, noizer: try out the fresh image and snapcraft after reading the email above ^^
<niemeyer> jdstrand?
<noizer> zyga-phone I updated my ubuntu-core already xD
<noizer> saw the good news from mvo :D
<ysionneau> zyga-phone: thx!
<ysionneau> I don't see any update after doing snappy update
<ysionneau> I'm in -15
<ysionneau> or should I re-generate an image using your ubuntu-image ?
<mvo> ysionneau: armhf version -15? that is ok that is the most current one
<ysionneau> ah so I was already on the right one, and with latest snapcraft
<ysionneau> so I don't get what's wrong
<ysionneau> maybe I should use "plugs" and not "slots"
<ysionneau> hmm nop snapcraft refuses it
<mvo> dpm: for calculator you need to so sed -i "s/slots:/plugs:/" meta/snap.yaml
<zyga-phone> ysionneau: you should use "plugs" for the snapcraft.yaml
<ysionneau> hmmm is github ubuntu-core/snapcraft up to date?
<ysionneau> cause I'm using that, and it refuses to parse my yaml if I use plugs :o
<ysionneau> 15:52 < zyga-phone> ysionneau: you should use "plugs" for the snapcraft.yaml : I get : Issues while validating snapcraft.yaml: Additional properties are not allowed ('plugs' was unexpected)
<zyga-phone> o_O
<zyga-phone> old snapcraft I guess
<zyga-phone> I don't know, it's just out of sync then
<ysionneau> looks like I don't have the right version, yes, I'm on master branche on SHA1 6d17a601d24b7053ffe92e3cb1d58e0bb9415a36
<ysionneau> branch*
<zyga-phone> ysionneau: you have to dig in for yourself for a while
<ysionneau> that's the last commit I see on https://github.com/ubuntu-core/snapcraft/commits/master
 * ogra_ dances around mvo 
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54544
<ogra_> livecd.ubuntu-core.ubuntu-core_16.04-20160308-15:04_amd64.snap (75.9 MiB)
<ogra_> :D
<mvo> ogra_: sweeeeeeeet
 * mvo hugs ogra_
<ogra_> mvo, i see ou added the arch name to the version in the ones you upload to the store ... should i do the same ?
<ogra_> (i'm also not sure about the colon in the timestamp)
<mvo> ogra_: its not longer needed, I did it because the store broke in a funny way in the past without it
<ogra_> ah, cool
<mvo> ogra_: it was also useful to debug an issue where the store send me a armhf os snap when I was an amd64, I only noticed because of the version string
<mvo> ogra_: but all those issues are fixed now
<ogra_> ok, cool
<ogra_> what about the colon, can that stay ?
<mvo> ogra_: technically its an epoch right now
<ogra_> oops
<ogra_> indeed
<mvo> ogra_: so a "-" would be nicer
<ogra_> funnny that the package actually built at 15:04 :)
<mvo> ogra_: however very very soon version numbers will have no semantic meaning whatsoever
<ogra_> ok
<mvo> ogra_: lol
<mvo> ogra_: nice
 * ogra_ changes to a dash 
<mvo> ogra_: so if its trivial, please just fix the ":" for now, soon it won't matter :)
<ogra_> i386 looks fine too ... waiting for the arms then i'll push that to the archive
<ogra_> yeah, totally trivial
<mvo> nice, great work!
<ogra_> heh, only the start ... the tricky part is to teack cdimage about .snap now
<dpm> mvo, ok, thanks! Will do it in a couple of hours and let you know. Any news on the upload of the snapcraft version that supports these changes?
<ogra_> *teach
<mvo> dpm: ups, I forgot, the last I heard from sergiusens was that he wants a stable os snap first that supports it. he is in a eastern timezone now I think so probably will read this tomorrow
<ogra_> yeah, he's probably already drowning in beer
<dpm> :)
<dpm> ok, thanks mvo
<jdstrand> niemeyer: I will have a moment for a call yes, but I haven't yet had a moment to catch up on the thread
<jdstrand> niemeyer: I'm going through this now. can I ping you in a few minutes?
<jdstrand> niemeyer: can I rely on the email thread as everything I need to know or should I read through the (long) tg discussion?
<niemeyer> jdstrand: The email thread+document is much better than the tg thread for context
<jdstrand> ok, let me get through that and ping you
<niemeyer> jdstrand: I'll step out for lunch now.. we can catch up in a couple of hours
<jdstrand> that works for me as well
<jdstrand> niemeyer: fyi, I left a comment on https://github.com/ubuntu-core/snappy/pull/606#issuecomment-193820189https://github.com/ubuntu-core/snappy/pull/606#issuecomment-193820189 which I'm not sure if it will affect your judgement on if it should be closed or not
<zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/608/files
<zyga-phone> jdstrand: I'm working on cleaning up patches that take this and splice the interface snippets inside in the right places
<jdstrand> cool
<jdstrand> zyga-phone: fyi, I came up with a very compelling use case for the policy being in files
<jdstrand> zyga-phone: the developer experience is supposed to be: snappy try <snap> (or similar)
<jdstrand> zyga-phone: that puts the snap in complain mode where everything is allowed, but violations to policy are logged
<jdstrand> zyga-phone: then another tool is supposed to take those violations and suggest things
<jdstrand> zyga-phone: that tool can't suggest things without having access to the policy files
<zyga-phone> jdstrand: I see, how does that tool work today?
<jdstrand> zyga-phone: well, there are several tools that are going to need to be combined to support the way this is supposed to work (ie, snappy try doesn't do any of the above-- it has to be implemented)
<jdstrand> zyga-phone: but essentially, the tools would all use libapparmor to parse the log
<jdstrand> zyga-phone: then they examine the policy files
<jdstrand> then they say 'add network to your plugs', etc
<zyga-phone> jdstrand: snappy can easily expose those over the API
<zyga-phone> jdstrand: this way the tool can actually work without changes later
<jdstrand> what api?
<zyga-phone> jdstrand: the rest api
<zyga-phone> jdstrand: we could simply expose all of the text verbatim
<jdstrand> zyga-phone: so you're saying that the tool asks the rest api to dump all of the policy for it to then examine?
<zyga-phone> jdstrand: so you could essentially wget each of the text files
<zyga-phone> jdstrand: something like it, the advantage is that you could work with the tool remotely as well (nice dev UX)
<zyga-phone> jdstrand: and locally it would not get out of date/out of sync
<jdstrand> using files it wouldn't get out of sync either-- it would only use the files on the system
<jdstrand> but yes, this is an option
<jdstrand> I guess it is also an answer to the auditing problem I mentioned
<zyga-phone> jdstrand: well, it'd be more complex to test consistent sets IMHO
<jdstrand> I don't see how
<zyga-phone> jdstrand: yeah, I think we can easily expose each snippet as plain text
<jdstrand> "give me all the files" vs "open all the files"
<zyga-phone> jdstrand: (you just need snappy, not any other package, to be consistent)
<zyga-phone> jdstrand: they come from different places
<jdstrand> I know you guys are excited about all the policy in go. I am not blocking, but I am not
<zyga-phone> jdstrand: this will also look more complex as snappy moves beyond 16.04
<jdstrand> cause looking at https://github.com/ubuntu-core/snappy/pull/608/files it would be just as easy for 'const defaultAppArmorTemplate = ' to be a read on a file in a known location, but I won't beat this horse any more
<zyga-phone> jdstrand: I though about that and have this implemented (for a few weeks)
<zyga-phone> jdstrand: but it's still more complex, e.g. on the desktop that package can be updated
<zyga-phone> jdstrand: so then you now must do invalidation properly
<zyga-phone> jdstrand: you have to do parsing (I'll break the template into parts so that parsing is not required)
<jdstrand> I don't consider policy updates a bad thing
<jdstrand> anyway, we shouldn't rehash this. you guys won
<zyga-phone> jdstrand: neither do I, but in this model you restart snapd and you're consistent
<zyga-phone> jdstrand: I'm not trying to convince you over random stuff, IMHO this is really easier to work with
<zyga-phone> jdstrand: from a purely technical POV
<jdstrand> please remember our caching discussion thouch
<jdstrand> though
<jdstrand> cause there are very important performance considerations
<zyga-phone> yeah, I know
<zyga-phone> I'll get to caching
<jdstrand> ok, cool
<jdstrand> that is the most important thing
<jdstrand> if we handle that right, we can see how the policy stuff goes and adjust
<zyga-phone> jdstrand: I'll try to make snap connect write all the security files today
<zyga-phone> won't reload aa profiles but will do 90% of the work
<jdstrand> cool
<zyga-phone> it's a big change with the state engine but the primitives are ready
<zyga-phone> just need to finish this real aa policy text to be there
<zyga-phone> jdstrand: https://github.com/ubuntu-core/snappy/pull/611
<zyga-phone> seccomp side
<jdstrand> zyga-phone: so, in addition to inserting snippets in the right place, you are aware in the apparmor template that you need to also set ###VAR### and ###PROFILEATTACH###, right?
<zyga-phone> jdstrand: yeah, I have that code for a few weeks
<jdstrand> ok
<zyga-phone> (my piglow demo behind me is a proof of that :)
<jdstrand> that's fine
<zyga-phone> :)
<zyga-phone> I'll ask you for review though
<jdstrand> just wanted to be sure
 * jdstrand nods
<zyga-phone> jdstrand: can you have a look at: https://github.com/ubuntu-core/snappy/pull/612
<zyga-phone> jdstrand: this changes how we call ubuntu-core-launcher
<jdstrand> yes, that is the thread I am trying to get to reading
<zyga-phone> jdstrand: oh, sorry
<zyga-phone> ok
<jdstrand> not your fault
<jdstrand> my inbox and irc backscroll is quite a lot today
<niemeyer> jdstrand: ping
<niemeyer> jdstrand: Can we have it now?
<niemeyer> jdstrand: ? :-0
<niemeyer> :-)
<jdstrand> still reading
<jdstrand> I thought I had two hours :)
<jdstrand> so I tended to other pressing things
<jdstrand> I'm almost through it
<niemeyer> jdstrand: Can you please join the hangout? mvo will be off in 40 mins
 * jdstrand notes this also requires a bit of research, which I'm also doing
<niemeyer> https://plus.google.com/hangouts/_/canonical.com/snappy-devel
<jdstrand> ok, forgive me if my opinion isn't as well-thought out as I'd like it to be
<niemeyer> jdstrand: Don't worry, that's a friendly call to sort it out.. we can discuss questions live
<elopio> fgimenez: I thikn this panics when the config is not present: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/base_test.go#L54
<elopio> https://www.irccloud.com/pastebin/kZ8l9nLL/
<elopio> fgimenez: what if I os.Stat the file, and put all this inside an if?
<fgimenez> elopio, yes, that can work and keeps all very clear
<elopio> plars: can you try this one please?
<jdstrand> zyga-phone: you asked me to look at https://github.com/ubuntu-core/snappy/pull/612/files. is that still needed in light of the meeting we just had?
<zyga-phone> jdstrand: I think not anymore :)
<jdstrand> ok, that's what I thought
<zyga-phone> jdstrand: thanks!
<zyga-phone> jdstrand: so I see you reviewed the seccomp blob, that's great, I'll merge it
<jdstrand> zyga-phone: I reviewed 611 (seccomp), do you need me to look at 608 (apparmor)?
<zyga-phone> please do the same for .. .yes :D
<zyga-phone> fanstastic
<jdstrand> hehe
<zyga-phone> I'll get this to work all the way today
<zyga-phone> jdstrand: I was looking at one extra thing but that can wait for tomorrow (even for discussion)
<zyga-phone> jdstrand: to have a know to switch a single snap to development mode
<zyga-phone> jdstrand: so we get advisory logs, not denials
<zyga-phone> jdstrand: I think I know how to do it but I'll tell you about what I think I know tomorrow :)
<zyga-phone> jdstrand: when t hat is available, we can remove hw-assign
<jdstrand> zyga-phone: that is actually quite easy. let me get that for you
<zyga-phone> jdstrand: is that just one extra flag in the "header" of the profile?
<zyga-phone> jdstrand: I read the python code that does aa-{stuff-i-forgot} from apparmor-utils
<jdstrand> it is
<zyga-phone> jdstrand: if that's the case I can just bake support for that right into the tooling
<plars> elopio: what is it you want me to try?
<zyga-phone> jdstrand: lovely, we need to think how to remember that in the state though (persistent, etc) but I think this will fly
<elopio> plars: this should fix your panic.
<jdstrand> zyga-phone: change this: '(attach_disconnected)' to 'flags=(attach_disconnected,complain)'
<jdstrand> zyga-phone: feel free to change '(attach_disconnected)' to 'flags=(attach_disconnected' in the normal case
<zyga-phone> jdstrand: noted, thanks
 * zyga-phone really writes this down on paper
<jdstrand> err
<jdstrand> 'flags=(attach_disconnected)'
<jdstrand> zyga-phone: unfortunately for seccomp the launcher is going to need to be updated
<zyga-phone> jdstrand: seccomp doesn't have anything like that, right?
<jdstrand> zyga-phone: (since it is effectively the seccomp policy parser)
<jdstrand> there is no parser like with apparmor
<jdstrand> the launcher is the parser
<zyga-phone> jdstrand: so how do you want that to work?
<zyga-phone> jdstrand: right, righth
<jdstrand> so the launcher needs to be updated
<zyga-phone> jdstrand: ah, the wrapper script
<zyga-phone> jdstrand: or the actual ubuntu-core-launcher
<zyga-phone> ?
<jdstrand> ubuntu-core-launcher
<elopio> mterry: can I bother you for a moment? I need help with the pipeline test you wrote ages ago.
<jdstrand> it is what takes the list of syscalls from our generated file, parses the file and then adds each syscall via a C api
<mterry> elopio, hello
<jdstrand> zyga-phone: and right now it only does enforce mode
<zyga-phone> yeah, I know, let's draft the minimum required change to the launcher to support developer mode
<elopio> mterry: hi. How are you?
<elopio> mterry: could you first explain to me what's the idea of this test?
<zyga-phone> and let's see what we can make with that
<jdstrand> the good news is this all happens after dropping privs
<mterry> elopio, uh...  can you point me where in the code we're talking about?
<elopio> mterry: https://github.com/ubuntu-core/snapcraft/blob/578fd4657218ce3e1900155a5742436b4757c8a2/examples/libpipeline/test.c
<elopio> oh, wait, that's an old revision.
<elopio> mterry: https://github.com/ubuntu-core/snapcraft/blob/master/examples/libpipeline/test.c
<jdstrand> zyga-phone: for this to work well we need to also patch the kernel to log the security label of the process seccomp is killing/auditing
<zyga-phone> jdstrand: ok, it seems that full developer mode is still a few days away then; do you have someone to do this work?
<mterry> elopio, um, if I recall, it was to demonstrate that snapcraft could integrate with your locally built project too.  Like you have your source tree.  And then you had snapcraft grab all the dependencies and build them.  And then you could run "snapcraft shell make" to build your local project pointing at the snapcraft built files.   I don't know whether that concept meshes with the snapcraft of today anymore
<mterry> elopio, (i.e. to demonstrate that you could build that local test.c against snapcraft's copy of libpipeline)
<jdstrand> zyga-phone: I will be doing the dev mode stuff from the security team. This will not land this week. I will be focusing on enabling you to move fast on interfaces, the framework migrations and snappy on classic policies before developer mode
<zyga-phone> okay
<zyga-phone> kiling hw-assign is not important, I just fixed it locally
<zyga-phone> so it now has $snap.$app IDs
<zyga-phone> I'll follow up with one more consolidation branch that makes $snap.$app just $snap when $app == $snap
<zyga-phone> I want to take a stab at Connect() today
<jdstrand> since it is implemented, that sounds fine, though I'd personally like to see what the interface equivalant of hw-assign will be once the old-security/caps is migrated and old-security/security-template is gone
<jdstrand> cool
<elopio> mterry: well, that makes sense today too. Now I'm wondering what should be the output of the test.
<mterry> elopio, I think it was designed to be run in that folder itself.  And it uses a different grep pipeline than http://bazaar.launchpad.net/~mterry/+junk/pipelinetest/view/head:/test.c does, so that the test knows it's using the local test, not the remote test
<elopio> mterry: it used to print https://paste.ubuntu.com/15329134/
<elopio> now it prints just the two first lines.
<elopio> and I don't understand why it prints grep c when this line shows grep s: https://github.com/ubuntu-core/snapcraft/blob/master/examples/libpipeline/test.c#L9
<mterry> elopio, grep c is because you're calling the test code from lp:~mterry/+junk/pipelinetest, not the locally built test
<mterry> elopio, http://bazaar.launchpad.net/~mterry/+junk/pipelinetest/view/head:/test.c
<elopio> mterry: ok, so it should print grep s. Not grep c. And it should print the contents of the snap, not of your junk.
<elopio> I think didrocks changed the cwd, so that explains ls not showing anything.
<mterry> elopio, well the idea is that we can run both, to show that snapcraft can build a local project and a remote project against an internally built libpipeline
<mterry> elopio, but yeah the cwd change would explain a new failure
<zyga-phone> oho
 * zyga-phone realized we need udevadm control --reload-rules
<zyga-phone> jdstrand: ^^ added to my todo
<zyga-phone> along with udevadm trigger
<elopio> mterry: thanks. That was a tangled test you wrote in there :)
<elopio> I'm happy for now that we are getting the "custom libpipeline called" message for now. I think we are calling the wrong test.c, but I'll dig more about it.
<elopio> we might need a better command than grep to test it now that the dir is empty.
<mterry> elopio, yeah that test probably could have been better documented  :)
<jdstrand> zyga-phone: nice
<Facu> Hi all!
<Facu> I'm trying to flash a device, but ubuntu-device-flash just hangs :/
<Facu> this is the third time I run it, now I left it a couple of hours
<Facu> see http://pastebin.ubuntu.com/15329318/
<Facu> is there any way to make it show progress or something?
<ogra_> Facu, you probably want the #ubuntu-touch channel
<Facu> ogra_, err, you right
<ogra_> :)
<plars> elopio: what is the change to make?
<Facu> ogra_, thanks!
<elopio> plars: https://github.com/ubuntu-core/snappy/pull/614/files
<zyga-phone> ogra_: hey
<plars> elopio: yeah, I thought that might be it from the backlog and had just tried it locally... doesn't *seem* to work
<ogra_> zyga-phone, yo
<zyga-phone> ogra_: how can I help to update firmware and other bits needed for pi2 camera?
<zyga-phone> (as in, how can I fix the problem for everyone)
<plars> elopio: wait, maybe... one sec
<elopio> plars: still panics?
<zyga-phone> hey plars, long time no see :)
<ogra_> zyga-phone, i need to update the firmware anyway (for rpi3 support), i'll try to get to it this week
<zyga-phone> ogra_: do you think you could show me how you do it
<zyga-phone> ogra_: I know you can do it but I'd love to learn how this works
<plars> elopio: it fails differently at least. I can get -h output now, but -check.list doesn't work. One sec and I will pastebing
<plars> *pastebin
<ogra_> zyga-phone, well, i pull the upstream binary blobs from github and replace the ones in the snap ... then buuild an image with that and see if it boots
<zyga-phone> in the kernel snap? check
<ogra_> no magic in that
<zyga-phone> ok
<ogra_> no
<ogra_> gadget
<plars> elopio: it still seems to try to run the setups
<zyga-phone> and if they work, where do you commit this back?
<plars> elopio: https://www.irccloud.com/pastebin/p58PGbaJ/
<zyga-phone> oh, gadget?
<zyga-phone> ok
<ogra_> zyga-phone, https://github.com/raspberrypi/firmware/tree/master/boot
<ogra_> the gadget source is in the snappy-hub branch
<zyga-phone> ogra_: I mean about our side, I know where the upstream blobs are
<zyga-phone> ah
<zyga-phone> ok
<zyga-phone> ogra_: if I do it, will you review my changes?
<ogra_> it is binaries ... there is nothing to review :)
<zyga-phone> ogra_: well, you can tell me that I did it right and land it :)
<zyga-phone> ogra_: I just want to 1) help 2) learn
<ogra_> if you replace the binaries and manage to still boot, i'm happy to nod it off
<zyga-phone> (maby 2), 1), because I'm a selfish dude)
<zyga-phone> perfect
<ogra_> (essentially bootcode.bin and the dtb's, the start* files we ship and the fixup* ones we ship need replacing)
<ogra_> and make sure to use the latest license files just to be sure they are not out of date
<ogra_> hmmmmm ....
<ogra_> so i have the livefs builder spit out ubuntu-core snaps now
<zyga-phone> 0o
<ogra_> but cdimage doesnt allow wildcards ... and the snap needs a version string in the name
<elopio> plars: the list command shouldn't be running the set up suite.
<ogra_> tricky
<elopio> plars: my pr seems to fix the init. So now I'll resurrect the list PR.
<ogra_> beuno, does the store care how my snap is named ? or does only the meta/snap.yaml data count ?
<beuno> ogra_, it totally ignores i
<beuno> it
<ogra_> beuno, so the snap at https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54560 could be totally unversioned ?
<ogra_> (and the store would happily accept)
<beuno> ogra_, yeap
<ogra_> yay
 * ogra_ changes the code to rip out the version string ... perfect 
<ogra_> so tomorrow we'll have all os snaps on cdimage then :)
<ogra_> (and tomorrow evening also the kernel snaps )
<beuno> woooo
<plars> elopio: I can try just cherry-picking it again in a bit, tied up with something else at the moment
<plars> elopio: ok, I pulled the list fix in and it's getting better:
<plars> https://www.irccloud.com/pastebin/NhcJ5PrG/
<plars> elopio: also, I think the systemctl calls should also be skipped but this is still pretty hacky as it just checks for that file. I need to check on something, but at some point we *have* to set up that file to run the tests. If that happens before we generate the list of tests, then we're back to the original troubles
<elopio> wesleymason: I see you have the errbot charm. Are you using it somewhere?
<elopio> plars: yes, we know we shouldn't be doing any calls in init.
<elopio> the systemclt calls are easy to move, but I need to discuss with Federico because he moved them here first.
<plars> elopio: sure, np
<wesleymason> Will be using it in the online services channel when I have chance to build a mojo spec for it.
<elopio> the others are not so easy. The wait is a workaround, so we could ignore it.
<elopio> the setup snappy from branch is going to be though, but with this simple if we can push the problem for later.
<wesleymason> The reactive framework has been both a pleasure and a pain. Like Fifty Shades of Juju.
<elopio> wesleymason: if you have patience with me while I learn juju, I can help.
<elopio> I will deploy it in my canonistack to check it out.
<wesleymason> elopio: after working with juju for so long patience is all I have left ;-)
<elopio> I accept the challenge leave you without even that!
<elopio> *to
<orby> is there a guide on how to secure a snappy core?  would like to replace the ubuntu account and switch from dhcp to static.  is it the same process as normal ubunutu or is there a specific process to make sure the config sticks?
<ogra_> orby, http://paste.ubuntu.com/15329884/
<ogra_> thats a script i use to set up machines
<orby> ogra_: thank you
<orby> google dns eh? :)
<ogra_> i'm lazy :)
<orby> what is the correct way to refer to the system, snappy, snappy core, ubuntu core?
#snappy 2016-03-09
<sergiusens> ogra_, any ideas about http://paste.ubuntu.com/15333155/ ?
<sergiusens> ah missing firmware
<dholbach> good morning
<zyga-phone> Good morning
<didrocks> hey zyga-phone
<zyga-phone> :-)
<ogra_> sergiusens, https://launchpad.net/~p-pisati/+archive/ubuntu/embedded you want dragon410c-firmware
<sergiusens> ogra_, yeah, thanks, I figured it out 6 minutes after pinging you (like in the message)
<ogra_> :)
<sergiusens> ogra_, I grabbed from upstream though
<sergiusens> https://developer.qualcomm.com/hardware/dragonboard-410c/tools
<ogra_> well, the package has the filesystem structure, which is why i prefer it
<ogra_> just a dpkg -x *deb /target/dir is enough ... i dont need to bother where the files go
<sergiusens> ogra_, right, the upstream stuff just needs to get dumped in lib/firmware
<ogra_> yep
<sergiusens> ogra_, I'll be sending out an email later today
<sergiusens> once the demo stuff is done I can focus on releasing a snapcraft with that interfaces swap
<ogra_> :)
<didrocks> dholbach, davidcalle: any time to HO and try the new template + content import? :)
<dholbach> didrocks, maybe some time after lunch?
<davidcalle> didrocks: dholbach: anytime wfm
<didrocks> dholbach: davidcalle: 2:30PM?
<dholbach> sure
<davidcalle> +1
<didrocks> invitations sent!
<noizer> Goodmorning
 * zyga-phone throws more branches out
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/621
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/618
<zyga-phone> https://github.com/ubuntu-core/snappy/pull/620
<zyga-phone> and a biggie: https://github.com/ubuntu-core/snappy/pull/617
<ogra_> mvo, hey, so looking at kernel snaps from livecd-rootfs i'm wondering what we do with azure
<ogra_> (today thats just a cp of the amd64 tarball iirc, for snaps we cant really do that since it will need different meta data .... should azure use the normal amd64 one or should i produce a *.azure.kernel.snap separately ?)
<dpm> mvo, quick question on your e-mail to snappy-devel: "3. The icon location has changed - It is now in meta/gui/icon.png instead of meta/icon.png". So far I've specified the icon location in snapcraft.yaml, so I'm not sure what effect that has for snaps that specify a particular path to the icon. Or is this just the default location icons will be searched for if they're not specified in snapcraft.yaml?
<mvo> dpm: if you use snapcraft it will take care of everything for you
<mvo> dpm: at least that is my understanding unless sergiusens_ corrects me :)
<dpm> mvo, I'm not sure I understand it at all. My icon lives in the upstream code under app/icon.png, and that's what I specify on snapcraft.yaml. So do I need to do any changes to snapcraft.yaml or the icon location in the tree after the latest snappy changes?
<dpm> e.g. http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snapcraft.yaml
<noizer> how does security-overide works?
<sergiusens_> dpm, mvo that's not landed yet
<sergiusens_> won't happen this week at least
<sergiusens_> this week it is all about the kernel
<dpm> sergiusens_, thanks. So when it lands, are there any changes that need to be done to that snapcraft.yaml file? ^^
<sergiusens_> dpm, none
<dpm> ok, cool, thanks
<dpm> sergiusens_, mvo, another question related to the announced change of the snap startup directory is now $SNAP_DATA instead of $SNAP: I'm using the copy plugin to install a config file with a relative path: http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snapcraft.yaml#L30
<dpm> The file itself is http://bazaar.launchpad.net/~dpm/ubuntu-calculator-app/snap-all-things/view/head:/snappy-qt5.conf
<dpm> so I guess I'll now have to change the ./ path to $SNAP explicitly on the config file
<dpm> is there any plugin to do variable replacements in files specified in snapcraft.yaml? Or a simpler way to do it?
<sergiusens_> dpm, instead of bin/calculator do 'calculator' or '$SNAP/bin/calculator'
 * zyga-phone triest to implement the first manager in the overlord
<dpm> sergiusens_, thanks. So just that change and the .conf file can stay as it is with its ./relative path?
<ogra_> mvo, did you see my ping abov ?
<ogra_> *above
<mvo> ogra_: sorry, I did not
<ogra_> <ogra_> mvo, hey, so looking at kernel snaps from livecd-rootfs i'm wondering what we do with azure
<ogra_> <ogra_> (today thats just a cp of the amd64 tarball iirc, for snaps we cant really do that since it will need different meta data .... should azure use the normal amd64 one or should i produce a *.azure.kernel.snap separately ?)
<mvo> ogra_: hm, I think azure need no special handling anymore but ben howard will know for sure
<ogra_> ok, i'll leave that out for now
<ogra_> mvo, btw http://paste.ubuntu.com/15333996/ ... is what i have so far
 * ogra_ will do a test build soon
<ogra_> oops ... just noticed an error
<mvo> ogra_: nice
<noizer> ogra_: Do you know more about the apparmor?
<ogra_> noizer, not really
<noizer> ogra_: Do you know somebody that have more experience?
<ogra_> jdstrand for example
<noizer> ogra_: Do you have any clue when he will be available?
<ogra_> nope
<ogra_> (if you just dump your question in the channle probably someone else can answer ... dont be so tied to specific persons ;) )
<ogra_> channel
<noizer> ok xD
<noizer> I'm making a snap that doesn't need to be available in the store. This snaps needs to be able to start (execute an other snaps wrapper) an other snap. So I thought to change the AppArmor a little. But i got some issue about this. Can anyone help me out with it?
 * ogra_ wonders why the arm64 builders seem to work at half speed today 
<zyga-phone> noizer: not today, I'm deep in integrating skills with the system
<beuno> ogra_, maybe someone needs to press the Turbo button?
<ogra_> haha
<ogra_> beuno, well, seems the build is jumping between bare metal and scaling stack ... seems a build on the latter takes abotu 1h while on the former it taks between 20-30min
<noizer> zyga-phone: No problem i will try further
<ogra_> zyga-phone, skills ?
<zyga-phone> ogra_: you caught me :)
 * ogra_ prepares mail announcing the new name change :P
<zyga-phone> ogra_: no it's not renamed
<zyga-phone> ogra_: interfaces
<zyga-phone> ogra_: just stale cache in my head
<ogra_> week is over ... new name imminent
<ogra_> snappy security ... best before: next week
<ogra_> :P
<ogra_> utlemming, yo
<ogra_> utlemming, do the cloud images already use all-snaps (asking because we currently treat azure images special on the image builders and i'd like to know what to do ... specifically for the former device tarball (now kernel.snap) )
<utlemming> ogra_: the cloud images do not use all-snaps
<ogra_> utlemming, oh ? how will they work in xenial then (system-image isnt supported anymore)
<ogra_> do we drop snappy in the cloud for xenial ?
<utlemming> ogra_: the work to do that has not been scheduled
<ogra_> heh, well, 5 weeks to release ... :)
<utlemming> ogra_: ack, understood
<ogra_> (and PPAs arent allowed anymore ... changes would have to be SRUed ... i assume you know what pain that can be)
<ogra_> WHEEE !
<ogra_> livecd.ubuntu-core.raspi2.kernel.snap livecd.ubuntu-core.os.snap livecd.ubuntu-core.kernel.snap
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54636
<ogra_> :D
<ogra_> now to teach cdimage to publish that to cdimage.ubuntu.com
<ogra_> hmm, and perhaps i shoul dbuild a test image from these snaps :)
<noizer> is it possible that the security-override doesn't works?
<dpm> mvo, so I updated http://bazaar.launchpad.net/~dpm/ubuntu-clock-app/snap-all-things/view/head:/snapcraft.yaml and built it with snapcraft trunk, which succeeded. But upon installation, there seems to be some issues finding the qmlscene binary. I'm not sure there is any path changes that might have happened behind the scenes
<dpm> $ ubuntu-clock-app.clock
<dpm> qmlscene: could not exec './usr/lib/x86_64-linux-gnu/qt5/bin/qmlscene': No such file or directory
<dpm> That's the output of the newly built and sideloaded app now ^
<ogra_> dholbach, anything on the agenda ?
<jdstrand> noizer: things are always possible, especially lately with all the code and yaml updates. do you have a specific question?
<dholbach> ogra_, I'll move the call to another time for next week - it clashes with our community team meeting
<dholbach> so better let's chat next week
<jdstrand> dpm: use $SNAP/... instead of ./
<ogra_> dholbach, ok, sounds good
<jdstrand> they changed the working directory recently
<jdstrand> dpm: or, 'cd $SNAP'
<jdstrand> before hand
<noizer> jdstrand: Yes ok I will make a snapp thats not be available in the store. So I want to that the app can execute the binaries from /snaps/bin/. So then can he acces other snaps.
<jdstrand> noizer: that isn't possible
<noizer> jdstrand: So i tought i will do some changes on the apparmor so a can execute these snaps.
<dpm> jdstrand, but the "./" appears on a .conf file. I'm not sure how to do variable substitution there
<jdstrand> the reason why is /snaps/bin are shell scripts that call the launcher, which needs priviliges to set up the sandbox. those privs can't be granted to apps
<jdstrand> dpm: then do a cd $SNAP
<jdstrand> dpm: I can't really advise how to implement the fix, I'm just saying that people decided to change the working directory and your snap need to do something about that
<dpm> I'm a bit lost to what I need to do here, just cd $SNAP in the wrapper script? (I appreciate the help, thanks jdstrand!)
<jdstrand> dpm: yes
<jdstrand> dpm: right at the top of your script
<jdstrand> dpm: fyi, 'Subject: Internal format updates' on snappy-devel. in addition to the working directory it talks about icon and desktop
<noizer> jdstrand: how can i make it possible then?
<dpm> jdstrand, yeah, that's why I started doing the changes
<ogra_> mvo, http://paste.ubuntu.com/15335324/ whats that "Removing unneded" message about ? (do i need to worry ? )
<ogra_> the resulting image boots fine
<jdstrand> noizer: it is only going to be possible if you do security-policy and have a very lenient profile, but this is going against how snappy works. typically, you bundle what you want in one snap. it is possible to do stuff with frameworks on 15.04, but frameworks are going away in favor of interfaces. the interfaces work is very much still being worked out, but at some point there will be a way for you to approach Canonical for new interfaces and then C
<mvo> ogra_: hm, that looks a bit scary. image boots and has all the snaps you expect it to have?
<ogra_> mvo, yeah
<ogra_> mvo, the snaps are from https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/+build/54634
<mvo> ogra_: aha, I do remember now, its fine
<ogra_> cool !
<mvo> ogra_: sorry, its a misleading message
<ogra_> then the livecd-rootfs built snaps all work :)
<mvo> ogra_: \o/
<ogra_> cdimage publishing pending :)
<noizer> jdstrand: so it will be possible in the future? but can I have now the solution because then i can test further with my code.
<noizer> jdstrand: I know its not how snappy works but it would be awesome for me that i would make 1 snap with some other priviliges.
<ogra_> you can surely make a completely unconfined snap and sideload it
<noizer> ogra_: how can i do that?
<elopio> ping ogra_: what triggers this? https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image
<elopio> an update in the PPA?
<ogra_> noizer, not sure how you do it in this weeks seciroty model ... two weeks ago i could do http://bazaar.launchpad.net/~ogra/+junk/htop-unconfined/view/head:/snapcraft.yaml
<ogra_> elopio, a cron job on "nusakan" (which is what outsoders know as cdimage)
<ogra_> *outsiders
<elopio> ogra_: awesome. That is solving half of the unknowns I had :D
<ogra_> elopio, well, or a manual call from a member of the cdimage team (like i did a few yesterday and today tomake the new snap bild code work)
<jdstrand> ogra and nozier: with ogra_'s example, do 's/uses/plugs/' and 's/type: migration-skill/interface: old-security/'
<ogra_> jdstrand, thanks ! (saves me from looking it up)
<elopio> ogra_: cron is alright. A url we can trigger would be even better, but nothing to worry about now. We hope to have solved the dput into the ppa by friday. I'll get back to you after.
<ogra_> elopio, if you clock on one of the last "Successfuly built" links you now find os and kernel snaps there
<noizer> jdstrand: ogra_ huh i don't understand it very good
<ogra_> *click
<ogra_> (note "last" means at the top)
<elopio> ogra_: yes, that's what I saw and that's why I'm happy.
<elopio> thank you.
<jdstrand> noizer: every place you see 'uses' in ogra_'s example, use 'plugs' instead
<ogra_> elopio, i currently work on making them show up on http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ... and then hope the store can pull them into the edge channel from there
<jdstrand> noizer: and every place you see 'type: migration-skill', use 'interface: old-security' instead
<elopio> ogra_: we can pull them from jenkins, and push them from there too. I'm not sure what's best yet.
<jdstrand> mvo: is this cause for concern: http://paste.ubuntu.com/15335485/
<ogra_> elopio, well, i like the idea that you could manually pull them from cdimage and test them ... its our canonical place for all official image fragments
<noizer> jdstrand: just a stupid question whats de difference between slots and plugs
 * jdstrand wonders why we are so emphatic with the developer ("canonical!")
<jdstrand> noizer: one is the providing side and one is the consuming side
<jdstrand> you provide a slot for a plug
<elopio> ogra_: I think I like that too. The only detail I'm thinking about is beta. I think that if we put the better tested beta in that daily folder, the testers would get a better experience than with edge.
<ogra_> elopio, i dont really care how they get into the store after this :) but we need them in the store to test upgraeability (snappy refuses to upgrade sideloaded packages)
<elopio> but we can adjust everything.
<jdstrand> ths os provides the old-security interface as a slot that apps may plug into
<elopio> we have all this blocks, it's easy to move them around.
<ogra_> yeah
<jdstrand> noizer: see the snappy-devel mailing list for more info
<jdstrand> noizer: but my summary is hopefully good enough
<noizer> jdstrand: an unconfined app i cant execute then the snaps/bin executables :s
<jdstrand> using the 'unconfined' template won't give you enough cause you need to be able to change profiles, etc
<elopio> ogra_: we are testing upgradeability with a fake store and a fake snap. That was really cool by mvo.
<elopio> We do need to test real updates and we have all the jobs ready, so yes, we need to upload to the store. But that's my least concern, we are already uploading snaps in the snapcraft suite (also a cool thing by pindonga).
<jdstrand> you need security-policy with unrestricted seccomp and lenient policy. you would need to look at /etc/apparmor.d/usr.bin.ubuntu-core-launcher for some of the perms
<jdstrand> fyi, this isn't the proper way to do things-- you're going to be quite on your own here
<ogra_> elopio, hmm, i thought we'd now work by store channels only ...
<noizer> jdstrand:   then i can change some profiles from seccomp and apparmor?
<jdstrand> noizer: you do something like this
<jdstrand> plugs:
<jdstrand>   "my-confinement":
<jdstrand>     interface: old-security
<elopio>  ogra_: well, not only. We can't upload the snap from pull requests to the store because they will be generally broken and conflicting and confusing. At that stage, we fake.
<jdstrand>     apparmor: path/to/apparmor/profile
<elopio> once we land into master/edge, we test the real thing.
<jdstrand>     seccomp: path/to/seccomp/profile
<beuno> elopio, ogra_, so, apps that are uploaded but not published to any channel are accessible by specified users
<beuno> you can CI it in every real sense without putting it in a channel
<elopio> beuno: that's interesting.
<jdstrand> noizer: put @unrestricted in path/to/seccomp/profile, and then adjust path/to/apparmor/profile to be what you want. you might start with what is in /usr/share/apparmor/easyprof/templates/ubuntu-core/16.04/unconfined
<elopio> beuno: are we going to be able to select a channel or not channel from snapcraft upload?
<beuno> elopio, getting a snap into the store involves 2 steps: upload & publish
<beuno> when you upload, you get back a revision which makes it accessible if you have upload rights to the snap
<jdstrand> noizer: if you ignore the package.yaml stuff in this page, there are things that might help: https://wiki.ubuntu.com/SecurityTeam/Specifications/SnappyConfinement/DevelopingFrameworkPolicy
<beuno> publishing is what actually makes it distributable via a channel
<jdstrand> noizer: at this point, you are far outside the snappy system and I've got to focus on the snappy system atm. good luck!
<noizer> jdstrand: hahah ok thx. but why can people start services and stop services from any snap they want with a REST api?
<jdstrand> noizer: because that breaks application isolation. apps aren't supposed to be able to mess with other snap's apps
<elopio> beuno: ok, I'll check again. So, no snapcraft publish command? We'll have to go to the URL.
<beuno> elopio, snapcraft still needs to grow the publish command, yes
<jdstrand> noizer: this isn't a reimplementation of the traditional linux distro, this is a new way of doing things
<elopio> great, that's even better :)
<jdstrand> noizer: you are free to stop and start your own services of course. the snap rest api may provide things for stopping and starting services. you might talk to Chipaca on if it does
<elopio> sudo snappy service ...
<jdstrand> noizer: if the snappy rest api allows for that, you can use:
<jdstrand> interface: old-security
<jdstrand> caps: [snapd]
 * jdstrand notes that old-security/caps is going away soon in favor of native interfaces
<noizer> jdstrand: but is it possible then to say to the service that he don't start while booting
<jdstrand> noizer: I don't think so, no
<jdstrand> maybe
<noizer> jdstrand: when this is possible i can start an application over services
 * jdstrand didn't design or implement the snappy rest api
<ogra_> beuno, elopio, well, we are talking about image testing ... so i guess ubuntu-device-flash will be involved ... i'm not sure it can currently deal with unpublished snaps apart from treating them as sideloaded
<ogra_> i know it can download from edge if i pass /edge to the snap name though
<elopio> ogra_: I'm sorry, I'm talking about everything at once.
<ogra_> but then the snap has already been published to the edge channel
<elopio> in particular, this unpublished thing is great to test the snapcraft examples. But I might find it useful in the snappy suite to.
<elopio> too
<ogra_> elopio, right, my focus is more on images currently :)
<elopio> ogra_: I know. That's why I'm not yet with you. Figuring out the earlier steps first.
<ogra_> well, snapcraft wont be involved in our image builds
<ogra_> (the builder doesnt really have access to the outside world beyonf the ubuntu archive)
<ogra_> (on purpose)
<elopio> ogra_: that's the part we need to figure out where to put. I want that a new OS snap is published to beta only if all the snapcraft examples pass on it.
<elopio> we don't need to generate an image for this tests
<ogra_> how else would you use the os snap if not in an image ?
<elopio> we will generate it only if the tests pass and the snap is promoted to a higher channel.
<ogra_> mount the squashfs and chroot ?
<ogra_> you kind of need to test the os snap in context (if the initrd doesnt set up your bind-mount farm to get you writable bis you cant boot etc etc)
<elopio> ogra_: hah, three possible tricks. The one we are using now is just calling a different snappy binary, not installed. The second option is to build the snap and get it installed through the fake store, or something. The third would be to generate our own image with udf and upload it to scalingstack, but I'm trying to avoid this one.
<ogra_> i cant imagine how to test that without at least generating an imge and boot it in a VM or some such
<ogra_> elopio, i think the last one is the only valid one ... else you will never test in real context
<ogra_> you need to knwo the boot process works, the env is correct after booting and ... well, then test the binaries etc
<elopio> ogra_: remember that I'm this week on the early stages. The focus is to test the snappy commands they are adding to the master branch, not the bootloader or the kernel.
<ogra_> ah, so only the snappy binary itself ... ok
<elopio> we have jobs in place to test the whole image in later stages. We need to add more coverage there, but we have a basic verification in place.
<ogra_> i thought you meant the os snap
<elopio> yes, I excused myself because I'm throwing all the topics at once.
<elopio> for this week, the least context and most isolation we can get, the better.
<ogra_> heh, i'm just slow in understanding today :)
<ogra_> to much cdimage code in my brain for the last two days ... that does weird things to you
<noizer> Chipaca is it possible to disable starting on boot a service?
<Chipaca> noizer, deactivate the snap?
<elopio> weird is the new cool.
<elopio> I'm happy not looking at cdimage though.
<noizer> Chipaca no no the app needs to be active but services (background-app) start automatically
<Chipaca> noizer, disable the service then
<noizer> can i start it later?
<Chipaca> noizer, or stop shipping it, if you don't want it to run :-)
<Chipaca> noizer, 15.04, or 16?
<noizer> Chipaca no i want to start it later with the REST api
<noizer> Chipaca it is 16
<Chipaca> noizer, enable/disable using the rest api
<Chipaca> noizer, e.g., http.POST snapd:///2.0/snaps/snap.mine/services/a-service action=disabe
<Chipaca> noizer, using http.chipaca
<Chipaca> disable*
<Chipaca> noizer, that'll probably change before 16 GA, moving to not need the .mine there
<Chipaca> noizer, enabling is with action=enable, obvs
<noizer> Chipaca hmmm can i init that so thats disabled by default?
<Chipaca> noizer, no
<noizer> Chipaca ok
<noizer> Chipaca Thx for the help
<Chipaca> noizer, if you need that feature, file a bug? but we're all full of things to do for 16 so i doubt we'd be able to do it any time soon
<noizer> Chipaca ok or maybe make it myself?
<Chipaca> noizer, what do you mean?
<noizer> Chipaca the disable function of services?
<ogra_> write a patch ?
<beuno> ogra_, I'm sure u-d-f could be taught to access snaps by revision
<beuno> and then you just make sure it has the right credentials
<ogra_> beuno, indeed it could, i was just talking about the status quo
<ogra_> it needs code :) and that needs someones time
<beuno> luckily, I'm ignorant about a lot of quo's
<ogra_> haha
<dpm> jdstrand, it worked! :)
<dpm> cd $SNAPPY, that is
<dpm> thanks a lot for the pointer
<jdstrand> dpm: woo!
<lool> kyrofa: hey! around?
<lool> All, when using multiple python2 parts in snapcraft, each part pulls a python2 runtime and then the parts clash when installing; what's the most elegant way of dealing with this?
<ssweeny> I'm working on building location-service for snappy and running into an interesting issue. When linking against apparmor it's picking the static lib in /lib/<triplet> which fails because everything else is built shared with -fPIC. I can work around by removing /lib/<triplet>/libapparmor.a or adding an unversioned .so symlink to the .so there but I'd like to solve the problem a bit more elegantly if possible :)
<ssweeny> this is snapcraft on xenial
<ssweeny> I notice that there is a .so symlink in /lib/<triplet> when the apparmor-dev package is installed but not in the staged version in my snap
#snappy 2016-03-10
<stgraber> I just uploaded a new version of lxd to the store, no change to policy, would be nice if it could go through soon, we've had a few folks complaining that 0.21 was a bit dated (by about 6 months :))
<stgraber> jdstrand: ^
<dholbach> good morning
<didrocks> good morning dholbach
<dholbach> salut didrocks
<noizer> good morning!
<noizer> How can I see that my custom seccomp and apparmor file is applied to my snap?
<noizer> jdstrand:   can I see that my custom seccomp and apparmor file is applied to my snap?
<mvo> willcooke, dpm: good news, the most recent snappy upload to xenail (should hit xenial-proposed with the next publishing) will have unity7 integration, i.e. nothing (hopefulyl) more to do. install cap-test and it will show up in dash searches etc (make sure you restart your session once after updating snappy because it installs a Xsession.d file for this). I'm very excited!
<willcooke> mvo \m/
<willcooke> mvo, thank you!!!
<willcooke> Trevinho, ^^
<dpm> mvo, awesome! I just managed to upload calculator to the store, for which I included the .desktop file support. I'll go ahead and test that too!
<dpm> just literally a few minutes ago
<dpm> so I'll give unity 7 integration a spin once I see the new snappy package in the archive
<mvo> dpm: yeah, xenial-proposed, there is a build failure on powepc that I look at next so it won't promote right away
<dpm> ok
<mvo> dpm: but you can directly grab the two debs from LP if you are eager to test :)
<mvo> dpm: plus the updated ubuntu-core-launcher but that will come as a normal update
<dpm> mvo, thanks. I am eager :), but I think I'll wait if it's just a matter of hours, which might save me some extra fiddling
<zyga> o/
<zyga> noizer: yes, look at /var/lib/snappy/{apparmor,seccomp}
<mvo> dpm: you are eager and WISE at the same time :)
<dpm> lol
<noizer> zyga:  ok i was looking at the correct files but with security-policy it doesn't work. http://pastebin.com/DmAdrhU3
<noizer> zyga: do you have any clue why my apparmor and seccomp files doesn't apply to my snap?
<dpm> mvo, how do updates to the ubuntu-core snap happen on the desktop? It is a bit like magic to me. I've tried "sudo snappy upgrade ubuntu-core" a few times and it tells me there are no new versions. Yet every now and then I see it updated automagically when I run "snappy list --verbose". So I'm not sure if this is something that needs to be manually maintained (and how?) or is autoupdated
<zyga> noizer: s/slots/plugs/ -- use the lastest released snapcraft (just released yesterday AFAIR) and it should work
<zyga> noizer: good luck
<zyga> noizer: sorry about the swap, it's stabilizing now
<noizer> Just switch between slots and plugs?
<zyga> noizer: you'll have access to many useful interfaces next week (+1/-1 image release)
<zyga> ye0
<zyga> yes
<noizer> But to be honest i think i need an unconfined snap just for my thing. So i try to make it by changing the apparmor and seccomp file
<Trevinho> mvo: great to hear
<noizer> zyga ok thx with plugs it works to edit the apparmor just need to see that mine apparmor is correct but now it fails
<zyga> noizer: sorry, I don't get the last part ;; what failed?
<noizer> wait i got the following error when I'm installing my snap with a custom apparmor
<noizer> zyga:  error, unexpected TOK_ID, expecting TOK_END_OF_RULE
<noizer> zyga: thats an error of mine apparmor
<zyga> noizer: yeah, I think your apparmor is just wrongly spelled
<zyga> noizer: btw there's an unconfined template that you can reference
<zyga> noizer: look at your desktop
<ysionneau> ah, snapcraft has been updated yesterday with the plugs/slots switch o/
<ysionneau> cool
<zyga> noizer: dpkg -L ubuntu-core-security-apparmor
<zyga> ysionneau: yep
<ysionneau> hmm would there be any interest in chrooting into $SNAP (after doing some bind mounts) ?
<ysionneau> I mean, before running an app
<zyga> ysionneau: why?
<ysionneau> that would for instance allow the app to use hard coded absolute paths
<zyga> ysionneau: and not allowed to do many other things
<zyga> ysionneau: I don't think this is needed
<ysionneau> this could be useful for some apps I  think, so that you don't have much work to "port" them to snappy
<ysionneau> instead of having to rewrite lots of code
<ogra_> i doubt chroot will be allowed by seccomp
<ysionneau> That could be an option in the snapcraft.yaml like "chroot: yes"
<ogra_> bu tthat doesnt stop you from shipping a full rootfs if you want and bend the env to completely use it
<ogra_> which would be close to a chroot
<ysionneau> what do you mean by "bend the env" ?
<ysionneau> I'm not sure there is a trick to allow an app to write to "/var/lib/<something>"
<ysionneau> other than chrooting
<ogra_> well, pretty much what the ubuntu-core-launcher does already but also make it use the shipped toolchain, linker, libc
<ysionneau> or maybe an LD_PRELOAD to hook open()
<ogra_> as long as $SNAP and $SNAP_DATA are on the same device you might be able to use hgardlinks for writable bits and dirs
<ysionneau> but, whatever I do, /var/lib/ will stay read-only
<ysionneau> that's my main issue
<ogra_> change it to ./var/lib then :)
<ogra_> (indeed that might mean to recompile the world ... i didnt say its easy ;) )
<ysionneau> the thing is, there are lots of occurence of this type of issues in the different softwares I want to "port" to snappy
<ysionneau> so I'm not a big fan of this solution
<ysionneau> (by solution here I mean pushing fixes in the code everywhere to use env VAR instead of hard coded absolute paths)
<ogra_> indeed ...
<ogra_> dont you need to just re-do the linker path though ?
<noizer> zyga: the unconfined template can he make some calls to /snaps/bin/... ?
<ogra_> noizer, unconfined apps have all the power a natively installed deb would have
<noizer> so he can exectute all things?
<ysionneau> 12:02 < ogra_> dont you need to just re-do the linker path though ?  < I'm talking about normal "open()" here, not library paths issues
<ogra_> (its just the paths and workdir that are different then ... )
<ysionneau> or maybe I don't understand what you propose :o
<ogra_> oh, open() in your code, i see
<ogra_> well, if you cant get around that one, you can always use lxd or docker
<ysionneau> ah, interesting!
<ogra_> that equivalent to a chroot i'd say (just a bit more secure)
<ysionneau> thanks!
<ysionneau> will think about that :)
<zyga> noizer: maybe not
<zyga> noizer: it's not so simple
<zyga> noizer: you cannot change aa profile anyway *AFAIR*
<noizer> zyga:   do you mean with AFAIR
<zyga> noizer: as far as I remember
<zyga> noizer: it's not identical to really unconfined
<zyga> noizer: but it very broadly permissive
<noizer> zyga: What I now did is took an empty apparmor and try to execute an binary from /snaps/bin/
<noizer> I see it is then possible to execute the binary
<noizer> zyga: But then i see the following error:
<noizer> error: /bin/sh: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
<zyga> noizer: I don't think that will work
<zyga> noizer: try doing what I said
<zyga> noizer: use old-security and unconfined template
<noizer> ok
<noizer> zyga: then i should be able to execute the binary?
<noizer> zyga: got then following error: aa_change_onexec failed with -1. errmsg: Permission denied
<ogra_> noizer, why didnt you fiollow jdstrand's advise from yesterday ?
<ogra_> *advice
<zyga> noizer: that's exactly what I said
<zyga> noizer: you cannot change aa profiles
<zyga> ogra_: what was the advice?
<ogra_> zyga, i gave him an existing (outdated) unconfined snapcraft.yaml and jamie gave all hints to adapt it to the new interfaces setup
<ogra_> there is no need to fiddle with apparmor files
<zyga> ogra_: i suspect that unless there were explicit changes somewhere you still cannot (even unconfined) run other snaps from your snap
<ogra_> why not ?
<zyga> ogra_: it's not allowed, even for unconfined programs (that are really confined but broadly permissive)
<ogra_> unconfined has the same powers as a deb ... just that all paths and the workdirs are completely mangled
<zyga> ogra_: I went through this issue a few times
<zyga> ogra_: nope
<zyga> ogra_: that is not true
<ogra_> i have an unconfined  debootstrap that woprks just fine
<zyga> ogra_: unconfined still gives you aa profile and seccomp profile and a cgroup for devices
<zyga> ogra_: it's not the same as running from the ssh shell
<ogra_> i dont see why an unconfined systemctl shouldnt be able to control services for example
<zyga> ogra_: because that's what's spelled out in unconfined, we'd have to make super-unconfined that has extra powers
<zyga> ogra_: FYI I'm not arguing with you; I'm just telling you how it really works today
<ogra_> so unconfined changed ?
<zyga> ogra_: no, it was always like that
<ogra_> with the last iteration
<zyga> ogra_: unconfined != not confined in practice
<ogra_> right
<zyga> ogra_: it was like that in 15.04
<zyga> ogra_: and I suspect still is in 16.04
<ogra_> well, unconfined in 15.04 lets me do everything with my system
<ogra_> i dont think your seccomp assumption is true
<zyga> ogra_: it's 100% true for aa
<ogra_> but aa wont be used in unconfined
<zyga> ogra_: you cannot load another aa profile while running unconfined profile
<zyga> ogra_: it _is_
<zyga> ogra_: 100% guaranteed it is
<zyga> ogra_: we've been through this many times in cert
<ogra_> you can not load another aa profile because aa_exec isnt in use at all
<zyga> ogra_: I don't think this is true, in any case, as unconfined snap, you cannot run other snap's apps
<ogra_> no, but youz can run thes system systemctl
<zyga> ogra_: sure but the error that noizer saw is exactly what I was describing
<zyga> ogra_: not related to systemctl
<dholbach> dpm, so snapcraft seems to do just what click-review expects:
<dholbach> snapcraft/commands/snap.py:    mksquashfs_args = ['-noappend', '-comp', 'xz', '-all-root', '-no-xattrs']
<dholbach> and for snappy it's http://paste.ubuntu.com/15340831/
<dholbach> the latter seems to miss "-all-root"
<dholbach> that was in snap/squashfs/squashfs.go, but in obj-x86_64-linux-gnu/src/github.com/ubuntu-core/snappy/pkg/snapfs/pkg.go it has the "-all-root" option
<dholbach> mvo, is there a reason that in one of the mksquashfs incantations the "-all-root" option is missing?
<zyga> dholbach: (mvo went for lunch, may reply with lag)
<dpm> dholbach, then perhaps an issue in click-review-tools? As I built the app with snapcraft, and I *think* LP does it with snapcraft as well
<dholbach> zyga, thanks
<ogra_> dholbach, --all-root means that all your files are chowned to root inside the squashfs ... probably not wanted in all cases
<dholbach> dpm, it might, yes
<ogra_> (definitely not for os snaps for example)
<dholbach> dpm, I just thought I'd check all incantations first :)
<dpm> makes sense, thanks dholbach :)
<noizer> zyga: So as conclusion it is not possible at all what I want even when i get my custom aa?
<noizer> zyga: or does i understand it completly wrong?
<zyga> noizer: you'd have to talk to jdstrand and ask if it is possible to use a custom template to unlock running other snaps from "unconfined" snap
<zyga> noizer: technically it is possible, it's just the matter of having the right template or the right extra bit in an existing template
<zyga> noizer: but jdstrand will know how (though he's super-busy so you might not get a quick answer)
<dholbach> jdstrand, I'm still seeing http://paste.ubuntu.com/15340881/ - do you know what the issue is?
<dholbach> that's with r605
<dholbach> dpm, it might be https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305
<ubottu> Launchpad bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed]
<dholbach> http://paste.ubuntu.com/15340912/ is what I tried
<dholbach> http://paste.ubuntu.com/15340914/ was the result
<dholbach> dpm, so it sounds like it's a known problem with snaps containing symlinks(?)
<dholbach> the mksquashfs arguments cited in the error message might be a red herring
<kyrofa> Good morning!
<dholbach> hey kyrofa
<kyrofa> lool, looks like you pinged me yesterday, you around?
<kyrofa> Hey dholbach, how are you?
<dholbach> good good - how about you? :)
<kyrofa> Not bad! Been out the last few days, felt nice
<kyrofa> Though now I have ~300 emails to slog through
<dholbach> good luck with those :)
<dpm> dholbach, weird, as the errors weren't triggered with the first rev1 upload
<dpm> thanks for digging it out
<dholbach> dpm, let me doublecheck - it could be that click-reviewers-tools didn't have the check at the time :-)
<dpm> ok!
<dholbach> dpm, looks like the old snap has the same problem
<dpm> strange, no errors were triggered on the rev1 upload
<noizer> zyga: ok so I don't need to change the apparmor from my snap because there are some other things thats needs to be done?
<zyga> noizer: no, you didn't understand what I said; I think it *is* possible technically but you have to figure out the right aa syntax by youreself
<zyga> noizer: I don't know how to do this FYI
<noizer> zyga ok thx in advance
<ogra_> mvo, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ... done ... all os and kernel snaps are now published there
<ogra_> (now onward to creating the dragonboard kernel.snap ... )
<dholbach> dpm, sorry didn't see your reply... as I said earlier: I think back when you uploaded rev1, click-reviewers-tools probably didn't have this check - it was added quite recently
<dpm> dholbach, ah, thanks. I had seen it, but somehow I hadn't connected the two. I'll blame it to multitasking rather than admitting I misread it :)
<dholbach> no worries :)
<dholbach> I just checked - there were 9 days between the uploads - an eternity in snappy's world :-P
<mvo> ogra_: nice
 * ogra_ tries a test build 
<ogra_> ubuntu@localhost:~$ snappy list
<ogra_> Name               Date       Version      Developer
<ogra_> canonical-pc       2016-02-02 3.0          canonical
<ogra_> canonical-pc-linux 2016-03-10 IOTfGNaBRCTJ sideload
<ogra_> ubuntu-core        2016-03-10 IOTfGOFdgPKF sideload
<ogra_> boots :)
<mvo> dholbach: that are the 9 days in which we rewrote it in hylang
<dholbach> mvo, good to hear you're focusing on the important stuff :-P
<ogra_> hylang ? not perl ?
<ogra_> hmm, webdm still not proted to interfaces ?
<ogra_> funny how all snaps are pretty exactly 20MB smaller than their tarball equivalents ... that seems to be constant, not actually a percentage or anything
<techraf> hello, I'm new here
<ogra_> hello techraf
<kyrofa> Hey techraf, welcome!
<techraf> I was trying to create example snaps -> with snapcraft 2.0 I could "snapcraft snap" and had .snap in result
<techraf> the same "snapcraft snap" 1.0 does not produce anything
<techraf> at least it does not create .snap
<kyrofa> techraf, right, the command-line is a little different in 1.x
<kyrofa> techraf, try just `snapcraft`
<kyrofa> techraf, the actual step in 1.x is called "assemble," but calling snapcraft with no arguments is equivalent
<techraf> snapping...
<kyrofa> techraf, `snapcraft --help` might be useful
<kyrofa> techraf, compare the output between versions, you'll see similarities
<techraf> will do, success so far
<techraf> you helped me much, thank you
<kyrofa> techraf, any time :)
<zyga> jdstrand: hey
<zyga> jdstrand: I've send you a ping on github for a code review
<zyga> jdstrand: it's not urgent but I'd love if we could spend a moment to go over the code there
<zyga> jdstrand: and ensure it's all good
<kyrofa> didrocks, how are things going for you this week? Examples still coming along?
<jdstrand> zyga: sure thing
<jdstrand> dholbach: can you give me the snap?
<jdstrand> noizer: hey, as mentioned, you are pretty outside of snappy atm and this is the snappy channel. since your questions are now of the form "how to profile with apparmor" I suggest taking a look at 'man apparmor.d' and bringing your questions up on #apparmor on oftc
<jdstrand> noizer: also, I saw your paste and you need to use 'plugs' instead of 'slots'
<jdstrand> noizer: be sure you are using snapcraft 2.4
<noizer> jdstrand I am using now snapcraft 2.4
<noizer> jdstrand: I am trying some things but now without any success xD
<jdstrand> noizer: I would start with using plugs instead of slots, otherwise you get the default confinement. also, you can see what confinement is bing used in /var/lib/snappy/apparmor/profiles
<jdstrand> being
<jdstrand> oh, that was in the wiki page I gave you yesterday
<jdstrand> dpm: you asked for someone to push the calculator through. did that happen? when I looked it wasn't showing up for review. if it didn't happen, can you request a manual review?
<noizer> jdstrand: I saw that today and now I am using plugs. and my apparmor changes
<jdstrand> ok good. now you are in the realm of how to profile
<jdstrand> that is where #apparmor can help
<noizer> Ok is that from snappy developers too?
<jdstrand> noizer: that is what I was saying you should take to #apparmor on oftc
<jdstrand> that has apparmor developers and community
<dholbach> jdstrand, I did a fresh checkout from c-r-t and ran ./bin/click-review on the .snap from https://myapps.developer.ubuntu.com/dev/click-apps/4630/rev/2/
<dholbach> with the installed version (0.38 from xenial) it does not crash
<zyga-phone> jdstrand: thanks
<jdstrand> mvo: are paths like this intended: /etc/systemd/system/snaps-cap\x2dtest.sideload-LSXRFfhCCLCY.mount
<jdstrand> mvo: the '\x2d' is causing bzr (etckeeper) to crash
<jdstrand> and it isn't clear why '-' is being escaped there and nowhere else
<jdstrand> unless you are using '-' as a delimiter, in which case I would suggest '_', since that isn't an allowable char in the snap package name
<jdstrand> (or some other not allowed char)
<jdstrand> dholbach: when you checked out crt and did ./bin/click-review, did you set PYTHONPATH? if not, you need to: PYTHONPATH=./ ./bin/click-review /path/to/snap
<dholbach> jdstrand, oh?
<dholbach> since when?
<jdstrand> always
<zyga-phone> jdstrand: sounds like misisng setup.py --develop in hacking docs
<jdstrand> otherwise you end up using what is in /usr
<dholbach> hohum
<zyga-phone> dholbach: this is typical to all python code
<dpm> jdstrand, dholbach helped me on this. I hadn't realized last night that I needeed to explicitly say "Request manual review". The apps are now published. We still don't know what the issue with the checksum is, but at least the published apps work as opposed to the old ones not working after the plugs<->slots change
<dholbach> jdstrand, confirmed
<dholbach> thanks
<jdstrand> dpm: you went offline before I could respond. the checksum issue is https://bugs.launchpad.net/ubuntu/+source/click-reviewers-tools/+bug/1555305
<ubottu> Launchpad bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed]
<noizer> jdstrand pff there aren't many people on #apparmor
<jdstrand> noizer: on OFTC?
<jdstrand> dpm: I have disabled the test for now until I can fix that
<dpm> ok, thanks
<noizer> jdstrand: sorry did some typo
<jdstrand> dholbach: ok, with PYTHONPATH, I can confirm it as well
<jdstrand> dholbach: I don't recall, did you file a bug for this? if not, don't worry about it
<mvo> jdstrand: I think the pats are the result of calling systemd-escape
<jdstrand> hrm
<jdstrand> I guess I'll file a bug against bzr and workaround it
<didrocks> kyrofa: hey! More busy with the developer website content. On the examples, I'm waiting for the poll feedback we launched with dholbach first to see if people like them :)
<kyrofa> didrocks, awesome!
<kyrofa> dholbach, how is that poll coming? I'm looking forward to seeing that myself
<jdstrand> dholbach: oh, heh, nm, I typoed PYTHONPATH. it works fine here, so nothing to do
<zyga-phone> jdstrand: I'll dive into more coding, ping me when you have a moment to go through that diff
<kyrofa> dholbach, do the review tools catch symlinks that point outside the snap?
<dholbach> kyrofa, yes
<jdstrand> zyga-phone: yeah, haven't gotten out of email and irc pings yet
<kyrofa> dholbach, ALL of them, no allowed whitelist or anything?
<dholbach> kyrofa, there's a whitelist
<kyrofa> dholbach, oh darn, that throws a wrench into my plans. Can I have a look at that list?
<elopio> hey kyrofa, you are back. I'm sorry, I assume we wouldn't have standup today.
<kyrofa> elopio, I am indeed! And that's okay :)
<elopio> I'll make it on time tomorrow.
<dholbach> kyrofa, http://bazaar.launchpad.net/~click-reviewers/click-reviewers-tools/trunk/view/head:/clickreviews/common.py#L631
<kyrofa> dholbach, excellent thank you :)
<kyrofa> elopio, how has the week been going?
<kyrofa> I finally made it through my emails, looks like we cranked out 2.4, nice
<elopio> kyrofa: yes, thinks are looking good. I'm still blocked on the closed ports to test the http examples, but most of the tests are running now.
<elopio> sergio is doing good progress on the kernel, he said it's almost ready.
<kyrofa> elopio, yeah I just looked through it
<kyrofa> elopio, no tests to speak of, but the code is looking pretty good
<kyrofa> elopio, and looks like you were able to greatly speed up travis tests, eh? Needs a rebase though
<elopio> kyrofa: yes, it's running again.
<elopio> I'm sad because we are no longer running on xenial, but I hope they will just update the machine in april.
<kyrofa> elopio, don't get your hopes up-- I think they still run on 12.04 by default unless you request trusty
<kyrofa> elopio, I get the impression that their architecture is very tightly integrated
<elopio> they are still calling them beta, the trusty machines...
<elopio> but it's GCE. I see no possible way it will be different to manage a xenial in there.
<elopio> I'm also sure they can prove me wrong :)
<kyrofa> elopio, heh
<varaindemian> is ubuntu trying to simlify the building process from source code? Is it trying to make something like "ports"/ABS-arch?
<zyga> varaindemian: no
<varaindemian> zyga, is ubuntu core a different os or is part of ubuntu?
<ogra_> it is a new type and setup of ubuntu (not using apt/dpkg in the runnung system, special filesystem setup, all the shiny new features of teh snappy package manager) but still ubuntu
<genii> varaindemian: http://www.ubuntu.com/internet-of-things
<varaindemian> ogra_, so ubuntu 16.04 lts won't have the snappy sotre
<varaindemian> store
<varaindemian> ogra_, right?
<ogra_> the snappy packagemanager will be shipped in ubuntu 16.04 installs
<ogra_> so you can indeed use snap packages from the store
<varaindemian> ogra_, oh, so I cna build packages for my own system right?
<ogra_> (on these systems thats additionally to dpkg packages)
<ogra_> yeah
<ogra_> you can use snapcraft to package up your github projects as snaps
<ogra_> (or whatever other projects yoou have)
<varaindemian> ogra_, nice and the building process from source code will be simplified?
<ogra_> yeah, snapcraft makes that pretty automated
<varaindemian> so cool
<ogra_> you create a yaml file that describes the build and just run the snapcraft tool in your workdir ... out comes a snap :)
<varaindemian> ogra_, Really really interesting. How would that differ compared to an os that uses "ports like" system?
<ogra_> dunno, i never used a "ports like" system
<ogra_> what you deal with are binary packages though ... the store also doesnt care about source (you can even snap up complete binary blobs if you want)
<ogra_> snapcraft just makes it easy to create them but source isnat mandatory
<ogra_> *isnt
<ssweeny> jdstrand, I'm trying to build location-service in snappy for 16.04 and it seems to want to link against libapparmor.a rather than the shared library. As best I can tell when I stage apparmor-dev in snapcraft something isn't running that sets up the unversioned .so symlink in /lib/<triplet>. Have you seen this sort of thing before?
<ssweeny> is it that staged packages are just unpacked and no scripts or triggers are run?
<kyrofa> ssweeny, you got it
<kyrofa> ssweeny, they're only unpacked
<kyrofa> ssweeny, no postinst, etc
<ssweeny> hm
<ssweeny> thanks kyrofa. is there some easy way to manipulate the staged tree as part of the build? i.e. remove a file or add a symlink
<ssweeny> this is the only library that has an issue for me while building
<kyrofa> ssweeny, I typically install the -dev packages as build-packages and only include the runtime packages as stage-packages
<kyrofa> ssweeny, have you tried that?
<ssweeny> kyrofa, I did try that but the build step was looking for stuff in stage
<ssweeny> so I assumed I was wrong
<jdstrand> ssweeny: I haven't no. I imagine I am going to run into this on my next snappy-debug upload though, so I'm interested in what comes of this
<ssweeny> kyrofa, so the theory of operation so to speak is the build-deps go in build-packages and runtime deps go in stage-packages.
<ssweeny> i can try it again but I'm certain it was looking for headers in stage/include/foo
<kyrofa> ssweeny, indeed. Not to say that having -dev in stage would hurt anything, but it bloats your snap unless you exclude them
<ssweeny> right
<ssweeny> ok I'll try it again. Maybe I was hitting a bug :)
<ssweeny> thanks kyrofa
<ssweeny> jdstrand, i'll let you know what I find
<kyrofa> ssweeny, yeah let me know as well
<ysionneau> do I understand correctly that it's not yet possible for an app to bind a unix socket?
<ysionneau> the unix-listener policygroup is marked as # TODO
<ysionneau> and I get a "denied" for this: Mar 10 16:24:48 localhost kernel: [182550.868636] audit: type=1400 audit(1457627088.221:21): apparmor="DENIED" operation="bind" profile="wifid.sideload_foreground_LSbLDVfnJSlm" pid=2988 comm="ld-linux-armhf." family="unix" sock_type="stream" protocol=0 requested_mask="bind" denied_mask="bind" addr="@776966696400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
<jdstrand> ysionneau: on 16.04 all of this is in flux. unix-listener is actually going away and there will be a proper interface for this
<ogra_> inter-app sockes within the same snap should be possible though ...
<ysionneau> jdstrand: ok thx
<jdstrand> ogra_: yes, but perms need to still be allowed
<jdstrand> it is being worked through
<ogra_> oh, even if the socket sits in SNAP_DATA ?
<jdstrand> ysionneau: today, use a named socket
<jdstrand> if that is possible
<jdstrand> since only file rules are in effect with those
<jdstrand> ysionneau: let me check the default policy real quick
<jdstrand> ogra_: this is an abstract socket
<ogra_> oh, right
<jdstrand> neither 15.04 nor 16.04 allow binding to an abstract unix socket. 16.04 will have an interface for that
<jdstrand> but like I said, it should work if you use a named socket
<jdstrand> (iirc)
<jdstrand> zyga: ok, I'm going to go pretty deep on this review and really study how things are being put together (except perhaps the xmanager bits)
<ysionneau> jdstrand: ok thanks!
<ysionneau> will try with a named unix socket
<zyga> jdstrand: thank you
<zyga> jdstrand: feel free to pull me in and ask any questions
<zyga> jdstrand: I have more aa-specifc patches piled, about to be pushed out soon
<zyga> jdstrand: ( https://github.com/ubuntu-core/snappy/pull/635 ) for later
<jdstrand> ack
<zyga> jdstrand: thanks
<zyga> jdstrand: also FYI, for some context how I plan to plug it together, look at this list of TODOs (before it gets stale) https://github.com/zyga/snappy/blob/master/overlord/ifacestate/ifacemgr.go#L93
<jdstrand> ok
<kyrofa> elopio, I just shared a google doc with you regarding the dirty build redesign
<kyrofa> elopio, essentially a distilled problems/solutions doc
<kyrofa> elopio, mind taking a look?
<rajen> Hi folks..I am seeing apparmour issues using new ubuntu-core image
<rajen> Any guidance would be of great help
<rajen> We are running our app unconfined as of now
<rajen> dmesg shows a lot of audit messages
<rajen> http://pastebin.com/nQvfDhX5
<zyga> elopio: it's not urgent (next week) but I'd like to write a few integration tests
<zyga> elopio: and I could use a quick interactive session with you
<zyga> elopio: my goal is to write a test that checks that udev/apparmor support fuctions really work; this basically means setting up some files, calling a function from snappy and then checking that some stuff happened (either with more snappy functions or just with brute-force helper shell command/file poke)
<zyga> elopio: when would be the best time to try this?
<kyrofa> rajen, install snappy-debug (snappy install snappy-debug) and run sudo snappy-debug.security scanlog
<kyrofa> rajen, wait... those messages are fine, they're just loading profiles and stuff
<rajen> Here is the latest from scanlog http://pastebin.com/tAgMJX5D
<jdstrand> rajen: is this on 16.04?
<rajen> Yes 16.04 daily build
<jdstrand> yeah, it needs to be updated
<jdstrand> let me do that real quick
<rajen> I picked the image an hour back from  http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<jdstrand> rajen: ok, update to snappy-debug 0.13
<jdstrand> it needed the to be updates for interfaces work
<jdstrand> s/the //
<rajen> jdstrand: Yeah Now I see better scalogs
<rajen> I see a lot of DENIED logs
<rajen> jstrand: Here is  a sample from the long logs http://pastebin.com/yRJi4GMD
<rajen> jdstrand: Do I have to update my snapcraft.yaml for it to work on new image? I am using slots and my snap app is working from on an ubuntu-core image 3 days back.
<jdstrand> rajen: likely-- can you paste it?
<ssweeny> kyrofa, using build-packages instead of stage-packages I'm getting cmake errors in the config stage. -lpthread failing and whatnot. Looking at the error log I'm seeing stuff like:
<ssweeny>  /usr/bin/cc   -I/home/ubuntu/location-service/trunk/snappy/stage/include -I/home/ubuntu/location-service/trunk/snappy/stage/usr/include -I/home/ubuntu/location-service/trunk/snappy/stage/include/x86_64-linux-gnu -I/home/ubuntu/location-service/trunk/snappy/stage/usr/include/x86_64-linux-gnu   -Wall -pedantic -Wextra -fPIC -DCHECK_FUNCTION_EXISTS=pthread_create   -o CMakeFiles/cmTryCompileExec495151839.dir/CheckFunctionExists.c.o   -c
<ssweeny> /usr/share/cmake-3.2/Modules/CheckFunctionExists.c
<rajen> jdstrand: http://pastebin.com/reRMKXHC
<ssweeny> kyrofa, so it's definitely looking for -dev stuff in stage
<jdstrand> rajen: yes. replace 'slots' with 'plugs'
<kyrofa> ssweeny, sure it looks there, but it also looks in the standard places
<jdstrand> rajen: in both places. that was very similar to what I had to do for snappy-debug incidentally. (the slots<->plugs rename is in the image now)
<rajen> jdstrand: Yay! Works now.
<rajen> Thanks for the help.
<jdstrand> nice :)
<elopio> zyga: I'm here just for that, so you chose the date and time. I usually start working at 14UTC, but I can adjust my working times easily too.
<elopio> zyga: we have a really simple test for hardware assign that we can use as a base: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/hwAssign_test.go
<elopio> kyrofa: looking
<ssweeny> kyrofa, at least in the logs it's not looking outside of stage
<kyrofa> ssweeny, the -I arguments ADD to the system include dirs-- it doesn't replace the
<kyrofa> m
<zyga> elopio: cool, let's aim for Tuesday
<zyga> elopio: I'll sync with you before that happens
<elopio> perfect. Thanks zyga.
<ssweeny> kyrofa, well I can't think of why it would fail then. I have libc6-dev installed on that system
<kyrofa> ssweeny, any chance you could share both your project and the build log?
<kyrofa> ssweeny, happy to look into it :)
<ssweeny> kyrofa, sure. let me push my branch up
<ssweeny> kyrofa, my branch is here: https://code.launchpad.net/~ssweeny/location-service/snapcraft-2.3 and it looks like you were right about includes. I was reading too much into CMakeErrors.log. However that just means I have no idea why my build is failing :)
<kyrofa> ssweeny, checking it out now
<ssweeny> kyrofa, many thanks
<kyrofa> jdstrand, I assume I just hit bug #1555305
<ubottu> bug 1555305 in click-reviewers-tools (Ubuntu) "resquashfs test fails if snap has symlinks" [High,Confirmed] https://launchpad.net/bugs/1555305
<kyrofa> jdstrand, I requested a manual review (owncloud.canonical). Mind taking a look?
<kyrofa> ssweeny, what is your intention with this glue part?
<ssweeny> kyrofa, I think that's leftover from an earlier version when we didn't know how to expose the binaries properly :)
<kyrofa> ssweeny, ahh, okay. Well first off, this is the first YAML I've seen in a subdirectory. I won't be surprised if that's the cause of your issues
<ssweeny> kyrofa, moving the yaml to the top-level dir didn't change anything
<kyrofa> ssweeny, sorry, got a few thing going at once, still investigating
<ssweeny> kyrofa, no worries. it might be a legitimate build failure actually. Some "recipe failed" lines were obscured by the jumbled "-j8" output
<kyrofa> ssweeny, huh. I assume you're tried outside of snapcraft though?
<ssweeny> kyrofa, yeah it builds fine in a normal cmake environment
<ssweeny> kyrofa, even weirder is I was able to get it to build when the build-packages were stage-packages
<elopio> kyrofa: Sergio will be super happy.
<kyrofa> elopio, think so? Most of that sound okay?
<kyrofa> elopio, I tried to reply to your comments
<elopio> kyrofa: everyting sounds great.
<kyrofa> elopio, thanks for taking a look! :)
<kyrofa> ssweeny, does this look like your build log? http://pastebin.ubuntu.com/15343243/
<ssweeny> kyrofa, yep that's it
<kyrofa> ssweeny, because dbus/dbus.h is not in the standard include paths
<kyrofa> ssweeny, it's core/dbus/dbus.h
<jdstrand> pindonga: I've got one more for you: r606
<jdstrand> pindonga: adjustment for recent snap.yaml changes
<pindonga> good thing I had such a busy today that I didn't even get to your previous request :/
<jdstrand> yay?
<pindonga> jdstrand, and unfortunately, looking at things we won't be able to update until monday
<pindonga> but I'll make sure it's top prio for early next week
<kyrofa> ssweeny, also, may I express my sympathies for needing to deal with dbus-cpp and the trust store
<ssweeny> kyrofa, haha, thanks
<jdstrand> pindonga: thanks! I wish I could say that there weren't go to be more requests of the next couple weeks, but things continue to change fast
<jdstrand> going*
<kyrofa> ssweeny, okay, so this is interesting
<jdstrand> kyrofa: approved
<kyrofa> jdstrand, many thanks!
<jdstrand> np
<ssweeny> kyrofa, i like interesting
<kyrofa> ssweeny, I may have been right about how -I added to the system includes rather than replacing them, but you were still right about it using the stage directory. /usr/include/dbus-1.0/ contains dbus/dbus.h, and it's added to the include path, but _within stage_
<tvoss> o/
<kyrofa> ssweeny, my question is: Why?
<pindonga> jdstrand, nw
<kyrofa> ssweeny, looking at the cmake output, it says it found dbus-cpp
<pindonga> jdstrand, I wish we had taken the time back then to automate the pulling of new crt revnos
<pindonga> instead of tying it to the normal deployment cycle
<kyrofa> ssweeny, but then the paths that get tacked on are in stage rather than the system paths
<pindonga> but then... :)
<kyrofa> ssweeny, ah, it uses pkg-config it seems?
<kyrofa> ssweeny, this may indeed be a bug
<ssweeny> woo hoo I found a bug!
<ssweeny> second one i found today :)
<kyrofa> ssweeny, may, I say!
<ssweeny> kyrofa, fair enough
<kyrofa> :P
<jdstrand> pindonga: yeah, well, hopefully it'll calm down a bit. I mean, click checks aren't updated very often
<kyrofa> ssweeny, just a sec, this touches a bit of snapcraft code I'm not super familiar with
<jdstrand> so after GA, I expect things to calm down a lot
 * kyrofa gets familiar
<zyga-phone> jdstrand: thanks for reviewing the branch; do you want me to merge it and follow-up with isolated changes or do you want me to pile them in the same pull request?
<nadu> I'm looking for information about security updates and auto updates. Can anyone help?
<zyga-phone> nadu: what do you want to know
<kyrofa> ssweeny, yup, bug. Snapcraft sets PKG_CONFIG_SYSROOT_DIR to the stage dir
<nadu> Is there something similar to unattended-upgrades and how are security upgrade applied?
<zyga-phone> nadu: snappy updates all snaps automatically
<zyga-phone> nadu: it's on by default
<ssweeny> kyrofa, aha!
<zyga-phone> nadu: security updates are rolled out as new versions of the os/kernel snaps
<zyga-phone> nadu: also, snappy reboots automatically to upgrade kernel/os
<zyga-phone> nadu: so you plug it in and it's on and secure by default
<nadu> sounds cool
<nadu> can I chroot into a docker container?
<zyga-phone> nadu: for other snaps the same thing happens but there's no reboot required, vendors are responsible for updating their software though
<kyrofa> ssweeny, so you know that advice I gave you about having -dev packages as build?
<zyga-phone> nadu: yes, you can use docker, lxd or you can use the classic dimension which gives you classic ubuntu directly on any snappy hsot
<kyrofa> ssweeny, ignore it in this case I guess :P
<zyga-phone> host*
<ssweeny> kyrofa, haha
<kyrofa> ssweeny, I'm not sure how to get it to work in both cases, though
<kyrofa> ssweeny, I'll have to give it some thought. Log a bug for us?
<ssweeny> kyrofa, sure
<kyrofa> ssweeny, thank you!
<ssweeny> kyrofa, no thank YOU
<ssweeny> i thought i was losing my mind
<nadu> zyga-phone: I'd like to do some configuration changes to a docker container without typing docker exec containername everytime
<zyga-phone> nadu: I don't know how that's related to snappy
<ssweeny> kyrofa, of course now I have the problem of libapparmor not being set up correctly when unpacked
<ssweeny> so i'm back where i started :)
<nadu> zyga-phone: you're right :)
<kyrofa> ssweeny, yeah that's annoying. You can probaby hack Snapcraft a little to work with the build packages if you want
<kyrofa> ssweeny, basically, just comment out line 366 in /usr/lib/python3/dist-packages/snapcraft/yaml.py
<kyrofa> ssweeny, see if that works better
<nadu> how can I print more information about a snappy packages? for example getting the maintainer?
<zyga-phone> nadu: each snap has a vendor field
<zyga-phone> nadu: snaps don't have maintainers
<zyga-phone> nadu: snaps are binary packages, not source packages
<zyga-phone> nadu: how you build your snaps is not important to snappy itself
<ssweeny> kyrofa, yep that fixes it
<zyga-phone> nadu: you can check the snap meta-data in snapcraft (2.x) documentation
<zyga-phone> nadu: I'm sorry, I don't have a link handy
<kyrofa> ssweeny, but of course, breaks it if you have .pc files in stage-packages
<ssweeny> of course
<zyga> jdstrand: thanks, I love how all of this is starting to take shape
<zyga> jdstrand: I replied to your Unload() question; I think it's fine to still merge this; we'll do a full pass over the security side of interfaces as things get glued
<ssweeny> kyrofa, looks like someone already found this issue: https://bugs.launchpad.net/snapcraft/+bug/1549570
<ubottu> Launchpad bug 1549570 in Snapcraft "pkg-config across multiple sysroots" [High,In progress]
<jdstrand> zyga: yeah, it is feeling like it is coming together
<jdstrand> zyga: btw, when do you think that old-security/caps will go away? I'm trying to decide if I should upload an ubuntu-core-security with my new x and unity7 policy
<jdstrand> zyga: this isn't pressure btw, it is just info for me to decide my next steps
<zyga> jdstrand: old-security will *probably* remain for a while but will get migrated over to interfaces as a native kind
<zyga> jdstrand: as to where we want to remove it entirely, I don't know -- I suspect it will live on for 16.04
<nadu> zyga-phone: got it
<zyga> jdstrand: but we'll trigger manual review and just stop allowing it
<zyga> jdstrand: sure, no worries, I think we have a good cooperation flow :)
<nadu> can I install vim to ubuntu-core?
<jdstrand> well, we agreed old-security will exist for a while for security-override and security-policy, but I thought old-security/caps and old-security-security-template were going away as soon as these native interfaces were in place
<zyga> jdstrand: mmmm
<zyga> jdstrand: perhaps, if only because some of those would be hard to support
<zyga> jdstrand: e.g. we'd have to parse and rewrite them partially
<jdstrand> zyga: any way, the removal was actually a shorthand way of asking the question. I'm trying to decide if I should update ubuntu-core-security or if ubuntu-core-security is going away very soon cause of the interfaces work
<zyga> jdstrand: that's a curious question
<zyga> jdstrand: do you need u-c-s for click?
<jdstrand> no
<zyga> jdstrand: or is the phone using something separate?
<jdstrand> phone uses other stuff
<jdstrand> the last thing we want is duplicated policy between ucs and snappy
<zyga> jdstrand: then I think it's slowly going to become unused
<jdstrand> so I wanted to know when the snappy stuff was going live
<zyga> jdstrand: ASAP
<zyga> jdstrand: as soon as we glue it together
<zyga> jdstrand: 16.04 ships with this
<jdstrand> yes
<jdstrand> hehe
<jdstrand> is it hours, days or weeks?
<jdstrand> if days, how many?
<zyga> days
<zyga> 2-3
<jdstrand> ok, then I'll hold off
<zyga> bits are missing
<zyga> in other parts of snappy
<zyga> in particular install/remove need to move over to the state engine first
<zyga> at least a little bit so that interfaces can "see" the snaps that are in the current state
<jdstrand> zyga: but so we are clear-- you are going to move all the policy that is in ubuntu-core-security to native interfaces, correct
<jdstrand> ?
<jdstrand> (in the trunk branch that I pointed you to)
<zyga> jdstrand: yes
<jdstrand> ok
<zyga> jdstrand: it was only nacked by gustavo last time to have me focus on bringing last bits of glue needed
<zyga> jdstrand: as soon as 1st interface works end-to-end I'll pull all the others over
<zyga> jdstrand: (which is simple then)
<jdstrand> zyga: and behind the scenes, old-security/caps will actually map to the native interfaces (and old-security/security-template is a noop/goes away)? (ie, so ucs can go away and we don't have to keep it and snappy in sync?
<zyga> jdstrand: I think that old-securtiy will become a native interface called "old-security" that emits particular security snippets
<zyga> jdstrand: perhaps with a bit of parsing here and there
<zyga> jdstrand: old-security as in the current codebase in snappy/ will go away sooner
<zyga> jdstrand: we'll keep the feature, switch implementations
<jdstrand> we can discuss that later-- so long as old-security/caps isn't using the old code that grabs policy from ucs, that is good enough for me for now
<zyga> jdstrand: so that any and all security related aspects will go through the interfaces/**.go
<zyga> jdstrand: yep
<jdstrand> right, sounds good
<zyga> jdstrand: that's guaranteed
<jdstrand> ok, thanks!
 * zyga wishes to see the day where big git rm -rf will happen
<zyga> :)
<zyga> jdstrand: btw, while we're on the topic: https://github.com/ubuntu-core/snappy/pull/636/files
<zyga> jdstrand: this one is shorter, this is the code that will reload udev rules after any rules get touched
<zyga> pitti: hey, could you please have a look at https://github.com/ubuntu-core/snappy/pull/636#discussion-diff-55722473R26
<zyga> pitti: and weigh in with your udev experience?
<zyga> jdstrand: thanks!
<jdstrand> np
<kgunn> hey all what's the _current_ way to remove an installed snap? sudo snap remove snap-name...giving me not found when it's clearly installed
<ogra_> kgunn, "snappy remove ... "
<kgunn> ta
<kgunn> ogra_: confusing with snap and snappy :)
<ogra_> well, naming isnt our strength in snappy (see the security ...)
<ogra_> :)
<ogra_> capaskillfaces with plugslots :P
<zyga> ogra_: you confused plugslots with slotplugs
<zyga> ogra_: snappy and snapd as commands are going away (from PATH)
<zyga> ogra_: snap is the only thing that people will tab-complete
<ogra_> zyga, in 4 months :P
<zyga> ogra_: no, more like in the next few days
<zyga> ogra_: all of install/remove/config/etc ops are available in the rest api
<zyga> ogra_: and exposed via snap
 * ogra_ wishes back blueprints ... where things were well defined, discussed early and written down in a public place :P
<zyga> ogra_: well, we still discuss and refine but it's not like we have a grand plan for each detail for the next 6 months anymore
<zyga> ogra_: too hard to do that
<zyga> ogra_: too inflexible
<ogra_> you discuss at some obscure sprints ...
<ogra_> and then someone writes down something in some well hidden google doc
<zyga> ogra_: I discuss most of my stuff on github
<zyga> ogra_: those are drafts, they trigger coding and feedback cycle
<zyga> ogra_: wanna look at some of the security work I'm doing with jdstrand? https://github.com/ubuntu-core/snappy/pull/617
<ogra_> well, i see very rarely any discussions of implementation in here
<ogra_> but i kind of started to give up caring since i'm in this team
<zyga> ogra_: that's true
<ogra_> everything got way to opaque
<zyga> ogra_: tradeoffs for hard deadlines, I don't think we could have made snappy the old way we made ubuntu before, not this time
<zyga> ogra_: doesn't mean we'll work this way all the time either
 * zyga -> shower
 * ogra_ TV 
<ogra_> :)
 * zyga -> EOD
#snappy 2016-03-11
<dholbach> good morning
<didrocks> Guten Morgen dholbach
<dholbach> salut didrocks
<dholbach> kgunn, in your mir-snaps article I removed the references to the snappy tools ppa - it should be available everywhere in xenial
<pitti> zyga: sorry, this PR does not really say much to me -- except for two comments it doesn't seem udev related at all?
<zyga> good mornign
<zyga> pitti: hey, thanks for looking at it
<zyga> pitti: this how snappy will reload udev rules when something security-related changes
<zyga> pitti: (we write or remove some udev rules)
<zyga> pitti: this is just a sanity check review
<noizer> Good morning
<noizer> I think i encountered an issue while making mine own apparmor profile
<noizer> the error looks like Mar 11 09:08:30 localhost kernel: [64990.973666] audit: type=1400 audit(1457687310.712:69): apparmor="DENIED" operation="open" profile="/usr/bin/ubuntu-core-launcher" name="/home/ubuntu/snaps/ad.sideload/LScnlHLRglbn/snaps/" pid=4159 comm="ubuntu-core-lau" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000
<dpm> mvo, Trevinho, did the u7 .desktop file support land yesterday? I wasn't sure which package to look at
<mvo> dpm: it landed but stuck in xenial-proposed due to a build failure
<mvo> on powerpc
<Trevinho> linkedinyou: dpm the package is the snappy one though
<Trevinho> Ouch... Autocompletion...
<dpm> mvo, Trevinho, ok, thanks 'ubuntu-snappy', then?
<dpm> mvo, While I have you here: I don't quite understand how upgrades for the ubuntu-core snap work on the desktop. Do they happen automatically or do I need to upgrade it manually?
<mvo> dpm: there is a systemd job that will auto-update ubuntu-core
<dpm> aha!
<dpm> I was getting confused
<dpm> I had tried
<dpm> $ sudo snappy update ubuntu-core
<dpm> the given snap is not installed
<mvo> dpm: hm, that is a bug, I think because we use channels now in some internal api
<dpm> mvo, where is the best place to file bugs for snappy, as the one you've just mentioned?
<mvo> dpm: the launchpad https://bugs.launchpad.net/snappy
<dpm> great, thanks
<mvo> dpm: and pining us also helps
<cr0nx> Hi Snappy users. I have a question about adding 3rd party kernel module to the snappy kernel. Is it an easy task or I have to rebuild the whole image?
<ogra_> cr0nx, you have to rebuiold the kernel snap
<dpm> mvo, ok, filed http://pad.lv/1556018
<ubottu> Launchpad bug 1556018 in Snappy "Cannot manually update ubuntu-core snap" [Undecided,New]
<cr0nx> ogra_  do you have any recommeded document about how to rebuild kernel snap?
<ogra_> cr0nx, snapcraft offers a kernel plugin ... though that builds completely from source
<ogra_> if you want to add a binary module http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the device tarballs that are used as input for our kernel snaps ... they are all based on deb packages from the ubuntu archive ...
<ogra_> https://launchpad.net/~mvo/snappy/mksnap-os-kernel has the scripts to turn a device tarball into a snap (note: requires xenial's snappy)
<cr0nx> perfect! thank you for your help. These are my first steps with snappy, but it seems to me as a great option for dedicated appliance I am working on. Do you know if somebody using snappy in a production env/product ?
<ogra_> dell seels its industrial gateways perinstalled with snappy
<ogra_> *sells
<ogra_> and there are several drone manufacturers shi9pping snappy based drones
<cr0nx> wow, exciting! And also last question:  do you have any experience running snappy kernel with grsecurity patch ?
<ogra_> nope, but note that we use seccomp, cgroups and apparmor massively in snappy ... not sure if the grsecurity patches change their behavior
<cr0nx> better ASLR is always better
<cr0nx> ok ogra_
<cr0nx> thank you very much for your help. I appreciate
<ogra_> here is a snapcraft.yaml for use with the snapcraft kernel plugin https://github.com/sergiusens/snapcraft/blob/feature/1552168/kernel-plugin/examples/kernel/snapcraft.yaml
<ogra_> (you'd just create a wrokdir, put that yaml file in there and run "snapcraft" ... the rest is automatic
<ogra_> )
<cr0nx> coool!
<ogra_> (though there is no concept of pathes i think, which means you might need your own git tree with your patch on top)
<ogra_> *patches
<ali1234> is there a click package for mythtv on ubuntu-core?
<ali1234> where do i even go to find packages?
<ogra_> click package ? this isnt #click :P
<ogra_> https://uappexplorer.com/ offers a search option for snaps in the store
<ali1234> well i specifically need a click package that works on snappy ubuntu core
<ali1234> i'm not sure what the difference is
<ogra_> that doesnt exist
<ali1234> oh?
<ogra_> click is deb based, snap is something completely new
<ogra_> there is no compatibility
<ali1234> https://myapps.developer.ubuntu.com/dev/click-apps/?format=snap
<ali1234> what does this URL mean?
<ali1234> this is where you end up at the end of the snappy tour
<ogra_> that shows your snappy packages in the store if you have any ...
<ogra_> and is the place to upload them if you produce any
<ali1234> why does it contain "click"
<ogra_> no idea, i never looked at the url
<ogra_> it is what you get to when clicking on "Ubuntu Core" at the top menu on the page
<ali1234> this is why i thought i needed a click package
<ali1234> in snap format
<ogra_> for actual click packages you'D go to "Ubuntu Personal" ...
<ali1234> the tour doesn't actually explain any of this, which is why i am reduced to guessing based on urls
<ogra_> well, the store UI is far from being complete ... i guess the web devs just re-used the click UIs for now
<ogra_> ali1234, https://lists.ubuntu.com/archives/snappy-app-devel/2016-March/000636.html
<ogra_> that is what you want when creating snaps nowadays ... i guess docs will updated on release day
<ogra_> *will get
<ali1234> i don't want to create a snap though
<ali1234> i want someone else to have already done it for me
<ogra_> heh
<ali1234> according to the tour, it is recommended to use 14.04, but "this" version of snapcraft only works on 16.04 (what "this" version means is not explained)
<cr0nx> ogra_: BTW: why docker version is so old? are you using backporting or it is really 1.6.2 version ?
<ogra_> ali1234, all older snapcrafts and older images will be obsolete with 16.04
<ogra_> cr0nx, no idea, i dont maintain that snap
<ogra_> (and have never used it)
<ogra_> ali1234, 16.04 is essentially snappys "1.0" release
<ali1234> great, but 1604 isn't released, therefore i am not running it
<ogra_> well, you have to ... or at least have to use a chroot if you want to build snaps for 16.04
<ali1234> i don't want to build snaps for 16.04
<ali1234> i want to build snaps for the current release, because that is what i will be deploying
<ogra_> well, then you have to use the old manual ways
<cr0nx> ok
<ogra_> but that it will be EOL in 5 weeks
<ali1234> but my main point is that the tour literally contradicts itself
<ogra_> *note that
<ogra_> yes, it will be overhauled for release, as i said
<popey> Do we support the Odroid devices (yet)? like http://www.hardkernel.com/main/products/prdt_info.php?g_code=G145457216438 ?
<ogra_> popey, longsleep (from spreed) did maintain one ... not sure hw has a 16.04 version and he wasnt around for some days
<ogra_> *not sure if
<popey> hm, okay.
<ali1234> can i run snapcraft on snappy core? is there a snappy package for it?
<ogra_> you can run: sudo snappy enable-classic; snappy shell classic
<ogra_> and then just apt-get install snapcraft
<ali1234> is that a good idea?
<ogra_> that is the purpose of the classic mode, so yes
<ogra_> (it runs a container on top of the readonly rootfs that just adds the missing pieces for a "normal" dpkg based rootfs)
<ali1234> where can i get a snappy 16.04 image for raspberry pi 2?
<ogra_> http://people.canonical.com/~mvo/all-snaps/
<ali1234> what does "all" refer t in the filename?
<ogra_> either grab the pre-made one ... (thats a few days old though) or grab ubuntu-device-flash from there to build your own
<ogra_> thats the new "all-snaps" image format, it means that everythiong is now a snap
<ali1234> does building my own require 16.04?
<ogra_> (rootfs, kernel, gadget (which is bootloader and device definitions))
<ogra_> no, ubuntu-device-flash is a static binary ... you should be able to use it on older releases
<ali1234> if i have a pi3, is the arm64 version a good idea?
<ogra_> (it probably makes sense to apt-get install ubuntu-devcie-flash first, there are some deps like kpartx)
<ogra_> no
<ogra_> the pi3 can not run arm64 code yet
<ogra_> that waits for a binary blob update from broadcom
<ali1234> oh yeah, i heard about that
<ogra_> (the currtent bootloader initializes the board in 32bit mode yet)
<ogra_> and for snappy i'm also waiting for a u-boot port ... thats also not completely done yet
<ali1234> it can initialize in 64 bit mode, but the kernel will fail when it tries to talk to the 32 bit videocore code
 * ogra_ has 2 pi3's lying here but not all bits exist yet)
<ogra_> right
<ali1234> something to do with kernel pointers being passed through videocore
<ogra_> i definitely plan to have an image for it ...
<ogra_> and once arm64 works fully on it, even an arm64 image
<ogra_> today the only arm64 board we support is the dragonboard though
<kyrofa> Good morning
<techraf> Good morning @21:22 in Osaka
<techraf> how can I get a .snap file of a snap from a store?
<techraf> is it possible to get the URL of a snap?
<techraf> for example to check where `snappy-debug` will be downloaded from?
<ogra_> techraf, there is uappexplorer.com ... not sure if it provides download links though
<beeray> hi, I am just hearing about snappy, just want to know the difference between it and docker
<techraf> ogra_, I'm not sure if these are the same apps that I was thinking of..
<techraf> @ogra_, I'm not sure if these are the same apps that I was thinking of...
<nothal> techraf: No such command!
<ogra_> snappy isnt a container system (you can use containers in it)
<ogra_> techraf, there is a search option for snappy
<popey> techraf: there is an api for the store. you could poke that and get the url to the snaps
<ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy
<popey> techraf: or you might find them in my mirror http://popey.mooo.com/mirror/clicks/2016/03/2016-03-11-050001/
<kyrofa> techraf, you can use the store API from the terminal
<kyrofa> popey, argh, you're too fast
<techraf> oh, these _are_ the same apps and store indeed shows a direct link to https://public.apps.ubuntu.com/anon/download/canonical/docker.canonical/docker.canonical_1.6.2.005-16.04.1-1_all.snap
<popey> that's the one
<kyrofa> techraf, curl http://search.apps.ubuntu.com/api/v1/package/snappy-debug
<kyrofa> beeray, welcome!
<techraf> does _all.snap mean all architectures? Actually I was looking for armhc
<kyrofa> beeray, Docker and Snappy solve completely separate problems
<ogra_> techraf, yes, all means all arches (that can mean it only contains scripts, but also that it ships binaries for all of them and switches according to the arch you run it on)
<kyrofa> beeray, Docker is a virtualization technology, and Snappy/Ubuntu Core is an operating system
<kyrofa> beeray, may I ask what you read that led you to believe they were similar?
<beeray> ok , thanks so much guyz
<beeray> so that mean I can use it to develop app, and it means it can run docker container as well
<ogra_> yeah
<kyrofa> beeray, you got it
<beeray> Just want to ask, is it faster than running docker on main ubuntu or other linux distros
<popey> ali1234: I have snappy on a pi2 here, and have two ssh sessions to it, one in 'snappy' mode, and one in 'classic' mode. I use classic to build snaps using snapcraft, and then switch to the 'snappy' mode session to test install them, as they share the same $home
<ogra_> most likely, since you can run apps in a securely confined way natively ... without having to have a container layer underneath
<ali1234> popey: that sounds like what i need
<ogra_> ali1234, see, we thought of you :)
<popey> although I did run out of space at one point
<popey> does snappy auto expand to fill the sd card?
<ali1234> i am going to use a 32Gb card
<ogra_> it should, yes
<ogra_> check with df, i heard recently that the auto-resize diidnt work for someone
<ogra_> (i'm currently re-writing it though)
<popey> /dev/mmcblk0p2  3.4G  3.2G   90M  98% /home
<popey> it's a 16GB sd card
<ogra_> looks fine
<techraf> thank you ogra_, popey, kyrofa - I got to do a homework with downloaded .snap now :)
<popey> so looks like it didn't
<ogra_> oh
<ogra_> yeah, then it didnt
<popey> /dev/mmcblk0p2      270336 31250000 30979665 14.8G 83 Linux
<ogra_> there should be logs in /run/initramfs
<popey> reported by fdisk
<popey> 1454620756: start
<popey> writable: clean, 41877/229824 files, 618695/917504 blocks
<popey> 1454620757: end
<popey> does classic have a limited amount of space?
<ogra_> nope
<popey> hmm
<ogra_> but it can only use as much space as your writable partition has indeed
<popey> my other one running edge, seems to have worked /dev/mmcblk0p2   29G  947M   26G   4% /home
<ogra_> please file a bug against initramfs-tools-ubuntu-core that the resize didnt work
<popey> (32GB card in that one)
<popey> So i guess no bug needed if it's fixed in edge?
<ogra_> not sure it is fixed in edge :)
<beeray> currently working on virtualization with docker, just want to ask if I can install docker on it, and then run container through the docker. OR is it possible like I read to develop app test it and run it on snappy without the need for container
<popey> hm
<ogra_> beeray, both is possible :)
<beeray> pls explain, you know each app is independent in container , how do they work in docker
<ogra_> there is a docker snap you can install an use if you want ... to just run your app in
<beeray> and also regarding RPi , can snappy replace the raspian or debian or ubuntu that we do install in RPi. if so what are the benefits
<ogra_> at the same time you can use snapcraft and just develop a snap for your app that runs it natively
<ogra_> it is really up to you ...
<ogra_> though by experience i'd not really run docker on something as underpowered as a rpi
<ali1234> does the rpi2 image work on rpi3?
<ogra_> transactional updates are surely a big benefit (of the OS as well as of the snaps) ...  the very high level of security and reliability are surely also putting it far above a deb based system (readonly filesystem apps are completely confined and cant just access stuff on the OS etc)
<ogra_> ali1234, nope
<ogra_> as i said, needs u-boot to be finished
<ogra_> i know srwarren is on it, shouldnt take long til he has something stable
<ali1234> is it expected that the SD activity led does not work?
<ali1234> oh nvm, it does work, it's just really slow
<ogra_> after the rootfs booted it works
<ogra_> the first boot takes a while since it resizes the OS and does some basic setup via cloud-init
<ogra_> subsequent boots are a lot faster
<beeray> thanks guyz
<ali1234> what is cloud-init? i don't like the sound of that
<ogra_> ali1234, it creates ssh keys and sets up the default user (in snappys case, it can generally do a lot more we dont use)
<ali1234> so it's basically oem-setup for the cloud?
<ogra_> right
<ali1234> okay, makes sense
<ogra_> well, in actual cloud-setups it does a lot more (installing debs and such, partitioning the cloud instance etc etc)
<ogra_> more like d-i
<ogra_> but as i said, snappy only uses the user setup and ssh key generator
<techraf> sorry to jump in
<beeray> So what is the difference between  snappy and main Ubuntu
<techraf> for ubuntu-core on RPi - before "sudo snappy enable-classic; snappy shell classic"
<techraf> do I need to install ubuntu-classic?
<JamesTait> mvo, did you by chance see bug #1555569 - is there a human-readable name in snap.yaml equivalent to title in a Click manifest?  Would that be summary?
<ubottu> Error: Launchpad bug 1555569 could not be found
<techraf> or it's not yet official?
<ogra_> techraf, nope, it should work by default (in the 16.04 images)
<ogra_> well, it needs to download the container content (which "sudo snappy enable-classic" does)
<techraf> ogra_, that explains why it does not work here on 15.10 :)
<ali1234> okay it must have finished booting by now
<ali1234> how do i log in?
<popey> ubuntu/ubuntu
<ali1234> what is the IP?
<popey> dhcp
<popey> or plug into a display and keyboard and login locall of course
<ali1234> okay i am logged in
<ali1234> it doesn't have a hostname
<ali1234> probably explains why avahi doesn't work
<ali1234> ubuntu@localhost:~$
<ali1234> /dev/mmcblk0p2  3.4G  158M  3.1G   5% /writable
<kyrofa> ali1234, if webdm is installed try webdm.local
<ali1234> what is webdm
<ali1234> i tried wemdb.local from the tour, but it does not work
<kyrofa> ali1234, a web-based package manager, if you will
<ali1234> .local is avahi
<ali1234> there is no avahi address associated with the IP
<ogra_> kyrofa, webdm isnt ported to interfaces yet
<kyrofa> ali1234, .local is just a convention. avahi is one of many ways to get mdns
<kyrofa> ogra_, ahh
 * ogra_ is waiting for that too 
<ali1234> so the writable partition didn't resize either
<ogra_> kyrofa, btw, what abotu an owncloud update ? :)
<ogra_> ali1234, yeah, thats a bug
<kyrofa> ogra_, amd64 has been rebuilt, but my rpi2 is crapping out on me
<ali1234> can i just e2resize it?
<ogra_> you can file it against initramfs-tools-ubuntu-core ... i'm working on fixing that though
<kyrofa> ogra_, I'm not sure if it's my SD card, the flash drive I'm using for swap, or a hardware issue
<ogra_> :(
<kyrofa> ogra_, the video gets all weird, like the text is garbled. It works for another half hour or so, then it's just gone
<ogra_> wow
<ogra_> that sounds very broken
<kyrofa> ogra_, yeah, feels like hw
<ogra_> ali1234, any logs in /run/initramfs/ ?
<kyrofa> Unfortunately it's the only arm I have... so I'm crossing my fingers for LP to finish allowing internet access in its builders
<ali1234> yes, resize-writable.log
<ogra_> any errors in  there ?
<ali1234> yes, e2fsck errors
<ogra_> ah
<ali1234> http://paste.ubuntu.com/15347369/
<ogra_> k, that gives me some pointer what to look for
<ogra_> well, but it finished fine ... lparted should have kicked in next ... weird that it didnt
<ogra_> -l
<ali1234> also these http://paste.ubuntu.com/15347403/
<ogra_> hmm
<ogra_> where does that BYT come from
<ali1234> "i dunno lol"
<ali1234> where does any of that output come from?
<ogra_> initrd
<kyrofa> ogra_, rebooting the rpi2, I have evbug lines all over my syslog
<ogra_> there is an awfully ugly resize script
<ogra_> kyrofa, lovely ... sounds like kernel then
<mvo> JamesTait: I think the best we have is indeed summary
<ogra_> (well, awfully ugly for GPT disks ... pretty standard for mbr ones)
<kyrofa> ogra_, should I log a bug, then?
<ogra_> kyrofa, yeah and attach the syslog ... against linux-raspi2 for the start
<ali1234> would it help if i did it again with a serial console?
<ogra_> no, all output is redirected to the log files ... you would only see some echos "resizing foo ..."
<ogra_> as i said, i'm working on it
<ogra_> since thats just an mbr disk you can easily resize it with gnome-disks or gparted in your PC for now .... to work around the bug
<techraf> ogra_ where can I get ubuntu core 16.04 for RPi?
<ali1234> http://people.canonical.com/~mvo/all-snaps/
<ogra_> techraf, http://people.canonical.com/~mvo/all-snaps/
<techraf> thank you
<ali1234> uh... something weird just happened
<ali1234> http://paste.ubuntu.com/15347526/
<ali1234> i didn't do anything
<ogra_> ali1234, auto update notification :)
<ali1234> so it just reboots any time by default?
<ogra_> if autoupdate is enabled, yes
<ali1234> i'll need to automatically defer that
<ogra_> (which it is by default)
<ali1234> if mythtv is recording something it should wait until the recording finishes, then reboot
<ogra_> so you disable it with snappy config ubuntu-core ...
<ogra_> echo -e "config:\n  ubuntu-core:\n    autoupdate: false\n" | sudo snappy config ubuntu-core -- -
<ogra_> that should do
<ogra_> (note the spaces are essential, it is yaml)
<ali1234> i don't want to disable it though. i just want to make sure the system doesn't reboot while it is doing something important
<ogra_> well, its an on/off thing currently
<ogra_> i agree that tthere should be finer grained inhibition ... but thats not there yet
<ogra_> (there migh be a way via the REST api though)
<kyrofa> elopio, standup?
<elopio> kyrofa: I'm trying to join.
<kyrofa> Oh google
<ysionneau> How am I supposed to debug a snap with gdbserver ?
<ogra_> from the classic shell you can attach to the pid
<ysionneau> the program crashes at startup
<ysionneau> s/program/snap/
<ogra_> ah, then probably by using strace from your startup script or some such ...
<ysionneau> and if I run gdbserver in the confined env, it is killed because of syscall 136 (personnality)
<ogra_> (which indeed requires re-snapping)
<ogra_> i think jdstrand had some clever way of using an overlayfs from classic, so you can dynamically hack your shell scripts in the snap dir etc
<ysionneau> from the startup script I've put something like if [ "$DEBUG" = "1" ]; then exec gdbserver :1234 $SNAP/usr/bin/wifid; else exec $SNAP/usr/bin/wifid; fi
<ysionneau> but gdbserver does not like being sandboxed
<JamesTait> mvo, so we're currently discussing the removal of the tagline field from click packages - I had mistakenly thought it was a field that we parsed from the click manifest, when in fact the upoader has to enter it in the upload form.
<JamesTait> mvo, the intention originally was to finally split it out into a separate field, and parse summary from snap.yaml into there - it sounds like a better approach might be to drop tagline entirely and parse summary into what clicks call title.
<elopio> fgimenez: I rewrote the dep8 test to use the test deps from source, but I still can't find them if I'm not inside the tests directory.
<elopio> I don't understand what I'm doing wrong. This should be the same as when we compile the tests binary.
<elopio> huh, weird. It works if I first generate the binary.
<fgimenez> elopio, mm we do this when building the binaries "command.Dir = filepath.Join(os.Getenv("GOPATH"), projectSrcPath)", are you using shell script for the dep8 test?
<elopio> shell script.
<elopio> but it worked, I think I'm happy with this. Not as ugly as before.
<elopio> I'll propose the branch for you to see.
<zyga> jdstrand: hey
<jdstrand> zyga: hey
<jdstrand> I saw the emails, I'm discussing it with the team
<zyga> jdstrand: thanks
<zyga> jdstrand: let's sync before EOD, I'd like to know what I stand on
<jdstrand> zyga: yes, that is why I started discussing it immediately after I came on :)
<elopio> mvo: https://github.com/ubuntu-core/snappy/pull/646
<elopio> autopkgtest.
<mvo> elopio: thats wonderful, thanks a lot!
<jdstrand> didrocks: hey, I can't help but comment since you sent the reminder-- the timing for surveying people on 16.04 snappy development is interesting since I imagine everyone is going to be incredibly frustrated since a ton of things are still in flight
<jdstrand> and that is going to continue for at least a couple of weeks
<jdstrand> 2 cents
<ogra_> are we re-defining interfaces again next week ?
<ogra_> :P
<jdstrand> not plugs/slots/etc but yes in that now that that is settled, the actual interfaces are going to land
<kyrofa> jdstrand, yeah I'm prepared for angry responses :P
<didrocks> jdstrand: yeah, that's what I first told to Daniel about the timing
<jdstrand> and old-security/caps names are not going to be the same as the os slots
<didrocks> but at least, we can measure, reassess, progress
<didrocks> yeah, I look forward to that, I lost a build because of a trailing "," in a json security.override
<didrocks> and no angryness on install! :p
<jdstrand> I guess in one sense you will have a nice baseline-- your next survey should have an overwhelmingly more positive response, so it'll look great then! :)
<kyrofa> Hahaha
<jdstrand> didrocks: click-review whould've noticed that
<jdstrand> should've
<jdstrand> didrocks: but security-override was literally *horrible* in 15.04 :)
<jdstrand> didrocks: I think you are the only person who used it
<kyrofa> jdstrand, not so! I've used it now
<jdstrand> yay?
<kyrofa> :P
<jdstrand> :)
<jdstrand> I mean, it does stuff...
<didrocks> it does somewhat worked yeah :)
<didrocks> but I'm happy we move to something more modern
<didrocks> kyrofa: speaking of which, you have an answer on http://askubuntu.com/questions/744696/how-to-create-snappy-nodejs-web-application :)
<kyrofa> didrocks, heh
<stgraber> jdstrand: any chance you can approve lxd 2.0.0 rc3?
<jdstrand> ogra_, ysionneau: fyi, this is in my notes: http://paste.ubuntu.com/15348328/
<jdstrand> ogra_, ysionneau: obviously the technique can be extended in various ways
<jdstrand> stgraber: I thought I did?
<ogra_> *if* yoour kernel has overlayfs
<ogra_> :)
<jdstrand> stgraber: is this a new one or from earlier this week?
<jdstrand> ogra_: indeed
<stgraber> jdstrand: that was rc2, I pushed rc3 last night
<jdstrand> ah
<jdstrand> yes, I can do that
<rajen> Hi Folks. I am experimenting with custom Snappy o/s image creation for our hardware. I was able to use "mk-snappy" scripts to create a custom kernel snap. I am picking up os snap from nightly builds. I used device-flash to create the .img file
<rajen> But I observe that ubuntu-core cannot be updated to newer versions as it is shown as sideloaded.
<rajen> http://pastebin.com/wLehLKHZ
<rajen> Any idea how we can overwrite sideload'ed apps with signed version from snappy store?
<ogra_> you cant
<ogra_> upload your snaps to the store ;)
<ogra_> (and push your updates through it too)
<rajen> okay..I am using the os snap provided.
<rajen> But it still shows up as sideloaded.
<ogra_> you make ubuntu-device-flash use it from the store ?
<ogra_> or did you download it locally
<rajen> Got it. I am downloading the snaps and tar balls locally and creating the img file using device-flash.
<ogra_> thats your issue :)
<rajen> I see what you are saying, if I tell device-flash to use o/s snap directly from store it will allow me to upgrade it.
<ogra_> you just want: --os ubuntu-core.canonical
<rajen> You see, we want our own customer kernel snap to be sideloaded. But ubuntu-core, we want it from the store.
<ogra_> that will download the signed one from the store and it will not be marked as sideloaded
<rajen> okay let me modify the scripts to do --os  ubuntu-core.canonical
<rajen> Thanks for the tip ogra_ !
<ogra_> if you want to upgrade your kernels you should consider uploading them too though
<rajen> W.r.t kernel, yeah we will get there soon.
<rajen> ogra_: What about gardget snap? canonical-pc?
<rajen> --gadget  ???
<dholbach> mvo, ogra_: do you know when snappy 16.04 images will live on cdimage.u.c?
<ogra_> dholbach, no
<dholbach> do we know who's working on this?
<ogra_> me if in doubt
<ogra_> we have the fragments on http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ (kernel and os snap) but these need to be automatically pulled into the store .... and thnen we need some automated way to run u-d-f
<ogra_> and as i just said in my mail we need the new all-snaps u-d-f to land first in the archive
<ogra_> as i also said in my mail i could do an alpha release manually ... but since the interfaces are still not final i'm not sure thats such a good idea
<ogra_> (people will have to re-do their snaps again once it is stable)
<dholbach> mh
<ogra_> mvo, when will the u-d-f for all-snaps land ? any reason to hold it back ?
<rajen> ogra_, Yes. Now I am able to see ubuntu-core snap installed with correct version and Developer.
<ogra_> great :)
<rajen> Cool. But, I have question now.
<rajen> The reason why were doing custom o/s snap was to work around a problem in Snappy.
<ogra_> a custom os snap is definitely the wrong way to work around any problems :)
<rajen> Our C application residing inside our snap package is allergic to dash and wants bash as default shell.
<rajen> Now is there a way in Snappy to specify /bin/sh to be bash for a Snap application.
<ogra_> we might remove bash from the image at some point
<rajen> I believe this is a feature that needs to be exported by the Snappy infrastructure.
<ogra_> andf your snaps should realyl not rely on anything in the os snap
<rajen> okay..here is the catch.
<rajen> "/bin/sh" is hardcoded when system("") libc API is used.
<ogra_> i think the right way would be to allow snapcraft to ship a /bin/sh override so you can ship your own shell insuide and the ubuntu-core-launcher would just point to whatever your snap ships
<rajen> So we do not want to hack libc to point to some other /bin/xxxx.
<ogra_> jdstrand, ^^^
<arges> Hi. Does a golang client library exist for the snappy REST api? or should i just use net/http.
<ogra_> jdstrand, and idea if it is possible to override /bin/sh from the launcher for a snap ?
<ogra_> i could imagine people shipping ksh scripts or tcsh scripts in their snaps would want that too
<ysionneau> is there a capability to allow a snap to use mount ?
<ogra_> i dont think so
<ysionneau> I'd like to have some rw directory accessible from several snaps
<ysionneau> I wanted to mount -o bind some /writable/parrot directory in /tmp/parrot (the sandboxed /tmp)  for each snap
<ogra_> i think the interfaces model will offer that (you would have a disk-provider snap or some such that your other snaps can consume) but thats not there yet
<ysionneau> but no luck :p
<ogra_> probably zyga can tell where we stand with that
<ysionneau> ok thanks!
<ogra_> i know he works on interfaces
<ogra_> but i doubt you will be able to actually use mount :)
<ysionneau> well mount is not mandatory I just wanted some solution to share some files
<ysionneau> and actually right now I want to share a named unix socket
<ogra_> yeah
 * ogra_ usually just dumps all bits that need to share a dir into one snap 
<ogra_> i.e. http://bazaar.launchpad.net/~ogra/+junk/upnp-server/files .... ships minidlna and lighttpd that share the same dir
<ysionneau> yes that's one solution, but it's not something we can do for everything
<ysionneau> that would end up like : parrot-firmware.snap
<ysionneau> instead of having several snaps
<ogra_> well, whats the advantage of having several snaps ?
<ysionneau> + we want to allow developers to do snaps which would be able to communicate with our autopilot running in another snap (a parrot snap)
<ogra_> (apart from requiring a lot more maintenance)
<ysionneau> and that means : shared memories, udp/tcp/unix sockets
<ysionneau> and files
<ogra_> yeah, the interfaces model will allow all that i think
<ysionneau> good :)
<ysionneau> is there some text somewhere describing this idea? (even if it's not implemented at the moment, I get it)
<ysionneau> so that I can grab the idea
<ogra_> not sure ... since we collect all such stuff in google docs i lost the overbview
<ogra_> i'm sure there is some doc *somewhere*
<jdstrand> ogra_: eek, yuck. /me notes system() is almost always unsafe.... I can't think of a way to do that in anyway that would be considered sane
<jdstrand> the scripts should be adjusted to be posix compliant or the system() calls should be replaced with something that does what they want
<ogra_> well, you could have a special libc that allows an env var for /bin/sh to override the system one .... and force-seed that var to an in-snap binary
<ogra_> but thats indeed very ugly
<ogra_> jdstrand, would it be bad to make seccomp actually block system() ?
<jdstrand> this all gets back to us defaulting to dash which we did in 6.10
<ogra_> (i assume this would make half the Sw non-functional)
<jdstrand> we can't block system(), that isn't a syscall
<ogra_> yeah
<jdstrand> libc implements system() with execl which is ultimately the execve syscall
 * ogra_ sighs ... 3rd firefox crash out f the blue in 1h ... FF 45 is really not for 15.10 it seems :(
<ogra_> hmm, doesnt libc actually respect the SHELL env var ?
<ogra_> hmm, not according to http://www.scratchbox.org/documentation/general/tutorials/glibcenv.html
<rajen> ogra_, Jdstrand: I am reading your conversation. Interesting points!
<ogra_> rajen, we have a porting doc to make shell scripts properly POSIX compliant btw https://wiki.ubuntu.com/DashAsBinSh ... perhaps that helps ?
<ysionneau> hmmm even from the same snap, if I run 2 apps, each one will get a different /tmp, right?
<ysionneau> but I can share files with $SNAP_DATA :)
<ogra_> ysionneau, yeah, i think there is a bug open for that
<ysionneau> ogra_: ok
<rajen> Okay dash/bash for scripts. Yes we fixed all that.
<rajen> The issues are with our C application.
<ogra_> /tmp should be per snap, not per app
<ysionneau> agreed
<rajen> jdstrand, ogra_: this is the actual problem we are trying to work around with http://stackoverflow.com/questions/35642734/ld-preload-not-applied-to-command-given-through-system-in-dash-but-working-wi
<jdstrand> you could maybe LD_PRELOAD system() so it uses bash
<ogra_> that doesnt solve the general issue that snaps fully rely on the os shell though
<rajen> I don't think that was possible.
<rajen> jdstrand,       _IO_execl ("/bin/sh", "sh", "-c", command, (char *) 0);
<rajen> glibc code does this. There is no escape from this I guess.
<rajen> _IO_new_proc_open()
<mhall119> hi all, where can I find documentation about the new "interfaces" in snappy and how to build a snappy that provides new ones?
<ogra_> mhall119,  in someones brain :P
<mhall119> who's brain to I need to extract? :)
<zyga> mhall119: mine
<zyga> mhall119: what do you need
<mhall119> zyga: to learn more about snappy, but specifically I want to understand the best way of providing a single ubuntu-sdk-libs snap package that other snap application packages can depend on
<zyga> niemeyer: oh, so code reuse
<zyga> er
<zyga> mhall119: ^^
<mhall119> yes
<zyga> niemeyer: sorry, habbit :)
<niemeyer> ;)
<zyga> mhall119: we discussed that times and again and the bottom line is that right now we don't have an off-the shelf solution; I'm pretty confident we could make one but that's something we're not working on now
<mhall119> zyga: with 16.04 desktop introducing snappy support, I'd like to make our new ecosystem of convergence apps available on it
<zyga> mhall119: the focus is to finish what we planned and that's very much what we are doing
<zyga> mhall119: I understand, it's just not ready yet
<zyga> mhall119: there's a few different ways we could do that, it's a bit complex around the edges
<mhall119> ok, then where can I learn about snappy interfaces more generally?
<zyga> mhall119: and we don't want to get back to debs and dependency issues
<zyga> mhall119: the core idea is super simple, it's a way for two snaps to interact
<jdstrand> mhall119: fyi, I think you are about 1 week early
<zyga> mhall119: using a well defined "protocol"
<zyga> mhall119: whatever that is (could be some actual protocol, could be just an agreement to write to a file, etc)
<jdstrand> mhall119: in about that time, much of this will be landed and presumably docs/... updated
<zyga> mhall119: yep, jdstrand is right
<zyga> mhall119: I'm working on plugging it all together; next week we'll have that in trunk and we'll focus on docs, polish and tons of interfaces
<mhall119> jdstrand: ok, who is working on landing that and writing those docs?
<zyga> mhall119: and to see what's the next focus for us
<zyga> mhall119: I suspect I'll work on that though I bet jdstrand will help me a lot in actual writing proper english :)
<mhall119> zyga: ack, I will come annoy you about it next Friday then :)
<zyga> mhall119: gladly!
<zyga> mhall119: sorry, I wish I could give it to you and the world today
<zyga> mhall119: (about that, time for a coffee and another pull request)
<jdstrand> zyga: I can say for sure after all that is there and the old-security/caps stuff is implemented, we should look hard at the existing frameworks (docker, lxd, mir, bluez, pulseaudio and nm)
<mhall119> zyga: a week is not so bad, I can wait that long :)
<jdstrand> zyga: each will likely present different challenges to work through. eg, sockets, dbus bus policy, etc
<zyga-phone> jdstrand: totally agree
<zyga-phone> (I cannot stand my office today, moved downstairs to see real living human beings)
<zyga-phone> jdstrand: I'd like to land udev/apparmor branches that I posted
<zyga-phone> jdstrand: while my attempt to reconcile snappy/security.go with interfaces failed miserably (everything is terrible ;-) I got a lot of things done
<jdstrand> zyga-phone: hehe, I doubt everything is terrible. Things are coming along! be happy :)
<zyga-phone> jdstrand: we parse the _name_ of the file with the apparmor profile in hw-assign, I tried to decouple that so we can rename the file but I gave up
<zyga-phone> jdstrand: I'd rather implement interfaces and developer mode and burn hw-assign with fire
<jdstrand> zyga-phone: hw-assign gone, sure. I am curious what we'll do for say, assigning /dev/video0 to a snap
<ogra_> voodoo
<jdstrand> ie, what these interfaces will look like wrt the os and gadget slots
<ogra_> (build a little camera out of straw ... ascrifice a chicken ... and hope the app works then)
<zyga-phone> jdstrand: enable developer mode, work with us on a proper interface
<zyga-phone> jdstrand: doing /dev/* assignment through interfaces is trivial (i have implemented this iface locally)
<zyga-phone> jdstrand: doing hw-assign requires going through a maze of legacy code
<jdstrand> ok, so you implemented the hw-assign functionality as an interface (that's fine and it will probably be useful for devs in the early stages), I more meant what does a proper interface look like for these things
<jdstrand> it is more pondering
<jdstrand> I guess we'll see :)
<zyga-phone> jdstrand: it would always depend on what is being assigned so that there's interoperability
<Ash___> hi
<Ash___> is it possible to use smartphone as a developement board for projects
<Ash___> since...todays smartphones are built on SOC s ..
<Ash___> pls post your views
<kyrofa> Ash___, sure, but aren't the bootloaders pretty locked down in most cases?
<rajen> Is anyone working on this issue? https://bugs.launchpad.net/snappy/+bug/1552458
<ubottu> Launchpad bug 1552458 in Snappy "Sharing tmp directory across multiple commands in a snap app" [Undecided,New]
<rajen> I hope this gets fixed soon so that we can prepare our snaps in time for 16.04 release
<Ash___> hi kyrofa..
<Ash___> can u just dive deeper ...to get better understanding
<kyrofa> Ash___, I'm not sure how much deeper we can go there. If phones were that easy to use, you wouldn't need to hack them to root them etc.
<kyrofa> Ash___, you're right, all the hardware is probably there (other than stuff like GPIO etc. that's on a typical dev board)
<Ash___> yeah, we should leverage its power....
<Ash___> Lets work together to use smarthone as a embedded system's heart
<kyrofa> Ash___, honestly I'd rather use something a bit more open
<Ash___> yeah, u r correct...even me too like to use in the same way....but as we see...the prices of smartphones are becoming cheap..in terms of prices and they are loaded with all sensors...processor....display...wifi...bluetooth....4G..3g..what not...
<popey> I'd rather use something like an arm chromebook for dev / building as it has an integral screen and keyboard, and integrated IO ports
<popey> so easier to debug when it messes up
#snappy 2016-03-12
<techraf> what happened to `snappy search` in 16.04?
<ogra_> techraf, was renamed to "snap find"
<ogra_> (there are plans to replace all of it with "snap" before release)
<techraf> ogra_: what does it show, btw?
<techraf> I got 3 snaps on RPi - does it filter by sth. by default?
<techraf> I could `snappy install docker` (not working), though
<techraf> I mean `snap find` showed 3 snaps only
<ogra_> the store is supposed to filter by arch ...
<ogra_> beyond that most packages have not been updated for the new security model
<techraf> so the security model also plays role?
<kyrofa> techraf, docker definitely doesn't work in 16.04
<techraf> kyrofa: that's ok, I was more interested why I could install it despite not being listed
<kyrofa> techraf, you mean snap find docker shows nothing but snappy install docker works?
<techraf> yes
<dasjoe> What are http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled images recommended/usable for? Is it unwise to unpack on a generic amd64 box, chroot into it, install linux-generic and let grub install itself?
<dasjoe> As in, are those images somewhat exclusively for cloud environments?
#snappy 2016-03-13
<ogra_> dasjoe, the tarballs are fragments used to build the actual snappy setup, no you cant just unpack and use them ... what you can do is use the snap packages from there together with the ubuntu-devce-flash from http://people.canonical.com/~mvo/all-snaps/ to create an image
<techraf> hello, on my playground Ubuntu Core machine I had Transmission running in docker container with its interface bound to port 9091
<techraf> I forgot about it and installed `snappy install transmission.matiasb` Transmission
<techraf> it created its directory in /writable, I deactivated it made changes to settings, activated it again
<techraf> by default it also runs on port 9091
<techraf> later when I was trying to locate downloads it turned out that I actually used already running dockerized Transmission
<techraf> why Transmission snap did not visually report any error that the port 9091 was already used?
<techraf> if it reported somewhere, where shall I look?
<techraf> (and is it "overall" snappy issue, or was it responsibility of that particular snap?)
<techraf> (running 15.04)
<netphreak> Hi, guys!
<netphreak> Anyone know how are os updates to Snappy Ubuntu handled? - automatically installed, or do these require manual user intervention?
<kyrofa_> netphreak, you still around?
<dasjoe> ogra_: sorry if this wasn't clear, I do not intend to use snappy but just the "old" Ubuntu Core
<netphreak> Hi, guys!
<netphreak> Anyone know how are os updates to Snappy Ubuntu handled? - automatically installed, or do these require manual user intervention?
<ogra_> dasjoe, then you dont ever want to use the -preinstalled bits ... they are all "snappified"
<dasjoe> ogra_: right, thanks :)
#snappy 2017-03-06
<titan_king> Hello, anybody tried installing snappy in Fedora?
<titan_king> The copr repo for feodra , Zyngacore/snapcraft does not work
<Rumple> What's the deal with --classic snaps on the stable branch? Is there any other way to access /sys/ without --classic?
<titan_king2> Does snapcraft support Fedora?
<titan_king2> The copr seems to be down
<pshod> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<pshod> used the pi3 image from here
<pshod> cannot get the bluetooth to work
<pshod> help help help!
<pshod> bluetotooth service not found
<pshod> when ran systemctl bluetooth status
<mup> PR snapd#2975 closed: overlord/snapstate: small cleanup of ensureForceDevmodeDropsDevmodeFromState <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2975>
<mup> PR snapd#2951 closed: interfaces: use seccomp specs <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2951>
<pshod> running core on pi3
<pshod> unable to get the bluetooth working
<pshod> http://cdimage.ubuntu.com/ubuntu-core/16/stable/current/
<pshod> using the img from here.
<pshod> help!
<soffokl_> Hello everyone. Can someone point me to the description of installation Ubuntu Core on Google Compute Engine?
<soffokl_> Is it really possible to make such installation?
<soffokl_> On AWS EC2 found image ubuntu-core16, but failed to find something similar on GCE :(
<mup> PR snapd#2984 opened: interfaces: seccomp test helper <Created by stolowski> <https://github.com/snapcore/snapd/pull/2984>
<pshod> how to load a service in core env?
<pshod> installed classic env in it
<kalikiana_> soffokl_: Unfortunately the instructions that existed seem to have disappeared from the snappy websites. But you can use a custom image.
<kalikiana_> (There was https://www.ubuntu.com/desktop/snappy#snappy-google in a previous iteration)
<pshod> NEED TO MAKE BLUETOOTH WORK ON CORE NOW!
<pshod> help help help!
<mup> PR snapd#2985 opened: hookstate: disable configure hook for core on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/2985>
<caribou> Hello, what is the best approach to copy a file from the parts/{part}/build directory to the parts/{part}/install directory using an install scriptlet ?
<caribou> I wanted to use the $SNAPCRAFT_PART_INSTALL as a target but I can't figure out if there is the equivalent source environment variable
<caribou> nevermind, found it
<popey> caribou: i use "cp -a * $SNAPCRAFT_PART_INSTALL" in my scriptlet, what did you decide on?
<Son_Goku> is zyga back from the grave yet?
<Son_Goku> mvo: hey, the 2.23 release tag doesn't match what you did last week
<Son_Goku> it's way older
<cachio> jdstrand, hi
<Son_Goku> mvo: please fix, because there's tons of stuff missing in the 2.23 download I get from GitHub :(
<mvo> Son_Goku: in a meeting right now, but what is going wrong?
<Son_Goku> mvo: the 2.23 tag published on GitHub is invalid
<mvo> Son_Goku: I check in a little bit
<Son_Goku> it's over two weeks old
<Son_Goku> whereas you just committed 2.23 a few days ago
<Son_Goku> so things like my SELinux policy and whatnot are missing
<mvo> Son_Goku: yes, definitely wrong, sorry for that, let me fix
<Son_Goku> as well as all of zyga's merged fixes for CentOS/Fedora
<mvo> Son_Goku: sorry for that! please checkout 2.23 again
<Son_Goku> mvo: yay, thanks
<Son_Goku> looks right now
<Son_Goku> mvo: is the vendored tarball supposed to have an inner directory "snappy.upstream"?
<Son_Goku> I would have figured it'd be snapd-2.23
<mvo> Son_Goku: yeah, its an artifcat of the way dpkg-buildpackage did it, I really should fix that, can do after the meeting :)
<Son_Goku> mvo: do you know when zyga will get back?
<mvo> Son_Goku: I think 2 more days
<Son_Goku> okay, thanks
<Rumple> What's the deal with --classic snaps on the stable branch? Is there any other way to access /sys/ without --classic?
<didrocks> cjwatson: hey! it seems that all my npm install --global are failing in launchpad (while they do pass on my machine). Can be that I have some in a local cache, but I don't know if there can be some proxy issue IS-side. (https://launchpadlibrarian.net/309867959/buildlog_snap_ubuntu_xenial_amd64_chuck-norris-webserver_BUILDING.txt.gz) (Note that the same package did build successfully on the 27th FYI)
<cjwatson> (the snap proxy isn't IS-side)
<didrocks> ah ok :)
<cjwatson> didrocks: I dunno, a chmod ENOENT doesn't seem very snap proxy-ish, and it does manage to download other files
<cjwatson> have you tried snapcraft cleanbuild?
<didrocks> cjwatson: sorry, yeah, I didn't scroll high enough, I was stuck in the "npm install"
<didrocks> cjwatson: it's probably my side, need to try in cleanbuild, I always forget about this option as my lxd container was broken for a while. Sorry to have bothered you :)
<cjwatson> np - let me know if you still can't get it to work, but it looks more likely to be a bug in the package's build system to me
<didrocks> cjwatson: agreed
<mvo> Son_Goku: should be fixed now
<jdstrand> cachio: hey
<cachio> jdstrand, I was creating some performance tests for dbus
<cachio> jdstrand, trying to validate dbus performance, then I found something interesting
<cachio> jdstrand, I created some scripts in python and one snap which is running these scripts
<cachio> when I run the python scripts I get about 50% more of performance compared with the snap execution
<cachio> both are executing the same scripts
<Son_Goku> mvo: much better :D
<jdstrand> cachio: this is testing the performance of starting a script?
<cachio> jdstrand, no, it is measuring the bandwidth when I sent 20k signals
<cachio> jdstrand, I is creating a client and a server and the client is creating the signals and the server is counting all the signals that are arriving to the specific address
<jdstrand> cachio: did you factor out the startup cost of starting the snap command?
<cachio> jdstrand, no, how can I do that?
<cachio> I am not sure if I should
<cachio> because the test start when the first message arrives to the server
<cachio> the server is getting metrics from the first message to the last
<caribou> popey: well, I just realized that the file I had to copy was in the . directory so cp sos.conf $SNAPCRAFT_PART_INSTALL/etc did the trick
<jdstrand> cachio: I'm asking all this for two reasons. 1) tyhicks did extensive testing of dbus performance with the apparmor patches and found performed extremely well for normal and beyond use cases and 2) launching a snap command is not lightwight-- there is ipc to snapd involved, an exec(), reading several files, setting up a seccomp filter, setting up namespaces, etc, etc, then another exec()
<jdstrand> cachio: ok, so if the test is first message to last, that should be ok. if it includes time to get to first message, then it is measuring too much
<jdstrand> cachio: I don't know your test, but if it is waiting for the first message and that appears in the results, a simple way to adjust that would be to starting your timing on the 2nd message
<jdstrand> cachio: and to be clear-- your test is a) start command b) send messages c) stop command and *not* a) start command b) send message c) stop command d) goto 'a'
<cachio> jdstrand, the tests are:
<mup> Bug #1670371 opened: Configure hook breaks content interface plug <Snappy:New> <https://launchpad.net/bugs/1670371>
<cachio> 1- start command  in parallel(2- spammer will send x signals 3- handler will receive those signals and report metrics) 3- stop command
<cachio> jdstrand, so the start should not interfere in the tests results
<caribou> oops, I think I may have run into a bug with the --classic confinement :
<jdstrand> cachio: to be 100% sure, we can avoid the launcher and isolate apparmor
<caribou> if I run the cmd, it appends the same argument over and over (see http://pastebin.ubuntu.com/24124987/)
<caribou> I don't get that in --devmode
<jdstrand> cachio: you can do: aa-exec <name of profile> -- /path/to/script <args>
<cachio> jdstrand, sure
<jdstrand> cachio: aa-exec is sufficiently lightweight to not skew the results. <name of profile> would be snap.name.command
<caribou> could be tied to a denied AppArmor profile request to rw on /dev/tty
<jdstrand> cachio: and also to be 100% clear-- you comparisons are all on the same machine, correct?
<cachio> jdstrand, yes
<cachio> real hardware
<jdstrand> caribou: the /dev/tty denial is likely harmless, but you can add '/dev/tty rw,' to /var/lib/snapd/apparmor/profiles/nap.your.profile and reload with 'sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/nap.your.profile'
<jdstrand> er, snap.your.profile
<caribou> jdstrand: yeah, was reading on of your comment on a previous bug
<caribou> jdstrand: so might not be tied to the CLI option repeating itself forever like the pastebin shows
<caribou> jdstrand: let me try that first
<jdstrand> caribou: it wouldn't be impossible that it is tied to it, would just be surprised
<caribou> jdstrand: looks quite similar to LP: #1664427
<mup> Bug #1664427: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:Incomplete> <https://launchpad.net/bugs/1664427>
<jdstrand> cachio: fyi, the tests tyhicks did were several years ago, and it was a similar test iirc (he would have the details)-- thousands and thousands in a short time span. iirc it was around 1% overhead, but I could be making that up
<caribou> jdstrand: well, it's the snap-confine profile that rejects it
<jdstrand> caribou: ah, well, then yes, add it there
<jdstrand> caribou: but, are you running from your snap a command in /snap/bin?
<jdstrand> caribou: cause that is allowed in classic but not devmode or strict
<jdstrand> caribou: I also think that is the problem in bug #1664427
<mup> Bug #1664427: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:Incomplete> <https://launchpad.net/bugs/1664427>
<caribou> jdstrand: well, that's a python script I just invoke it as "command: sosreport"
<caribou> jdstrand: and that's the classic mode that is failing, not devmode
<mup> PR snapd#2986 opened: tests: specify the core version to be unsquashfs'ed in the failover tests <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2986>
<jdstrand> oh right, 1664427 was also with classic. any way, feel free to add that rule to /etc/apparmor.d/usr.lib.snapd.snap-confine. I suspect it won't fix the issue
<cachio> jdstrand, http://paste.ubuntu.com/24125055/
<cachio> jdstrand, I ran in my machine the tests, using aa-exec, running the snap command and running python
<cachio> I see like a 20% of difference if yo usee the metric 'messages_sec'
<caribou> jdstrand: you're right, has nothing to do with it
<jdstrand> cachio: at this point I'm going to point you at tyhicks for historical context. he may bounce it back to me
<jdstrand> cachio: he should be online in a few minutes
<cachio> jdstrand, sure, tx
<popey> jdstrand: you just rejected my ffscreencast snap - can I point you to https://bugs.launchpad.net/snapcraft/+bug/1670162 ? I don't believe it needs a .desktop file.
<mup> Bug #1670162: publish complains about desktop file un-necessarily <Canonical Click Reviewers tools:New> <Snapcraft:Triaged> <Software Center Agent:New> <https://launchpad.net/bugs/1670162>
<jdstrand> popey: if it is a cli tool, why does it need x11?
<popey> jdstrand: it's a screen capture tool.
<popey> uses x11 utils etc
<cjwatson> kyrofa: snap proxy timeout is now two hours rather than one
<mup> PR snapd#2592 closed: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<jdstrand> popey: can you request for manual review?
<mup> Bug #1670384 opened: refresh to same revision yields broken SNAP_USER_DIR <Snappy:New> <https://launchpad.net/bugs/1670384>
<popey> jdstrand: done
<mup> PR snapd#2987 opened: store: download from authenticated URL if there is a device session set <Created by matiasb> <https://github.com/snapcore/snapd/pull/2987>
<mup> Bug #1670397 opened: On Debian Stretch (9) /snap/bin is not added to path <Snappy:New> <https://launchpad.net/bugs/1670397>
<popey> thanks jdstrand
<tyhicks> hi cachio
<tyhicks> cachio: I'm not sure if I still have my old performance testing data
<jdstrand> pmcgowan: hey, do you have a branch with snapcraft.yaml for your webdemo snap?
<tyhicks> cachio: what does messages_sec represent?
<pmcgowan> jdstrand, I do, I havent pushed the latest but could
<pmcgowan> jdstrand, which bug you interested in
<mup> PR snapd#2980 closed: client, daemon: move "snap list" name filtering into snapd <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2980>
<barry> i'm trying to build a snap out of only ubuntu packages (mostly a custom command around nmap).  i'm running into trouble with missing shared libraries.  is there some snapcraft plugin that would automatically include dependent libraries or do i have to code that up myself?  i was thinking an 'apt' plugin might be nice for use cases like that
<jdstrand> pmcgowan: the denials included in bug #1667480
<mup> Bug #1667480: browser-support needs to be an implicit interface, not implicit classic <snapd-interface> <snapd (Ubuntu):Fix Committed by jdstrand> <https://launchpad.net/bugs/1667480>
<jdstrand> pmcgowan: I fixed all of those already, but then I was wanting to test on dragonboard and saw some other stuff I want to investigate
<jdstrand> pmcgowan: I have r19 from the store
<pmcgowan> ok the last branch is ok then, https://code.launchpad.net/~pat-mcgowan/+junk/webdemo
<pmcgowan> jdstrand, ^
<jdstrand> pmcgowan: thanks!
<mup> Bug #1670397 changed: On Debian Stretch (9) /snap/bin is not added to path <snapd:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1670397>
<tyhicks> cachio: I found my old benchmarks
<tyhicks> cachio: they were done on a nexus 7 phone
<tyhicks> cachio: at that time, the focus was click confinement and we expected that the common case would be a confined click application (client) talking to an unconfined trusted helper (daemon/service)
<tyhicks> cachio: measured overhead using the dbus-ping-pong test was steady at about 10%
<tyhicks> cachio: it sounds like you're confining both the client and the server in your benchmarks so that may explain the additional overhead
<cachio> tyhicks, in some machines I got the 50% of overhead
<cachio> tyhicks, i am not sure it is known
<cachio> I mean, if this overhead is what you expect or it is so much
<cachio> tyhicks, do you want to see the test code?
<cachio> just to verify the tests are ok Â¡
<cachio> ifconfig
<tyhicks> cachio: yes, please share the test code with me
<tyhicks> cachio: 50% overhead should definitely not be happening
<tyhicks> cachio: I landed that code years ago and haven't been involved since so something may have changed
<cachio> tyhicks, http://paste.ubuntu.com/24125526/
<cachio> I have a snap here
<cachio> http://bazaar.launchpad.net/~sergio-j-cazzolato/ubuntu-performance-tests/trunk/files/head:/resources/apps/kpi-dbus-tests/
<cachio> tyhicks, the snap uses these py files
<cachio> tyhicks, the I run the tests running python3 <script> <params> and through the snap
<cachio> if you want to install the snap it is stored in edge
<tyhicks> cachio: thanks - I have to run off to a meeting now but will try take a closer look by tomorrow
<cachio> tyhicks, sure
<tyhicks> cachio: is this just something interesting that you noticed or is there a real world snap that is affected by the performance?
<cachio> thibautr__, well I did similar tests for python code and external libraries, to see if the confinment was affecting its performance, and in that case the results are pretty similar running with and without confinment
<cachio> tyhicks,  well I did similar tests for python code and external libraries, to see if the confinment was affecting its performance, and in that case the results are pretty similar running with and without confinment
<timothy> hi, why did you MOVED a git tag? =.=
<cachio> tyhicks, so I am trying to measure and detect where the performance is degraded
<tyhicks> cachio: got it - I think you've narrowed in on it and, to some point, the degradation is expected
<tyhicks> cachio: we just want to make sure that the degradation is still within the acceptable bounds
<cachio> tyhicks, exactly
<timothy> the "new" tag of release 2.23 is not releaseable on archlinux :(
<timothy> since we don't have libcap static
<timothy> neither fedora
<BjornT> hi. could someone please unblock my snap bjornt-prometheus-node-exporter? it says it's pending review
<kyrofa> timothy, that might be worth a mailing list post
<mup> PR snapd#2988 opened: tests: do *not* nuke the entire /etc/systemd/system/snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/2988>
<Pharaoh_Atem> timothy: the tag was a mistake and should have been deleted weeks ago
<Pharaoh_Atem> it was just fixed this morning
<mup> PR snapd#2988 closed: tests: do *not* nuke the entire /etc/systemd/system/snapd.conf.d dir when changing store settings <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2988>
<cholcombe> so i'm building a Go snap for the first time and it's complaining about some package context stuff
<cholcombe> http://paste.ubuntu.com/24126216/
<cholcombe> i have no idea what i'm doing :) any help is appreciated
<kyrofa> cholcombe, looks like it's coming from the vendored gorilla
<kyrofa> cholcombe, are you using godep?
<kyrofa> cholcombe, because it looks like it wants you to use a Makefile
<kyrofa> cholcombe, maybe one of their standalone tarballs would be better: https://github.com/heketi/heketi/wiki/Standalone-Installation
<cholcombe> kyrofa: hmm ok
<cholcombe> yeah i saw that Makefile
<cholcombe> they've got a dockerfile also that i can follow
<cholcombe> kyrofa: no i wasn't using godep.  let me paste my snapcraft file
<cholcombe> kyrofa: http://paste.ubuntu.com/24126310/
<kyrofa> cholcombe, yeah I suggest you follow their README and wiki for installation guides
<cholcombe> kyrofa: not a good candidate for a snap?
<kyrofa> cholcombe, not necessarily, just saying you're not building it in a manner they suggest
<cholcombe> sure
<kyrofa> cholcombe, nowhere do they say `go get` will work
<cholcombe> that's true
<kyrofa> The fact that they use a Makefile typically implies to me that `go get` will _not_ work
<cholcombe> the docker file does a go get it looks like
<cholcombe> ok
<cholcombe> kyrofa: https://hub.docker.com/r/heketi/heketi/~/dockerfile/
<cholcombe> if i remember correctly this is just a gluster CLI wrapper
<kyrofa> cholcombe, they're go-getting godep; they clone heketi
<cholcombe> oh yeah i see it.  they call make
<cholcombe> crap
<kyrofa> cholcombe, welcome to go
 * kyrofa runs
<cholcombe> i heard it was a mess
<kyrofa> Yeah, not my favorite
<cholcombe> that reminds me.  i wonder if that snapcraft release has been made that allows you to install a snap to build a snap
<jdstrand> ogra_: hey, so I installed 'classic' on the dragonboard, but apt-get update gives me: http://paste.ubuntu.com/24126359/
<jdstrand> ogra_: apt-key and gnupg are present. I can kinda workaround this by using 'sudo apt-get -o APT::Sandbox::User=root ...' but that is icky. is this known?
<kyrofa> jdstrand, what revision of the core snap was used when `sudo classic` was first run?
<jdstrand> r397
<jdstrand> that's too low
<jdstrand> hmm
<kyrofa> That seems super old...
<kyrofa> 1337 is stable amd64, I'd expect a number closer to that
<jdstrand> yeah. I though I snap refershed
<jdstrand> thought*
<jdstrand> $ sudo snap refresh
<jdstrand> All snaps up to date.
<kyrofa> ...
 * kyrofa fires up my dragonboard
<jdstrand> $ sudo snap refresh core --stable
<jdstrand> that pulled down 1268
<jdstrand> weird
<kyrofa> Oh, dang. That seems like a bug
<kyrofa> Unless you were on a channel that for some reason never was updated?
<jdstrand> I just pulled it down from cdimage based on https://developer.ubuntu.com/core/get-started/dragonboard-410c
<jdstrand> and it didn't update automatically
<kyrofa> Huh... weird
<jdstrand> indeed
<kyrofa> That might be worth trying again
<jdstrand> well, I'm updated now
<kyrofa> Hahaha
<kyrofa> I just mean to figure out if there's a bug there
<kyrofa> If you have time
<jdstrand> I've added a todo
<jdstrand> kyrofa (cc ogra_): looks like if I upgrade the core snap, then install classic, then install classic from --edge, 'sudo apt-get update' still has an issue. I'll file a bug
<kyrofa> jdstrand, after you updated the core snap, you removed the classic snap?
<kyrofa> (and then re-installed it)
<jdstrand> yep
<jdstrand> and it unshashfs'd, etc
<kyrofa> Yeah sounds like a bug then
<jdstrand> kyrofa (cc ogra_): fyi, https://bugs.launchpad.net/snappy/+bug/1670475
<mup> Bug #1670475: apt-secure complaints with classic snap <Snappy:New> <https://launchpad.net/bugs/1670475>
<mup> Bug #1670475 opened: apt-secure complaints with classic snap <Snappy:New> <https://launchpad.net/bugs/1670475>
<kyrofa> jdstrand, does snap-confine set things up such that the snap is mounted in /snap/<name>/<revision> even if in reality (e.g. fedora) it's not mounted there?
<kyrofa> Wow that was a terribly-phrased question
<kyrofa> jdstrand, I mean in the snap's execution context, does it appear there even if it isn't actually there on the host?
<jdstrand> kyrofa: I've not played with fedora at all. my understanding is that the snap will see a consistent runtime. on fedora, you could install the hello-world snap then do 'hello-world.env|grep SNAP' and see what snapd is exporting
<kyrofa> jdstrand, alright. I don't have an install handy, but perhaps Pharaoh_Atem is around?
<Pharaoh_Atem> ?
<kyrofa> Pharaoh_Atem, snapd doesn't actually mount snaps in /snap on fedora, right?
<Pharaoh_Atem> absolutely not
<Pharaoh_Atem> it better not
<kyrofa> Pharaoh_Atem, does it appear like it from the snap's perspective?
<Pharaoh_Atem> it should look like any other snap from the inside
<kyrofa> Pharaoh_Atem, any chance you're in a position to install the `hello` snap and run the test jdstrand just suggested?
<Pharaoh_Atem> with the latest snapd?
<kyrofa> It doesn't have to be latest, but post November would be ideal
<jdstrand> kyrofa: it looks like snap confine honors a configure option, SNAP_MOUNT_DIR and so it would *not* be /snap/foo/current/... but instead /wherever/it/is/on/fedora/snap/foo/current
<Pharaoh_Atem> latest I've got is snapd 2.16 with snap-confine 1.0.44
<Pharaoh_Atem> only started working on getting new snapd working today
<Pharaoh_Atem> since mvo tagged it properly today
<kyrofa> Pharaoh_Atem, good enough for me if you don't mind
<Pharaoh_Atem> sure, give me a sec
 * jdstrand isn't sure it is good enough, but I guess we'll see
<jdstrand> 1.0.44 is Oct/Nov iirc
<kyrofa> jdstrand, yeah that makes sense. I knew that it supported mounting in other areas, my real question is: what does that look like to the snap?
<Son_Goku> jdstrand, kyrofa: what do you want me to do?
<Son_Goku> I have my Fedora system with snapd 2.16 and snap-confine 1.0.44
<kyrofa> Son_Goku, install the `hello` snap, and run `hello.env | grep SNAP` and pastebin the output
<jdstrand> it looks like SNAP_MOUNT_DIR is only for finding the core snap. snap-confine builds up the runtime environment from the core snap. I see that it will mount on /snap in the runtime environment but that what is mounted is configrable based on SNAP_MOUNT_DIR
<jdstrand> kyrofa: ^
<jdstrand> we'll know if my quick read is correct soon enough :)
<Son_Goku> hello.env doesn't exist?
<Son_Goku> I see hello and hello.universe
<kyrofa> Wha...
<jdstrand> it's hello-world
<kyrofa> jdstrand, oh darnit
<kyrofa> Son_Goku, sorry, I lied
<kyrofa> Son_Goku, try hello-world :P
<Son_Goku> kyrofa, jdstrand: https://paste.fedoraproject.org/paste/idScR6VoZkXLzjq21KyatV5M1UNdIGYhyRLivL9gydE=
<kyrofa> Son_Goku, thank you very much :)
<Son_Goku> no problem
<Son_Goku> also keep in mind that snapd and snap-confine are permanently in devmode
<jdstrand> Son_Goku: that is with snap-confine 1.0.44 and snapd 2.16?
<Son_Goku> yes
<jdstrand> kyrofa: I think newer code will do something different
<Son_Goku> sources here: http://pkgs.fedoraproject.org/cgit/rpms/snap-confine.git/tree/
<kyrofa> jdstrand, what do you think... too old to be a valid test?
<Son_Goku> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/
<kyrofa> jdstrand, fair enough
<Son_Goku> well, I'm working on snapd 2.23
<Son_Goku> without zyga, I have to kinda do it myself :/
<kyrofa> Son_Goku, if you get that to a working point, I'd be curious to see the same test if you're able
<Son_Goku> sure
<jdstrand> kyrofa: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/mount-support.c#L356
<Pharaoh_Atem> back to my workstation
<kyrofa> jdstrand, indeed, that does look relevant
<erimsa> Hello
<kyrofa> Hello erimsa, welcome!
<erimsa> I have lots of questions about snappy and ubuntu core
<erimsa> but I think it is too new using for a commercial product
<kyrofa> erimsa, please ask away :)
<erimsa> thanks
<erimsa> I want to use it for industrial batch controllers
<erimsa> a headless system a webserver in
<erimsa> it
<kyrofa> Sure
<erimsa> First, Can I create a snap package from existing executables ?
<kyrofa> erimsa, definitely
<kyrofa> erimsa, snaps are just squashfs images. They can contain whatever you like, organized however you like
<erimsa> I couldnt find any documentation for that
<erimsa> Ahh ok then
<kyrofa> erimsa, do you have just a tarball or binaries/libraries, then?
<erimsa> Yes, binaries
<erimsa> I have to run Codesys "PLC runtime"
<nacc> the dump plugin?
<erimsa> in Ubuntu Core
<erimsa> OK I see
<nacc> erimsa: was just a thought, for copying binaries into the snap -- kyrofa knows way more than I :)
<kyrofa> nacc, yeah I'm throwing a quick example together using just that
<erimsa> You are saying use "dump plugin"
<erimsa> for that
<kyrofa> erimsa, yeah I'll show you
<erimsa> OK Im waiting
<nacc> erimsa: right, the 'dump' plugin takes a source (as defined in the snapcraft.yaml) and verbatim copies it into the snap squashfs
<kyrofa> erimsa, take a look at this: http://pastebin.ubuntu.com/24127222/
<kyrofa> erimsa, of specific note, the last four lines
<kyrofa> erimsa, there you see `plugin: dump` as nacc is suggesting
<kyrofa> erimsa, that will download the tarball (assuming it's a URL) and extract it into the snap
<erimsa> Ok I will try it in a few days
<erimsa> In beagle bone black
<nacc> erimsa: and to be clear, that does assume the tarball's binaries have no dependencies themselves in the snap -- if they do, then you need to have those specified in your snapcraft.yaml
<kyrofa> erimsa, you need a little more metadata there to actually expose a binary to be callable (add the `apps` section that you'll see in the docs/tutorials)
<kyrofa> nacc, good catch
<erimsa> I think I getting to close to understand
<erimsa> Im
<kyrofa> erimsa, if for example your tarball depends on some debian packages, you can add them there using `stage-packages` (which you'll also see in the docs/tutorials)
<erimsa> Can you send me link for that tutorials ?
<erimsa> There are lots web page
<erimsa> s
<nacc> http://snapcraft.io/
<nacc> probably docs -> build snaps
<erimsa> Second Question
<erimsa> We need our own Custom Store
<erimsa> for snap packages
<erimsa> Is that possible ?
<kyrofa> erimsa, there are a few possibilities for that. Can you explain what you're trying to accomplish with that? Or just a "we want it under our own roof" type of thing?
<erimsa> Im working for a company that produces industrial controllers for food,chemisty,textile industries
<erimsa> And using Debian Linux as OS for devies
<erimsa> We have really problems with package versioning and installing in fields
<erimsa> I m trying to solve kind of problems
<kyrofa> erimsa, sure-- I mean specifically what you're looking for/trying to accomplish with a "custom store"
<erimsa> Lets say I decided to use Ubuntu Core and Snap technology
<erimsa> Our Snap packages should not be open for everyone
<erimsa> Publicly
<erimsa> It should be private to keep them
<kyrofa> erimsa, first of all, you can have private packages in the official store
<erimsa> I didnt know that
<erimsa> Official means Canonical Store ?
<kyrofa> Indeed, the Ubuntu Store
<erimsa> I see
<erimsa> We have lots of devices around the world ,
<kyrofa> erimsa, if you need more control than that we do have an "on-premises store" offering, but I'm not the guy to talk to about that. I can put you in touch with the people who are, though
<erimsa> Yes definitly
<erimsa> If you can give me email address I can write then
<kyrofa> erimsa, if you shoot me your email address in a private message I can send an introduction if you like
<erimsa> OK
<mup> PR snapd#2989 opened: many: some opensuse patches that are ready to go into master <Created by zyga> <https://github.com/snapcore/snapd/pull/2989>
<mup> PR snapd#2990 opened: cmd: link libcap dynamically <Created by zyga> <https://github.com/snapcore/snapd/pull/2990>
<mup> PR snapd#2991 opened: packaging: add opensuse permissions files <Created by zyga> <https://github.com/snapcore/snapd/pull/2991>
#snappy 2017-03-07
<mup> Bug #1609883 changed: Add an interface to allow access to /var/lock and/or /run/lock/ <cpc> <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1609883>
<mup> Bug #1620693 changed: Permission denied to access /sys/kernel/mm/hugepages/ <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1620693>
<mup> Bug #1638529 changed: Auto-connect is not working for connection between network-manager and modem-manager <snapd-interface> <Snappy:Expired> <https://launchpad.net/bugs/1638529>
<pshod> " kernel needs apparmor 2.4 compatibility patch " for snap install on ubuntu mate for pi3
<pshod> help1
<pshod> help1
<pshod> help!
<pshod_> anyone answered pshod?
<mup> PR snapd#2983 closed: Support spread testing with proxy <Created by nuclearbob> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2983>
<torusJKL> Hi
<torusJKL> I'm creating a Snap which contains 2 parts. The second part needs files that have been created in the first part otherwise it will not build.
<torusJKL> I tried to use a relative path, starting in the root directory of the current part, but libtool does not accept it. If I use the absolute path it builds but now the snapcraft.yaml is not portable anymore.
<torusJKL> This is what I have now:
<torusJKL> build: |
<torusJKL>   ./autogen.sh && ./configure LDFLAGS='-L/home/snapcraft/mySnap/parts/libdb4.8/install/usr/local/BerkeleyDB.4.8/lib/' CPPFLAGS='-I/home/snapcraft/mySnap/parts/libdb4.8/install/usr/local/BerkeleyDB.4.8/include/'
<torusJKL> Is there an environmental variable that holds the absolute path of previous parts? Or is there any other way to do this?
<torusJKL> I have also asked this here: http://askubuntu.com/questions/890448/snapcraft-how-do-i-use-an-absolute-path-to-files-of-a-previous-part
<joedborg> o/
<joedborg> hi torusJKL, have you used the stage and prime directives to keep the files?
<joedborg> torusJKL, you can check by looking into the prime and stage directories
<torusJKL> hi joedborg. How would I active the stage and prime directives?
<joedborg> torusJKL, have a look at https://snapcraft.io/docs/reference/plugins/common and focus on the 'stage' and 'snap' sections (but replace 'snap' with 'prime in your yaml, or you'll get warnings)
<joedborg> torusJKL, I'm still pretty new to snaps as well, so I hope i've understood what you mean
<torusJKL> joedborg. So I could copy the files from the first part to the stage area and then point to them. is there an environment variable for the stage area path?
<torusJKL> joedborg. I will try the following $SNAPCRAFT_STAGE
<joedborg> torusJKL, you could do it manually, but it'll make repeatably a bit difficult
<torusJKL> joedborg, I will try it. Thanks!
<joedborg> torusJKL, no problem; good luck.  feel free to ping me if you have any other problems (I might not be able to help, but can always try)
<mup> PR snapd#2992 opened: hookstate: run the right "snap" command in the hookmanager <Created by mvo5> <https://github.com/snapcore/snapd/pull/2992>
<alf_> Hi all! I am trying to install a snap on trusty on a system with limited network connectivity, and I get:
<alf_> Get
<alf_> https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2
<alf_> Cconfinement: net/http: request canceled while waiting for connection (Client.Timeout exceeded while awaiting headers)
<alf_> Which is expected since the network may not be working. However, and here is the issue, I get the same error when trying to install the same snap from a local copy (.snap/.assert)
<alf_> Any idea what could be going on?
<mup> Bug #1670662 opened: snap refresh modem-manager returns always that it has been refreshed (and it hasn't) <Snappy:New> <https://launchpad.net/bugs/1670662>
<ogra_> ppisati, hey ... did our apparmor patches actually make it into the 96boards kernel tree or is that only in ours ?
<mcphail> Wonder if it is just coincidence my "core" snap is at revision "1337"? :p
<ogra_> mcphail, magic ;)
<mup> PR snapd#2985 closed: hookstate: disable configure hook for core on classic <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2985>
<ppisati> ogra_: only our, and we keep getting new patches
<mup> Bug #1670662 changed: snap refresh modem-manager always returns that it has been refreshed (and it hasn't) <Snappy:Invalid by pedronis> <https://launchpad.net/bugs/1670662>
<qengho> for a tarball source with one directory in its root, autotools should start within that child dir as root, yes?
<kyrofa> qengho, where is the configure.ac file (or similar)?
<qengho> kyrofa: foo/configure.ac
<kyrofa> qengho, then yeah, if you're talking about snapcraft, you probably need to set source-subdir to foo
<qengho> kyrofa: Is that new behavior? I thought a single dir out of a tarball was a special case, for which the curdir of the upcoming "automake" was different.
<kyrofa> qengho, I'm not sure I understand what you're asking. No, source-subdir is not new behavior. It just sets the working directory for the plugin's build process
<daker> Question : is there a way to decompress a .snap file without installing it ? renaming it to .zip doesn't help
<qengho> daker: It's "unsquashfs"
<qengho> It's not a zipfile.
<nacc> daker: and to be clear, extensions in linux mean nothing
<nacc> daker: so that doesn't make any sense. this isn't windows! :)
<qengho> ...except to zip programs.
<qengho> seriously, they're dumb.
<daker> nacc: for zip programs it does
<nacc> i believe that is no longer true
<daker> qengho: yes i did forget about this one (y)
<nacc> "If no matches are found, the specification is assumed to be a literal filename; and if that  also  fails,  thesuffix  .zip  is  appended."
<nacc> that is, the tooling hides that stupidity from you
<qengho> daker: "file foo" will tell you the format of a file named foo, btw.
<nacc> but in any case, one could assume that if it were a .zip file and it needed to be *.zip to be useful, it would be named *.zip
<daker> qengho: thanks it did work
<qengho> Lots of things are zipfiles, nacc, not meant to be opened by humans. some Python modules, Jarfiles, Chrome extensions, none will be named .zip, but renaming to .zip will let you unzip them with the command line tools that have existed since 1992.
<nacc> qengho: interesting
<nacc> qengho: i still stand by my initial response of extensions are dumb on linux :)
<qengho> Okay then.
<nacc> qengho: but i see why .zip might make sense (using `file` first still seems sane)
<mup> Bug #1670165 changed: alsa interface can't see microphones <snapd-interface> <snapd:Triaged> <https://launchpad.net/bugs/1670165>
<mup> Bug #1639095 changed: On archlinux, /snap/bin is not added to the $PATH <archlinux> <snapd:New> <https://launchpad.net/bugs/1639095>
<mup> PR snapd#2993 opened: interfaces: fix default content attribute value <Created by mvo5> <https://github.com/snapcore/snapd/pull/2993>
<mup> Bug #1670749 opened: classic confinement requires manually setting PATH and PYTHONPATH <Snappy:New> <https://launchpad.net/bugs/1670749>
<elopio> ppisati: can you please take a look at this? https://github.com/snapcore/snapcraft/pull/1148#pullrequestreview-25426337
<mup> PR snapcraft#1148: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1148>
<mup> PR snapd#2993 closed: interfaces: fix default content attribute value <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2993>
<jdstrand> ogra_: hey, fyi my comments in bug #1670475. it seems to only affect dragonboard
<mup> Bug #1670475: apt-secure complaints with classic snap on arm64 (dragonboard) <Snappy:New> <https://launchpad.net/bugs/1670475>
<Odd_Bloke> We have a snap that we only want to be available to a few select users (i.e. the people who publish the snap, and a bot account which is auth'd on our production systems).  Are we able to upload a snap in such a way that it can't be installed by Jane Random but can be by a subset of people?
<Odd_Bloke> (I know a lot of work has happened on collaboration since I was last looking at this last year, but I haven't kept track closely enough to answer my own question. :p)
<pedronis> Odd_Bloke: yes, private snaps work like that
<Odd_Bloke> Sweet; and we can have the full channels experience with them?
<Odd_Bloke> (We only really need channels 1.0; we won't have more than a single major release for quite some time.)
<pedronis> Odd_Bloke: afair yes, they get published to channels etc, just that only the people with access can get them
<kyrofa> Odd_Bloke, pedronis that's my understanding as well
<mup> PR snapd#2994 opened: interfaces: fix default content attribute value <Created by mvo5> <https://github.com/snapcore/snapd/pull/2994>
<Odd_Bloke> OK, great.
<Odd_Bloke> And, last question, I think: how do I make a snap private?  None of the snapcraft commands appear to refer to either public or private (and I think the default is public?).
<kyrofa> Odd_Bloke, indeed, I'm not sure that's exposed in snapcraft very well, but it's definitely on myapps.developer.ubuntu.com
<kyrofa> There's a "Make private" button
<Odd_Bloke> Coolio.
<cachio_> tyhicks, ping
<tyhicks> cachio_: hey - no progress on the dbus perf testing yet
<cachio_> tyhicks, ok, thanks
<jdstrand> niemeyer: hey, I sent 3 messages to snapcraft@ today, but they aren't showing up. I sent something to the internal list and it did. are my emails to snapcraft@ being moderated?
<kyrofa> jdstrand, yeah, last email I see from you was on the 3rd
<jdstrand> yeah, I sent two yesterday and they aren't there
<jdstrand> it shouldn't be my client. it is sending to the canonical smtp server for the internal list as well as the external, and the ones to the internal are going through
<kyrofa> jdstrand, SOMEONE didn't like what you had to say...
<kyrofa> :P
<jdstrand> I guess so :)
<kyrofa> Maybe barry is secretly putting anti-jdstrand filters into mailman and it's only been deployed to snapcraft.io so far
<jdstrand> heh
<jdstrand> I don't *think* he'd do that to me :)
<barry> kyrofa: SSSH!! you're not supposed to tell anyone
<kyrofa> Haha
<jdstrand> hehe
<mup> PR snapd#2995 opened: Extend out-of-process provider support <Created by vosst> <https://github.com/snapcore/snapd/pull/2995>
<mwhudson> kyrofa: hey, i think https://github.com/snapcore/snapcraft/pull/1170 is waiting for you?
<mup> PR snapcraft#1170: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <https://github.com/snapcore/snapcraft/pull/1170>
<kyrofa> mwhudson, +1 from me, but I'm not clear if elopio is supposed to do something before it merges
<mwhudson> kyrofa: fair enough, but could you change your review? i don't know who is waiting for who either :)
<kyrofa> mwhudson, oh I did!
<kyrofa> mwhudson, thanks for the ping, I was waiting to see what happened there and didn't notice I was still requesting changes
<mwhudson> kyrofa: oh sorry, thanks, the mail took a while to arrive
<mup> PR snapcraft#1174 opened: copy, dump plugin: ignore symlinks to libc <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1174>
<bdmurray> ubuntu core includes a file /usr/share/snappy/dpkg.list, is that available somewhere outside of the Ubuntu Core system?
<bdmurray> Like the manifest file on cdimage
<mup> Bug #1670852 opened: python entry_points not installed into /snap/<snap>/current/bin <Snappy:New> <https://launchpad.net/bugs/1670852>
<mup> PR snapd#2994 closed: interfaces: fix default content attribute value <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2994>
<mup> PR snapcraft#1173 closed: demos, tests: add a message to exit the mosquitto subscriber <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1173>
<mup> PR snapd#2992 closed: hookstate: run the right "snap" command in the hookmanager <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2992>
<kyrofa> Huh... jdstrand I just realized MY emails to snapcraft aren't going through either!
<kyrofa> jdstrand, the last one in the archive from me is from the 1st
<jdstrand> the saga continues
<jdstrand> niemeyer: fyi, ^
<kyrofa> jdstrand, even though I see the email I sent in the list on thunderbird
<mup> PR snapcraft#1170 closed: core: fix symlink resolution in get_core_dynamic_linker <Created by mwhudson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1170>
<kyrofa> jdstrand, suddenly all our emails will show up and we'll both look like we're waaaay behind the times
<jdstrand> kyrofa: if it is both of us, it is likely others
<dasjoe> I'm having some trouble getting my apu2c4 to boot snappy 16 off a USB stick, is ttyS0 disabled after grub?
#snappy 2017-03-08
<kyrofa> dasjoe, that's probably a question for ogra_, but he's probably EOD by now (he's in Germany)
<kyrofa> dasjoe, if you come by a few hours earlier tomorrow he'll probably be around, or you can send an email to the list
<dasjoe> kyrofa: I see. We're pulling an all-nighter to get some stuff done. Oh well, I'll stick to netboot.tar.gz for now
<liuxg> in devmode, do we still need to do manually connect for platform interface?
<liuxg> I am having a problem here. in devmode, even if the platform (Qt libs content sharing) interface is disconnected, my app still can run well. It really confuses me.
<liuxg> timp, recently, I just noticed that platform interface can be automatically connected. is this trueï¼
<liuxg> kalikiana_,  is there any change on the platform interface? I find that now I do not need to manually connect the platform (qt content sharing interface) interface
<lutostag> I'm hitting https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz if anyone can help me debug that would be appreciated...
<mup> PR snapd#2996 opened: interfaces: fix default content attribute value (#2994) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2996>
<mup> PR snapd#2997 opened: hookstate: run the right "snap" command in the hookmanager (#2992) <Created by mvo5> <https://github.com/snapcore/snapd/pull/2997>
<mup> PR snapd#2998 opened: tests: do not nuke the entire snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/2998>
<mup> PR snapd#2999 opened: snapstate: revert PR#2958, run configure hook again everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/2999>
<mup> PR snapd#3000 opened: snapstate: revert PR#2958, run configure hook again everywhere (2.23) <Created by mvo5> <https://github.com/snapcore/snapd/pull/3000>
<mup> PR snapd#2991 closed: packaging: add opensuse permissions files <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2991>
<mup> PR snapd#3001 opened: partition: deal with grub{,2}-editenv in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3001>
<mup> PR snapd#2989 closed: many: some opensuse patches that are ready to go into master <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2989>
<ogra_> jdstrand, thanks for digging into it ... i'm traveling this week but will look into why the dragonboard does this once i'm home
<mup> PR snapd#3002 opened: Add support for dbus::ObjectManager session paths <Created by vosst> <https://github.com/snapcore/snapd/pull/3002>
<mup> PR snapd#2999 closed: snapstate: revert PR#2958, run configure hook again everywhere <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2999>
<mup> PR snapd#2998 closed: tests: do not nuke the entire snapd.conf.d dir when changing store settings (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2998>
<mup> PR snapd#3003 opened: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3003>
<Son_Goku> meep
<Son_Goku> mvo, left feedback on https://github.com/snapcore/snapd/pull/3001
<mup> PR snapd#3001: partition: deal with grub{,2}-editenv in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3001>
<mvo> Son_Goku: \o/
<mvo> Son_Goku: makes perfect sense, I will fix it
<Son_Goku> the joys of GRUB, eh?
<Son_Goku> :P
<Son_Goku> we just dropped GRUB Legacy as an option for fresh installs in Mageia, so I *know* this can be a problem :/
<Son_Goku> for whatever reason, some people seem to think GRUB Legacy is better than GRUB 2 :(
<mup> PR snapd#3000 closed: snapstate: revert PR#2958, run configure hook again everywhere (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3000>
<kalikiana_> liuxg: Can you elaborate? What has changed?
<liuxg> kalikiana_, it seems to be that the platform interface is automatically connected.
<liuxg> kalikiana_, just take a look at https://bugs.launchpad.net/snappy/+bug/1670371
<mup> Bug #1670371: Configure hook breaks content interface plug <Snappy:Confirmed> <https://launchpad.net/bugs/1670371>
<kalikiana_> liuxg: So what exactly is the question here? Does the configure hook change the connection behavior of the ubuntu-app-platform?
<kalikiana_> The comments in the bug seem contradictory to me, so I feel I'm missing some context
<liuxg> kalikiana_, you may try a test app at https://github.com/ubuntu/snap-tutorials-code/tree/master/webapp-ubuntu/final. it does use the platform interface. It seems that I do not need to manually connect the interface
<mup> PR snapd#3004 opened: tests: do *not* nuke the entire snapd.conf.d dir when changing store settings <Created by mvo5> <https://github.com/snapcore/snapd/pull/3004>
<kalikiana_> liuxg: That snap has no hooks... so it's an unrelated change then?
<liuxg> kalikiana_, yes, this one does not have the hooks. but it shows the change.
<kalikiana_> liuxg: So you can install it for the first time and it automatically connects?
<mup> PR snapd#2997 closed: hookstate: run the right "snap" command in the hookmanager (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2997>
<kalikiana_> liuxg That didn't work like 2 weeks ago I'm pretty sure
<liuxg> kalikiana_, yes, that is the case..
<kalikiana_> liuxg: Did you by chance check if it also works if uap isn't installed?
<liuxg> Mirv, I am now developing a Qt tutorial. in the app, it needs to use qml and quick module. would you please add it the qt remove part? thanks The modules should be commonly used.
<liuxg> kalikiana_, what is uap?
<liuxg> kalikiana_, http://paste.ubuntu.com/24137373/
<kalikiana_> liuxg: ubuntu-app-platform
<liuxg> kalikiana_, yes, it is installed..
<kalikiana_> liuxg: That's pretty cool then
<kalikiana_> Will have to try it here
<liuxg> kalikiana_, what do you mean? so this is a designed feature for it? or it is a bug?
<liuxg> kalikiana_, ok. thanks
<Mirv> liuxg: those modules are in both Qt and u-a-p remote parts
<Mirv> liuxg: with u-a-p however you'll need to have the overlay PPA versions installed on your local machine to build, u-a-p is runtime only
<liuxg> Mirv, but when I compiled my Qt app, it complains that the modules are not there.
<liuxg> Mirv, I have install the overlay for sure..
<liuxg> Mirv, I did it in a container, let me show you the result of it.
<Mirv> liuxg: qtdeclarative5-dev should have qml/quick development files
<Mirv> liuxg: however you need to specify whether you are using u-a-p or qt57/qt58 remote parts, which are different
<liuxg> Mirv, oh really? sorry, I do not know that.
<kalikiana_> liuxg: That's what was planned for a while, content iface snaps should be connected and downloaded automatically if needed
<liuxg> Mirv, what are the differences?
<Mirv> liuxg: if your tutorial is about app targeting Ubuntu Personal, you should probably be using u-a-p. if not targeting Ubuntu Personal, then maybe qt57/qt58
<Mirv> liuxg: u-a-p has lots of Ubuntu specific things like UI Toolkit, qt57/qt58 are for pure Qt applications
<liuxg> Mirv, for my case, it is a ubuntu phone app
<liuxg> Mirv, so what should be the right thing to use? how to use it?
<liuxg> Mirv, this is the output from building my project http://paste.ubuntu.com/24137400/
<liuxg> Mirv, the source code is at https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app
<liuxg> Mirv, just take the final version of it https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app/final
<Mirv> liuxg: for phone app, indeed use u-a-p (runtime) and install whatever is needed from overlay PPA when compiling, including qtdeclarative5-dev
<liuxg> Mirv, but the qml and quick are not there. I installed the phone overlay for sure.
<Mirv> liuxg: if you have qtdeclarative5-dev package installed, then I can't think of a reason it wouldn't find them when compiling. it works for me.
<Mirv> (on 16.04 LTS + overlay PPA)
<liuxg> Mirv, I used a 16.04 LTS container to build it. Inside it, I installed the overlay ppa
<Mirv> zbenjamin: ^ if you want to help
<Mirv> liuxg: ok
<liuxg> Mirv, if I manually install them, I can build it through. I just want to have it there from the remote part. that would be the best..
<Mirv> liuxg: the remote part is for runtime, it's not related to build time. that why you need to install the dependencies where you build.
<mup> PR snapd#3003 closed: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3003>
<zbenjamin> liuxg: i assume you did run apt update and apt dist-upgrade after adding the overlay?
<liuxg> zbenjamin, I did
<liuxg> zbenjamin, I just did it once again, and it showed me the same error..
<zbenjamin> what error
<liuxg> zbenjamin, http://paste.ubuntu.com/24137400/
<liuxg> zbenjamin, basically, it complains that the qml and quick modules are not there..
<liuxg> zbenjamin, the source code is at https://github.com/ubuntu/snap-tutorials-code/tree/master/snap-qt-app/final
<zbenjamin> liuxg: try installing ubuntu-sdk-qmake-extras
<liuxg> zbenjamin, Mirv the problem is that it would be good to have it in the remote part so that developers do not worry to put the packages as build-packages in the snapcraft.yaml.
<liuxg> zbenjamin, Mirv, we can install the packages manually to resole the problem. the intention is to have it in the remote part. what do you think?
<Mirv> liuxg: you just said it's working for you when you install qtdeclarative5-dev. like I said, remote part is for runtime, it's not related to your local development environment.
<zbenjamin> liuxg: forget the remote part for build time... it has nothing to do with that. The remote part is just there to provide your modules at runtime
<zbenjamin> you still need to tell snapcraft the build deps
<liuxg> Mirv, if I understand correctly, the remote part will help to install some needed packages to the development environment, right?
<Mirv> liuxg: that is, currently remote part cannot specify extra build-package from what I know. if you want to contribute such a feature to snapd, that'd be great.
<Mirv> liuxg: no, it does not install needed packages
<mup> PR snapcraft#1175 opened: demo files for snaping the bitcoin-qt client <Created by torusJKL> <https://github.com/snapcore/snapcraft/pull/1175>
<liuxg> Mirv, didrocks, what do you think?
<liuxg> zbenjamin, didrocks, Mirv, I know. qml and quick module are so commonly used. I think it would be good idea to inclu.de it in the remote part as a dependence so that it can be installed automatically
<Mirv> liuxg: the 16.04 + overlay PPA requirement do make it quite manual anyway, but yes if adding to remote part works then not only those but everything included in runtime should be added
<liuxg> Mirv, for qt apps, qml + quick are just the basic modules. if they can be include, that would be the best :)
<Mirv> liuxg: basically all or nothing. so yes if can be added, also those will be added and everything that is included in the runtime.
<liuxg> Mirv,  I have seen some modules are already there. but for the qml app support is not much.
<Mirv> liuxg: no actually there's nothing currently, only stage-packages
<liuxg> Mirv, will stage-packages be finally installed onto the development environment?
<liuxg> Mirv, if it works, can we add them into the stage-packages?
<liuxg> Mirv, it is just for building the project. I think it is not part of the runtime, am I right? having them in the stage-packages should be fine. what do you think?
<Mirv> liuxg: no, they are all in the stage-packages already, and nothing there helps in building the project
<Mirv> liuxg: what you might be missing is that there's "ubuntu-sdk-libs" in stage packages which means everything Qt you can think of
<liuxg> Mirv, how is it different from ubuntu-sdk-qmake-extras?
<liuxg> Mirv, in the error message, it says that the qml and quick are missing. build-packages is designed for setting up the build env, right?
<Mirv> liuxg: you can check both packages and see what they are, they are not related
<liuxg> Mirv, just now zbenjamin pointed that it was the  ubuntu-sdk-qmake-extras. so, I just wanted to know the difference.
<liuxg> Mirv, do you mean that stage-packages will not install the packages into the development env?
<Mirv> liuxg: he was just thinking if you have missing dependencies locally, but it's not related
<liuxg> Mirv, OK. my question is whether stage-packages help to install the needed debian pacakges into the development env. if yes, we can add the packages for qml+quick
<Mirv> liuxg: no, it should be build-packages, and not in ubuntu-app-platform but in snapcraft-desktop-helpers. I think thought in the latter it could be expanded.
<liuxg> Mirv, sorry, I got wrong. I mean the build-pacakges :)
<liuxg> Mirv, clearly, qml+quick now are not in the build packages.
<Mirv> liuxg: yep, but it's indeed the snapcraft-desktop-helper where those are missing, not u-a-p. anyway, technical details to you, check again tomorrow, there might be something improved by then.
<liuxg> Mirv, thanks for helping.. we need the build packages for building apps :)
<liuxg> Mirv, once you get it done, please let me try it.
<Mirv> liuxg: ok
<liuxg> Mirv, thanks a lot!
<liuxg> Mirv, one more thing. I using uap for my qt/website apps. it shows the platform is connected, however, it always shows an error like http://paste.ubuntu.com/24137751/
<Mirv> liuxg: that is unfortunately a snap bug, you need to ping zyga for the status of the bug
<Mirv> liuxg: it sometimes doesn't work correctly
<liuxg> Mirv, yes, it is very annoying
<Mirv> liuxg: I only find bug #1652369 now but I've seen a similar more visibly tracked bug too
<mup> Bug #1652369: Cannot connect to ubuntu-app-platform package on consecutive installs <Snappy:New> <https://launchpad.net/bugs/1652369>
<Mirv> liuxg: I agree
<Mirv> liuxg: right, this is the actual bug, in progress by zyga: https://bugs.launchpad.net/snappy/+bug/1645731
<mup> Bug #1645731: Fail to access the shared content if app starts before connect interface <Canonical System Image:Confirmed for pat-mcgowan> <Snappy:In Progress by zyga> <Ubuntu App Platform:Confirmed> <https://launchpad.net/bugs/1645731>
<liuxg> Mirv, yeah, I know the bug. it affects my creating of tutorial :(
<mup> Bug #1652369 changed: Cannot connect to ubuntu-app-platform package on consecutive installs <Snappy:New> <https://launchpad.net/bugs/1652369>
<mup> Bug #1671062 opened: Cannot open rocketchat-server on a VM <Snappy:New> <https://launchpad.net/bugs/1671062>
<kalikiana_> liuxg: Do you know the namespace work-around? At least that lets you fix it without re-installing the snap
<liuxg> kalikiana_, yes, I know the workaround. I still need to reinstall the snap,right?
<liuxg> anyway, I just make sure everything is right. remove clear install
<kalikiana_> liuxg: No you don't, that's the point
<liuxg> kalikiana_, ?
<zyga> o/
<kalikiana_> liuxg: You don't reinstall, that is the point of the work-around ;-)
<liuxg> kalikiana_, the solution is not stable sometimes.
<mup> PR snapd#3004 closed: tests: do *not* nuke the entire snapd.conf.d dir when changing store settings (2.23) <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3004>
<didrocks> Mirv: not sure what you mean, but if yu add build-packages: it's part of the build definitions and it will installed what's needed
<didrocks> Mirv: remote parts are not for runtime, they are at build time
<didrocks> Mirv: so basically, you can specify such -dev packages (you already specify qtbase5-dev btw)
<Mirv> didrocks: yeah I just got got confused by the discussion spreading in many directions, you have a pull request already
<didrocks> Mirv: oh great! Didn't get to that yet. Thanks :)
<didrocks> Mirv: merged, many thanks!
<mup> PR snapd#2996 closed: interfaces: fix default content attribute value (2.23) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2996>
<mup> PR snapd#3005 opened: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/3005>
<Mirv> thanks!
<jdstrand> ogra_: thanks :)
<zyga> jdstrand: hello
<jdstrand> hey zyga :)
<mup> PR snapd#3005 closed: packaging, tests: use "systemctl list-unit-files --full" everywhere <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3005>
<mup> PR snapcraft#1172 closed: demos, tests: add the mount-observe plug to be able to run godd <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1172>
<Son_Goku> damn it zyga, you can't hide from me! :P
<mup> PR snapd#3006 opened: interfaces browser-support,mir,opengl,unityy: updates for mir-kiosk <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3006>
<jdstrand> pmcgowan: good news, ^
<jdstrand> pmcgowan: I was able to get the dragonboard setup and work through some policy issues. there are a couple of things you should be aware of though
<pmcgowan> jdstrand, listening
<lutostag> anybody got an idea how to fix https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz ?
<jdstrand> pmcgowan: the first is that something in the webdemo snap is making it so that the first run succeeds, but all subsequent runs segfault. this is not caused by security policy denials. I resorted to doing this in webdemo: http://paste.ubuntu.com/24139053/
<jdstrand> pmcgowan: notice how if the script finds SNAP_USER_DATA, it removes a bunch of stuff
<pmcgowan> jdstrand, thats odd, I am not seeing that with y latest version
<jdstrand> pmcgowan: I don't know which of those things is the problem, but something is saved so that the next time a different code path is taken (I think it starts to think X is around) and then it segfaults
<jdstrand> pmcgowan: this is in strict mode
<jdstrand> for both sides
<pmcgowan> ah ok, so I need to see
<jdstrand> pmcgowan: but there are no denials, so it is weird
<jdstrand> pmcgowan: the other thing is that webdemo wants to save stuff in XDG_RUNTIME_DIR. snapd correctly sets this to /run/user/<uid>/snap.$SNAP_NAME, but snappy doesn't create that directory
<ogra_> just rename the demo to suicidal-browser ... done ...
<jdstrand> pmcgowan: so webdemo tries to mkdir -p $XDG_RUNTIME_DIR
<pmcgowan> jdstrand, where does it do that?
<jdstrand> pmcgowan: and while the policy correctly allows creation of /run/user/<uid>/snap.$SNAP_NAME, it (correctly) does not allow creation of /run/user/<uid>/, in this case /run/user/0
<jdstrand> pmcgowan: some library
<jdstrand> it's a freedesktop thing
<jdstrand> pmcgowan: so, the snap dies trying to create /run/user/0
<jdstrand> pmcgowan: if you do 'sudo mkdir -m 0700 /run/user/0' then start the snap, and have the policy from the above PR, then it all works in strict mode
<pmcgowan> jdstrand, but where is it that needs that folder?
<jdstrand> pmcgowan: so, we had code for creating XDG_RUNTIME_DIR properly in a PR, but it was backed out. I need to track that down
<pmcgowan> jdstrand, is that just a snap bug?
<jdstrand> pmcgowan: I don't know the specific library. it is a standard xdg thing. Somewhere in Qt
<pmcgowan> jdstrand, it seems to make a snap folder there, which hass nothing in it
<pmcgowan> not really getting how thats a qt thing
<jdstrand> pmcgowan: it is just a snap bug. snappy should be doing it. zyga had concerns with how it was being done and that part of the XDG_RUNTIME_DIR PR was reverted. I don't recall the details, but I'll chase it down
<pmcgowan> ok
<jdstrand> pmcgowan: it's a qt thing because how these libs are written is that if XDG_RUNTIME_DIR is not set, it uses a default value, if it is set, it uses that value. if the value doesn't exist, it creates it
<mup> PR snapd#3007 opened: merge the 2.23.1 release back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/3007>
<jdstrand> pmcgowan: but it isn't limited to qt. this is needed by some gnome stuff. eg, dconf
<pmcgowan> jdstrand, ok but not clear to me why it needs it? or is it just that it may need it
<jdstrand> pmcgowan: I don't think it does need it (I never saw anything in there), it is just Qt making sure it is there in case your app needs it
<pmcgowan> right
<jdstrand> it is being overly helpful in this case
<jdstrand> normally, /run/user/<uid> is going to be created by something in the user's session
<jdstrand> that is not confined
<pmcgowan> jdstrand, I really want to retest once all the content interface issues are fixed as I am never sure if we are hitting those
<ogra_> cant youjust point it to /tmp as workaround ?
<jdstrand> but we don't have a concept of user sessions in core, so nothing is doing that, so snappy needs to
<pmcgowan> ok
<jdstrand> pmcgowan: you could adjust the wrapper script to do:
<jdstrand> export XDG_RUNTIME_DIR=/tmp
<jdstrand> like ogra_ said
<pmcgowan> jdstrand, in the latest snapd/core, can I try to run confined or do you have more to land?
<pmcgowan> jdstrand, I am using a shared helper so not sure I can override it
<jdstrand> pmcgowan: yes, that content bug was annoying. I found myself doing this: sudo apparmor_parser -r /var/lib/snapd/apparmor/profiles/snap.webdemo-jdstrand.webdemo ; sudo service snap.webdemo-jdstrand.webdemo stop ; sudo /usr/lib/snapd/snap-discard-ns webdemo-jdstrand ; sudo service start snap.webdemo-jdstrand.webdemo
<jdstrand> pmcgowan: that's a bit unwieldy ;)
<pmcgowan> wow
<jdstrand> pmcgowan: you can test it yourself let me get you a paste
<jdstrand> pmcgowan: http://paste.ubuntu.com/24139271/
<jdstrand> pmcgowan: note, snapd will periodically regenerate the profiles so you might have to re-add the apparmor rules
<pmcgowan> jdstrand, thanks I will try it later on, I updated my snap to run as a daemon again and support a configure script
<jdstrand> pmcgowan: also, be sure to use a new enough core
<pmcgowan> jdstrand, stable core ok?
<jdstrand> pmcgowan: yes, all of this is presupposing 'daemon: simple'
<jdstrand> (that's why <uid> is 0 in /run/user/<uid> )
<pmcgowan> ah of course
<jdstrand> pmcgowan: which brings me to my final point. there is a check in the review tools aboug using browser-support with 'daemon'. I'll be fixing that
<pmcgowan> jdstrand, I assume you added browser-support to the list of plugs?
<jdstrand> pmcgowan: oh yes, I did
<jdstrand> pmcgowan: and pulseaudio
<pmcgowan> jdstrand, yeah I saw why pulse?
<jdstrand> pmcgowan: it was trying to use it so I put it there
<jdstrand> pmcgowan: this is my snapcraft.yaml: http://paste.ubuntu.com/24139303/
<pmcgowan> ok, prolly a browser things
<jdstrand> pmcgowan: wc.wrapper is in bin/wc.wrapper and is http://paste.ubuntu.com/24139053/ (chmod 755)
<jdstrand> pmcgowan: yeah
<Rumple> How do you get a --classic snap into the stable branch>
<Rumple> ?
<pmcgowan> jdstrand, ok will play around with it, did you need that mir-socket loop? I haent had an issue, and I worry about defining the socket path since the wrapper figures that out
<jdstrand> pmcgowan: in all, I think kiosk with oxide is in really good shape in terms of snappy with that pr (XDG_RUNTIME_DIR notwithstanding, but that is easily worked around)
<pmcgowan> jdstrand, thanks a lot for hammering on it
<jdstrand> pmcgowan: I just did it as a precaution. note that hardcoding it is basically ok cause the mir interface only allows that path
<pmcgowan> jdstrand, I thought there were two possible paths depending
<jdstrand> pmcgowan: so it is set in stone for series 16
<pmcgowan> oh
<jdstrand> there is a second unprivileged one somewhere that is exposed when you have a session like unity8
<pmcgowan> right I think thats what I recall
<jdstrand> but the kiosk scenario found and used that one
<jdstrand> (/run/mir_socket that is)
<pmcgowan> yep, so I will add it with some comments
<jdstrand> pmcgowan: it might be worth double checking with the mir team if in the kiosk scenario /run/socket is what should be used. kgunn wrote this interface with kiosk in mind, so I suspect this is all correct
<jdstrand> err, /run/mir_socket
<jdstrand> pmcgowan: right, /run/user/<uid>/mir_socket is what was used on Touch
<jdstrand> pmcgowan: but for kiosk, it is /run/mir_socket. we probably need to adjust the interface to use /run/user/<uid>/mir_socket, perhaps as an attribute, for things like the unity8-session snap (cc mterry and tedg) ^
<tedg> jdstrand: Oh, we changed that for you :-)
<tedg> That way the mir interface would be generic.
<jdstrand> tedg: oh. please give details and I'll update the comment in the interface
<tedg> jdstrand: So the idea was that there was a standard mir interface, I think an attribute or something would work.
<tedg> jdstrand: I think the change we made was to move it out of the unity8-session subdirectory as well.
<tedg> jdstrand: Though if it was an attribute, we could keep it there.
<jdstrand> tedg: I think I misunderstood. this is future stuff, not today stuff? (in terms of snapd)
<jdstrand> tedg: sorry, if you responded, I missed it
<tedg> jdstrand: No, I saw you disconnected, so I waited :-)
<tedg> jdstrand: so I'm not sure what "future" and "today" is. But I'd be all for the mir interface having an attribute for the socket path. I think it'd give us good flexibility.
<tedg> jdstrand: We really need interface hooks to apply it though, as apps would need to be able to turn that property into a MIR_SOCKET variable.
<tedg> (on connection)
<tedg> What's awesome about that is that an application switches from kiosk mode to unity8 mode based on who its mir interface is connected to.
 * tedg has a dream of a calculator kiosk to compete with the TI-81 ;-)
<jdstrand> tedg: heh, ok, cool, we are on the same page then. when unity8-session slots mir, we can discuss the attribute
<cjwatson> didrocks: do you know if there's something special required to make snaps work that want to make HTTP requests using GIO?
<cjwatson> didrocks: I have a silly little snap (http://paste.ubuntu.com/24139502/) that I've got as far as being able to show a UI, but when it tries to make any requests it says stuff like "** (telegnome:20336): WARNING **: http.vala:63: Unable to fetch 'http://www.ceefax.tv/cgi-bin/gfx.cgi?page=100_0&font=big&channel=bbc1': Operation not supported", which I think is GIO's way of saying that it doesn't ...
<cjwatson> ... have the modules it needs to talk to that particular kind of GFile
<didrocks> cjwatson: hum, I didn't try this, but yeah, I bet that the warning is a consequence of a missing module for GIO, like gvfsd-http maybe?
<didrocks> sounds like it's in gvfs-backends
<cjwatson> aha, that could be, I was thinking of gio rather than gvfs
<didrocks> yeah, but IIRC, it's using gvfs to transparently map to a file system access
<didrocks> whichâ¦ I doubt strongly will work easily with snaps
<didrocks> (daemons outside, providing a path on the systemâ¦)
<didrocks> do you want me to have a deeper look as time permits?
<cjwatson> I *thought* that gio was supposed to be able to talk HTTP itself without gvfs
<cjwatson> but it's been a while since I imported that stuff into my brain
<didrocks> it's possible that my memory is blurry and you are right. I would need to dig into the glib code
<cjwatson> yeah, if you have any time to have a look I'd appreciate it - it's totally not urgent for my thing which is unimportant, but maybe it affects other snaps too?
<cjwatson> or things that aren't yet snaps but could be
<didrocks> yeah, I guess
<didrocks> ok, adding to my list :)
<cjwatson> cheers
<didrocks> yw! I'll keep you posted (probably next week)
<cjwatson> sure, np
<mup> PR snapd#3008 opened: testutils: address review feedback from PR#2997 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3008>
<popeytest> hello world
<kyrofa> popeytest, that appears successful
<owen_> *sigh*
<benjamin_> Curious
<HumbleBeaver> Is anyone here using tpaws blender snap?
<kyrofa> HumbleBeaver, I'm not using it anyway-- is something wrong?
<HumbleBeaver> kyrofa, It has a massive slow down when working with larger files. Like its not accessing the GPU
<HumbleBeaver> Was curious if anyone else was using it on a daily basis, I don't have the same issue with the non-snaped version.
<kyrofa> HumbleBeaver, hmm, yeah I'm not sure
<ogra_> probably GPU related ... we used to have issues with nvidia and the GL interface in the past
<ogra_> (not sure if all bits have been sorted yet)
<kyrofa> HumbleBeaver, I'd suggest logging a bug against the snap in question, but the URL in the snap seems to be invalid
<kyrofa> HumbleBeaver, looks like this might be it: https://github.com/TPaw/TPawSnaps
<kyrofa> HumbleBeaver, and it's README seems to confirm your suspicions: https://github.com/TPaw/TPawSnaps/tree/master/snaps/blender
<kyrofa> At least... I think that's what is meant by SoftwareGL mode
<HumbleBeaver> Thanks, kyrofa, I'll send him a request for an update.
<lutostag> I'm guessing this bug https://bugs.launchpad.net/ubuntu/+source/lsb/+bug/1662357 is causing the launchpad build to fail for https://launchpadlibrarian.net/310093787/buildlog_snap_ubuntu_xenial_amd64_juju-crashdump_BUILDING.txt.gz, is that correct or am I off base?
<mup> Bug #1662357: Can't use lsb_release on Ubuntu Core 16 <lsb:Confirmed> <Snappy:New> <Snappy Ubuntu Core:New> <lsb (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662357>
<kyrofa> lutostag, builds on LP don't happen within Ubuntu Core
<lutostag> so its still calling lsb_release -a on the xenial system as a whole which is seemingly falling over
<kyrofa> lutostag, indeed, perhaps cjwatson has some insight there
<cjwatson> lutostag: no idea why that would fail; it should work.  have you tried it in snapcraft cleanbuild on a non-Ubuntu-Core system?
<lutostag> cjwatson: yeah local builds are 100% fine
<lutostag> yakkety on xenial lxds
<lutostag> (yakkety host) w/ xenial lxds
<cjwatson> lutostag: I guess file a bug on launchpad-buildd to start with, though not quite sure when I'll find time :-/
<lutostag> cjwatson: yeah I thought it was a borked core-16 release build w/ lsb_release, but if that's not the case not an 'easy' fix, will file
<cjwatson> you can deploy a Launchpad builder unit using https://jujucharms.com/u/launchpad/launchpad-buildd (for some reason you have to be logged into the charm store to see that URL), but working out how to operate it is still a bit of a chore
<cjwatson> (that's not how real builders are deployed, but it's good enough for most purposes)
<mup> PR snapd#3009 opened: interfaces/builtin: small refactor of dbus tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3009>
<kyrofa> Hey kgunn, I need some qmake advice if you have a sec?
<nacc> stokachu: did you end up doing the conjure-up transition from deb to snap? istr you talking about it in here a while ago
<stokachu> nacc: yea we're full on snap now
<stokachu> nacc: if you see documentation that still mentions the ppa way to install lemme know
<stokachu> needs to be updated
<nacc> stokachu: oh i was just curious if you did packaging changes to transition / how you went about it
<nacc> stokachu: as in, did you forcibly install the snap via a postinst of the dummy package or something?
<stokachu> nacc: yea i basically put a postinst in the deb package to say "remove this, snap install conjure-up"
<stokachu> i still had them run the snap install commands, i just errored
<nacc> stokachu: ah, in the PPA version? or in the published version
<stokachu> yea in the ppa version
<nacc> stokachu: ok, thanks! is there a reason you didn't transition them for you (beyond it being a bit abnormal)
<nacc> *them for them
<nacc> I guess you would have to ensure you can install snaps, etc. (user could have removed snapd)
<stokachu> nacc: yea
<stokachu> nacc: if they run snap install and it fails to find snap they get directed to apt-get install snapd :)
<stokachu> that's what i rely on for making sure they can install snaps
<stokachu> brb lunch
<nacc> stokachu: ah ok -- thanks!
<jdstrand> kyrofa: hey, is this supported: http://paste.ubuntu.com/24141235/
<kyrofa> jdstrand, that grammar is only supported for stage-packages
<jdstrand> kyrofa: basically, on amd64 I need those packages to use the preload part, but libc6-dev-i386 only exists on amd64, not say, armhf
<jdstrand> kyrofa: hmm, is that a missing feature or should I do this differently?
<kyrofa> jdstrand, so can this even be built on armhf?
<jdstrand> kyrofa: yes
<kyrofa> jdstrand, but with a different set of build-packages?
<jdstrand> I didn't test it yet, but I have https://myapps.developer.ubuntu.com/dev/click-apps/7180/rev/5/
<jdstrand> kyrofa: if I remove the build-packages, it builds on everything but amd64
<kyrofa> jdstrand, I think you're the first person who has run into this for build-packages. All the previous requests were for stage-packages. So yeah, I say log a bug
<jdstrand> kyrofa: for amd64 I used build-packages with those 4. I was wanting to then add those 4 for only amd64
<jdstrand> ok
<jdstrand> kyrofa: fyi, https://bugs.launchpad.net/snapcraft/+bug/1671238
<mup> Bug #1671238: please support selectors in build-packages too <Snapcraft:New> <https://launchpad.net/bugs/1671238>
<kgunn> kyrofa: hay back, sorry...lunch and then super distracted helping my 18 yo with his laser etching project involving inkscape ;)
<kyrofa> Thanks jdstrand, I'll bring that up in standup
<kyrofa> kgunn, ooo, that sounds like a fun project!
<kgunn> what advice can i help with?
 * kgunn worries about kyrofa asking me for advice :)
<kyrofa> kgunn, we got https://bugs.launchpad.net/snapcraft/+bug/1670146 logged against the qmake plugin snapcraft
<mup> Bug #1670146: QMake plugin should allow specifying custom Qt paths <Snapcraft:New> <https://launchpad.net/bugs/1670146>
 * kgunn reads
<kyrofa> kgunn, do you have any thoughts about how to best approach that? Does my comment sound promising?
<pmcgowan> kyrofa, what is simpler than what example [1] there is doing?
<pmcgowan> just use the existing qt part for the version you need?
<pmcgowan> or he may be using the qt lite stuff to make a custom one
<kyrofa> pmcgowan, and using QTDIR? Is that the best way to do this?
<kyrofa> pmcgowan, would we need to set QMAKESPEC and QT_PLUGIN_PATH as well? Not sure if there are others
<pmcgowan> kyrofa, Mirv is the best one to ask
<Olympionex> Does anyone know what is required to be running inside a docker container in order for snap to install the core image?  I have snapd running inside the docker, but when I try to install core it downloads fine but fails to mount.  I'm just trying to build a classic confinment snap inside a docker image, but it looks like snapcraft needs the core image for linking in libs.
<kgunn> kyrofa: pmcgowan ...ah his issue is, it's a local part, but he's wanting to use the system provided plugin..is that the issue?
<Olympionex> sorry, didn't mean to interrupt right there
<kgunn> don't apologize...it's always messy on irc :)
<kyrofa> kgunn, pmcgowan indeed, the problem is that the system plugin (shipped in snapcraft) only supports qt from the system, and _specifically_ only qt4 and qt5
<kgunn> right
<kgunn> so he's kind of wanting to "override" that with his local stuff
<kyrofa> kgunn, at least, that's what's happening in [1] on the bug. Not sure what the deal is with [2], but it looks like it's available somewhere on the system
<kgunn> to me, i don't think it's completely wrong to say...copy over the plugin and modify it
<pmcgowan> oh I see
<kgunn> i used to do that with qt stuff for mir-kiosk in early days
<kyrofa> Olympionex, I don't think running snaps inside docker is supported
<kyrofa> kgunn, yeah that's always an option if there's no easy way to make this work
<kyrofa> Olympionex, you're right in that snapcraft needs the core snap, but it supports a magical flag for exactly your situation
<kyrofa> Olympionex, try `SNAPCRAFT_SETUP_CORE=1 snapcraft`
<Olympionex> awesome, i'll try it
<kyrofa> Olympionex, and it'll download the core snap itself and unpack it instead of expecting it to be mounted into place
<kgunn> kyrofa: in the second one, he's also modified the plugin...basically to build local
<kgunn> so...that might be a reasonable request like....
<kgunn> plugin will do qt4, qt5 or custom qt setup local to your snap
<kgunn> at this point, it's prolly a Mirv proposal we'd want on how exactly to do that...
<kgunn> not sure who originally wrote the qmake plugin?
<kyrofa> kgunn, me, with your testing. You don't remember that?
<kyrofa> kgunn, that's why you're my qmake guy!
<kgunn> lol
<kyrofa> Teach you to help me
<kgunn> ah...so all my complaints ended up on your desk...oops
<kyrofa> kgunn, pmcgowan alright, thank you both for your help! It's super late for Mirv so I'll get in contact with him
<pmcgowan> jdstrand, I am back to testing ont he dragonboard and of course nothing works like it did on amd64, I am getting all sorts of denials in devmode
<pmcgowan> and I dont see my configure hook run
<Olympionex> thanks very much kyrofa!
<kyrofa> Olympionex, did that work out okay?
<Olympionex> kyrofa: yeah, doing final testing, but seemed to start it building
<kyrofa> Olympionex, good deal. And yeah, don't apologizing for jumping in-- you'd never get a word in sometimes if you didn't!
<kgunn> kyrofa: you bet.... i was still noodling inthe background...kind of wonder if there's not a way to do the override from within his yaml
<kgunn> like isn't there a configflags: field
<kyrofa> kgunn, options, yeah
<kgunn> then just looking at this
<mup> PR snapcraft#1128 closed:  tests: support bzr branches for external tests <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1128>
<kgunn> http://doc.qt.io/qt-5/qmake-variable-reference.html
<Olympionex> thanks
<kgunn> a-la "DEFINES += USE_MY_STUFF"
<kgunn> anyhoo..just an idea
<kyrofa> kgunn, that would end up being handed to the compiler though, right?
<kgunn> yes
<kyrofa> kgunn, the "application type" is interesting, though: "The target is a Qt application or library and requires the Qt library and header files. The proper include and library paths for the Qt library will automatically be added to the project. This is defined by default, and can be fine-tuned with the \l{#qt}{QT} variable."
<kgunn> but my presumption is, he's just wanting to point to his local Qt like a tool for the qmake to run
<kyrofa> kgunn, if he uses a precompiler definition, he'd have to somehow handle that in his code, no? That won't actually affect qmake, unless I'm misunderstanding
<kgunn> ah, i think you might be right
 * kgunn thinks some more
<mup> PR snapcraft#980 closed: sources: add optional "source-checksum" property <Created by pachulo> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/980>
<mup> PR snapcraft#1176 opened: demos, tests: remove the tomcat demo snap <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1176>
<mup> PR snapcraft#1177 opened: sources: update documentation for source-subdir <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1177>
<pmcgowan> kyrofa, is there a way to reinit the snapctl config for a snap, to work around that bug
<kyrofa> pmcgowan, I think you need to stop snapd, then update that json file, then start snapd again
<pmcgowan> oy
<pmcgowan> kyrofa, thanks
<kyrofa> Any time
<mup> Bug #1671266 opened: rfkill should be included in the core snap <Snappy:New> <https://launchpad.net/bugs/1671266>
<mup> PR snapcraft#1163 closed: docs: update the directory where the API pages are generated <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1163>
<kyrofa> nessita, noise][ we are having some terrible connectivity issues with the store right now that's wreaking havoc with CI. status.snapcraft.io looks clear... are there any known issues?
<kyrofa> Lots of "Connection reset by peer"
<elopio> kyrofa nessita noise][: this bug https://bugs.launchpad.net/snapstore/+bug/1666061
<mup> Bug #1666061: snapcaft tests that download the core snap fail sometimes <tests> <Snapcraft:New> <Snap Store:New> <https://launchpad.net/bugs/1666061>
<kyrofa> elopio, WAY more than 1 out of 10 today. It's been like 8/10 for me
#snappy 2017-03-09
<mup> PR snapcraft#1178 opened: tests: make the kernel unit tests architecture independent <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1178>
<Mirv> kyrofa: the bug's example links - both mine and Tim's, are modified qmake plugins. so yes, QTDIR, LIBS, QMAKE_LIBS, QMAKE_LIBDIR, INCLUDEPATH, QML_IMPORT_PATH, QML2_IMPORT_PATH would be the ones that would need to optionally allow custom path in addition to the defaults in the current qmake plugin
<mup> PR snapd#3009 closed: interfaces/builtin: small refactor of dbus tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3009>
<mup> PR snapd#2947 closed: cmd/snap-confine,tests: bind-mount /etc/os-release <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2947>
<mup> Bug #1671386 opened: cannot run a snap shell <Snappy:New> <https://launchpad.net/bugs/1671386>
<mup> PR snapd#3010 opened: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3010>
<mup> Bug #1671386 changed: cannot run a snap shell <Snappy:Invalid> <https://launchpad.net/bugs/1671386>
<mup> PR snapd#3007 closed: merge the 2.23.1 release back into master <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3007>
<mup> PR snapd#2974 closed: many: add new (hidden) `snap debug ensure-state-soon` command and use in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2974>
<Son_Goku> meep
<gbisson> hi all, I'm trying to make an ubuntu image for Boundary Devices platforms (NXP i.MX-based). I've started off the roseapple-pi and built an image ok but have several questions.
<gbisson> 1) when looking at 'snap changes' when booted up, I can see "Initialize device" in Doing state
<gbisson> it gets stuck there and I don't where to look in order to change that
<gbisson> 2) do I need to upload the gadget/kernel snaps to my dev portal so that it is recognized properly?
<gbisson> (asking cause the snap list show a rev of x1 with no developer name)
<gbisson> 3) when booting up I can see a bunch of "mkdir: can't create directory '/root/writable/system-data//etc/xxx', is that normal?
<gbisson> hmm, regarding 1 I can now see the log: ERROR cannot deliver device serial request: unexpected status 400
<mup> Bug #1671446 opened: content interface behaves different if tried an operation before connecting the interface <Snappy:New> <https://launchpad.net/bugs/1671446>
<gbisson> ok, so according to https://www.mail-archive.com/snapcraft@lists.snapcraft.io/msg02253.html this error is normal
<gbisson> since my device hasn't been pushed to canonical yet
<mup> Bug #1569581 changed: snapd no longer detects apparmor changes on upgrade <Snappy:Fix Released by zyga> <apparmor (Ubuntu):Triaged by jdstrand> <snapd (Ubuntu):Triaged> <apparmor (Ubuntu Xenial):Triaged by jdstrand> <snapd (Ubuntu Xenial):Triaged> <https://launchpad.net/bugs/1569581>
<cachio> tyhicks, any news about the dbus tests?
<Rumple> Can a (non-core) interface be provided in a snap?
<kalikiana_> Rumple: Snaps can implement interfaces, provided snapd declares it
<kalikiana_> What sort of interface is it?
<Rumple> kalikiana_: awesome, I wish to access /sys/class/hwmon & /sys/dev - it's a fancontroller (fancon)
<Rumple> kalikiana_: can you point me to some documentation on including an interface, I haven't been able to find any
<Rumple> kalikiana_: sorry misread you, there is no interface that provides the access
<kalikiana_> Rumple: Have a look at interfaces/builtin/basedeclaration.go in snapd, pulseaudio for example can be provided by the system or a snap, lxd is only implemented by a snap
<kalikiana_> You'll want to add a new interface exposing what you need
<mup> Bug #1581610 changed: snap connect/disconnect does not abort when an error occurs <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1581610>
<mup> Bug #1665590 changed: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:Fix Released by zyga> <https://launchpad.net/bugs/1665590>
<kalikiana_> Rumple: Although it sounds like you mainly need access to those devices? No extra service implementing them?
<Rumple> kalikiana_: correct. I would use --classic but stable branch does not allow that (without manual review')
<King_InuYasha> sergiusens: hey, it's been a long time!
<King_InuYasha> haven't seen you around here in a while
<kalikiana_> Rumple: Maybe double-check with jdstrand which is more sensible
<Rumple> kalikiana_: thanks I'll give it a try
<Jasem[m]> so I tried to make a snap for my app (KStars), and I install KF5 content snap, but when I start the program (kstars), I get error while loading shared library: libKF5Crash.so.5: cannot open shared object file
<mup> PR snapcraft#1176 closed: demos, tests: remove the tomcat demo snap <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1176>
<qengho> Anyone have a trick for a upstream project that doesn't honor the INSTALL_ROOT env var to its "make" invocation?
<qengho> I see "make-install-var" yaml key. I'm not sure it takes anything.
<qengho> fg
<sergiusens> Jasem[m]: you need to publish as the same publisher as the kde5-frameworks one or maybe manual connect to the content interface slot for kde-frameworks5
<sergiusens> qengho: that allows you sets you up to use prefix instead
<Jasem[m]> sergiusens: how do I do that? manuall connect the content interface?
<Jasem[m]> sergiusens: I just looked in my /snap directory, have ubuntu-core, kde5-frameworks-5, and kstars
<Jasem[m]> in kstars, there is /snap/kstars/current/kf5 but empty, and of course /snap/kstars/current/usr/lib/* does not have libKF5Crash.so provided by the kde-frameworks-5 snap
<qengho> Ah, "artifacts" yaml key. Got it.
<nuclearbob> I'm not sure who to ask about this (maybe ogra_ ?) but I'm trying to auto-import a system-user assertion on a virtual machine, and in the logs I see things proceeding up to the api call to create the user, but the user doesn't actually get created
<mup> Bug #1671511 opened: snap run --shell <snap> should ignore env vars such as PROMPT_COMMAND <Snappy:New> <https://launchpad.net/bugs/1671511>
<tyhicks> cachio: no, sorry, I've been busy with security updates this week and haven't been able to get enough breathing room to look into perf testing
<Jasem[m]> so I ran snap interfaces kde-frameworks-5
<Jasem[m]> but got nothing, no Slot/Plug!
<Jasem[m]> also ran snap interfaces kstars and got only some of the plugs specified in the snapcraft.yaml file, the rest (camera, serial-port, pulseaudio) not listed
<sergiusens> Jasem[m]: maybe it isn't connected to anything and doesn't show? http://paste.ubuntu.com/24146456/
<Jasem[m]> sergiusens: so I connect it to kstars ? sorry never done this before
<sergiusens> Jasem[m]:  snap connect kstars:<plug-name> kde-frameworks-5:<slot-name>
<Jasem[m]> sergiusens: let me run that and check
<sergiusens> don't know your plug-name and slot-name you can check in my paste
<Jasem[m]> sergiusens: error: cannot perform the following tasks:
<Jasem[m]> - Connect kstars:kde-frameworks-5-plug to kde-frameworks-5:kde-frameworks-5-slot (cannot connect plug "kde-frameworks-5-plug" from snap "kstars", no such plug)
<Jasem[m]> This is what I get from 'snap interfaces kstars' https://paste.kde.org/prugyftgz
<elopio> didrocks: davidcalle: I was making a snap for bitcoin and found that most of the other cryptocoins out there are just forks. So I think it would be really useful to have a tutorial to snap bitcoin. What do you think?
<Jasem[m]> sergiusens: here is my snap if you want to test it yourself: http://indilib.org/jdownloads/snap/kstars_2.7.5_amd64.snap
<didrocks> elopio: I would prefer we cover the per-topic tutorials first
<didrocks> once we are done, yeah, real life use case can be useful
<davidcalle> elopio: is it an electron app?
<didrocks> if it serves a real purpose directly, we can turn it into that topic
<didrocks> like electron
<elopio> davidcalle: no. It's qt, a daemon and a cli.
<didrocks> oh, interesting topic
<didrocks> but yeah, can be once we covered the basics
<didrocks> (unless you volounteer to write it)
<davidcalle> can you port it to Electron?
<davidcalle> (kidding)
<elopio> didrocks: not me, but a guy from the community. Should I tell him to start writing it and maybe publish it somewhere else while the basic tutorials are in place?
<didrocks> elopio: no, he could just coordinate with us (we can flush out together the titles/structures)
<didrocks> I'm happy to help
<elopio> didrocks: cool. If I fail to convince him, I'll do it myself.
<elopio> the only problem I see is that we need to apply a tiny patch in the source code. But I hope that snappy will give us a workaround.
<didrocks> elopio: \o/
<didrocks> yeah :)
<Rumple> How long does 'manual review' take, and does it occur on every release (classic confinement snap in stable branch)?
<mup> PR snapcraft#1179 opened: godeps plugin: add git to build-packages <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1179>
<flexiondotorg> seb128 didrocks Have you ever tried using classic confinement and the desktop helpers?
<flexiondotorg> This combination results in desktop-launch not found.
<mup> PR snapd#3011 opened: tests: remove core_name variable <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3011>
<didrocks> flexiondotorg: I didn't, but you need to say bin/desktop-launch I think
<didrocks> I opened a bug about it, was set as "low" priority (at least having an error message)
<flexiondotorg> I'll give that a go. I think I been here before ;-)
<mup> PR snapcraft#1178 closed: tests: make the kernel unit tests architecture independent <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1178>
<mup> PR snapd#3001 closed: partition: deal with grub{,2}-editenv in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3001>
<gbisson> hi all, what would be the best type to package firmware (wifi, bt, etc..) inside its own snap?
<kyrofa> gbisson, I don't quite understand the question
<gbisson> kyrofa: I need to had some firmware files to my image
<sergiusens> gbisson: kernel snap
<gbisson> kyrofa: from what I can see there's a firmware section to the kernel snap
<gbisson> but I'm asking if it can be in its own snap
<gbisson> so you can update the firmware files without updating the kernel basically
<kyrofa> gbisson, hmm, I doubt it, but sergiusens might know some more about how that's structured
<gbisson> kyrofa: thanks! I'm not sure to understand the motivation behind forcing the firmware to be with the kernel snap
<kyrofa> gbisson, unfortunately I'm afraid I don't either, but I'm sure there's a reason
<kyrofa> gbisson, I don't have as much experience with kernel snaps as I'd like
<kyrofa> gbisson, ppisati may have some insight into this as well
<elopio> stgraber: hey, I haven't received a confirmation from you on the calendar. Are we still up for the testing day tomorrow?
<stgraber> elopio: yeah, all good
<gbisson> sergiusens: ppisati: anymore detail on this limitation about the firmware?
<gbisson> sergiusens: ppisati: also, does it have to be in a tar-content? or can it be from a folder?
<sergiusens> gbisson: from whatever valid source you have
<sergiusens> kyrofa: gbisson the reason for it all to be together is predictability
<elopio> stgraber: \o/
<gbisson> sergiusens: thanks for the clarification although I'm still not convinced (what is the difference with a regular Ubuntu system where each fw has its own package)
<gbisson> sergiusens: this also avoids installing firmware you don't need, which is useful for embedded systems with some space constraints
<sergiusens> davidcalle: do we have docs going over the differences in Ubuntu Core? ^
<sergiusens> gbisson: I suggest going to the mailing list and bringing up your concenrs there
<gbisson> sergiusens: I know the difference between Ubuntu and Snappy, I meant the difference in predictability between the two
<sergiusens> gbisson: then why are you asking these questions?
<gbisson> sergiusens: I'm not saying I know it all, I just wanted to point that my question was only about "why is predictability an argument for Snappy and not Ubuntu" and not "what are all the difference between the 2"
<gbisson> sergiusens: anyway I'll add the firmware inside the kernelsnap as it's supposed to be, thanks
<sergiusens> gbisson: what I mean is, ask these questions on the mailing list; the whys will be answered there
<mup> Bug #1670749 changed: classic confinement requires manually setting PATH and PYTHONPATH <openstack> <Snappy:Invalid> <https://launchpad.net/bugs/1670749>
<pmcgowan> jdstrand, hey, testing the confined version and getting one denial still accessing mir, did I miss something
<pmcgowan> Mar 09 20:15:29 patsdragon audit[5240]: AVC apparmor="DENIED" operation="capable" profile="snap.mir-kiosk.mir-kiosk" pid=5240 comm="Mir/IPC" capability=21  capname="sys_admin"
<mup> Bug #1670749 opened: classic confinement requires manually setting PATH and PYTHONPATH <openstack> <Snappy:New> <https://launchpad.net/bugs/1670749>
<pmcgowan> jdstrand, nm, somehow lost the kiosk changes
<mup> PR snapd#3012 opened: [interfaces] Enable location.Service.Provider in dbus policy <Created by vosst> <https://github.com/snapcore/snapd/pull/3012>
<mup> PR snapcraft#1180 opened: tests: support snap directory in external tests <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1180>
<mup> PR snapcraft#1179 closed: godeps plugin: add git to build-packages <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1179>
<Odd_Bloke> Can anyone point me at an example of using seed.yaml to seed snaps for installation on first boot?  I'm struggling to get it to work (on zesty, classic).
<Odd_Bloke> I have the snap I want installed in /var/lib/snapd/seed/snaps/ and the assertion that was downloaded by `snap download` at /var/lib/snapd/seed/assertions/.
<Odd_Bloke> My seed.yaml is 'snaps: [ "hello-world_27.snap" ]' (but formatted more like yaml).
<Odd_Bloke> snapd tells me I need a model assertion, and I'm not sure how to produce one in this one-off case.
<Jasem[m]> can you install a GUI app on Ubuntu Core?
<Odd_Bloke> OK, I've found http://people.canonical.com/~vorlon/amd64-generic-model.assertion but then I hit "devicemgr: cannot find account-key (9tydnLa6MTJ-jaQTFUXEwHl1yRx7ZS4K5cyFDhYDcPzhS7uyEkDxdUjg9g08BtNn): assertion not found" and I'm not sure how to fetch that assertion.
<slangasek> huh
<Odd_Bloke> Presumably due to "sign-key-sha3-384: 9tydnLa6MTJ-jaQTFUXEwHl1yRx7ZS4K5cyFDhYDcPzhS7uyEkDxdUjg9g08BtNn" in that assertion.
<slangasek> have the keys rotated or something?
<slangasek> Odd_Bloke: you probably want to 'snap known' the model assertion, now that this interface exists, instead of using my one-time cached one
<Odd_Bloke> slangasek: `snap known model` gives nothing; perhaps you meant `snap ack /var/lib/snapd/seed/assertions/model.assert`?  That gives the same error.
<slangasek> Odd_Bloke: 'snap known model series=16 brand-id=canonical model=pc-amd64 --remote' - ok, the model hasn't changed.  so instead, you need 'snap known account-key public-key-sha3-384=9tydnLa6MTJ-jaQTFUXEwHl1yRx7ZS4K5cyFDhYDcPzhS7uyEkDxdUjg9g08BtNn --remote' to grab the account-key assertion from the store
<pmcgowan> Jasem[m], yes, for example https://developer.ubuntu.com/en/snappy/guides/mir-snaps/
<pmcgowan> jdstrand, about?
<slangasek> Odd_Bloke: but I think you probably don't want the pc-amd64 assertion here, since that enforces gadget+kernel and I assume you're trying to seed onto classic?
<Odd_Bloke> slangasek: I am, yeah.
<Odd_Bloke> Was just sort of looking around for model assertions I could steal from.
<slangasek> Odd_Bloke: which loops back around to a question from mvo on one of the bugs about how to do seed.yaml for classic
<Jasem[m]> pmcgowan: well I need to run KStars which is a KDE application, so that's not possible?
<slangasek> https://bugs.launchpad.net/snappy/+bug/1609903/comments/7
<mup> Bug #1609903: Enable the installation of snaps in a classic chroot <cpc> <Snappy:New> <https://launchpad.net/bugs/1609903>
<slangasek> Odd_Bloke: ^^ I don't know what the "needed" assertions are for seed.yaml on classic
<slangasek> but I'm sure you don't want the pc-amd64 model assertion
<pmcgowan> Jasem[m], it may work following the approach there as its a qt app and thats what that demo shows, not sure what else KStars needs
<Odd_Bloke> slangasek: OK, fair enough.
<Odd_Bloke> This sort of question was much easier to get answered in my old timezone. :p
<Jasem[m]> pmcgowan: It need Qt5+KF5 so obviously X11
<pmcgowan> Jasem[m], there is a QPA plugin directly to MIR that does not require X11, but you do not get a window manager
<Jasem[m]> pmcgowan: well, a minimal desktop environment is required. I guess Ubuntu Core is not the solution I'm looking for. Maybe Ubuntu Mate would do
<pmcgowan> Jasem[m], yes core is not quite ready for a full desktop, we are working toward it
<Jasem[m]> pmcgowan: If I use Ubuntu Mate, but install my app as a snap, it still would get the benefit of snaps like if I update it on the store, then users would get the updates atomically?
<pmcgowan> Jasem[m], yes
<Odd_Bloke> slangasek: I continued poking at it, and I think those model assertions need s/TBD/canonical/.
<Odd_Bloke> But, of course, making those changes means that the signature doesn't validate.
<slangasek> Odd_Bloke: right, those are not the official assertions (not sure why the ones published there have that) - the official assertion is the one retrievable by 'snap known model series=16 brand-id=canonical model=pc-amd64 --remote'
<Odd_Bloke> OK, now I get to "state ensure error: devicemgr: cannot seed a classic system with an all-snaps model" as we would expect.
<Odd_Bloke> The system works!
<slangasek> :)
<Odd_Bloke> Just not currently in my favour.
<Mario__> hi all! I'm evaluating Rocket Chat using snap. I want to now if there is some, let's say, convinient way to backup the current installation before applying major configuration changes to the app. Perhaps it's just about taring the app directory below snap.
<Odd_Bloke> slangasek: Is there a way I can list model assertions that the store has?
<slangasek> Odd_Bloke: you can query by attributes; I don't believe you can list
<qengho> Mario__: Find the SNAP_DATA (or SNAP_COMMON), and copy it. For a daemon, you are guaranteed that the dir there has the only files the package changed, because snap disallows anything else.
<Mario__> thanks a lot qengho
<Odd_Bloke> slangasek: Hmph, I need to know the model of a model assertion to query for it.
<Odd_Bloke> So I can't see if we have any classic assertions.
<slangasek> right
<Odd_Bloke> Am I able to create my own model assertion, or will snapd choke because my key isn't in the store's web of trust?
<kyrofa> Odd_Bloke, it'll choke, but you can get your key there
<kyrofa> Odd_Bloke, follow this tutorial, you'll see what I mean: https://tutorials.ubuntu.com/tutorial/create-your-own-core-image#0
<Odd_Bloke> kyrofa: Thanks!
<Odd_Bloke> It worked! \o/
<Odd_Bloke> kyrofa: One piece of feedback on that tutorial: "you will find it on your account page" <-- it wasn't immediately obvious to me how to get to my account page to find this
<kyrofa> Odd_Bloke, the account ID, you mean?
<Odd_Bloke> kyrofa: Yep, sorry, should have given more context.
<kyrofa> Odd_Bloke, you may wonder how I knew exactly what you were talking about: I ran into the same thing :P
<Odd_Bloke> ^_^
<kyrofa> Odd_Bloke, so yeah, agreed
<Odd_Bloke> Not sure if you're the person to feed back to, but this is what happens when you're helpful. ;)
<kyrofa> I think probably either didrocks or davidcalle
<davidcalle> Odd_Bloke: that's a fair point, do you mind filing an issue about it? https://github.com/canonical-websites/tutorials.ubuntu.com/issues
<Odd_Bloke> davidcalle: Sure thing.
<davidcalle> Thanks!
<Odd_Bloke> davidcalle: https://github.com/canonical-websites/tutorials.ubuntu.com/issues/137
<davidcalle> Nice, ty
<kyrofa> jdstrand, could I borrow your eyes for a minute? The nextcloud snap has a bug against it that I can't quite figure out: https://github.com/nextcloud/nextcloud-snap/issues/221
<kyrofa> jdstrand, oparoz is saying that it reminds him of a snap-confine issue from a while back, but I'm fuzzy
<mup> PR snapcraft#1157 closed: repo: support versioned stage-packages <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1157>
<mup> PR snapcraft#1177 closed: sources: update documentation for source-subdir <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1177>
#snappy 2017-03-10
<mup> PR snapcraft#1180 closed: tests: support snap directory in external tests <Created by elopio> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1180>
<mup> PR snapcraft#827 closed: Support setting build targets in the maven plugin. Make the maven pluâ¦ <Created by evandandrea> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/827>
<mup> PR snapcraft#1181 opened: repo: fixup with python, not sed <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1181>
<mup> PR snapcraft#1182 opened: meta: do not quote the command wrapper args <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1182>
<Son_Goku> sergiusens: ping
<sergiusens> mwhudson: hey, would this fix my problem https://github.com/lxc/lxd-pkg-ubuntu/pull/27 ?
<mup> PR lxc/lxd-pkg-ubuntu#27: Quote $@ in the lxc wrapper <Created by sergiusens> <https://github.com/lxc/lxd-pkg-ubuntu/pull/27>
<sergiusens> Son_Goku: pong, but you know I am more reliable on rocket ;-)
<mwhudson> sergiusens: that looks more plausible yes
<Son_Goku> mrrr
<sergiusens> mwhudson: great, I guess I can propose for the use of environment and get rid of the wrapper in that branch too
<mwhudson> sergiusens: in fact i said on the bug "This bug looks more like a $@ that should be quoted isn't rather than one that is quoted and shouldn't be." :-)
<mwhudson> (this hasn't gone out in mail yet afaict)
<sergiusens> ah, thanks, well I will invalidate the bug, thanks
<mup> PR snapcraft#1182 closed: meta: do not quote the command wrapper args <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1182>
<mwhudson> sergiusens: bash quoting is comletely insane
<mwhudson> +p
<sergiusens> mwhudson: when it comes to something stgraber did I sometimes just doubt myself too much :-)
<mwhudson> haha
<justinmcp> hey all, can I add gcc, et al., to a snap so that scripts in the snap can compile?
<mup> PR snapd#2302 closed: asserts: implement snap-developer type <Created by emgee> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2302>
<mup> PR snapcraft#1183 opened: First step; ruby support <Created by justincan> <https://github.com/snapcore/snapcraft/pull/1183>
<mup> PR snapd#2752 closed: snap: add support user-sessions from snaps <Blocked> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2752>
<mup> PR snapd#2938 closed: cmd/snap-update-ns: compute next action to transition mount profile <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2938>
<mup> PR snapd#2782 closed: timeutil: a bunch of helpers for the scheduled refreshes <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2782>
<mup> PR snapd#2787 closed: interfaces: add unity8 plug permissions <Created by mikix> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2787>
<mup> PR snapd#2978 closed: cmd/snap-confine: use sc_do_umount everywhere <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2978>
<mup> Bug #1590767 changed: Support snap installed completion scripts <isv> <snapd-interface> <Snapcraft:Triaged> <snapd:In Progress by chipaca> <https://launchpad.net/bugs/1590767>
<mup> PR snapd#2930 closed: tests: add systemd dependency loop failover test scenario <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2930>
<mup> Bug #1671776 opened: snap install halt during installation <Snappy:New> <https://launchpad.net/bugs/1671776>
<mup> Bug #1671778 opened: failover:emptysystemd test fails <Canonical System Image:New> <Snappy:New> <https://launchpad.net/bugs/1671778>
<mup> PR snapcraft#1181 closed: repo: fixup with python, not sed <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1181>
<mup> PR snapcraft#1011 closed: ci: use a named docker instance with proper working dir and env <Created by 3v1n0> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1011>
<mup> PR snapd#2972 closed: cmd/libsnap: add sc_quote_string <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2972>
<mup> PR snapd#2963 closed: interfaces: use MockInfo in tests <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2963>
<mup> PR snapd#2986 closed: tests: specify the core version to be unsquashfs'ed in the failover tests <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2986>
<mup> PR snapd#3008 closed: testutils: address review feedback from PR#2997 <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3008>
<mup> PR snapd#3006 closed: interfaces: updates for mir-kiosk in browser-support, mir, opengl, unity7 <Created by jdstrand> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3006>
<mup> Bug #1671776 changed: snap install halt during installation <Snappy:Invalid> <https://launchpad.net/bugs/1671776>
<mup> PR snapd#2984 closed: interfaces: seccomp spec API tweaks for better tests <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2984>
<pstolowski> niemeyer, thank you!
<niemeyer> pstolowski: np, and thanks for pushing those!
<mup> PR snapcraft#1164 closed: tests: run the master tests against the staging server <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1164>
<elopio> didrocks: I think the title here is wrong, because they are not all desktop snaps: https://insights.ubuntu.com/2017/03/09/10-desktop-snaps-written-in-february
<mup> PR snapd#3013 opened: cmd/libsnap: simplify sc_string_quote default case <Created by zyga> <https://github.com/snapcore/snapd/pull/3013>
<mup> PR snapcraft#1184 opened: store: enable retries for store calls <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1184>
<joedborg> thanks for bringing build.snapcraft.io to my attention popey
<didrocks> elopio: agreed, I didn't write the content though, just hilighted the ones that should be in
<didrocks> elopio: I'll pass the message, but now that it's publishedâ¦
<didrocks> elopio: thanks for noticing btw :)
<coreycb> elopio, do you recall what the reason was for having to build python for classic python snaps?  just curious for my own knowledge.
<stokachu> anyone know if there is a kpi dashboard for snap downloads?
<mup> PR snapd#3014 opened: tests: add dbus interface spread test <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3014>
<coreycb> stokachu, oh hey, maybe you know the answer to my question
<stokachu> coreycb: hey! yea there was a reason i just dont remember it, lemme look through git logs
<coreycb> stokachu, ok thanks, no big deal really, just curious
<stokachu> coreycb: https://github.com/snapcore/snapcraft/issues/1080; https://github.com/snapcore/snapcraft/issues/1090
<stokachu> think those were the 2 big ones
<elopio> coreycb: I got lost there too. I just got that zyga has more details. Sergio can explain that too.
<elopio> it seems both have migrated to rocket chat.
<coreycb> stokachu, elopio: thanks.  they're not in here eh?
<niemeyer> jdstrand: ping
<jdstrand> niemeyer: hey, I saw all your PR pings
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Yeah, was really about to see if you could do a run through today by any chance
<jdstrand> niemeyer: I'm going to try my best to get to them today, but I need to attend to a high priority item before them
<niemeyer> jdstrand: I did almost a full pass today, and there are quite a few low-hanging fruits in there
<niemeyer> jdstrand: Thanks, appreciated!
<jdstrand> niemeyer: my plan was: high priority item, go through low hanging fruits PRs and go to higher and higher hanging as have time :)
<mup> Bug #1671855 opened: snap command should provide a way to display account ID <Snappy:New> <https://launchpad.net/bugs/1671855>
<niemeyer> jdstrand: Sounds perfect, thanks!
<jdstrand> niemeyer: I can say I did respond to the maliit one earlier
<niemeyer> jdstrand: Sweet, I think that one is ready to merge
<Trevinho> I'm running snapd in trusty (with xenial kernel backport)...
<Trevinho> and after a reboot no snap seem to work
<Trevinho> marco@tricky:~:â $ snap run hello
<Trevinho> cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_BsULNe//dev: No such file or directory
<mup> PR snapd#2793 closed: interfaces: add maliit input method interface <Created by Elleo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2793>
<Trevinho> ok, for some reason I had core and multiple snaps marked as "broken"
<Trevinho> now it works
<Trevinho> check http://paste.ubuntu.com/24152298/
<cachio> niemeyer, hi, I am trying to create 2 snaps which use the content interface, and it is not mounting as it would expected, do you know who could help we with that?
<niemeyer> cachio: zyga is most familiar with those details.. we're aware of one bug that he's actually working on right now that might impact that exact case
<niemeyer> cachio: What are the details?
<cachio> basically, 1 snap is creating slots read and write and the other plugs those and it is trying to execute an executeble in the read section
<cachio> niemeyer, but when I run the app, I make an ls inside it and I don0t see the directory  mounted where it should be
<cachio> basically I should see a directory $SNAP/extra-bin and it is not there from the app context
<cachio> niemeyer, should that be affected by that bug?
<niemeyer> cachio: Might be.. try this: stop any daemons/processes running from that snap.. type "sudo rm /run/snapd/ns/<snap name>.*", then try again
<cachio> niemeyer, getting rm: cannot remove '/run/snapd/ns/kpi-content-consumer-tests.mnt': Device or resource bus
<cachio> y
<cachio> niemeyer, and there are not any process/daemon running for that snap
<niemeyer> cachio: That probably means something is still running from that snap
<niemeyer> cachio: Sorry, you may need to umount it actually
<niemeyer> cachio: sudo umount it
<cachio> niemeyer, ok
<cachio> cannot mount /snap/kpi-content-producer-tests/x14/bin at /snap/kpi-content-consumer-tests/x24/extra-bin with options bind,ro: No such file or directory
<cachio> I should create the dir extra-bin first?
<cachio> niemeyer, or snapd should do that?
<niemeyer> cachio: That directory is read-only, so you need to provide it in your snap
<cachio> niemeyer, ok, make sense
<Fohlen-> heya there. Is it any way possible to use a virtualenv in a scriptlet?
<Fohlen-> seems to be buggy as hell for me
<Fohlen-> I do want to use conan which is installable via pip, but global install seems to be even more buggy
<kyrofa> Fohlen-, hmm, and using `python-packages` isn't working?
<kyrofa> Oh wait, conan is a build system huh
<Fohlen-> kyrofa: nope.When using python from a scriptlet with the python plugin it falls back to the system python
<Fohlen-> which is quiet annoying
<kyrofa> Fohlen-, I've never tried with virtualenvs from scriptlets, but worst case you can write a custom plugin for it
<Fohlen-> I probably have to
<kyrofa> Fohlen-, yeah, that makes sense
<kyrofa> Fohlen-, I think you've reached the limits of scriptlets, heh
<Fohlen-> apparently I did :)
<kyrofa> Fohlen-, just put the custom plugin in snap/plugins/, you can distribute it along with the snapcraft.yaml
<Fohlen-> kyrofa: in that case I'd have to use env variables from snapcraft, would that be feasonable?
<kyrofa> Fohlen-, I'm not sure what you mean
<Fohlen-> consider this,       CONAN_USER_HOME=$SNAPCRAFT_PART_INSTALL/usr/local/games/inexor conan install . --build=missing
<Fohlen-> as a plugin
<Fohlen-> I'd need it to install the dependencies inside the snap, otherwise it breaks when packaging up
<Fohlen-> :|
<kyrofa> Oh certainly
<kyrofa> Fohlen-, when you shell out to call conan, you can set the environment right there
<Fohlen-> that was what I did initially, and it nicely broke up on another systm
<Fohlen-> kyrofa: how'd I do that?
<Fohlen-> and would that work out with a plugin?
<Fohlen-> https://github.com/Fohlen/conan-snapcraft
<Fohlen-> is what the plugin looks like
<kyrofa> jdstrand, any idea what's happening here? https://askubuntu.com/questions/888497/snap-confine-refuses-to-launch-application-to-avoid-permission-attack
<jdstrand> kyrofa: it looks like snap-confine is compiled for enforce mode and installed setuid but there is no apparmor profile for it
<jdstrand> kyrofa: this is something zyga added recently
<kyrofa> jdstrand, someone in rocket is getting that error claiming to be running normal Ubuntu 16.04. How could that happen?
<kyrofa> Ah, hmm
<jdstrand> kyrofa: perhaps the profile was unloaded?
<jdstrand> kyrofa: eg, sudo aa-status | grep snap-confine
<jdstrand> kyrofa: there is something mvo was working on that would run snap-confine from the core snap with a path to the profile from the core snap. not sure if that landed, but if it did and it is trying to run that snap-confine but that profile isn't loaded, the same thing would happen
<kyrofa> jdstrand, oh interesting, although I expect that would break for everyone
<kyrofa> jdstrand, of course, he left :(
<kyrofa> jdstrand, well anyway, thanks for the info! Not sure what's happening here
<cachio> niemeyer, working now, that umount that I have to do should be fixed whith that bug that you mentioned?
<niemeyer> cachio: Right, it's supposed to work dynamically.. no need to do anything else other than connecting the interface
<cachio> niemeyer, great, thanks
<niemeyer> cachio: If you sit here in the channel in the next few days you'll hear about the term "update-ns".. that's what this is about
<cachio> niemeyer, great
<cachio> niemeyer, thanks for the help
<lutostag> if somebody can review for snap id: N6CL1Ml1gj5SmGCmyy97CSvE3vzgjfb3, would be appreciated
<mup> PR snapd#3015 opened: interfaces: alphabetize framebuffer in base decl and add it to all_test.go <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3015>
<mup> PR snapcraft#1142 closed: state: asset tracking - store versions of stage-packages <Created by josepht> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1142>
<kyrofa> jdstrand, the user came back, saying the aa-status command you gave me produced no result, which I assume means the profile was unloaded somehow?
<alecu> jhodapp: hi! I think there might be a markup mistake in this page, because code and prose sections seem to switch place towards the end of the document: https://docs.ubuntu.com/core/en/stacks/bluetooth/doc/overview
<alecu> jhodapp: wanted to submit a patch, but I can't the bluetooth docs here: https://github.com/CanonicalLtd/ubuntu-core-docs/tree/master/en/stacks
<alecu> am I looking at the right place?
<jhodapp> alecu, the actual docs are part of the bluez snap
<jhodapp> alecu, we keep them distributed and they get pulled in with repo
<alecu> ah, that sounds better
<jhodapp> that makes it much easier for developers to contribute docs
<jhodapp> let me get you the link to the docs
<jhodapp> alecu, here you go: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/bluez/tree/doc/overview.md
<alecu> jhodapp: seems to be be missing  ``` in line 199
<alecu> jhodapp: https://code.launchpad.net/~alecu/snappy-hwe-snaps/+git/bluez/+merge/319613
<jhodapp> alecu, nice
 * jhodapp looks
<alecu> took me a while to figure out git in lp :P
<jhodapp> alecu, yes it's pretty different from the way most other git web systems work
<jhodapp> we tried to fit a square peg in a round hole there ;)
<alecu> hahah, right
<jhodapp> alecu, good feedback on the docs too...we'll update the readme so that it's obvious that the stack documentation is distributed
<alecu> jhodapp: btw, do you know if bluetooth is supported on the raspi3 with core? I can't seem to get it to work
<alecu> perhaps I should ask ogra_ about that
<jhodapp> alecu, ask morphis or koza...I'm not sure
<alecu> sounds good, thanks
<jhodapp> I only have a pi2 and dragonboard and can't remember off hand
<alecu> right, pi2 does not have onboard bt
<jhodapp> exactly
<alecu> alright, thanks a bunch!
<jhodapp> alecu, not a problem!
<mup> PR snapd#3016 opened: interfaces: add kubernetes-support interface and adjust related interfaces (LP: #1664638) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3016>
<alecu> jhodapp: and, here's another tiny fix: https://code.launchpad.net/~alecu/snappy-hwe-snaps/+git/bluez/+merge/319620
<jhodapp> alecu, keep 'em coming :)
<jhodapp> alecu, are you sure it needs that? konrad assured me we have the alias on the store side in place for that
<alecu> jhodapp: well, after sshing into the raspi and installing the bluez snap, I can't find the bluetoothctl command
<alecu> I do find bluez.bluetoothctl
<alecu> perhaps I need a newer snap, or edge?
<alecu> let me try that
<jhodapp> alecu, you might and it may in fact be going out soon
<jhodapp> alecu, try "snap aliases"
<alecu> jhodapp: ah! the snap on edge is rev27. The one I had from stable is rev12 !!!
<jhodapp> alecu, yup, that's the issue
<alecu> jhodapp: I refreshed the snap, and now I can see the alias
<jhodapp> awesome
<alecu> wonderful :-)
<alecu> and, now I've learned about aliases
<jhodapp> quite an afternoon ;)
<jhodapp> aliases are awesome
<alecu> certainly useful for other snaps we are preparing...
<jhodapp> absolutely
<alecu> and, with the latest snap on the raspi, bluetoothctl still can't find the controller
<alecu> so, I guess I'll bother ogra_ and morphis next week
<alecu> jhodapp: thanks a bunch!
<jhodapp> np
<cachio> niemeyer, hey, quick question, I ma trying to create a file socket within a snap and > I get Bad system call (core dumped)
<cachio> If I run the python code it works properly, but if failes when I call the snap app
<cachio> niemeyer, any idea about what could be the reason? or where I could see the logs?
<cachio> niemeyer, this is the only I see in the syslog http://paste.ubuntu.com/24153684/
<kyrofa> cachio, that's a seccomp filter denial. You're probably missing the network plug
<kyrofa> (or network-bind)
<kyrofa> cachio, you could learn more by using snappy-debug
<jdstrand> it would also tell you to use network-bind
<kyrofa> cachio, and run `sudo snappy-debug.security scanlog` in one terminal while running your app in the other
<jdstrand> $ scmp_sys_resolver 49
<jdstrand> bind
<kyrofa> jdstrand, did you actually run that, or do you have 49 memorized? ;)
<jdstrand> you shouldn't have to use the network-bind interface to use a unix socket, but for now you do
<jdstrand> kyrofa: I actually did have it memorized, but I double checked myself :)
<cachio> kyrofa, jdstrand great, thanks for the info
<kyrofa> jdstrand, haha, nice
<cachio> kyrofa, jdstrand I am creating a file socket for process communication, should I use the networking plugin in that case too?
<jdstrand> cachio: network-bind should be sufficient. use snappy-debug and it'll tell you for sure
<cachio> jdstrand, ok, I'll do it, thanks
<cachio> jdstrand, ERROR: Could not find '/snap/snappy-debug/27/policy/17'
<mup> Bug #27: temporary test <iso-testing> <Baz (deprecated):Invalid> <https://launchpad.net/bugs/27>
<cachio> snappy debug is giving me that
<jdstrand> whoa
<jdstrand> oh, what release are you on?
<jdstrand> zesty?
<cachio> zesty
<cachio> jdstrand, snapd 2.22.7
<jdstrand> cachio: can you do 'snap refresh snappy-debug --edge' and try again?
<cachio> jdstrand, sure
<cachio> jdstrand, it worked
<cachio> jd tx
<jdstrand> cachio: np
<jdstrand> roadmr: hey, would you mind pulling r847 into the store? it isn't an emergency. next week is fine
<roadmr> jdstrand: sure thing, I'll put it in the pipeline and check what the deployment status is
<jdstrand> roadmr: oh, actualy, give me a second
<roadmr> jdstrand: sure thing, I haven't proposed anything yet
<jdstrand> I added the code to override but I didn't add the thing to override :)
<roadmr> haha :) who overrides the overrider?
<jdstrand> roadmr: ok, r848
<jdstrand> heh
<roadmr> jdstrand: did I hear something about snapd on trusty installing systemd which then makes $SOMETHING go crazy? this may be juju-related only :(
<jdstrand> roadmr: snapd on trusty will install a special systemd, yes. I haven't heard about anything going crazy. if you are seeing something, please file a bug so the snappy team can take a look at it
<roadmr> jdstrand: ok, I'll dig up the comment I saw.
<mup> PR snapcraft#1185 opened: repo: add version support for build-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1185>
<jdstrand> niemeyer: ok, I was able to get to everything you pinged my on except the mknod branch. mvo could answer on that, but I'd like to be around when that lands, so I will comment when I am back
<jdstrand> pinged me*
<niemeyer> jdstrand: Thanks so much!
<jdstrand> np
<niemeyer> jdstrand: I'll try to find some time over the weekend to merge what I'm able to
<jdstrand> cool
<jdstrand> niemeyer: actually, there was one I handed off to Tyler-- PR#2624
<jdstrand> (pid-1 mount namespace)
<jdstrand> so he'll follow through on that in my absence
#snappy 2017-03-11
<olive> Hi
<olive> I don't know if it's a snappy bug or LXD. LXD (installed by snap) suddenly stoped working and now I have this error : cannot perform operation: mount /var/lib/snapd/hostfs/var/lib/lxd /var/lib/lxd -o nosuid,nodev,noexec,rbind,rslave: Permission denied
<olive> /var/lib/snapd/hostfs/var does not exists
<olive> seems similar to this discussion https://irclogs.ubuntu.com/2016/10/05/%23snappy.html#t13:22
<olive> and https://ubuntuforums.org/showthread.php?t=2346797
<olive> but I don't know what to do
<olive> is this relevant ? http://codegists.com/snippet/shell/patch-core-snapsh_zyga_shell
<olive>     # support for the LXD quirk
<olive>     mount options=(rw rbind nodev nosuid noexec) /var/lib/snapd/hostfs/var/lib/lxd/ -> /var/lib/lxd/,
<olive>     /var/lib/lxd/ w,
<olive>     /var/lib/snapd/hostfs/var/lib/lxd r,
<olive> (in /etc/apparmor.d/usr.lib.snapd.snap-confine)
<mup> Bug #1646415 changed: Cannot run configure hook <Snappy:Expired> <https://launchpad.net/bugs/1646415>
<olive> Where can i get help for ?
<olive> I think my problem is about conflict between ubuntu-core-launcher and snap-confine
<olive> or something like that...
<jwallden> Hello! I just did a "snap find" and got error message "cannot list snaps". Seems like repo servers are down. Any idea whats going on?
<olive> hello jdstrand any idea for me ? (loic minier tell me to ping you ;))
<olive> I tried with an upgrade of snap-confine from -proposed
<olive> same thing
<olive> I just did aa-complain /usr/lib/snapd/snap-confine but now lxd socket is not found (but lxd is running)
<mup> PR snapcraft#1141 closed: parser: use the project loader code to find the origin's snapcraft.yaml <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1141>
<mup> PR snapcraft#1184 closed: store: enable retries for store calls <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1184>
<mup> PR snapcraft#1174 closed: copy, dump plugin: ignore symlinks to libc <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1174>
<matthias__> Hi there!
<matthias__> Has anyone an idea how I can use the serial interface on my Ubuntu core Raspberry Pi3?
<matthias__> I am using openhab and would like to use the z-wave USB-dongel
<matthias__> The snap openhab has an interface openhab:serial-port
<matthias__> But the core snap (pi2-kernel, pi3 gadget) has not serial plug.
<matthias__> Can someone help?
<matthias__> Sorry, the core snap (pi2-kernel, pi3 gadget) has not serial-port _slot_.
<matthias__> Noone out there?
<matthias__> Or has noone an idea?
<RoninDev> Hello! I am trying to make snap package of Slic3r. It's perl and c++ source in it. It has perl build script. So I use dump plugin to get sources and 'build: perl Build.PL --sudo && perl Build.PL --sudo --gui' in part section
<RoninDev> But after build, nothing is copy in prime/stage directory.. I need all files after build script run in destination folders
#snappy 2017-03-12
<mup> Bug #1672169 opened: cannot login the first time on raspberry pi3  <Snappy:New> <https://launchpad.net/bugs/1672169>
<JBeardie> Hi all. I just started to introduce myself to Ubuntu core with pi3
<JBeardie> I'm having problems with wlan
<JBeardie> I have installed wireless-tools snap, but it's not working properly
<JBeardie> wireless-tools.iwconfig returns following error
<JBeardie> /snap/wireless-tools/9/sbin/iwconfig: error while loading shared libraries: libiw.so.30: cannot open shared object file: No such file or directory
<ogra_> JBeardie, any particualr reason for this (using the wireless-tools snap vas just using the preinstalled console-conf )
<ogra_> s/vas/vs./
<ogra_> looking at the source for the wireless-tools snap it seems to not include any of the required libs in stable-packages .. i doubt it could actually work on an actual core image
<ogra_> https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/wireless-tools/tree/snapcraft.yaml
<JBeardie> i even tried to all manually a config file-> /etc/network/interfaces.d/wlan0 but it's not loading up either
<ogra_> did you run through the initial config wizard ?
<ogra_> thats required to set up the user and ssh access
<ogra_> (and networking)
<JBeardie> Yes. I found wlan from it, but i couldnt complete the wizzard wirelessly. I had to make it over lan
<ogra_> on the pi3 you need to do that via wired lan or a monitor/kbd for the initial setup ... there is a bug with the wlan driver that makes it not work there
<JBeardie> lan and ssh are ok
<ogra_> well, ssh in via lan ...
<JBeardie> yes
<ogra_> then run "sudo console-conf"
<ogra_> turn off wired ... configure wlan ... reboot
<ogra_> (then check for the new IP the device got when switching to wlan after the reboot)
<ogra_> you dont need wireless-tools, just the above steps
<JBeardie> that's it. Thanks!
#snappy 2018-03-05
<Son_Goku> zyga-ubuntu, can you please make snap-confine build on rawhide again?
<Son_Goku> your Werror makes it fail: https://paste.fedoraproject.org/paste/e6J2VTfHxPHGtuI9-gbZ2A
<Son_Goku> zyga-ubuntu, from what I can tell, these are littered all over the snap-confine testing code, so this will fail everywhere
<Son_Goku> zyga-ubuntu, since I think this is going to take a while for you, I just did this for now: https://src.fedoraproject.org/rpms/snapd/blob/master/f/snapd-2.31.1-Drop-Werror.patch
<Son_Goku> but please fix for 2.32
<Son_Goku> and ideally also for 2.31, especially if a new release is going to get cut
<mup> PR snapd#4788 opened: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4788>
<Chipaca> sergiusens: ping
<kalikiana> o/
<mup> PR snapd#4785 closed: tests: moving ubuntu core from linode to google backend <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4785>
<mup> PR snapd#4789 opened: many: support holding refreshes by setting refresh.hold <Created by pedronis> <https://github.com/snapcore/snapd/pull/4789>
<sergiusens> Chipaca: pong
<Chipaca> sergiusens: can we have a chat about packing and validation?
<Chipaca> sergiusens: this week i mean :-)
<jamesh> jdstrand: I think the changes I've made to my xdg-open-file PR satisfy your concerns now.
<zyga-ubuntu> Pharaoh_Atem: ack, I'll look into it this week
<mup> PR snapcraft#1968 closed: demos: avoid use of the wrapper for java-hello-world <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1968>
<mup> PR snapcraft#1972 closed: tests: remove _options dependency from integration suite <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1972>
<zyga-ubuntu> Pharaoh_Atem: what's the easierst way to run rawhide
<zyga-ubuntu> Pharaoh_Atem: install 27 and just update?
<Son_Goku> zyga-ubuntu: yeah
<zyga-ubuntu> Son_Goku: ok, let me do that now
<Son_Goku> zyga-ubuntu: once you're in Fedora 27, just do the following:
<zyga-ubuntu> oh :)
 * zyga-ubuntu waits
<Son_Goku> sudo dnf --releasever=rawhide --refresh distro-sync --allowerasing
<Son_Goku> oh wait
<Son_Goku> sudo dnf --nogpgcheck --releasever=rawhide --refresh distro-sync --allowerasing
<Son_Goku> the problem is that the gpg key doesn't exist for rawhide until after it's installed :P
<Son_Goku> zyga-ubuntu, so that command will let you sync your system up to rawhide
<Son_Goku> after it's done, reboot immediately
<zyga-ubuntu> Thanks, Iâll ping you back if I have problems
<mup> PR snapd#4766 closed: userd: add an OpenFile method for launching local files with xdg-open <Critical> <Sprint> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4766>
<mup> PR snapcraft#1977 closed: lifecycle: when priming dependencies need to be primed <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1977>
<mup> PR snapcraft#1983 opened: snap: update revision of patchelf to use <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1983>
<fkdks> does cannonical manage(offitially suppoft) each snaps?
<zyga-ubuntu> fkdks: each snap is supported by the owner of that snap, canonical does officially support a set of snaps but obviously not all ofthem
<zyga-ubuntu> Chipaca:  gcloud auth application-default login
<robert_ancell> Is there a way to know which interfaces are used by snaps in the store? i.e. list the interfaces by most used
<jamesh> robert_ancell: https://cprov.blogspot.hu/2017/06/great-snapcrafters-steal.html gives a curl command to grab the meta/snap.yaml for a given snap.  You could combine that with various "snap find" invocations to get a list of snap names
<zyga-ubuntu> jdstrand:, jjohansen : can you guys please visit us in the snappy room
<zyga-ubuntu> we are exploring an idea and we need your expertise
<jjohansen> do you have cake?
<zyga-ubuntu> we can arrange some
<jjohansen> so the cake is a lie?
<jjohansen> zyga-ubuntu: we can come over in a bit, we are in the middle of a meeting atm
<zyga-ubuntu> jjohansen: that's perfect, thank you
<zyga-ubuntu> jjohansen: the cake is probably a lie unless the hotel can help us
<nacc> popey: thanks for the assist on the snapcraft SRU
<mup> PR core#83 opened: move most of the ubuntu-core config deb into the snap snap build <Created by mvo5> <https://github.com/snapcore/core/pull/83>
<mup> PR core-build#26 opened: move most of the customization into the core snap build <Created by mvo5> <https://github.com/snapcore/core-build/pull/26>
<popey> nacc: no worries.
<mup> PR snapcraft#1984 opened: Snapcraft test user <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1984>
<kyrofa> It's so quiet in here
<kyrofa> Echo... echo...
<Pharaoh_Atem> hi
<kyrofa> Ah! Someone!
 * Pharaoh_Atem waves at kyrofa
<kyrofa> Haha, hey Pharaoh_Atem
<Pharaoh_Atem> kyrofa: can I get you to update squashfuse in Fedora?
<Pharaoh_Atem> there's been a new release out for a while
<kyrofa> Yeah I got an email about that over the weekend
<kyrofa> I'll do it today
<Pharaoh_Atem> cool
<kyrofa> Uh. Are any store people here?
<kyrofa> nessita ?
<Pharaoh_Atem> probably not ;)
<kyrofa> This issue is getting old: https://forum.snapcraft.io/t/snapcraft-releases-are-blocked-no-automatic-reviews-are-happening/4353
<Pharaoh_Atem> :/
<zyga-ubuntu> kyrofa: I can ask nessita tomorrow
<kyrofa> Thanks zyga-ubuntu
<zyga-ubuntu> no worries, ping me if I can help somehow :)
<mup> PR snapd#4790 opened: jsonutil/puritan: introducing puritan.String & etc <Created by chipaca> <https://github.com/snapcore/snapd/pull/4790>
<Pharaoh_Atem> zyga-ubuntu: https://github.com/snapcore/snapd/pull/4788
<mup> PR #4788: packaging/fedora: Merge changes from Fedora Dist-Git plus trivial fix <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/4788>
<Pharaoh_Atem> why does the tests keep breaking in unrelated ways?!
#snappy 2018-03-06
<mwhudson> $ snapcraft --version
<mwhudson> snapcraft, version 2.39.3+really2.35
<mwhudson> "oh"
<nacc> mwhudson: we had to revert :)
<nacc> mwhudson: due to classic snap issues out the wazoo
<mwhudson> hm hm looks like go 1.10 in bionic causes snapd's autopkgtests to fail?
<mwhudson> (because it runs vet)
<mwhudson> and hm breaks the compiler?
<zyga-ubuntu> nessita: hey
<zyga-ubuntu> nessita: yesterday kyle had an issue with the store not processing package revies
<zyga-ubuntu> *reviews
<zyga-ubuntu> nessita: there's a thread about this here: https://forum.snapcraft.io/t/snapcraft-releases-are-blocked-no-automatic-reviews-are-happening/4353
<zyga-ubuntu> nessita: I'm just relaying the message so perhaps if you know the cause you could reply there
<Chipaca> jamesh: hi
<jamesh> Chipaca: hi
<Chipaca> jamesh: we're getting failures in the xdg-open spread test on opensuse-42.2
<Chipaca> jamesh: when can I bother you with the details?
<nessita> kyrofa, zyga-ubuntu hi! what's the stuck snap? we need a name or something :-)
<zyga-ubuntu> nessita: on the forum it looks like it was snapcraft
<zyga-ubuntu> https://forum.snapcraft.io/t/snapcraft-releases-are-blocked-no-automatic-reviews-are-happening/4353/2
<jamesh> Chipaca: I'm in a meeting right now, but I can look at it after if you've got a link
<nessita> zyga-ubuntu, snapcraft is fully unblock, so maybe daniel fixed it as per his reply, or the blocked snap is another one
<Chipaca> jamesh: I've got an open ssh to the failing machine, even :-)
<zyga-ubuntu> nessita: thanks, I'll relay that to kyrofa later today
<Chipaca> nessita: zyga-ubuntu: sergiusens was asking wgrant (i think?) to fix it this morning over breakfast
<Chipaca> (if it wasn't wgrant, apologies to him and whoever it was)
<juanrubio> Hi, I was wondering if someone would haveave some time look at this forum post
<juanrubio> https://forum.snapcraft.io/t/tizonia-command-line-app-and-dbus-daemons-in-the-same-snap/4340
<juanrubio> Thanks!
<ogra_> niemeyer, FYI .... seems the build.sh script i showed to you guys yesterday is not the only one of this type ... https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/tests-extras/tree/create-image-scripts/create-image.sh
<ogra_> apparently this script is being recommended to some of the ROS guys
<ogra_> (pretty much the same except that it uses kpartx to inject stuff into /writable after the image is built)
<ogra_> i start to wonder how many different variants of these scripts exist ...
<ogra_> niemeyer, https://forum.snapcraft.io/t/how-to-preconfigure-custom-image/4154/7 for reference ...
<mup> PR snapcraft#1985 opened: tests: update store tests user <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1985>
<mup> PR snapcraft#1979 closed: pluginhandler: simplify logic when elf patching is required <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1979>
<mup> PR snapd#4791 opened: tests: chroot into core to run xdg-open there <Created by chipaca> <https://github.com/snapcore/snapd/pull/4791>
<mup> PR snapcraft#1986 opened: schema: add keep-execstack <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1986>
<mup> PR snapd#4791 closed: tests: chroot into core to run xdg-open there <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4791>
<mup> PR snapd#4792 opened: overlord/snapstate: block install of "system" <Created by chipaca> <https://github.com/snapcore/snapd/pull/4792>
<ogra_> niemeyer, one for you https://forum.snapcraft.io/t/disabling-console-conf-for-gadget-or-core-config-option/4358
<jdstrand> oSoMoN: hey! I wanted to test the 0ad snap with https://github.com/snapcore/snapd/pull/3998 to see if process-control could be discocnnected, but it won't launch on (at least) xenial
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<jdstrand> oSoMoN: $ 0ad
<jdstrand> execl failed: No such file or directory
<jdstrand> child exited with status 1
<jdstrand> other snaps seem to work ok
<jdstrand> oSoMoN: fyi, that is stable channel. I'll try one of te others
<jdstrand> oSoMoN: same thing with --beta
<jdstrand> oSoMoN: oh that is still r1. /me tries edige
<jdstrand> edge
<oSoMoN> jdstrand, IÂ don't expect that'll make much difference, but who knows
<oSoMoN> jdstrand, I can look into why it's not starting later, if you want
<jdstrand> oSoMoN: well, I'm content to move on
<jdstrand> oSoMoN: I should mention that I see that in a vm
<jdstrand> oSoMoN: curious, it runs on my 17.10 laptop
<mup> PR snapcraft#1987 opened: pluginhandler: add option to disable patchelf for a part <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1987>
<oSoMoN> jdstrand, is there a way to test that change without building snapd myself? do the CI jobs make it available by any chance?
<jamesh> zyga-ubuntu: did you want to chat about user mounts now?
<zyga-ubuntu> jamesh: yes but neither gustavo nor mvo is here now
<zyga-ubuntu> so I think we want to postpone that for a while
<jdstrand> oSoMoN: you have to build it. CI does build debs but I don't think they are retrievable
<jamesh> zyga-ubuntu: okay.  I'm still hacking on the replacement replacement xdg-open, so ping me when you're ready
<jdstrand> oSoMoN: however, building is not too bad
<oSoMoN> ack, I'll build it then
<jdstrand> oSoMoN: you can use dpkg-buildpackage to build it. importantly, you need to rev debian/changelog since that branch has the same version as the core snap. I uas 2.31.2~pre1
<zyga-ubuntu> jamesh: ack, will do
<jdstrand> oSoMoN: also, you need to patch https://github.com/mvo5/libseccomp-golang/pull/2
<mup> PR mvo5/libseccomp-golang#2: ActLog fixup <Created by tyhicks> <https://github.com/mvo5/libseccomp-golang/pull/2>
<jdstrand> oSoMoN: what I did is just manually update seccomp.go and seccomp_internal.go before you build. that is a little funky though cause its in the vendor dir so it sometimes gets reverted
<jdstrand> oSoMoN: I can give you a snapd for 16.04 it that is helpful
<mup> PR snapd#4793 opened: progress: tweak ansimeter cvvis use to no longer confuse minicom <Created by chipaca> <https://github.com/snapcore/snapd/pull/4793>
<Chipaca> ^^ are my PRs getting too obscure
<jdstrand> oSoMoN: curious. I downgraded the deb (so it reexecs from the core snap), it works. I wonder if there is something new in trunk that is breaking things
 * jdstrand builds a deb out of tip of master
<jdstrand> oSoMoN: don't bother trying it yet. I talked to zyga about the bug which exists in master
<mup> Bug #1753760 opened: Adding public RSA Key doesn't make login on device possible <Snappy:New> <https://launchpad.net/bugs/1753760>
<oSoMoN> jdstrand, ok, thanks
<robert_ancell> flexiondotorg, have you noticed the onlyoffice-desktopeditors snap doesn't have a title set?
<mup> PR snapd#4794 opened: xdgopenproxy: integrate xdg-open implementation into snapctl <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4794>
<flexiondotorg> robert_ancell: Yes. popey and I have discussed reviewing the quality of store descriptions for features snaps as we build the new lists. We'll reach out to those publishers should add screenshots or modify titles etc.
<jamesh> niemeyer: here's my stab at the "snapctl user-open" implementation: https://github.com/snapcore/snapd/pull/4794
<mup> PR #4794: xdgopenproxy: integrate xdg-open implementation into snapctl <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4794>
<jdstrand> roadmr: hi! I noticed that https://dashboard.snapcraft.io/snaps/tesseract/ is stuck on https://dashboard.snapcraft.io/snaps/tesseract/revisions/138/, but it says 'Task state is unknown' with no button to re-run the tests
<jdstrand> roadmr: https://dashboard.snapcraft.io/snaps/solc/ is in a similar situation
<jdstrand> and https://dashboard.snapcraft.io/snaps/minio/revisions/1025/
<jdstrand> and https://dashboard.snapcraft.io/snaps/cpp-ethereum/revisions/435/
<mup> PR snapd#4795 opened: polkit: ensure error is properly set if dialog is dismissed <Created by azzar1> <https://github.com/snapcore/snapd/pull/4795>
<roadmr> jdstrand: hm... let me see. kyrofa had a couple of similar situations in the past couple of days
<roadmr> jdstrand: checking!
<roadmr> jdstrand: oh wow! "scan error" but this was submitted 5 months ago
<jdstrand> roadmr: sme are old, yes, some from last week
<roadmr> jdstrand: cpp-ethereum had this 6 days ago, probably got caught in rebootmageddon
<jdstrand> some*
 * jdstrand nods
<jdstrand> roadmr: I click re-run for the ones I can
<jdstrand> I'm*
<jdstrand> meh
<jdstrand> I'm clicking*
<roadmr> jdstrand: and I notice solc was on the same day as tesseract
<roadmr> jdstrand: so my theory is they all got caught in some server upload issue, I'll fix the borked uploads so the rest of the snaps can process, and file a bug about this problem which happens when there's a "scan error", as opposed to a e.g.failed review
<jdstrand> roadmr: thanks
<SDB_Stefano> Hi everyone, I'm looking how to install avahi-browse in Ubuntu Core.
<niemeyer> jamesh: Thanks! We'll look into it soon
<SDB_Stefano> Hi everyone, I'm looking how to install avahi-browse in Ubuntu Core.
<nacc> SDB_Stefano: afaict, there's no snap for avahi-browse
<SDB_Stefano> Hi nacc, I was considering using sudo classic
<kyrofa> nessita, I'm sorry if it wasn't clear-- it was the snapcraft snap itself. All fixed this morning, it seems
<nacc> SDB_Stefano: https://forum.snapcraft.io/t/how-can-i-lookup-host-name-from-snap-core-using-avahi-mdns/3828/4 ?
<nacc> SDB_Stefano: not sure what you mean by 'sudo classic' ?
<SDB_Stefano> nacc: ubuntu core has the classic mode in which all the ubuntu functionaliies should be provided.
<roadmr> jdstrand: all reported snaps (4 of them) are now unblocked and fully processed, and I've filed (and subscribed you to) a bug
<ackk> zyga-ubuntu, hi, I'm hitting a strange error with snaps in a newly created bionic container. whenever i run any snap command, it fails. strace shows this error https://pastebin.canonical.com/p/MR3K6sN9kK/
<ackk> zyga-ubuntu, any idea what could be failing/
<ackk> zyga-ubuntu, https://paste.ubuntu.com/p/vyhKhvJrQ5/ (complete trace)
<cachio__> Chipaca, hey
<Chipaca> cachio__: \o
<zyga-ubuntu> ackk: looking
<ackk> zyga-ubuntu, I'm not sure why, but removing ~/snap fixed it
<zyga-ubuntu> oh!
<zyga-ubuntu> that's so odd
<zyga-ubuntu> ackk: I'm running 18.04 daily on my laptop, did you do something interesting and then it started failing or did it just fail out of the blue?
<zyga-ubuntu> ackk: can you look at journalctl and see if you have any apparmor denials (look for DENIED)
<jamesh> sergiusens: I was wrong about the ELF interpreter path being defined in FHS.  This seems to be the canonical list for Linux on different architectures: https://sourceware.org/glibc/wiki/ABIList
<jdstrand> zyga-ubuntu: if you are talking about the snappy-app-dev rename, I did not
<zyga-ubuntu> jdstrand: I think mvo fixed it but unless you were running edge it would still be an issue with newly built snapd.deb
#snappy 2018-03-07
<mup> PR snapd#4725 closed: tests: avoid removing preinstalled snaps on core <Created by sergiocazzolato> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4725>
<mup> PR snapcraft#1988 opened: RFC: elf: only set rpaths to libs of the same arch <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1988>
<jdstrand> zyga-ubuntu (cc mvo): ack, thanks. I was running stable core and local built from master deb
<zyga-ubuntu> That explains it then
<jdstrand> zyga-ubuntu: would you mind looking at https://travis-ci.org/snapcore/snapd/builds/350156100#L5241 ?
<zyga-ubuntu> looking
<jdstrand> zyga-ubuntu: I'm puzzled by the failure cause it only fails on 16.04 i386 and debian-9. it is failing in a file I edited, but not a test case I edited. I don't see how PR 3998 would cause this to fail, and if it did, why it would be specific to i386 Ubuntu and debian-9
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<jdstrand> zyga-ubuntu: but I've done 3 retries and it always fails, for just those two
<zyga-ubuntu> hmmm debian 9 and i386 xenial
<zyga-ubuntu> I'll look into it after breakfast
<zyga-ubuntu> I should get going :)
<jdstrand> zyga-ubuntu: ok. thanks! I've looked at my changes in that pr, but you might want to double check
<jdstrand> zyga-ubuntu: the only thing I was thinking is maybe there restore() or the snap removes were leaving artifacts, but again, why just those two?
<jdstrand> zyga-ubuntu: have a nice breakfast :)
<mup> PR snapcraft#1987 closed: pluginhandler: add option to disable patchelf for a part <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1987>
<mup> PR core#84 opened: xdg-open: switch to "snapctl user-open" based implementation <Created by jhenstridge> <https://github.com/snapcore/core/pull/84>
<mup> PR snapcraft#1959 closed: elf: only patch elf files that aren't referenced by DT_NEEDED <Created by jhenstridge> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1959>
<jamesh> zyga-ubuntu: https://forum.snapcraft.io/t/supporting-desktop-themes-via-the-content-interface/4122
<ackk> zyga-ubuntu, hi, so actually turns out that removing the ~/snap directory didn't fix my issue with snap-confine failing with permission denied
<jdstrand> zyga-ubuntu: I know your busy, but curious if you found anything onthe  PR 3998 spread test issue
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<jdstrand> zyga-ubuntu: I ask, in part, because popey and friends would love to see PR 3998 in 2.32, and I need to chat with mvo about that, but only once it lands
<popey> +1 :)
<popey> It blocks a bunch of electron apps which try to chown, and games which try to setpriority
<jdstrand> I've enumerated what this fixes in the PR too
<zyga-ubuntu> jdstrand: ish, I'm testing a fix now
<zyga-ubuntu> jdstrand: it took me $FOREVER because I didn't have my linode key and I had to bring the i386 qemu image over
<zyga-ubuntu> it's testing locally now
<jdstrand> zyga-ubuntu: oh, if you have a moment, can you paste the diff? I'm curious what it was
<zyga-ubuntu> jdstrand: sure, though not sure it works :)
<zyga-ubuntu> in 3 min I will know
<jdstrand> :)
<ackk> zyga-ubuntu, is there a way to get more debug logs from snap-confine? I'm not sure what that failure is about
<jdstrand> as mentioned, I was pretty puzzled by it
<zyga-ubuntu> ackk: you can set SNAP_CONFINE_DEBUG=yes SNAPD_DEBUG=1
<zyga-ubuntu> ackk: that will show you way more things
<ackk> zyga-ubuntu, thanks
<ackk> zyga-ubuntu, that gives me this message: 2018/03/07 09:32:12.793577 cmd.go:102: DEBUG: core snap (at "/snap/core/current") is older ("2.31.1") than distribution package ("2.31.1+18.04")
<zyga-ubuntu> ackk: that's okay, that's coming from parts other than snap-confine though
<jdstrand> roadmr: fyi, I think this is another one like yesterday: https://dashboard.snapcraft.io/snaps/love-game/revisions/231/
<BjornT_> sergiusens: this is what i currently have for bug 1752538: https://github.com/bjornt/snapcraft/commit/676457cfc4ad090387ea9d807ceca521bb936f01
<mup> Bug #1752538: Building snap using base-18 is broken with 2.39 <Snapcraft:Confirmed> <https://launchpad.net/bugs/1752538>
<jdstrand> ralsina: and hi! :)
<ackk> zyga-ubuntu, http://paste.ubuntu.com/p/vDQrQvj8JR/ is the full strace
<mup> PR snapd#4796 opened: cmd/snap: "current"â"installed"; "refreshed"â"refresh-date" <Created by chipaca> <https://github.com/snapcore/snapd/pull/4796>
<Chipaca> kyrofa: o/?
<roadmr> hey jdstrand ! Let me check
<Dianomic_Stefano> Hi, we have developed a service (FogLAMP) that uses avahi, it is visible using the command 'avahi-browse' when it runs in Ubuntu Server - but it is not visible when it runs in a snap in Ubuntu Core, any suggestions ?
<roadmr> jdstrand: yes, sorry about that. I'll unwedge that one
<Chipaca> Dianomic_Stefano: does your snap include an avahi daemon?
<Dianomic_Stefano> yes : foglamp@foglamp-core:~$ snap list
<Dianomic_Stefano> Name          Version                   Rev   Tracking  Developer  Notes
<Dianomic_Stefano> avahi         0.7-26-g89573c2           87    edge      ondra      -
<Dianomic_Stefano> avahi-client  0.6.32                    38    stable    ondra      devmode
<Dianomic_Stefano> classic       16.04                     26    edge      canonical  devmode
<Dianomic_Stefano> core          16-2.31.1+git606.68b2ef4  4176  edge      canonical  core
<Dianomic_Stefano> pc            16.04-0.8                 9     stable    canonical  gadget
<Dianomic_Stefano> pc-kernel     4.4.0-116.140             104   stable    canonical  kernel
<Dianomic_Stefano> foglamp@foglamp-core:~$
<Dianomic_Stefano>  
<Chipaca> Dianomic_Stefano: sorry, do you mean your _service_ is visible in avahi-browse, or your _server_?
<Dianomic_Stefano> this is the snap list :
<Dianomic_Stefano> foglamp@foglamp-core:~$ snap list
<Dianomic_Stefano> Name          Version                   Rev   Tracking  Developer  Notes
<Dianomic_Stefano> avahi         0.7-26-g89573c2           87    edge      ondra      -
<Dianomic_Stefano> avahi-client  0.6.32                    38    edge      ondra      -
<Dianomic_Stefano> classic       16.04                     26    edge      canonical  devmode
<Dianomic_Stefano> core          16-2.31.1+git606.68b2ef4  4176  edge      canonical  core
<Dianomic_Stefano> foglamp       1.2.0                     x1    -         -          devmode
<Dianomic_Stefano> pc            16.04-0.8                 9     stable    canonical  gadget
<Dianomic_Stefano> pc-kernel     4.4.0-116.140             104   stable    canonical  kernel
<Dianomic_Stefano> foglamp@foglamp-core:~$
<Dianomic_Stefano> foglamp is our snap
<Dianomic_Stefano> I installed avahi-client to being able to use 'avahi-client.browse'
<Chipaca> Dianomic_Stefano: you said
<Chipaca> Dianomic_Stefano: you " have developed a service [â¦]  that uses avahi, it is visible using the command 'avahi-browse' when it runs in Ubuntu Server"
<Dianomic_Stefano> if I start foglamp in a Ubuntu server (in the same network) - I can see the service in the Ubuntu core using 'avahi-client.browse -a -t'
<Chipaca> ah
<Chipaca> Dianomic_Stefano: ok
<Chipaca> Dianomic_Stefano: so, how does your snap talk to the avahi snap?
<Dianomic_Stefano> if I start foglamp within the 'foglamp snap' I can't see the service running using 'avahi-client.browse -a -t' (and foglamp is running for sure)
<Dianomic_Stefano> so, should I configure my snap 'foglamp' to talk with the avahi snap ? how ?
<Chipaca> Dianomic_Stefano: the avahi snap exposes avahi-observe and avahi-control
<Chipaca> Dianomic_Stefano: you probably need to connect your snap to avahi-control to add services, but I'm not sure
<Chipaca> ondra: can you inform us?
<Dianomic_Stefano> thanks for helping...
<Chipaca> niemeyer: could you make spread look in ~/snap/google-cloud-sdk/current/.config/gcloud/ as well as ~/.config/gcloud for the google creds?
<ondra> Chipaca Dianomic_Stefano hi, sorry in the meeting, will have a look after
<mup> PR snapd#4797 opened: many: add the snapd-generator <Created by zyga> <https://github.com/snapcore/snapd/pull/4797>
<ondra> Dianomic_Stefano ping
<ondra> Dianomic_Stefano you can use avahi-client as example how to implement and connect to avahi snap daemon service.
<ondra> Dianomic_Stefano source for avahi client is here https://github.com/kubiko/avahi-client
<ondra> Dianomic_Stefano depending how you want to expose your service, you can either use dbus, socket interface, or you can as well use content interface for service and simply place service file in there
<Saviq> niemeyer: "Cannot allocate google:fedora-27: cannot allocate new Google server for fedora-27: required 'compute.images.useReadOnly' permission for 'projects/computeengine/global/images/fedora-cloud-base-27-1-6-x86-64'" when trying to use google with fedora images
<Saviq> https://travis-ci.org/MirServer/mir/jobs/350005082
<jdstrand> zyga-ubuntu: hi! :)
<jdstrand> zyga-ubuntu: what happened with the test?
<jdstrand> zyga-ubuntu: if you're busy, I understand, but I need to get it working so if you can't, can you tell me what you think it is?
<zyga-ubuntu> jdstrand: re, so I tested it a little but then we found another bug that broke the test entirely
<zyga-ubuntu> jdstrand: (squashfs)
<zyga-ubuntu> jdstrand: we fixed that
<zyga-ubuntu> jdstrand: and as soon as this lands I can merge master and see if my fix is ok
<zyga-ubuntu> jdstrand: and while this happens I'm fixing the snap.mount unit for containers
<zyga-ubuntu> and that's where we are
<zyga-ubuntu> I wrote down the list of bugs we found this weeks so that we can keep track of things and not forget it
<jdstrand> zyga-ubuntu: hey ok. yay for bug fixes! boo you are hitting them all at once. but yay people are here to interact with! but ... ;)
<jdstrand> heh*
<zyga-ubuntu> jdstrand: yeah, I hope to get to roughly the same bug count we had in the morning soon :D
<jdstrand> zyga-ubuntu: thank you. not trying to be a pest (do I have to try?)
<jdstrand> zyga-ubuntu: haha
<Dianomic_Stefano> ondra: thanks, I'm going to take a look to it.
<ondra> Dianomic_Stefano you are welcome :)
<Chipaca> kyrofa: o/?
<jamesh> popey: I've got a skeleton themes package.  Where did you want me to upload it?
<popey> jamesh: did we agree to put it under snapcrafters?
<jamesh> popey: yeah.  So I guess github.com/snapcrafters/gtk-common-themes?
<popey> yes
<popey> if you put it somewhere on github I can import it into snapcrafters jamesh
<mup> PR snapcraft#1988 closed: elf: only set rpaths to libs of the same arch <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1988>
<Dianomic_Stefano> ondra:hi, our service, foglamp, uses dbus so we have to expose that type of functionality. is it something related to changes in the snapcraft.yaml file only or is it something also in the code that we have to change/adapt ?
<ondra> Dianomic_Stefano if you are using dbus, then all you need to defined in your snapcraft.yaml is avahi-control plug
<ondra> Dianomic_Stefano then once you install your snap, snap connect <your snap>:avahi-control  avahi
<ondra> Dianomic_Stefano define plug like this https://github.com/kubiko/avahi-client/blob/master/snap/snapcraft.yaml#L32
<niemeyer> Saviq: Fixed the role so that everybody has access to that permission too
<niemeyer> Saviq: Please let me know if you see anything else like this
<Saviq> niemeyer: thanks!
 * Saviq tries
<Saviq> niemeyer: we hit ENOSPC on the fedora images, should we grow the partition ourselves? I suppose cloud-init does it on ubuntu hosts?
<Saviq> s/hosts/nodes/
<cachio__> Saviq, are you running on google?
<cachio__> Saviq, how much space do you need?
<kyrofa> Hey Chipaca, I'm here now!
<kyrofa> Are you?
<kyrofa> Our days almost completely miss each other while you folks are in budapest
<Chipaca> kyrofa: i am
<Chipaca> kyrofa: hello
<Chipaca> kyrofa: let's talk about timestamps in our commands' output
<kyrofa> Chipaca, hey there, sure!
<Chipaca> kyrofa: so, we want to let people tinker with the output of stuff easily using grep/cut/etc
<Chipaca> kyrofa: so for that it looks like RFC3339 is the way to go
<Chipaca> that's the nassty YYYY-mm-ddTHH:MM:SSzzz format
<Chipaca> but, because that's nasty for humans, we'd like to also offer friendlier timestamps
<Chipaca> current proposal is for it to be "NN days ago, at HH:MM:SS ZZZ"
<kyrofa> Chipaca, would supporting outputting json be better for such use-cases?
<Chipaca> kyrofa: I think json would be a nice addition, but not replace things
<kyrofa> Fair enough. Default to the human-friendly ones?
<Chipaca> yeah
<Chipaca> one nit with the human-friendly one is that if N is big, it's not that useful
<kyrofa> Works for me. At some delta, does it make sense to switch from "days ago" to a date?
<kyrofa> Exactly
<Chipaca> say, "779 days ago, at 09:35 PST"
<kyrofa> Yeah totally
<Chipaca> yeah
<kyrofa> I think more than a week it's not very useful
<Chipaca> I think switching to just a YYYY-mm-dd after that would be alright
<Chipaca> I don't have a good, locale-aware way of printing that unfortunately
<Chipaca> (but everybody should understand that particular one ,right? i mean, it's iso :-p )
<kyrofa> I'm trying to think if times would still be useful to know for some things. Like when snaps were released
<Chipaca> kyrofa: I think i'd set the cutoff a bit further out than a week
<Chipaca> precisely because it drops time precision
<Chipaca> but if you need to know the time of something further out than that i'm not too worried about you having to grok the rfc3339 nastiness (because aiui it'd be rare)
<kyrofa> Good point, if we support that it covers everything
<kyrofa> However, you raise a good point about locale. We need a way to do the same thing across both go and python
<kyrofa> Would it be easier to forgo the "days ago" approach and just provide "YYYY-mm-dd, at HH:SS Z" ?
<Chipaca> at my end, translating messages isn't an issue
<Chipaca> translating times, is
<kyrofa> Ah. Both are an issue for us :D
<Chipaca> kyrofa: how so?
<kyrofa> Mostly kidding-- we don't actually translate at all
<Chipaca> kyrofa: if you do want to start doing it, you could piggyback on our catalogues
<kyrofa> Yeah that's a larger discussion we need to have
<kyrofa> Do you want to forgo translating the times for now, and push ahead with this? Or do some research?
<kyrofa> I like the approach
<kyrofa> Just need to decide the cutoff for days ago
<kyrofa> Keep in mind that a lot of the timestamps coming from the store are without the zone, which means they're UTC if I remember correctly
<kyrofa> Also, what option were you thinking of using for switching between them? --nasty?
<kyrofa> Would be nice to have it be the same between tools
<Chipaca> kyrofa: 'coming from the store', in the json? or elswhere
<Chipaca> kyrofa: that reminds me, human-friendly times would be local, machine-friendly would be utc
<kyrofa> Yeah, json. I think the acl timestamps are lacking zones
<kyrofa> Chipaca, makes sense
<Chipaca> kyrofa: we should double-check that's not a bug, and that they are indeed z
<kyrofa> Chipaca, here I have a chat log
<Chipaca> kyrofa: wrt flags, --absolute-times?
<kyrofa> Hmm... doesn't seem obvious, but I don't really have a better suggestion either
<Chipaca> kyrofa: sleep on it?
<Chipaca> wrt cut off, 30 days?
<kyrofa> Chipaca, https://pastebin.ubuntu.com/p/86bTpK98BW/ FYI
<kyrofa> Sounds good
<mup> PR snapd#4798 opened: snap: don't create empty Change with "Hold" state on disconnect <Created by stolowski> <https://github.com/snapcore/snapd/pull/4798>
<Dianomic_Stefano> ondra:Hi, I changed the snapcraft.yaml of our snap in :
<Dianomic_Stefano> apps:
<Dianomic_Stefano>   foglamp:
<Dianomic_Stefano>        command: usr/bin/wrapper-foglamp
<Dianomic_Stefano>        plugs:
<Dianomic_Stefano>           - avahi-control
<Dianomic_Stefano>           - network
<kyrofa> Chipaca, thanks for the chat, that's been bothering me for a while
<Dianomic_Stefano> at at the start of the service I have got : Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService message Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client46/EntryGroup1, member=AddService Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService
<Dianomic_Stefano> ----
<Dianomic_Stefano> Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService message
<Dianomic_Stefano> Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client46/EntryGroup1, member=AddService
<Dianomic_Stefano> Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: Error parsing EntryGroup::AddService message
<Dianomic_Stefano> Mar  7 15:54:35 foglamp-core avahi.avahi-daemon[1169]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client46/EntryGroup1, member=AddService
<Dianomic_Stefano> --
<Chipaca> kyrofa: perfect thanks
<Chipaca> Dianomic_Stefano: please use a pastebin for pasting long text
<Chipaca> Dianomic_Stefano: pastebin.ubuntu.com
<Dianomic_Stefano> ok
<Dianomic_Stefano> ondra: https://pastebin.ubuntu.com/p/HQJqBdNTzK/
<mup> PR snapcraft#1989 opened: elf: don't parse elf more than we need to <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1989>
<morphis_> kyrofa, popey: do you guys have an example snap somewhere which is using Qt+QML? I don't get one working, things are crashing just badly for me so far
<ondra> Dianomic_Stefano this looks like problem with your dbus message to the avahi service, is this working when you run it on classic system?
<ondra> Dianomic_Stefano is it working when you run it  in --devmode
<Dianomic_Stefano> I installed using 'sudo snap install --devmode foglamp_1.3.3_amd64.snap'
<Dianomic_Stefano> ad it produce the error messages in the syslog
<ondra> Dianomic_Stefano first make sure that your client is working well with avahi daemon before you start snapping it. Debugging in snap confinement is just adding unnecessary burden to debugging
<Dianomic_Stefano> it works fine in a standard Ubuntu Server and using for example 'avahi-browse -t -a  -d local ' to check its existence
<ondra> Dianomic_Stefano OK once I have time I will debug with my example client avahi-client.browse -t -a  -d local
<ondra> Dianomic_Stefano as that seems to be also failing now
<ondra> Dianomic_Stefano so quick work around, avoid use of avahi-browse -a
<ondra> Dianomic_Stefano avahi does not broadcast correctly PTR record, at least what I could so far find about this error
<popey> morphis_: i do not
<Dianomic_Stefano> ondra: the point seems different:  I was able to start our service using the snap that was created having  the snapcraft.yaml having only ' plugs: [network]'
<ondra> Dianomic_Stefano I was testing with avahi-client.browse _http._tcp
<Dianomic_Stefano> ondra: I was no more able to start our service when I created the snap having in snapcraft.yaml '  plugs:           - avahi-control           - network'
<ondra> Dianomic_Stefano and that works, but when I call avahi-client.browse -t -a  -d local
<ondra> Dianomic_Stefano then I get error
<ondra> Dianomic_Stefano that just means that your service was before not talking to avahi daemon at all
<Dianomic_Stefano> but it worked fine in the standard Ubuntu server
<ondra> Dianomic_Stefano yeah because there daemon is installed as deb package and is not confined
<morphis_> popey: hm
<ondra> Dianomic_Stefano on core apparmor will fag any unauthorised communication to the daemon
<ondra> Dianomic_Stefano so running client as --devmode does not guarantee you that you can talk to avahi snap daemon
<ondra> Dianomic_Stefano communication is secured from both sides. On server it's only from one side if you are talking to something from classic side
<Dianomic_Stefano> ondra: could I completely disable apparmor ? if this could help.
<ondra> Dianomic_Stefano you can install also avahi in devmode
<ondra> Dianomic_Stefano then both sides are unconfined
<Dianomic_Stefano> ondra: I'm going to try
<morphis_> popey: I feel like the xenial Qt version was just too old and buggy for my use case
<Dianomic_Stefano> ondra: same situation - https://pastebin.ubuntu.com/p/BKPH3qCNfM/
<Nafallo> hiya. can I overwrite ~/snap to ~/.snap somewhere? :-)
<nacc> Nafallo: i think it's pretty well defined to be ~/snap
<morphis_> popey: so yes, that was the problem; using newer qt prebuilt from qt.io fixes the problems and make the snap working on various Ubuntu versions
<mup> PR snapcraft#1990 opened: tests: build and install snapcraft on osx <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1990>
<Nafallo> nacc: i.e. I can't change it?
<nacc> Nafallo: I don't believe so, but I'm not 100%
<nacc> Nafallo: i think you'd need to patch snapd to do so, but I'm not sure (SNAP_USER_DATA and SNAP_USER_COMMON depend on that path)
<ondra> Dianomic_Stefano hmm, I'm not expert on avahi, so we might need to ask lathiat for help
<ondra> Dianomic_Stefano are you calling avahi-browser directly?
<Nafallo> nacc: thanks for the response. I'll guess we need IndexIgnore for the home dir next ;-)
<nacc> Nafallo: :)
<Dianomic_Stefano> ondra: no, I have used 'avahi-client.browse -a -t'
<ondra> Dianomic_Stefano interestingly without changing anything vahi-client.browse -t -a  -d local does work now
<ondra> Dianomic_Stefano ok avahi-client.browse -a -t does work here
<ondra> Dianomic_Stefano so what are you running this on?
<ondra> zyga-ubuntu any idea what this means? https://paste.ubuntu.com/p/HH7NK5hPF5/
<zyga-ubuntu> ondra: It means that the snap has a content interface plug with a default provider that does not exist
<zyga-ubuntu> CC mvo
<ondra> zyga-ubuntu hmm, it is installed on that machine
<ondra> zyga-ubuntu and shouldn't this be warning instead of error blocking installation
<ondra> zyga-ubuntu OK my bad, I had wrong version of default provider, sorry for that
<fireclawTheFox> Hey everyone. My snapcraft plugin doesn't work when run on launchpad, quiting with "no attribute '_python_major_version'". The plugin is derived from the python plugin and does work fine if run locally. Does anyone know what could cause this?
<nacc> fireclawTheFox: how are you building locally? cleanbuild?
<nacc> fireclawTheFox: in any case, i'd first check the version of snapcraft locally vs. the version on LP
<fireclawTheFox> the snapcraft version I have is the stable 2.39.2 (1177)
<nacc> fireclawTheFox: and how are you building locally?
<nacc> fireclawTheFox: and on what release?
<fireclawTheFox> usually snapcraft -d I did try cleanbuild but last time I tried it stopped almost instantly with some lxd problem. Will try that again.
<fireclawTheFox> release of what? Do you mean the Ubuntu version?
<nacc> fireclawTheFox: yeah
<fireclawTheFox> 16.04
<nacc> fireclawTheFox: ok, that rules out one thought i had :)
<nacc> fireclawTheFox: note that the snapcraft used by LP is from the debs (I believe) and is currently at 2.39.3+really2.35
<nacc> fireclawTheFox: so you should test using that one, probably
<fireclawTheFox> using cleanbuild I get this: https://paste.ubuntu.com/p/z7yTYDzHJ9/
<nacc> fireclawTheFox: yeah, i believe that was fixed in snapcaft (it's aobut using a snap to call lxd
<nacc> kyrofa: --^ do you know if that's fixed in snapcraft? i think you had commented on this in the github issue
<fireclawTheFox> How do I get the 2.39.3 deb version?
<nacc> fireclawTheFox: of snapcraft? i assume you need to uninstall the snapcraft snap and install the snapcraft deb (apt)
<fireclawTheFox> ah ok, will try
<nacc> although that does raise the question of why the snapcraft snap is behind the the snapcraft deb
<kyrofa> nacc, I don't believe it's fixed, we didn't want to introduce a hack in snapcraft to work around a lxd bug
<nacc> kyrofa: ack, is there a suggestion for fireclawTheFox to workaround it?
<kyrofa> nacc, fireclawTheFox I personally fire up a clean lxd image with a custom profile that installs snapcraft, then build in there
<kyrofa> Not as seamless, but works well enough for me
<kyrofa> Could also use our docker container if you like, snapcore/snapcraft
<kyrofa> :latest is the deb, :<channel> is each channel of the snap, edge, beta, candidate and stable
<nacc> kyrofa: ah makes sense
<fireclawTheFox> ok, installed the deb version which gives me the same version as launchpads and as expected results in the same error.
<magicaltrout> stupid question multiple developers, if you want to grant access to push to the same snap. Can you? :)
<kyrofa> fireclawTheFox, indeed, it's not a snapcraft bug, it's a lxd bug
<kyrofa> As long as you have lxd installed from the deb, you'll have that issue
<kyrofa> magicaltrout, indeed you can add collaborators in the web interface of the store, but it's kind of all or nothing-- they can administer the snap
<kyrofa> (i.e. not just push)
<fireclawTheFox> kyrofa: I meant the error that I get because of the not existing _python_major_version, not the lxd one. I do wonder though, if the deb version is a more recent version than the sources on git, as this specific variable I was using is still there in the git sources.
<nacc> fireclawTheFox: *older* version than what is in git
<nacc> fireclawTheFox: the issue is presumably that, since you were using a newer snapcraft (from the snap) than what is in xenial-updates
<nacc> kyrofa: which brings up a good point about the snapcraft snap, hsouldn't it get reverted too?
<nacc> kyrofa: given we know it's broken for certain (*cough*) classic snaps
<fireclawTheFox> ah ok, so I'm ahead.
<nacc> fireclawTheFox: well, you were (when on the snapped snapcraft)
<kyrofa> nacc, it IS? Oh no, I should have spent every day this week on that! :D
<magicaltrout> ah yeah got it
<magicaltrout> thanks
<nacc> kyrofa: heh :)
<nacc> kyrofa: it was more a question of how the snapped snapcraft works relative to the deb :)
<nacc> (version wise)
<kyrofa> nacc, kidding aside, I'm not sure. It's actually been released for a lot longer than the deb, but things didn't explode until we released the deb since that's what all the infrastructure is based upon
<nacc> kyrofa: yeah
<kyrofa> nacc, the snap works a bit differently since it bundled the correct version of patchelf
<kyrofa> With the deb, we didn't have that option
<nacc> kyrofa: oh sure
<fireclawTheFox> nacc, kyrofa, does it change anything, if I switch the series of the snap reciep on launchpad (e.g. to Artful or Bionic) or will it always use the same snapcraft version?
<kyrofa> fireclawTheFox, if you're building a snap in LP, I suggest always using xenial
<nacc> fireclawTheFox: you don't (generally) want to do that :)
<nacc> for other reasons :)
<fireclawTheFox> ok
<fireclawTheFox> so for now, I either have to wait until LP will update the snapcraft version or fix my custom plugin, right?
<nacc> fireclawTheFox: yes, I believe so. The latter is probably preferable, since it seems to be dependent on external python code (which you don't control the version of)
<kyrofa> fireclawTheFox, I haven't actually seen the issue you've hit. I think I missed it above
<kyrofa> All I saw was the lxd bit
<fireclawTheFox> kyrofa, the error I posted above was before I changed to the deb version. The new one looks like the one I get on launchpad so that's fine.
<kyrofa> fireclawTheFox, ohhh, you're using a local plugin written against git master, but the deb is much older
<kyrofa> Okay, same page now
<nacc> kyrofa: yeah, and that's why i was asking about the snap :)
<fireclawTheFox> yeah, I have a local plugin which was based on the snap/git version of snapcraft
<kyrofa> fireclawTheFox, normally that wouldn't be a problem except we haven't had a deb release for a while so it's pretty far behind. I suggest updating the local plugin referring to the 2.35 tag
<fireclawTheFox> will do
<fireclawTheFox> if the standard python plugin would be able to accept custom setup tool commands (e.g. replacing the install arg) I might not even needed to build a custom plugin.
<bashfulrobot> hey guys... how does one remove a snap from a channel in the store? I tried doing `snapcraft release {name} {rev} {channel}` with an older revision. But `list-revisions` shows both in the original channels. Isthis something that you do with the `close` option?
<bashfulrobot> sorry - "remove a snap revision"
<kyrofa> bashfulrobot, check `snapcraft status` instead
<kyrofa> Or `snap info`
<kyrofa> bashfulrobot, or, in list-revisions, look for the asterisk
<kyrofa> Basically, the store remembers that a given snap was released into a given channel, and list-revisions shows you that
<kyrofa> But the only thing that really matters is which revision is currently ACTIVE in that channel
<kyrofa> fireclawTheFox, can you be more specific about what the plugin is doing today and what you need it to do?
<kyrofa> fireclawTheFox, we're always open to adding to it
<bashfulrobot> kyrofa: Rockstar! Thanks. Misunderstood the output
<kyrofa> bashfulrobot, there's a lot of info there, easy to misinterpret
<fireclawTheFox> kyrofa, it's a plugin to utilize the deployment system of the Panda3D game engine. It doesn't do that much, just calling the setup.py script with -OO and build_apps instead of install and finally copy some libs into the root directory.
<mup> Issue snapcraft#1991 opened: Distrubuted ROS system among multiple snaps <Created by Lingaprahasam> <https://github.com/snapcore/snapcraft/issue/1991>
<fireclawTheFox> kyrofa: you can take a look at my actual plugin here: https://bazaar.launchpad.net/~fireclawthefox/thetravelingfox/snap/view/head:/snap/plugins/x_panda3d.py
<kyrofa> fireclawTheFox, oh man, you're gonna be so sad making that work on 2.35
<kyrofa> Don't throw this away
<kyrofa> fireclawTheFox, so panda3d won't work with pip?
<fireclawTheFox> kyrofa I can install it with pip, but then I have the complete engine installed which isn't really desirable. Using the deploy tools of the engine will pack up everything nicely and will save a lot of space.
<kyrofa> fireclawTheFox, interesting, okay. As you may have seen in the code, as call setup.py install directly as a workaround for a bug, not really as a thing we expect many people need
<kyrofa> s/as/we/
<kyrofa> Perhaps that needs to change
<fireclawTheFox> yeah, not sure if many people do write custom setup tools, but for those who are, having this configurable would be a welcome addition.
<fireclawTheFox> btw, what bug are you talking about that calling setup.py install directly fixes?
<mup> Issue snapcraft#1991 closed: Distrubuted ROS system among multiple snaps <Created by Lingaprahasam> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1991>
<Lite5h4dow> Hi there
<Lite5h4dow> Im having issues installing snapd
<Lite5h4dow> from the AUR
<Lite5h4dow> well, snapd and snapd-git both fail to build
<Lite5h4dow> is any one here?
<Lite5h4dow> guess not
<Lite5h4dow> rest in pepperonies
<bashfulrobot> kyrofa: It's actually not too bad. But it is one of those things as you work through it for the first time... ð
<Lite5h4dow> hello palasso
<palasso> hello
<Lite5h4dow> do you know anything about building snapd on arch?
<palasso> Yeah, it's on the AUR
<Lite5h4dow> yeah
<Lite5h4dow> problem with that
<Lite5h4dow> it fails to build
<Lite5h4dow> both snapd and snapd-git fail
<palasso> could you pastebin the output?
<Lite5h4dow> https://pastebin.com/HwTtu8eG
<palasso> hmmmm it's not descriptive
<palasso> snapd gives you same output?
<Lite5h4dow> yup
<Lite5h4dow> same error
<palasso> Have you considered to build the package through makepkg?
<Lite5h4dow> yup
<Lite5h4dow> same error
<Lite5h4dow> its an error in the pkgbuild
<palasso> I'll try to build it now and see what will happen
<Lite5h4dow> autoreconf isnt a recognised command
<Lite5h4dow> any luck?
<palasso> It's still building, I'll let you know once it's finished
<Lite5h4dow> ok
<palasso> and finished
<Lite5h4dow> xD
<palasso> It builds on my machine
<Lite5h4dow> huh
<Lite5h4dow> weird
<Lite5h4dow> could you walk me through what you did?
<Lite5h4dow> because i built it and it broke
<palasso> just makepkg
<Lite5h4dow> your on arch right?
<palasso> yeah of course
<Lite5h4dow> ok
<Lite5h4dow>  really weird
<palasso> I could upload the built package for you to download if you want
<Lite5h4dow> i think it was just my version of base-devel
<Lite5h4dow> it was a little old
<Lite5h4dow> yeah
<Lite5h4dow> it installed
<Lite5h4dow> my bad
<palasso> Okay, nice
<Lite5h4dow> im on a macbook, so not every package works
<Lite5h4dow> so i had the core packages frozed
<Lite5h4dow> frozen*
<palasso> Ahh yeah this is a problem for arch.
<palasso> If you freeze lost of core packages it's hard to install newer software
<Lite5h4dow> yeah
<Lite5h4dow> anyway
<Lite5h4dow> ty for taking the time to help
<palasso> yw
<Lite5h4dow> now to see if i can get anbox installed
<palasso> Lite5h4dow: if you wish to remain with many packages frozen consider using the Arch Linux Archive. You could point your repo to a specific date and get all software from that date (no security fixes). Otherwise perhaps you should look for some other distro that does fixed-point releases. Or maybe some strategy for rollbacks in case of regressions after updating
<Lite5h4dow> oh ok
<Lite5h4dow> ill definately do that
<Lite5h4dow> but im looking into it and it seems all the current versions of the core packages support my macbook
<Lite5h4dow> so im going to do a full upgrade tonigh
<Thillai> hello team
<Thillai> I have a Edge Gateway that runs ubuntu-core/15.04/stable..
<Thillai> I am trying to install Apache2 on this device.. Does anyone have idea on thi..
#snappy 2018-03-08
<__chip__> kyrofa: o/
<mup> PR snapd#4799 opened: cmd/snap: use timeutil.Human to show times in `snap refresh --time` <Created by chipaca> <https://github.com/snapcore/snapd/pull/4799>
<zyga-ubuntu> Hey
<mup> PR snapcraft#1989 closed: elf: don't parse elf more than necessary <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1989>
<Dianomic_Stefano> ondra: Hi, ondra this is the situation https://pastebin.ubuntu.com/p/gZPQVr2vDp/ - our snap/service still crash with the error in the syslog, any suggestions ?
<mup> PR snapcraft#1992 opened: tests: run integration tests on trusty <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1992>
 * tbr slaps Dianomic_Stefano around a bit with a frozen trout
<Dianomic_Stefano> Hi, I'm having problem using our service 'foglamp' in a snap and using avahi - it crashs with the errors - https://pastebin.ubuntu.com/p/gZPQVr2vDp/ - it works fine in the standard  Ubuntu server, any changes for help ?
<Dianomic_Stefano> lathiat: hi lathiat
<mup> PR snapcraft#1993 opened: core: initial support for bases <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1993>
<jamesh> jdstrand: hi.  Do you know whether the /usr/share/applications access in the browser-support interface is necessary?  It is interfering with a browser snap kenvandine is working on
<sergiusens> kenvandine: https://github.com/snapcore/snapcraft/pull/1994
<mup> PR snapcraft#1994: docker: add the architecture <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1994>
<mup> PR snapcraft#1994 opened: docker: add the architecture <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1994>
<ondra> Dianomic_Stefano hi
<ondra> Dianomic_Stefano so I installed avahi-client on couple of devices and it does work there
<ondra> Dianomic_Stefano so without knowing more about your app it's hard to say
<ondra> Dianomic_Stefano but let's try one thing
<greyback> zyga-ubuntu: hey, using edge core worked for me (the layout thing works) - and edge core installed ok (no idea why it failed before, sorry)
<zyga-ubuntu> greyback: that's excellent news!
<zyga-ubuntu> thank you for checking
<greyback> np
<greyback> definitely a quick guide on best way to hack on snapd would be welcome (if your devtools are not recommended)
<Dianomic_Stefano> ondra: could it be something related to the avahi version ? we use ' avahi-daemon 0.6.32-rc'  in the standrad Ubuntu server
<Dianomic_Stefano> ondra: is it possible to install a snap having the specific version 'avahi-daemon 0.6.32-rc'  ?
<ondra> Dianomic_Stefano you can always compile avahi from source
<ondra> Dianomic_Stefano there are some older revisions of avahi for 6.32-rc let me see if I can find them
<ondra> Dianomic_Stefano can try following
<ondra> Dianomic_Stefano $ snap run --shell <yourt snap name>.foglamp
<ondra> Dianomic_Stefano this should give you shell into your snap sandbox
<ondra> Dianomic_Stefano now $ cat $SNAP/command-foglamp.wrapper
<ondra> Dianomic_Stefano you will see there couple of exports, run those manually so you get all paths set properly
<ondra> Dianomic_Stefano now try to run $ avahi-browse -a
<ondra> Dianomic_Stefano what do you get?
<Dianomic_Stefano> 1 sec
<Dianomic_Stefano> ondra: https://pastebin.ubuntu.com/p/GkprpWfXys/
<ondra> Dianomic_Stefano BTW my client is 0.6.32-rc
<ondra> Dianomic_Stefano so no problem to talk to newer daemon
<ondra> Dianomic_Stefano yeah so run manually: $ export PATH="$SNAP/usr/sbin:$SNAP/usr/bin:$SNAP/sbin:$SNAP/bin:$PATH"; export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:$SNAP/lib:$SNAP/usr/lib:$SNAP/lib/x86_64-linux-gnu:$SNAP/usr/lib/x86_64-linux-gnu"; export LD_LIBRARY_PATH="$SNAP/usr/lib/x86_64-linux-gnu:$LD_LIBRARY_PATH"; export LD_LIBRARY_PATH=$SNAP_LIBRARY_PATH:$LD_LIBRARY_PATH
<Dianomic_Stefano> ondra: it seems that the problem is relate to foglamp (our service) talking to avahi-daemon https://pastebin.ubuntu.com/p/BBVnC2Wkmz/ - this is whey I was thinging about the versioning.
<ondra> Dianomic_Stefano and now run avahi-browse
<Dianomic_Stefano> ondra: foglamp doesn't start after the exports - https://pastebin.ubuntu.com/p/s8QQXpYfgH/
<ondra> Dianomic_Stefano can you try to run avahi-browse -a
<ondra> Dianomic_Stefano so we know at least that basics are set correctly
<Dianomic_Stefano> ok, I have exeduted '$SNAP/usr/bin/wrapper-foglamp start'
<ondra> Dianomic_Stefano yes, you are inside snap sandbox, so you run directly wrapper-foglamp
<Dianomic_Stefano> ondra: same errors in the syslog
<ondra> Dianomic_Stefano can you run avahi-browse -a please
<ondra> Dianomic_Stefano does that give you error?
<Dianomic_Stefano> avahi-brows works - https://pastebin.ubuntu.com/p/6cYPD7cnbS/
<Dianomic_Stefano> ondra: but our service is crashing 'Starting FogLAMP v1.2............................................................foglamp@foglamp-core:/'
<ondra> Dianomic_Stefano OK so uit;
<Dianomic_Stefano> wiht the  errors ' Mar  8 10:15:51 foglamp-core avahi.avahi-daemon[9205]: Error parsing EntryGroup::AddService message
<Dianomic_Stefano> Mar  8 10:15:51 foglamp-core avahi.avahi-daemon[9205]: dbus-entry-group.c: interface=org.freedesktop.Avahi.EntryGroup, path=/Client1/EntryGroup1, member=AddService
<Dianomic_Stefano> '
<ondra> Dianomic_Stefano so problem is not related to snapd security,but more to your dbus messages, if you want to test older avahi deamon
<ondra> Dianomic_Stefano I can get you some older ones, what architecture do you need?
<Dianomic_Stefano> ondra: x86_64 - version ' avahi-daemon 0.6.32-rc'  - thanks a lot for helping.
<ondra> Dianomic_Stefano http://people.canonical.com/~okubik/avahi-0.6.32_amd64.snap
<ondra> Dianomic_Stefano can't guarantee it works but you can try it
<Dianomic_Stefano> ondra: tanks
<Dianomic_Stefano> thanks
<mup> PR snapcraft#1995 opened: options: introduce Project and ProjectInfo <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1995>
<mup> PR snapcraft#1970 closed: meta: parse LAUNCHPAD_BUILD_INFO for inclusion in the manifest <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/1970>
<oSoMoN> are there known issues with snapd and nvidia proprietary drivers on 18.04 ?
<oSoMoN> (https://forum.snapcraft.io/t/call-for-testing-chromium-65-0-3325-146/4390/2)
<zyga-ubuntu> We donât have anyone on the core team with modern nvidia for daily testing
<mup> PR snapd#4800 opened: cmd/snap: in changes and tasks, default to human-friendly times <Created by chipaca> <https://github.com/snapcore/snapd/pull/4800>
<pstolowski> andyrock, can you remind me your snap --version on bionic?
<mup> PR snapd#4794 closed: xdgopenproxy: integrate xdg-open implementation into snapctl <go go go go!> <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4794>
<pstolowski> andyrock, also, can you send me your state.json?
<mup> PR snapd#4793 closed: progress: tweak ansimeter cvvis use to no longer confuse minicom <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4793>
<Chipaca> zyga-ubuntu: https://vt100.net/docs/vt220-rm/contents.html
<Chipaca> zyga-ubuntu: http://terminals-wiki.org/wiki/index.php/Main_Page
<ikey> jdstrand, sorry for delay on steam interface right now, you can put that blame on me
<ikey> sorta stuck on other stuff atm
 * Chipaca chomping on gummy bears
 * zyga-ubuntu shakes fist at ikey ;-)
<zyga-ubuntu> ikey your stuff is late and _you_ want it
<zyga-ubuntu> how are you doing? :-)
<ikey> i know im my own worst enemy
<ikey> im good thanks, ear is a bit ouch, you?
<zyga-ubuntu> ouch, had that two weeks ago, we're churning along with fixes and some features
<zyga-ubuntu> I'm trying to get a systemd generator to behave
<ikey> the ear thing is my fault. got it repierced yesterday xD
<ikey> oh ok
<zyga-ubuntu> ah, well that's what you get when you inflict self damaga :)
<ikey> :D
<zyga-ubuntu> apart from that some catch-up where we are and if we can land things for the next release
<ikey> shaved my head off too so im cold. again my fault
<zyga-ubuntu> in the winter?!!
<ikey> i know xD
<zyga-ubuntu> whaaat
<ikey> i get ideas. not all of them good
<zyga-ubuntu> why?
<ikey> it was *long*
<ikey> did you see the webcam thing?
<zyga-ubuntu> "hold that thought" until sprint
<zyga-ubuntu> *spirng
<zyga-ubuntu> aw
<zyga-ubuntu> spring
<zyga-ubuntu> the webcam thing?
<zyga-ubuntu> the photo on G+
<ikey> https://twitter.com/ufee1dead/status/971021153371377671
<ikey> *snort*
<King_InuYasha> ikey: you look awesome :D
<ikey> with my comb and scissors? :P
<ikey> i look simply fabulous..
<ikey> so yeah now its all gone
<ikey> swapped hair for a holy ear and sense of coldness
<mup> PR snapcraft#1996 opened: tests: add SNAPCRAFT_KEEP_DATA to debug <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1996>
<zyga-ubuntu> holly cow
<zyga-ubuntu> that's some extra hair you have there
<ikey> right?
<ikey> you can see in the reply the lack of hair after :D
<ikey> and cheese didnt work with my webcam so i have to use guvcview..
<ikey> darned gnome apps
 * ikey decided to accelerate his midlife crisis by a couple decades
<mup> PR snapd#3998 closed: snap-confine, snap-seccomp: utilize new seccomp logging features <Created by tyhicks> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3998>
<jdstrand> ikey: no worry on my end. I was just trying to be transparent with my PR comment; not trying to add pressure
<ikey> honestly mate ive not even read it yet, i just know i have a notification, sorry bud
 * zyga-ubuntu needs more VMs
<zyga-ubuntu> is there anything that's not libvirt, not virtualbox that works out of the box and is not an overly-engineered monster?
<zyga-ubuntu> (that is before I snap vmware)
<King_InuYasha> eh, for me, libvirt "Just Works"
<King_InuYasha> install virt-manager, boom, done
<King_InuYasha> or use gnome-boxes if you're into that sort of thing (that is, gnome ;) )
<mup> PR snapd#4801 opened: cmd/snap-seccomp: Cancel the atomic file on error, not just Close <Created by chipaca> <https://github.com/snapcore/snapd/pull/4801>
<jamesh> popey: the gtk-common-themes snap should be mostly working (testing against https://people.canonical.com/~jamesh/theme-experiment/gtk3-demo_0.1_amd64.snap)
<BuActuallyGosh> How do I install Spotify ? I dont have snapcraft installed on rosa ?
<jamesh> popey: 27 MB for GTK3 and icon themes covering Adwaita (GNOME/Fedora), HighColor (a11y), Ubuntu, and Solus, and the Arc GTK theme
<BuActuallyGosh> Who's jamesh ?
<mup> PR snapd#4802 opened: strutil: simple shell lexer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4802>
<BuActuallyGosh> Is princes Leia here, on the answer my question - horizon ?
<popey> jamesh: nice
<BuActuallyGosh> popey, I'm at home on Rosa 10 LxQt (sorry about that) - any chance you could halp me install Spotify today, as a snap, please ? Just boot LxQt for first time :-)
<BuActuallyGosh> **booted
<popey> BuActuallyGosh: hello codereurope. if it's based on ubuntu you can "snap install snapd" and then "snap install spotify"
<BuActuallyGosh> thankyou gura mie ayd.  i shall try to keep quiet in future.
<BuActuallyGosh> https://paste.ubuntu.com/p/VMWshwjb8n/
<popey> oops, typo on my part
<popey> "sudo apt install snapd"
 * BuActuallyGosh chuckles
<popey> (assuming this thing is based on debian or ubuntu - I'd not heard of rosa 10 lxqt before)
<BuActuallyGosh> okay - it worked - yu assume too much. I won't both you again until after beaver. gura mie ayd popey.
<mup> PR snapcraft#1997 opened: lxd: merge existing image info contents <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1997>
<Chipaca> zyga-ubuntu: https://hackertyper.net/
<ondra> zyga-ubuntu ping
<zyga-ubuntu> pong
<ondra> zyga-ubuntu actually unpong
<ondra> zyga-ubuntu my error, was mixing bind and bind-file
<ondra> zyga-ubuntu BTW have you had thought about that install error for default content provider?
<ondra> zyga-ubuntu I still think that should be error, not blocking error
<ondra> zyga-ubuntu what if you uninstall provider, then refresh would fail
<ondra> zyga-ubuntu and I though default, does not mean "only" provider
<zyga-ubuntu> ondra: I don't know much about the default provider, I would have to check
<ondra> zyga-ubuntu or who would be to talk about this?
<zyga-ubuntu> ondra: mvo would be best
<mup> PR snapd#4803 opened: snap-confine, snap-seccomp: utilize new seccomp logging features - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4803>
<ondra> zyga-ubuntu cool, will chat with him about it
<greyback> zyga-ubuntu: can I use layouts to bind mount a file into somewhere I need it?
<greyback> ooh "bind-file"
<greyback> unping
<mup> PR snapd#4804 opened: strutil/shlex: import github.com/google/shlex into the tree <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4804>
<mup> PR snapd#4802 closed: strutil: simple shell lexer <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4802>
<mup> PR core#84 closed: xdg-open: switch to "snapctl user-open" based implementation <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/core/pull/84>
<Chipaca> jdstrand: tyhicks: Q for you: is 14.04 getting the backport of the seccomp EPERM thing?
<zyga-ubuntu> greyback: yes, just use bind-file
<mup> PR snapcraft#1998 opened: pluginhandler: add {pre,post}-build scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1998>
#snappy 2018-03-09
<mup> PR snapcraft#1986 closed: schema: add keep-execstack <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1986>
<axino> zyga-ubuntu: hi
<axino> zyga-ubuntu: a team mate just filed https://bugs.launchpad.net/snapd/+bug/1754367, and it very much looks like a bug you helped me work around a few months ago
<mup> Bug #1754367: error removing snap: /snap/<snap name>/<rev> not mounted <snapd:New> <https://launchpad.net/bugs/1754367>
<zyga-ubuntu> Hi
<tyhicks> Chipaca: all the underlying seccomp changes are already in 14.04 (I SRU'ed those all late last year)
<jdstrand> Chipaca (tyhicks): https://forum.snapcraft.io/t/strict-mode-seccomp-policy-violations-now-set-errno-to-eperm-instead-of-killing-the-process/4397/3
<Chipaca> jdstrand: woooooooo*cough**wheeze*ooooooooooo
<robert_ancell> Chipaca, is the classic confinement error (snapstate.go:70) an async error or a sync one? Would be nice to have an error kind to match on that one.
<robert_ancell> Since the error message is translated we can't match on the string.
<mup> PR snapd#4795 closed: polkit: ensure error is properly set if dialog is dismissed <Created by azzar1> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4795>
<mup> PR snapd#4805 opened: Note in system info if can install snaps in classic mode <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4805>
<mup> PR core#85 opened: live-build/hooks/500-create-xdg.binary: fix silly quoting bug <Created by mvo5> <https://github.com/snapcore/core/pull/85>
<mup> PR core#85 closed: live-build/hooks/500-create-xdg.binary: fix silly quoting bug <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/85>
<robert_ancell> popey, do you have a nice document online that explains how to setup classic snaps on Fedora?
<robert_ancell> Fedora bug for reference https://bugzilla.redhat.com/show_bug.cgi?id=1552512
<popey> robert_ancell: how do you mean "how to setup classic snaps"?
<popey> robert_ancell: "snap install foo --classic", if it doesn't work, then it's a bug (probably already known)
<robert_ancell> popey, no the instructions on how to make the symlink
<robert_ancell> i.e. "how to make classic snaps work in Fedora"
<popey> google "install snapd on fedora"
<robert_ancell> with a "why we're asking you to type these commands"
<popey> if you dont find it we have a problem
<robert_ancell> https://docs.snapcraft.io/core/install-fedora ?
<robert_ancell> That doesn't mention the symlink
<robert_ancell> Pharaoh_Atem, don't know if you have anything ^
<jdstrand> roadmr: hi! would you mind pulling r1010 of the review tools? teensy changes, not emergency
<jdstrand> niemeyer: fyi, ^ has your request to warn on the use of layouts
<mup> PR snapd#4801 closed: cmd/snap-seccomp: Cancel the atomic file on error, not just Close <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4801>
<roadmr> jdstrand: sure thing!
<jdstrand> roadmr: thanks! :)
<popey> robert_ancell: https://github.com/canonical-docs/snappy-docs/commit/dd95c7b56ebb6527811fc0d902c70b5f0ceee64b
<robert_ancell> popey, huh, who did that?
<robert_ancell> ah, David
<robert_ancell> oh, that's a different symlink
<robert_ancell> not the /snap symlink
<popey> https://github.com/canonical-docs/snappy-docs/commit/68281ccd45f59fa68559e06d56915ab378aef816#diff-a43c50837ba5ccb56bd1951920805fc2
<popey> :)
<popey> i dont have any fedora systems handy, if you believe the page is wrong, then we should check with the fedora developers and update it
<mup> PR snapd#4797 closed: many: add the snapd-generator <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4797>
<greyback> zyga-ubuntu: this is a bash snippit I use a lot in my snaps: https://pastebin.ubuntu.com/p/QGXKtWwpz7/
<davidcalle> popey: robert_ancell, so which symlink should be back? :)
<davidcalle> Ah, the /snap one
<Chipaca> tyhicks: jdstrand: if you happen to find yourself wondering what to do next, we've got something that might be entertaining for you to look at
<davidcalle> @popey @robert_ancell https://github.com/canonical-docs/snappy-docs/pull/372
<mup> PR canonical-docs/snappy-docs#372: Fedora symlink fix and explanation <Created by caldav> <https://github.com/canonical-docs/snappy-docs/pull/372>
<robert_ancell> davidcalle, thanks!
<mup> PR snapd#4796 closed: cmd/snap: "current"â"installed"; "refreshed"â"refresh-date" <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4796>
<zyga-ubuntu> stgraber: Hey, is 14.04 with snapd and lxd snap running 14.04 and snapd a supported scenario?
<stgraber> zyga-ubuntu: no
<stgraber> zyga-ubuntu: 14.04 containers can't run snaps
<stgraber> zyga-ubuntu: 14.04 host with 16.04 container should be able to run snaps though
<zyga-ubuntu> stgraber: thank you for confirming that
<robert_ancell> I have a test failing on my PR - cannot update snap namespace: cannot create writable mimic over "/etc": no such file or directory
<robert_ancell> snap-update-ns failed with code 1: File exists
<robert_ancell> Is that a common failure?
<zyga-ubuntu> robert_ancell: I'm looking into that
<zyga-ubuntu> yes, it's annoyingly common
<robert_ancell> zyga-ubuntu, so I should restart the tests or is that considered mergable as is?
<zyga-ubuntu> robert_ancell: just restart, yes
<zyga-ubuntu> I will address that soon (as soon as I can(
<zyga-ubuntu> )
<robert_ancell> zyga-ubuntu, thanks
<robert_ancell> zyga-ubuntu, feel free to reiview https://github.com/snapcore/snapd/pull/4805 too
<mup> PR #4805: Note in /v2/system-info if can install snaps in classic mode <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/4805>
 * robert_ancell pushes his luck
<ogra_> so brave
<mup> PR snapd#4806 opened: vendor: update github.com/mvo5/libseccomp-golang <Created by zyga> <https://github.com/snapcore/snapd/pull/4806>
<robert_ancell> popey, flexiondotorg - you guys might have an opinion on https://forum.snapcraft.io/t/add-method-to-show-recently-updated-snaps/4409
<mup> PR snapd#4792 closed: overlord/snapstate: block install of "system" <Created by chipaca> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4792>
<popey> robert_ancell: left a comment :)
<robert_ancell> popey, ta
<robert_ancell> zyga-ubuntu, how do I get https://forum.snapcraft.io/badges/101/fedora ?
<robert_ancell> and https://forum.snapcraft.io/badges/106/ubuntu
<zyga-ubuntu> robert_ancell: you ask niemeyer for that I think
<Chipaca> robert_ancell: any admin can do that
<Chipaca> robert_ancell: like that
<robert_ancell> thanks!
<mup> PR snapd#4806 closed: vendor: update github.com/mvo5/libseccomp-golang <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4806>
<mup> PR snapd#4807 opened: tests: remove snapd.refresh.timer everywhere <Created by mvo5> <https://github.com/snapcore/snapd/pull/4807>
<mup> PR snapd#4804 closed: strutil/shlex: import github.com/google/shlex into the tree <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4804>
<mup> PR snapd#4757 closed: cmd/snap: unhide --no-wait; make wait use go via waitMixin <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4757>
<mup> PR snapd#4808 opened: cmd/snap: use shlex when parsing `snap run --strace arguments` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4808>
<mup> PR snapd#4807 closed: tests: remove snapd.refresh.timer everywhere <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4807>
<mup> PR snapd#4809 opened: cmd/snap: tweak and polish help strings <Created by chipaca> <https://github.com/snapcore/snapd/pull/4809>
<om26er> popey: ping
<popey> hey om26er
<popey> my internet disconnects in 8 mins, so I may disappear :)
<om26er> popey: https://forum.snapcraft.io/t/call-for-testing-android-studio/3051/24
<om26er> lets graduate it to stable.
<popey> ok. just doing a quick install here to test (I believe you)
<om26er> tested on OpenSUSE 42.3 as well.
<popey> ooh, that work okay?
<om26er> popey: sounds good. Hope you have fast enough internet to download that within the remaining minutes.
<popey> hehe, me too!
<om26er> yes, worked fine on OpenSUSE as well.
<popey> Looks good. Great to hear. Gonna push it now.
<popey> thanks for working on this om26er !
<popey> done
<om26er> popey: cool, great stuff. Thank you for the patience to test it so many times.
<popey> No worries. Have a great weekend.
<ondra> zyga-ubuntu ping
<zyga-ubuntu>  Pong
<zyga-ubuntu> ondra: it is not the best time
<ondra> zyga-ubuntu yeah only quick, if layout made it out of edge
<ondra> zyga-ubuntu works in edge, but beta suggest higher version but does not work there
<zyga-ubuntu> Yeah
<zyga-ubuntu> Beta moved back
<zyga-ubuntu> For micro release
<ondra> zyga-ubuntu ah, that would explain
<ondra> zyga-ubuntu thanks and good travel back!
<mup> PR snapcraft#1999 opened: tests: document the SRU testing process <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1999>
<mup> PR snapcraft#1984 closed: tests: update store tests user <bug> <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1984>
#snappy 2018-03-10
<muravey> Hi all
<muravey> please help me with problem of launch snap package. Build and install is fine. But after run program crash with "file not found", but this file exist in snap package.
<muraveyomsk> dead chat?
<muraveyomsk> how set workdir for command in snap?
<zyga-ubuntu> Many people are traveling now so wonât respond to questions
<zyga-ubuntu> Please catch us next week
<Pharaoh_Atem> zyga-ubuntu: are you one of those?
<mup> PR snapd#4810 opened: osutil: DropPrivs morphs an *exec.Cmd to drop privileges <Created by chipaca> <https://github.com/snapcore/snapd/pull/4810>
#snappy 2018-03-11
<Shibe> is wine available as a snap?
<Shibe> I'm having troubles getting wine32 working on ubuntu 17.10 and I would like if there was a snap
<pbek> Shibe: doesn't look like there is one... https://uappexplorer.com/snaps?q=wine&sort=relevance
<zyga-ubuntu> Pharaoh_Atem: i was on a sprint last week but i ma home now
<zyga-ubuntu> I meant to say that I am home now :-)
<TingPing> does using the gnome platform actually require users manually install and connect them or am i missing something?
<TingPing> based off this: https://forum.snapcraft.io/t/auto-connection-for-gnome-3-24-content-interface/1379/75 - it still can't autodownload platforms?
#snappy 2019-03-04
<zyga> hello
<mborzecki> morning
<zyga> hey
<zyga> mborzecki: quick qustion, does the aur packaging limit architectures?
<zyga> mborzecki: someone is asking for snapd on manjaro on aarch64
<mborzecki> zyga: yes and no, iirc the general consensus was that you put x86_64 there and then people building the package on other arches can edit PKGBUILD to their liking
<mborzecki> also aur helpers usually allow to ignore the arch and build with whatever the local one is
<mborzecki> i've added i386 for some arch-on-x86 project poeple asked about
<mborzecki> i can add aarch64 too
<zyga> mborzecki: uh, that's odd, why do you have to put x86_64?
<zyga> mborzecki: yeah, let's add aarch64 and just call it a day (on that issue)
<mborzecki> haha i see the forum topic now
<mborzecki> so poeple can close and call makepkg -i but don't bother to read the manpage :P
<zyga> "snap install things quickly" :)
<mborzecki> zyga: i'm seeing 434 syscalls known to libseccomp in the current master branch
<zyga> mborzecki: how are you measuring?
<mborzecki> zyga: there's arch-syscall-dump tool in the source code that dumps the known syscalls for that arch
<zyga> ah, nice
<mborzecki> zyga: this is combined for all arches: https://paste.ubuntu.com/p/3vDk88tFZf/
<zyga> brb,dog.walk()
<zyga> re
<zyga> hello mvo
<mvo> hey zyga ! good morning
<zyga> welcome back :)
<zyga> how was your week off?
<mvo> zyga: it was very nice
<mvo> zyga: thank you
<mvo> zyga: what did I miss?
<zyga> mvo: let me think
<zyga> mvo: I think last week was mostly quiet
<zyga> mvo: for me some things that are important are 2.13 apparmor - we need to urgently release with support for it
<mvo> zyga: in what distros is it used? and what changes for us?
<zyga> mvo: I also raised the topic of snapd LTS but pedronis asked to move the discussion to this week, once you are back
<zyga> mvo: it's going in everywhere, opensuse, debian and ubuntu as well
<zyga> mvo: there's a PR from jdstrand
<zyga> mvo: I proposed  that 2.37 become the first LTS branch that just gets bug fixes and is periodically released again
<zyga> and that we have tracks with that version
<zyga> mvo: apart from that, we have ongoing beta validation
<zyga> mvo: and I think that's it, lots of reviews to do
<mvo> zyga: thanks
<mvo> zyga: anything holding back beta validation? I mean, any issue that prevent the move to candidate?
<zyga> mvo: I don't recall any details, sorry
<mvo> zyga: ta, I will chase it
<mborzecki> mvo: hey
<pstolowski> morning
<mvo> good morning mborzecki  and pstolowski !
<Chipaca> moin moin
<Chipaca> ooh, new git
 * Chipaca accepts the gift of the apt gods 
 * zyga reviews https://github.com/snapcore/snapd/pull/6079
<mup> PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<mborzecki> zyga: thanks!
<mborzecki> zyga: https://paste.ubuntu.com/p/cJ2v9hfJhH/ snap-seccomp version is added at the very beginning
<mborzecki> it's the library version followed by the hash of the supported syscall names
<zyga> mborzecki: looks great,
<zyga> mborzecki: would you mind moving the hash to the 2nd line and saying what it is
<mborzecki> zyga: mhm, and the changes aren't that huge either
<zyga> mborzecki: "# hash of sorted list of supported system calls
 * zyga is slow today, both wife and  older daughter have fever :/
<zyga> mborzecki: bonus points for naming the hash algo
<wgrant> mvo: Morning, welcome back.
<wgrant> mvo: Any idea on the current situation with backporting the catalog randomisation?
<mvo> wgrant: its in beta and we uploaded the SRU last week, afaict no SRU reviewer has looked at it yet, I will poke people about it today
<wgrant> mvo: Does that include xenial/bionic-security?
<mup> PR snapd#6558 opened: many: remove unused code (mostly) <Created by chipaca> <https://github.com/snapcore/snapd/pull/6558>
<pedronis> mvo: hi, welcome back, hope the week (mostly) off was restful
<pedronis> Chipaca: hi,  #6545 should be mergeable if you are ok with the tweaks I pushed there
<mup> PR #6545: cmd/snap, daemon: make the connectivity check use GET <Created by chipaca> <https://github.com/snapcore/snapd/pull/6545>
<smallville7123> What's the difference between kotlin and kotlin/native
<smallville7123> What's the difference between kotlin and kotlin-native*
<smallville7123> For example, "Kotlin/Native compiler" and "Command line Kotlin compiler"
<smallville7123> kotlin-native            0.9.3     jetbrains  classic  Kotlin/Native compiler
<smallville7123> kotlin                   1.3.21    jetbrains  classic  Command line Kotlin compiler
<Chipaca> smallville7123: read the description of both?
<smallville7123> Where do i find thay
<smallville7123> That
<Chipaca> smallville7123: snap info kotlin kotlin-native (snap info kot-alt-*)
<smallville7123>   Statically typed programming language for modern multiplatform applications
<smallville7123> Yet its summery is  summary:   Command line Kotlin compiler
<smallville7123> So which is it -_-
<Chipaca> pedronis: you introduced a double-lock on state, there
<Chipaca> unless i missed something
<Chipaca> nope
<Chipaca> smallville7123: read the description? the summary was already in the output of 'snap find'
<smallville7123> Also why are there two if both are to be the same
<smallville7123> What does one provide that the other doesnt
<Chipaca> smallville7123: the information is there if you read it. And ultimately, even if it weren't, ask jetbrains; how should *we* know?
<smallville7123> Cus YOU package and provide them
<pedronis> Chipaca: ?
<Chipaca> smallville7123: we do not package it, jetbrains does
<Chipaca> pedronis: in the POST route
<pedronis> Chipaca: are we missing a test?
<Chipaca> pedronis: the state you pass to checkConnectivity is locked
<smallville7123> -_-
<pedronis> Chipaca: checkConnectivity and unlocks and relocks
<pedronis> not locks and unlocks
<Chipaca> pedronis: hah. my bad.
<mup> PR snapd#6545 closed: cmd/snap, daemon: make the connectivity check use GET <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6545>
<Chipaca> pedronis: any conclusion on blob vs snapfile vs ...?
<Chipaca> pedronis: wrt #6532
<mup> PR #6532: daemon: allow downloading snaps blobs via .../blobs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6532>
<mup> PR snapd#6162 closed: interfaces/greengrass_support: update accesses for GGC 1.8 <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6162>
<pedronis> Chipaca: no,  was focused on 2.38 things
<pedronis> Chipaca: could you re-review #6079 ?
<mup> PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<Chipaca> mborzecki: 6556 is included in 6079?
<mborzecki> Chipaca: no, i've reverted that patch from 6079
<mborzecki> Chipaca: iirc the plan is snap conenctions for 2.38, then deprecation & hide interfaces in .39
<Chipaca> ok
<Chipaca> i need to step out for a bit, i'll review when i return
<zyga> mvo: one more thing, more core18 / core discovery, one more unhandled problem
<zyga> sorry, forgot to mention
<zyga> but we can chat again when you have time
<zyga> pedronis: on 2nd thought I think snap-confine *does* know the boot base on core
<zyga> pedronis: we  parse os-release and differentiate classic, core18, core-other
<pedronis> zyga: does it use the info though?
<zyga> pedronis: yes
<zyga> and specifically for this choice too
<zyga> I will double check and see if we have any tests
<zyga> but it may be less terrible than we thought last week
<mvo> zyga: lets talk in ~45min again then my head should be a bit less busy
<pedronis> zyga: yes, I see the relevant code now, it's quite spread out
<zyga> pedronis: because of ns hops
<pedronis> hops?
<zyga> pedronis: we look and remember and  then use the fact much  later
<zyga> but yeah
<zyga> joining various namespaces
<pedronis> there's a helper sc_should_use_normal_mode(distro, base_snap_name)
<pedronis> it's used exactly twice
<zyga> yeah, and distro is probed early
<Chipaca> mborzecki: +1 to 6079
<Chipaca> mborzecki: thank you
<mborzecki> Chipaca: thanks for the review!
<mborzecki> will be out for a while, left a note in the forum
<Chipaca> ok, _now_ i'm stepping out for a bit
 * dot-tobias waves
<mup> PR snapd#6558 closed: many: remove unused code (mostly) <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6558>
<pedronis> mvo: you should look at #6549 (there's a question there about when to cover the snapd snap), and also re-review #6322
<mup> PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549>
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6322>
<mup> PR snapd#6559 opened: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <https://github.com/snapcore/snapd/pull/6559>
<pstolowski> pedronis: hey, does this https://pastebin.ubuntu.com/p/tF3X8RV6t9/ more less match the idea re flattening? this is a dump of state with 5 timings, for each timing there are 3 nested timings, flattened per-timing
<pedronis> pstolowski: yes
<pedronis> assuming it works as I would expect
<pstolowski> pedronis: i'll show you an example in a moment
<pedronis> pstolowski: I mean what happens if there is more than one 1 etc
<pedronis> zyga: it's a bit unclear which of/whether your last comments on #6549 should block it
<mup> PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549>
<zyga> pedronis: I don't want to block it yet, it mainly depends on the reaction to my small RFC branch
<pedronis> zyga: we are trying to do 2.38 today or tomorrow
<zyga> pedronis: I see
<zyga> pedronis: I'm happy with 2.38 having this code if you don't object
<zyga> and growing something easier to follow in master
<pedronis> ok
<pedronis> we still need to understand what to do about the snapd snap case
<pstolowski> pedronis: then you have this: https://pastebin.ubuntu.com/p/Bp9gGj7gvz/ (see the first and last nested measurement of each timing)
<pedronis> pstolowski: yes, that's what I would expect
<pstolowski> pedronis: ok, good
<pstolowski> pedronis: and this is how it's used https://pastebin.ubuntu.com/p/5hgwQqHckt/
<pedronis> pstolowski: thx, looks reasonable
<mvo> pstolowski: nice stuff!
 * mvo is very excited about this feature
<mup> PR snapd#6557 closed: tests/main/high-user-handling: fix the test for Go 1.12 (2.37) <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6557>
<mup> PR snapd#6543 closed: Add force_turbo to the list valid pi config keys <Created by sergey-borovkov> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6543>
<mborzecki> re
<pstolowski> pedronis, mvo thanks for quick feedback, in that case i'll polish it a bit and propose a base PR
<mvo> pstolowski: sounds great
<Chipaca> we should split spread tests into "distros that often break because of mirrors and other related bull" and "real distros :-p", and use travis's can-fail flag for the former
<Chipaca> allow_failures i mean
<pedronis> mvo: it seems I created confusion with my comment about Active
 * zyga takes the dog out 
<zyga> mvo: I pushed an update to https://github.com/snapcore/snapd/pull/6498
<mup> PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
<mborzecki> damn, sudden power loss :/
<Chipaca> I remember having to have an UPS for my router :-)
<Chipaca> mborzecki: thank you for pointing out the changing of publisher across revisions btw
<mborzecki> Chipaca: np
<Chipaca> it would've been a regression
<mborzecki> Chipaca: my router & nas are under a ups already, but the desktop isnt :P
<Chipaca> I've got these nifty computers with an integrated UPS
<mborzecki> call 'em laptops?
<Chipaca> :-D
<ijohnson> hey folks if I wanted to see which commit of snapd the edge channel of the core snap was built from, is this doable? i.e. I currently have 2.37.4+git1173.2c7e249~ubuntu16.04.1 but 2c7e249 doesn't seem to be a commit in snapd
<pedronis> ijohnson: there is some indirection, it is built from here: https://git.launchpad.net/snapd-vendor/commit/?id=2c7e24947044fd67c166871d81374dcee76b135c
<ijohnson> ah I see, so then that repo builds into the PPA here https://code.launchpad.net/~snappy-dev/+archive/ubuntu/edge which is then what goes into this: https://code.launchpad.net/~snappy-dev/+snap/core which is the core snap released, correct?
<mvo> zyga: thank you for the update to 6498
<lborda> Question: I have two snaps and I need them to talk each other via redirection to sterr and stout (using example juju status > file.log ) from another classic snap. Currently I get apparmor errors (DENIED) is there a slot, plug or interface I should use to make them accept the syscall ?
<lborda> looks like I got some help here: https://github.com/lborda/snap-bug/issues/1 will give it a try
<lborda> sergiusens, ^ ty
<jdstrand> lborda: the denial says you are doing something different than what you describe. perhaps use a pipe of /dev/stderr /dev/stdout?
<jdstrand> err
<jdstrand> pipe or* /dev/stderr and /dev/stdout?
<lborda> jdstrand, to explain exactly what I am doing is: I am running snap-bug which call popen(juju status) and using juju status > log.file from it... should I not be using that ? see the reproducer there... I am using popen for that... https://github.com/lborda/snap-bug/blob/master/collect.py
<jdstrand> yes, that is what I figured. the problem isn't the snaps, but snap-confine. they may be two classic snaps that are effectively unconfined, but they are going through a strictly confined snap-confine
<jdstrand> (when you call the second snap)
<jdstrand> snap-confine doesn't have access to log.file, as can be seen from the denial
<jdstrand> and it needs it due to fd inheritence
<mborzecki> jdstrand: hi, when you have some time, could you take a look at https://github.com/snapcore/snapd/pull/6485 ?
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<jdstrand> lborda: instead of specifying stdout and stderr as files, perhaps use Popen.communicate to get the output, then write that out yourself
<jdstrand> there are probably other ways to fix it
<jdstrand> mborzecki: ack
<mborzecki> jdstrand: thanks!
<lborda> jdstrand, I can give it a try. looks like a workaround... is this  bug related to my issue ? https://bugs.launchpad.net/snapd/+bug/1815869
<mup> Bug #1815869: Command of classic snap fails with denial when output is redirected <snapd:Fix Released by zyga> <https://launchpad.net/bugs/1815869>
<jdstrand> lborda: the underlying issue (fd inheritence with apparmor) is the same, but that is a different issue
<jdstrand> lborda: this has some detail: https://forum.snapcraft.io/t/snapd-2-32-breaks-live-server-installer/4597/10
<jdstrand> lborda: but put more siccinctly, it is a limitation that should improve with time
<jdstrand> succinctly*
<lborda> jdstrand, yes agree different issue same underlying issue...
<lborda> jdstrand, agree well let me do some attempts here... I am working on getting cdk and juju log output so we can gather logs for later troubleshooting... having access to the $USER env is a must
<jdstrand> lborda: the individual snaps have that. snap-confine does not. it is the way you are gathering the output that is causing snap-confine to become entangled. snap-confine has access to /dev/stdout and /dev/stderr, so if you can adjsut your calls to use those, you should be fine
<jdstrand> which communicate() should do (untested)
<lborda> jdstrand, yes looks like it! :) give me a few to make changes here
<sborovkov> hi, is there any apparmor stuff still working when snap is installed in devmode?
<sborovkov> after I upgraded Qt to the latest version in my snap, I can't get qt webkit running for whatever reason, even though it's still at the same version and only qt's version went up (and all other libraries it comes with)
<sborovkov> it works fine on the raspbian with 0 issues
<sborovkov> does not start even in devmode on the core
<zyga> re
<zyga> mvo: thank  you  :)
<zyga> jdstrand: hello :-)
<zyga> jdstrand: I sent a small patch to snap-confine, your review  is required https://github.com/snapcore/snapd/pull/6498
<mup> PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
<mup> PR # closed: snapd#5644, snapd#5822, snapd#5915, snapd#6079, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6381, snapd#6401, snapd#6404,
<mup> snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6492, snapd#6498, snapd#6502, snapd#6532, snapd#6539, snapd#6541, snapd#6549, snapd#6553, snapd#6556, snapd#6559
<mup> PR # opened: snapd#5644, snapd#5822, snapd#5915, snapd#6079, snapd#6098, snapd#6108, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360, snapd#6367, snapd#6381, snapd#6401, snapd#6404,
<mup> snapd#6410, snapd#6418, snapd#6436, snapd#6485, snapd#6491, snapd#6492, snapd#6498, snapd#6502, snapd#6532, snapd#6539, snapd#6541, snapd#6549, snapd#6553, snapd#6556, snapd#6559
<Chipaca> sborovkov: in devmode, apparmor is set to allow everything but log
<Chipaca> sborovkov: seccomp, also
<sborovkov> Chipaca, so basically nothing is forbidden? the only messages I see bbefore it crashes is that it can't create some kind of udev monitor and send some dbus commands to NetworkManager which is followed by "could not create AF_NETLINK socket" and a crash of process
<Chipaca> sborovkov: nothing is forbidden by apparmor / seccomp, but the view of the system remains the same as in strict
<sborovkov> I guess the cause should be somewhere in there then :(
<Chipaca> sborovkov: don't you get anything in the system logs?
<sborovkov> all I see are those errors, I pasted above, it crashes right after bbeing unable to create AF_NETLINK socket
<sborovkov> I thought it'd work in the devmode at least but that's not the case
<sborovkov> I guess I will try to get that process running in gdb.
<Chipaca> sborovkov: snap run --gdb ?
<sborovkov> I did not even know that was a thing now :)
<Chipaca> sborovkov: also 'snap run --strace' :-)
<Chipaca> and trace-exec â¦
<Chipaca> it's getting all fancy and grown-up
<sborovkov> that's pretty cool, not sure it's going to work for me though - my main process is not crashing
<sborovkov> webb process does
<sborovkov> and I have done bind mount of the directory containing modified snap so gdb spews out some errors because of that I guess
<zyga> popey: hey, sublime-text  doesn't work on 18.10
<zyga> I'm not sure what happened because it used to work
<om26er> could anyone with appropriate permissions please click "retry" there ? https://launchpad.net/~build.snapcraft.io/+snap/c7f9e9a2d76707f5da7a8175b964b834/+build/482950
<cjwatson> om26er: done
<om26er> apparently the upload to store failed and I can't retry (and I am not admin on that said repo to force a rebuild)
<om26er> cjwatson, thanks :)
<mup> PR snapd#6560 opened: cmd/snap-confine: drop uid from random /tmp name <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6560>
<mvo> 6549 needs a second review
<mup> PR snapd#6079 closed: cmd/snap: `snap connections` command <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6079>
<pedronis> \o/
<mvo> pstolowski|afk: I will merge 6322 - I had some nitpicks (mostly tests) but can all be followups
<mvo> pedronis: want to look at 6322 again before it goes in ?
<mvo> 6492 also needs a second review
<pedronis> mvo: 6322 should be fine if you are ok with
<pedronis> mvo: yes, 6492 is next on my list
<mvo> pedronis: I think you did 6492 already :)
<pedronis> mvo: ah, yes, was confusing it with another one
<mvo> pstolowski|afk: nice job on 6322 btw, I find this easier to read than the old code
<mup> PR snapd#6322 closed: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6322>
<mvo> pedronis: ok, I hope I did not merge too early then :/
<mup> PR snapd#6561 opened: cmd/snap-confine: chown private /tmp to root.root <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6561>
<zyga> jdstrand: I opened one more cleanup from my review of older notes ^
<zyga> pedronis: design quesion, should the contents of private /tmp directory be preserved across  "snap  refresh" of said snap?
<pedronis> zyga: you mean in a world where we are sure nothing runs of the snap during the refresh?
<zyga> pedronis: yes
<zyga> pedronis: should it retain  contents across refresh?
<zyga> pedronis: today it doesn't but I don't think that was deliberae
<zyga> *deliberate
<zyga> pedronis: it could easily do so
<pedronis> zyga: that's interesting because I would have expected the reverse
<zyga> pedronis: why?
<zyga> pedronis: or sorry, reverse  as in, it is retained?
<pedronis> because if stuff can be running, how can we delete its content?
<zyga> we don't technically delete the contents
<pedronis> it's a tmpfs in the namespace?
<zyga> ah, wait, I think I was mistaken a little, the conditions are more complex
<zyga> it's not a tmpfs, it's a real directory in /tmp
<zyga> we "delete" it when the base snap changes
<zyga> but retain it while refreshing
<zyga> I was thinking of refreshes but it is really the base that matters here, not the app
<zyga> so the question, asked properly is: should we retain the /tmp that snaps see when the base has refreshed (we currently do not)
<pedronis> I need to go have dinner, seems I need to understand this more
<zyga> pedronis: sure, it's not urgent, just observation from the  two tiny patches I posted
<zyga> jdstrand: hey, I posted https://github.com/snapcore/snapd/pull/6559 with some apparmor-y things in relation to your 2.13 work
<mup> PR #6559: pkg/apparmor: scratch documentation of apparmor <Created by zyga> <https://github.com/snapcore/snapd/pull/6559>
<zyga> jdstrand: I understand 2.13 is urgent  so I don't want to block your PR but I would like to know what you think about the ideas I posted
 * zyga EODs
<pedronis> mvo: I tried to answer your naming nitpick, let me know
<mup> PR snapcraft#2494 opened: sources: handle network request errors <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2494>
#snappy 2019-03-05
<mwhudson> er does cmd/snap progress reporting essentially assume that any task where total > 1 is downloading something?
<mwhudson> that sounds like a chipaca question
<mwhudson> behold my snazzy progress bar! https://asciinema.org/a/aTbeNl5BnF2jtbWlXZT8ed7eE
<zyga> Hello
<mborzecki> morning
<zyga> hey mborzecki  :-)
<zyga> how are you doing>?
<mborzecki> zyga: hey
<mborzecki> zyga: fine, 'connections' landed yesterday :)
<zyga> I saw, nice work  :)
<mborzecki> zyga: hm need to figure out why the spread test fails in #6485
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<mborzecki> zyga: the small s-c patches are waiting for perdronis right?
<zyga> mborzecki: and jdstrand
<zyga> mborzecki: I'm making breakfast for kids now
<zyga> re
<zyga> mborzecki: looks l like core18 + snapd not working
<zyga> mborzecki: did you try to get a debug shell?
<zyga> though given that this is prepare it  may be broken too
<mborzecki> zyga: which pr?
<zyga> perhaps  we need  to adjust that code thttps://github.com/snapcore/snapd/pull/6485
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<zyga> so that we bail out early if snap is not on path
<mborzecki> zyga: stuck looking at some review now
<zyga> ok
<mborzecki> zyga: but that's interesting
<pstolowski> mornings
<mvo> good morning pstolowski
<zyga> Hey PaweÅ, Michael
<mborzecki> pstolowski, mvo: morning guys
<mvo> hey zyga and mborzecki !
<mvo> 6492 needs a second review (its on the 2.38 critical path)
<mvo> pedronis: 6356 looks good to me, unless you want to do something with it I will merge it
<mup> PR snapd#6560 closed: cmd/snap-confine: drop uid from random /tmp name <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6560>
<mup> PR snapd#6561 closed: cmd/snap-confine: chown private /tmp to root.root <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6561>
<pedronis> mvo: it's fine to merge for me,  but make sure people are aware you would like follow ups
<mvo> pedronis: I will wait for john - followups are not strictly needed, its mostly ideas/suggestions nothing strictly required
<pedronis> ok
<mborzecki> 5.0 kernel is already in testing repo in arch, hope we don't make any assumptions about kernel versions in our code
<pedronis> mborzecki: we compare it in a couple of places to see if it's higher than some version
<pedronis> but usually there's a distro check as well
<pedronis> mborzecki: I see code like in apparmor backend.go seccomp backend.go and sanity/version.go
<pedronis> they should be fine afaict
<mborzecki> yeah
<mvo> mborzecki: when we compare we use the semantic versions compare that follows the debian rules which the kernel honors currently so we should be good
<pedronis> mvo: you left some optional comments also in #6322 for pstolowski
<mup> PR #6322: overlord/hookstate: apply pending transaction changes onto temporary configuration for snapctl get <Complex> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6322>
<pstolowski> pedronis: i noted these comments and will address in a followup, these were cosmetics
<zyga> Hey, with dog at vet, Iâll start around 10 today
<zyga> Thanks for merging mvo
<doko> how is mvo merged?
<zyga> Mvo is very dedicated, one could say merged with is duties ;-)
<mvo> haha
<mvo> pedronis: I addressed the feedback in 6381, the one question is if I should remove "setDeviceFromModelAssertion" again from that PR and move it into a later one
<mup> PR snapd#6539 closed: cmd, daemon: split out the common bits of mapLocal and mapRemote <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6539>
<mvo> 6492 needs a second review
<mvo> Chipaca: I will merge 6356, there are some nitpicks/ideas in my review but feel free to ignore or do in a followup
<Chipaca> hmm
 * Chipaca looks
<Chipaca> mvo: ok :-)
<mwhudson> Chipaca: for some reason i think you might like this https://asciinema.org/a/aTbeNl5BnF2jtbWlXZT8ed7eE
<mvo> zyga: you mentioned you want to re-review 6549, could you please make it a priority? I would like to finalize 2.38~pre1 this morning
<Chipaca> mwhudson: nice!
<Chipaca> mwhudson: how much would that break if the snap progress bar took up more lines?
<mwhudson> Chipaca: not at all, it's pinging v2/changes/$id
<Chipaca> mwhudson: ah, it's doing its own thing? ok
<joedborg> jdstrand: I'm unable to pause them due to this issue https://github.com/canonical-websites/build.snapcraft.io/issues/623
<Chipaca> mwhudson: using ansimeter?
<mwhudson> Chipaca: no, urwid has it's own process bar thingy
<zyga> mvo: ack
<zyga> mvo: let me look now
<zyga> wow, it's windy today
<mwhudson> Chipaca: you can tell it's not ansimeter becuase it's not reporting time remaining :)
<Chipaca> ah and it says MiB
<Chipaca> ok
<mvo> mwhudson: nice indeed
<Chipaca> mwhudson: basically, you can have more than 1 thing in Doing
<mwhudson> Chipaca: wait.go / ansimeter seems to assume that anything that has total > 1 is downloading something
<mup> PR snapd#6356 closed: overlord/snapstate: during refresh, re-refresh on epoch bump <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6356>
<Chipaca> mwhudson: and currently we just report the first one
<Chipaca> which is 'fun'
<mwhudson> Chipaca: ah!
<mvo> did I mention that 6492 needs a second review ? *please* ?
<mwhudson> i guess it wouldn't be so hard to cope with that in my code
<mwhudson> Chipaca: is this something that happens in practice?
<Chipaca> mwhudson: that's why if you install something that needs to download a content snap, it'll stay in 'connecting' for ages
<mwhudson> ah ha
<Chipaca> mvo: i'll do it
<mwhudson> so if i was refreshing to a version of subiquity that depended on core18, for example...
<mvo> Chipaca: thank you!
<zyga> mvo: I can look as well after apparmor review
<mvo> zyga: appreicated, but if john looks that is enough, its relatively small and already has a review :) thanks still!
<zyga> ok
<Chipaca> mvo: in 6492 you say you "added the check for .Active", but I don't see it
<Chipaca> mvo: ah, i see the last commit now, ok
<Chipaca> mvo: we don't block disabling snapd though
<Chipaca> mvo: so you could have snapd installed and disabled
<Chipaca> mvo: (add TypeSnapd to snapstate's canDisable)
<Chipaca> mvo: why am i not writing this on github
<mup> PR snapd#6562 opened: timings: base API for recording timings in state <Created by stolowski> <https://github.com/snapcore/snapd/pull/6562>
<pedronis> Chipaca: lots of things break, we don't check for Active core either
<Chipaca> pedronis: core _is_ in the list that can't be disabled
<pedronis> Chipaca: is it?
<Chipaca> []snap.Type{snap.TypeGadget, snap.TypeKernel, snap.TypeOS}
<pedronis> it wasn't for a long time
<Chipaca> core is TypeOS
<Chipaca> we don't check TypeBase
<pedronis> anyway sounds a different problem
<pedronis> we do need to switch to a type
<pedronis> for snapd
<Chipaca> pedronis: ?
<Chipaca> snapd is TypeSnapd already
<pedronis> Chipaca: it isn't
<pedronis> Chipaca: look at snapcraft.yaml
<Chipaca> dang
<Chipaca> we _have_ TypeSnapd
<pedronis> or do snap info snapd
<pedronis> Chipaca: we do
<pedronis> but the store and snapcraft weren't on the plan
<Chipaca> are we dum
<Chipaca> :-(
<Chipaca> we r dum
<pedronis> sounds we need to push
<pedronis> Chipaca: I created a card for mvo
<Chipaca> oh no! i have only one PR up!
 * Chipaca strives to fix this
<pedronis> Chipaca: you can write docs instead
<Chipaca> pedronis: :-)
<Chipaca> pedronis: I also have a followup to the snapinfo pr that just landed, that i'm running spread on locally now that it's rebased
<mup> PR snapd#6492 closed: snapstate: restart into the snapd snap on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6492>
<mborzecki> wonder whether we should really fail to initialize seccomp backend when snap-seccomp version-info does nto match the patter or is otherwise invalid
<pedronis> mborzecki: we control both sides, no?
<mborzecki> pedronis: yes, so it's unlinkely to happen
<mborzecki> pedronis: however unlikely, should this fail, backend will not initialize and snapd won't start
<pedronis> mborzecki: we have many (slightly unlikely) things that will make snapd not start
<mborzecki> ok, so maybe not a problem after all
<mborzecki> especially since both ends are in sync
<pedronis> I mean, if we didn't control the other side, I would agree
<pedronis> that being robust is more important
<pedronis> but if we do, something is off anyway
<mborzecki> agreed
<mup> PR snapd#6563 opened: ctlcmd/tests: tests tweaks (followup to #6322) <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6563>
<pstolowski> mvo: ^ trivial per your comment to 6322
<mvo> pstolowski: thanks, I have a look in a wee bit
<zyga> jdstrand: reviewed https://github.com/snapcore/snapd/pull/6549#pullrequestreview-210608273
<mup> PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6549>
<mvo> zyga: I answered some questions, please let me know if its sufficient for merge or if you would prefer more info (it seems the open issues can be done in a followup maybe?)
<zyga> looking
<zyga> mvo: replied
<zyga> mvo: can we add the snapd part and then merge it?
<zyga> mvo: unless you think my questions about profileIsRemovableOnCoreSetup warrant more time
<mvo> zyga: good question, I'm not super happy with the function but I played around and all my attempts to change it just made it different but not "better"
<zyga> mvo: I'd split it to spearate checks per line
<zyga> with comment that explains what is being matched
<zyga> unlike one very long line
<mvo> zyga: if you have an idea, could you please do it and add a comment what it would look like?
<zyga> sure
<zyga> doing that now
<mvo> ta
<zyga> mvo: I tried and none of my ideas were any better
<zyga> mvo: I'll defer to you in case you want to land and release
<mvo> zyga: thank you, I had the same experience, might be worthwhile to add a note in the PR (or a FIXME in the code) that it would be nice to find something nicer looking
<mvo> zyga: but otherwise I think we are good to merge and can polish in a followup :) (sorry, a bit in OCD mode to get a first 2.38~pre1 out)
<zyga> mvo: there's always .1
<zyga> ;-)
<zyga> (right?)
<mvo> zyga: *cough*
<mvo> zyga: in this case a ~pre2 ,)
<zyga> I, for one, embrace the trigger happy merge because we need to get faster, not slower
<mborzecki> damn spread snap-seccomp spread test, it's passing on arch nowm but failing on ubuntu still for some reason
<zyga> mborzecki: hmm?
<mborzecki> and debian sid doesn't build because we're patching the source code
<mborzecki> zyga: tests/regression/lp-1805838 is failing with the seccomp branch, even with the fixes i added
<zyga> oh
<zyga> that's serious
<pedronis> yes, we do need to patch the patches
<pedronis> at least now they are in the same tree
<mvo> mborzecki: what PR is that?
<mborzecki> mvo: #6485
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<mborzecki> mvo: no worries, i'll update those, but it took a while to figure out what's happening there
<mvo> mborzecki: thank you!
<mup> PR snapd#6549 closed: apparmor: support AppArmor 2.13 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6549>
<mborzecki> btw. fedora packaging does sed to place that libseccomp-go import, we should probably use the same patch as for debian there instead
<pedronis> mvo: do we need to keep the configure hook in core in sync with the code in snapd?  (it's mostly not used on classic), and if you get a new core you get also a new snapd
<pedronis> mvo: Q is about this:  https://github.com/snapcore/core/pull/102
<mup> PR core#102: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <https://github.com/snapcore/core/pull/102>
<mvo> pedronis: I think we don't, we do it all internally now, don't we?
<pedronis> mvo: yes, that's why the question, I wonder if we can drop it now completely? or make it empty?
<pedronis> mvo: we needed for a while for reverts, during the transition
<mvo> pedronis: yeah, I think making it empty is the right move
<mvo> pedronis: lets add a card, should be trivial
<pstolowski> dammit, power outage here
<pedronis> mvo: https://trello.com/c/IakOtfSS/183-replace-hooks-configure-in-core-with-an-empty-one
<zyga> brb
<mvo> pedronis: ta
<mvo> pedronis: https://github.com/snapcore/snapd/blob/release/2.38/packaging/ubuntu-16.04/changelog has the 2.38~pre1 changelog
<pedronis> mvo: thx, will look at in a little bit
<mvo> pedronis: no rush, its a ~pre1
<mup> PR snapd#6564 opened: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/6564>
<pedronis> mvo: I looked at the new things since the last list, I was aware of most of them, I also double checked a couple of snap-confine stuff
<mborzecki> pstolowski: any storms cooming your way today?
<pstolowski> mborzecki: nope
<mborzecki> mvo: zyga: i've updated the seccomp patch, please take a look if that's fine by you or should i add a new one on top of the current series
<zyga> mborzecki: sure, give me a sec to look
<mborzecki> pstolowski: well, the season has already started :P
<pstolowski> mborzecki: in that case it's a maintenance in the nearby area
<zyga> mborzecki: hmmm
<zyga> mborzecki: snap-seccomp version must go into system key, otherwise snapd update with new snap-seccomp won't trigger a regeneration
<mborzecki> zyga: build id will change
<mborzecki> oh, w8
<mborzecki> hm
<zyga> oh, perhaps that is sufficient?
<mborzecki> nvm, need to look at it again
<pedronis> mborzecki: I mentioned something related in the PR
<mborzecki> off to pick up the kids
<zyga> mborzecki: review sent
<mup> PR snapd#6324 closed: Fixing socket permissions on 4.15 kernels  <Created by kubiko> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/6324>
<jdstrand> zyga: I think I answered your questions in PR 6549
<mup> PR #6549: apparmor: support AppArmor 2.13 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6549>
<jdstrand> mvo, zyga: fwiw, I rewrote that function a bunch of times too. see my comment on why I landed on what I did
<jdstrand> joedborg: ok, can you at least make a fix to it and say that it 'architectures: [ all ]' (it doesn't ship any binaries). that will make it easier to deal with reviews, but you should also request classic confinement in the forum since nothing passes review atm
<joedborg> okay jdstrand
<pedronis> jdstrand: I asked a question there
<zyga> jdstrand: thank you, looking
<jdstrand> pedronis: answered
<zyga> jdstrand: thank you for the answers
<zyga> jdstrand: note that some of my questions and the rfc branch was trigged by my unfamiliarity with 2.13
<jdstrand> I rewrote this a bunch of ways and like mvo couldn't come up with something better (in my mind). I picked one; classic bikeshed
<jdstrand> happy to do a followup PR if there is something clearly better
<zyga> jdstrand: tumbleweed is using 2.13 now so I'm learing about it
<jdstrand> zyga: it really isn't that different
<zyga> .features file is fun
<zyga> lisp but with braces instead of parentheses ;)
<jdstrand> zyga: the only thing that 2.13 is different about is it creates a hash of the features and kernel abi as a subdir of the cache dir and puts everything in there
<zyga> jdstrand: oh, interesting, so 2.13 already has cache populated with snapd stuff
<jdstrand> zyga: the unified directory is not dictated by 2.13. that is just something Debian did, but anyone could have
<zyga> jdstrand: unified directory?
<zyga> do you mean /var/cache/apparmor?
<jdstrand> zyga: if tumbleweed has 2.13 and is generating snap policy, I think you'll find that you cannot remove snaps on tumbleweed right now
<zyga> jdstrand: on TW /var/cache/apparmor/$cache.0/ has stuff like snap-confine.core.1234
<zyga> oh!
<zyga> jdstrand: fun
 * zyga tries
<jdstrand> zyga: yes, /var/cache/apparmor
<jdstrand> zyga: the cache location is still chosen by the distro. in Debian and soon to be ubuntu 19.04, it is /var/cache/apparmor. it might be that elsewhere.
<zyga> cannot remove vlc on TW https://www.irccloud.com/pastebin/7HWJOWvZ/
<zyga> standup time
<zyga> but I will dig in a moment
<jdstrand> zyga: the choosing of the cache location is separate from the forest behavior is all I'm saying. the fact the Debian combined /etc/apparmor.d/cache and /var/cache/apparmor into on unified dir is separate from 2.13
<zyga> Chipaca: ^ is this expected?
<zyga> jdstrand: ah, I see now
<zyga> jdstrand: thank you for this
<jdstrand> np
<zyga> jdstrand: I am iterating on responses and patches based on your feedback, thank you for that as well
<Chipaca> zyga: no, that's not expected
<jdstrand> zyga: I maintain that it is an isolated changed in just Unload that breaking out a bunch of code and added machinery is probably not worth it
<jdstrand> zyga: but I'll let others decide that
<jdstrand> adding*
<Chipaca> zyga: what does âfind /var/snap/vlc -lsâ print out
<jdstrand> zyga: note that the vls removal is a different error than what I saw with 2.13 apparmor on Ubuntu. It seems you are hitting a different error earlier than when snapd tries to remove the cache files but can't
<jdstrand> vlc*
<zyga> zyga@yantra:~> sudo find /var/snap/vlc -ls
<zyga>   2234362      4 drwxr-xr-x   3  root     root         4096 mar  5 15:01 /var/snap/vlc
<zyga>   2367702      4 drwxr-xr-x   2  root     root         4096 lis  6 22:06 /var/snap/vlc/555
<zyga> ack
<Chipaca> zyga: so the question is why did os.RemoveAll fail to remove that
<zyga> Chipaca: note that this is reproducible!
<zyga> undo works
<zyga> so ... good?
<zyga> https://www.irccloud.com/pastebin/qdZMzJ6Q/
<Chipaca> zyga: undo of remove does not work
<zyga> it's interesting that we snap disconnect
<zyga> why do we do that? CC pstolowski
<pstolowski> zyga: because of hooks that may run on the other end of connection
<zyga> aha
<pstolowski> (interface hooks)
<zyga> we should be able to optimize away the ones that don't have any
<pstolowski> zyga: +1
<Chipaca> zyga: so the question is why do you have revision 555 there
<zyga> dunno
<Chipaca> (also maybe we should be more resilient about this)
<zyga> why cannot snapd remove it?
<Chipaca> zyga: because it doesn't try to
<Chipaca> it doesn't expect that to be there
<zyga> aaah
<pstolowski> zyga: actually we probably don't create hook tasks if not needed already
<zyga> I see
<Chipaca> zyga: it removes all the revisions, and then the parent
<zyga> pstolowski: I'm pretty sure disconnecting stuff from vlc is not needed when you remove the snap
<zyga> and all the connections go to core
<Chipaca> zyga: vlc has mpris which doesn't go to core, fwiw
<zyga> Chipaca: yes but mpris is not connected
<zyga> https://www.irccloud.com/pastebin/tJtbkHRy/
<zyga> Chipaca: it's from october
<zyga> but this is my dev machine so anything is possible
<Chipaca> zyga: snap list --all ?
<zyga> tried it, not there
<Chipaca> I can't find an obvious way of repro'ing it
<Chipaca> maybe there's a cleanup missing
<Chipaca> ?
<zyga> no worries, we know it may happen
<zyga> shall I report it for tracking:
<Chipaca> that is, a refresh or install that fails and doesn't un-mkdir?
<zyga> ?
<Chipaca> hah!
<Chipaca> zyga: yes indeed we do!
<Chipaca> zyga: o/s/b/link.go, updateCurrentSymlinks
<Chipaca> zyga: happily does a MkdirAll(snap.DataDir())
<Chipaca> zyga: and then more stuff
<Chipaca> zyga: and that more stuff can fail
<Chipaca> zyga: and there is no clean up of the mkdir on fail
<zyga> good
<zyga> I'm happy we're happy now :)
 * Chipaca looks around
<Chipaca> we are?
<zyga> shallow eyeballs all that stuff
<mup> PR snapd#6565 opened: snap: remove obsolete license-* fields in the yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/6565>
<Chipaca> zyga: i'll push a pr in a bit
<Chipaca> first i need to go move my car
<Chipaca> oh! mvo: tomorrow I need to go to do an anual paperwork thing for kid #2 (kid #1's is in a couple of weeks), probably won't make it to the standup even
<Chipaca> i'll file for a half-day later
<pedronis> jdstrand: hi, could you adjust the summaries in #5644 , then it could be landed as per agreement
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<pedronis> assuming the tests follow-up
<jdstrand> pedronis: so, I was wanting to ask you about that. I did make some changes before your last comment ot make changes
<jdstrand> pedronis: what is it you are looking for exactly?
<jdstrand> (and yes, when tests can be written, I'll write them)
<pedronis> jdstrand: https://github.com/snapcore/snapd/pull/5644/files#r212674777
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<jdstrand> pedronis: oh, that change. ack. I thought this was something else
<mvo> Chipaca: thanks
<mvo> Chipaca: no worries
<pedronis> jdstrand: to be fair, I see we use your spelling quite a bit
<pedronis> well, not quite a bit
<pedronis> but in a few cases
<pedronis> degville: interestingly there are a few things that are document for snapcraft.yaml but not snap.yaml :)
<pedronis> degville: https://forum.snapcraft.io/t/snapcraft-app-and-service-metadata/8335
<degville> pedronis: yeah, I've been pinged about updates to snapcraft.yaml  but didn't think to push them back to the snap.yaml doc.
<zyga> Lunch
<zyga> Chipaca: thank you! :-)
<pedronis> jdstrand: pulseaudio is interesting because the summary in the code talks about operating as the service, but the doc doesn't https://forum.snapcraft.io/t/the-pulseaudio-interface/7906
<pedronis> jdstrand: while I would, sort of, expect the reverse
<pedronis> jdstrand: I mean the simple summary to explain the plug/consumer POV, the "extended" docs to explain that the slot can be implemented by apps
<mborzecki> zyga: pedronis: under the assumption that snapd and snap-seccomp are in sync, i think we don't need to include snap-seccomp version in version-info, just the library version and the hash are enough
<zyga> mborzecki: what about system-key?
<zyga> mborzecki: I agree with your statement
<zyga> mborzecki: but system-key correctness is essential for correctness
<mborzecki> zyga: we still need that, i.e. put version-info in system-key
<pedronis> ?
<mborzecki> zyga: what i mean we don't necessarily need to include the compiler version in the output
<pedronis> I'm missing something
<mborzecki> (snap-seccomp being the compiler)
<zyga> pedronis: I think mborzecki is working with the assumption that we have snapd build-id in system-key
<zyga> though
<zyga> to be fair
<zyga> I think it's not correct
<mborzecki> which we have
<zyga> once we get reproducible builds
<zyga> snapd can remain unchanged
<zyga> while snap-seccomp can change
<pedronis> yes
<zyga> so in that sense it's not fully sufficient
<pedronis> that's the part that is delicate
<pedronis> I sort of think we are trying to avoid adding a number
<pedronis> at the expense of subtle bugs
<mborzecki> hm maybe we should then use the build-id of snap-seccomp too
<zyga> pedronis: I agree
<zyga> pedronis: let's do it cleanly
<zyga> mborzecki: that would be okay
<mborzecki> so version-info would be: <build-id> <library-version> <hash>
<zyga> and I prefer the build-id over a version
<zyga> versions are easy to misuse
<pedronis> that's fine, in the end this an optimisation over always regen
<mborzecki> yup
<mborzecki> ok, build-id it is
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6563
<mup> PR #6563: ctlcmd/tests: tests tweaks (followup to #6322) <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6563>
<pstolowski> zyga: k, merging, thx
<mup> PR snapd#6563 closed: ctlcmd/tests: tests tweaks (followup to #6322) <Simple ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6563>
<jdstrand> pedronis: ok, https://github.com/snapcore/snapd/pull/5644 updated. note, it is for master/2.38 and *not* for 2.38 (I need time to do the other supporting work in electron, snapcraft, etc, etc)
<jdstrand> meh
<mup> PR #5644: interfaces: add audio-playback/audio-record and make pulseaudio manually connect <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5644>
<jdstrand> master/2.39*
<jdstrand> this is 2.39 material, not 2.38 (so many typos this morning :)
<jdstrand> but not in the PR! ;)
<zyga> jdstrand: I nuked stdio from https://github.com/snapcore/snapd/pull/6498
<mup> PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
<jdstrand> ack, thanks
<mvo> sil2100: https://github.com/snapcore/core/pull/103 is probably something for you :)
<mup> PR core#103: hooks: apt warning should return an error <Created by townsend2010> <https://github.com/snapcore/core/pull/103>
<sil2100> mvo: hey! Oh, it's for core?
<mvo> sil2100: yeah
<mvo> sil2100: oh, sorry
<sil2100> But yeah, it makes sense :)
<sil2100> +1
<mvo> sil2100: yeah, its for core, I guess that means still our turf
<mvo> sil2100: sorry, ENEEDMORETEA :)
<mup> PR core#103 closed: hooks: apt warning should return an error <Created by townsend2010> <Merged by mvo5> <https://github.com/snapcore/core/pull/103>
<sil2100> mvo: hm, do we actually have a warning wrapper like this in core18? Would have to check
 * sil2100 is too deep in point releases in the last weeks
<mvo> sil2100: oh, indeed - are they all done now? or one more to go?
<ChrisTownsend> mvo: Hey, thanks for merging that.  It will help us on Multipass and our support for core.
<ChrisTownsend> I didn't see an analogous script in the core18 code though.
<sil2100> One in progress, hopefully the last one ;)
<mvo> ChrisTownsend: thank you! we may need to add one for core18 too, I will sync with sil2100  on that (but no worries, will also exit 1)
<ChrisTownsend> mvo: Sure, glad to contribute:)
<mup> PR snapd#6566 opened: interface: avahi-observe: Fixing socket permissions on 4.15 kernels wâ¦ <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/6566>
<jdstrand> mvo: hey, just as a heads up, I don't have any policy updates for 2.38 other than getting ^ in for ondra
<ondra> jdstrand thank you :)
<jdstrand> ondra: you're welcome. I owed it to you for the delay in the PR review ;)
<ondra> jdstrand no worries, it only came back when ogra started to use 4.15 kernel on some of his new boards
<jdstrand> cool
<jdstrand> glad it hasn't been a persistent pain point
<ogra> yeah, i have a bunch of new rockchip boards (and images)
<ogra> using ubuntu-bionic.git (and -disco) for the kernels
<jdstrand> neat
<Chipaca> mvo: you around?
<Chipaca> zyga: v
<zyga> v?
<zyga> ah
<zyga> incoming :)
 * Chipaca waits for mup
<mup> PR snapd#6567 opened: overlord/snapstate/backend: make LinkSnap clean up more <Created by chipaca> <https://github.com/snapcore/snapd/pull/6567>
<Chipaca> zyga: ^
<zyga> heh :)
<Chipaca> zyga: there's still a bug there, as pointed out in the pr
<pedronis> ondra: hi, btw you still a couple of PRs open where jdstrand left feedback asking changes
<Chipaca> and it might be something that's impacting people
<Chipaca> because, it aligns with some funny "why is it thinking it needs to boot this" errors
<ondra> pedronis yep, on my list. I was on hols and then tradeshow and only back in the office this week
<pedronis> ondra: ok
<zyga> break, time to take the dog out again
<mvo> Chipaca: in meetings
 * Chipaca hugs mvo 
<mvo> Chipaca: how can I help you?
<Chipaca> mvo: wondering if there's an easy way to 'undo' boot.SetNextBoot(info)
<Chipaca> mvo: in https://github.com/snapcore/snapd/pull/6567/files#diff-1fdad998bbd61f4345491c0b17b6585eR115
<mup> PR #6567: overlord/snapstate/backend: make LinkSnap clean up more <Created by chipaca> <https://github.com/snapcore/snapd/pull/6567>
<mvo> Chipaca: I think so, just unsetting snap_try_core should be enough
<mvo> Chipaca: still in  a meeting so a bit terse
<Chipaca> mvo: no worries :-)
<mup> PR snapd#6568 opened: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap <Created by stolowski> <https://github.com/snapcore/snapd/pull/6568>
<kenvandine> mborzecki: hey, i'm playing around with parallel installs and ran into an issue.  mvo said i should raise it here with you
<kenvandine> i installed gedit from edge as gedit_master
<kenvandine> the gtk-common-themes content interfaces all connected fine
<kenvandine> but the gnome-3-28-1804 content interface didn't
<kenvandine> i manually connected it and it seems to have failed
<Chipaca> kenvandine: what's 'snap tasks' of the failed change? (maybe --last=connect)
<kenvandine> Done    today at 11:21 EST  today at 11:21 EST  Connect gedit_master:gnome-3-28-1804 to gnome-3-28-1804:gnome-3-28-1804
<kenvandine> that was my manual connect
<kenvandine> but the content is not mounted in the snap
<Chipaca> ah (?)
<kenvandine> i installed another parallel snap and that connected everything just fine
<mborzecki> kenvandine: let me try that locally
<kenvandine> i'm guessing if i remove gedit_master and install again it might work
<kenvandine> since other snaps are working
<kenvandine> but i'll leave it broken in case i can collect any useful info for you
<mborzecki> kenvandine: it ought to be deterministic :P
<kenvandine> *ought* to be
<mborzecki> kenvandine: can you upload `snap change` of that install to pastebin?
<kenvandine> mborzecki: you mean the line from snap changes?
<mborzecki> kenvandine: the output of `snap change <that-change-id>`
<kenvandine> oh
<kenvandine> never done that before :)
<mborzecki> installed here just fine
<kenvandine> http://paste.ubuntu.com/p/sGxcwknFRp/
<kenvandine> yeah, i've since installed several other gnome snaps fine
<kenvandine> looking at the change, it doesn't even list gnome-3-28-1804
<mborzecki> kenvandine: ok, can you run `snap changes` locate the manual connect that failed and paste snap changes <that-id> ?
<Chipaca> mborzecki: snap tasks <that id>
<Chipaca> or snap change <that id>
<kenvandine> mborzecki: Done    today at 11:20 EST  today at 11:20 EST  Connect gedit_master:gnome-3-28-1804 to gnome-3-28-1804:gnome-3-28-1804
<kenvandine> it didn't think it failed
<Chipaca> kenvandine: anything interesting in jouranlctl -u snapd ?
<Chipaca> or some other command that rhymes with that
<kenvandine> Mar 05 11:20:03 x230 snapd[1778]: api.go:1077: Installing snap "gedit_master" revision unset
<kenvandine> only thing around the same time
<kenvandine> the interface is currently connected, but the mount point is empty
<mborzecki> ah ok, so the content interface is conencted but the data is nto visible?
<kenvandine> right
<kenvandine> mborzecki: although it didn't connect at install
<kenvandine> like it should have
<kenvandine> i manually connected it
<mborzecki> kenvandine: ok, maybe try this, sudo nsenter -m/run/snapd/ns/gedit_master.mnt /bin/findmnt and paste the output
<kenvandine> mborzecki: http://paste.ubuntu.com/p/xHmnP6mSgT/
<mborzecki> kenvandine: nothing stands out, can you also paste the contents of /var/lib/snapd/mount/snap.gedit_master.fstab ?
<kenvandine> mborzecki: http://paste.ubuntu.com/p/5m5JpD2pgw/
<mborzecki> kenvandine: the content mount points of gtk-common-themes and gnome-* seem to be populated here just fine, i mean mounted and there's data inside
<kenvandine> yeah
<kenvandine> same here for all the other snaps
<kenvandine> that i installed since
<kenvandine> so i suspect if i remove and reinstall it will be fine
<kenvandine> this was the first snap i installed after enabling parallel installs on core
<mborzecki> kenvandine: ok, let's see if we can reproduce it at least, can you stop gedit, run sudo /usr/lib/snapd/snap-discard-ns gedit_master and then run `SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=1 snap run gedit_master` and paste the output
<kenvandine> mborzecki: https://pastebin.ubuntu.com/p/XCKtXgRSYx/
<kenvandine> mborzecki: it actually ran fine
<mborzecki> kenvandine: idk, things seem to look fine in the outputs, probably be good if zyga could take a look too
<kenvandine> now it all works fine
<kenvandine> so something there cleared it up
<kenvandine> i guess the snap-discard-ns ?
<mborzecki> kenvandine: yes, that tool removes the mount namespace and it will be recreated on the next snap run
<zyga> kenvandine: yes, you can use it to get a clean slate
<zyga> pedronis: hey, do you want to have a look at https://github.com/snapcore/snapd/pull/6498 before  it lands?
<mup> PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
<pedronis> zyga: I think it was alright,  do we have something using it yet? or is that coming?
<zyga> pedronis: that's upcoming in another branch
<zyga> pedronis: just separated for different review people usually
<zyga> pedronis: (and shorter)
<zyga> pedronis: though it's already used
<zyga> pedronis: because of freezer code now beign based on this
<pedronis> yes, that I understand
<pedronis> ok
<zyga> one question, I forgot to add copyright headers
<zyga> s/question/change/
<zyga> ok, pushed
 * zyga EODs
#snappy 2019-03-06
<mwhudson> hm
<mwhudson> i thought as a developer of a snap i could download it by revision?
<mwhudson> ah https://forum.snapcraft.io/t/as-a-snap-owner-not-able-to-download-a-snap-by-revision/10062/2
<mborzecki> morning
<mborzecki> new kernel 5.0.0-arch1-1-ARCH
<mborzecki> a lot of ubuntu-16.04-32 prepare jobs failed
<mborzecki> mvo: morning
<mvo> hey mborzecki ! good morning
<mborzecki> i'll be out for a while, left a note in the forum
<mvo> mborzecki: thanks for letting me know
<mvo> mborzecki: s/me/us/ :)
<mborzecki> mvo: sure
<mborzecki> mvo: i've restarted some travis jobs, seems like ubuntu-16.04-32 was reaching a kill timeout in prepare
<mborzecki> but i'd guess it's repos being slow
<mup> PR snapd#6569 opened: tests: check that apt works before using it <Created by mvo5> <https://github.com/snapcore/snapd/pull/6569>
<pstolowski> heyas
<mup> PR snapd#6570 opened: snapstate: only keep 2 snaps on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6570>
<pedronis> mvo: hi, I created a card about that ^
<pedronis> mvo: see bottom of upcoming
<mvo> pedronis: thanks
<mvo> pedronis: I added the PR to the card
<pedronis> mvo: I'm not seeing it
<mvo> pedronis: hm, trello acted up, should be there now
<pedronis> mvo: yes, probably the if it's kept open for too long it needs a reload (sometimes)
<mvo> yeah, I think that was what happend
<mvo> (reload "fixed" it)
<pedronis> mvo: there's  a lot red in tests
<pedronis> anything clear about why?
<zyga> good morning
<mvo> pedronis: yes, working on it - 6569 should fix it
<mvo> hey zyga - good morning
<pedronis> ah
<zyga> hey, sorry, long night,  starting late to be awakee
<zyga> mvo: I replied to https://github.com/snapcore/snapd/pull/6498
<mup> PR #6498: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
<zyga> oh, tests are red today
<mvo> zyga: thanks, I see - yeah, +1 then on the PR. thanks for explaining the difference
<zyga> go.googlesource.net 502 :/ https://www.irccloud.com/pastebin/dHeNm5vD/
<zyga> mvo: we use the freezer to track snap-wide scope and  pid to track security-tag scope
<zyga> mvo: in v2 we can  design a nicer hierachy where  snapd/foo.snap/bar.app/ is used, for example
<mvo> zyga: 6569 should make tests green again
<zyga> fun :)
<zyga> thank you
<zyga> last night was hours and hours of homework
<zyga> followed by some more hackng but I finished late after midnight
<zyga> mvo: wow, thank you for https://github.com/snapcore/snapd/pull/6570
<mup> PR #6570: snapstate: only keep 2 snaps on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6570>
<mvo> my pleasure
<mborzecki> zyga: i think we need to have a package that wraps calls to snap-seccomp
<mborzecki> zyga: added some code to interrogate snap-seccomp when building the system-key and it's a bit awkward
<zyga> mborzecki: can you tell me more about this idiea
<zyga> *idea
<zyga> mborzecki: I _may_ have something better soon
<zyga> mborzecki: but for 2.39 at earliest
<zyga> mborzecki: snap-seccomp won't need to exist as a binary anymore
<mborzecki> zyga: ah, your custom bpf compiler? :)
<zyga> mborzecki: just really a super simple assembler
<zyga> mborzecki: all I need is the syscall tables now
<zyga> mborzecki: the advantage is that we have less C code, no need for a standalone binary and one less  depednency
<zyga> mborzecki: given that we use snap-seccomp for a very simple task it is not hard to reproduce that
<zyga> but anyway, let me know  more about your current idea
<mborzecki> zyga: ho?
<zyga> mborzecki: sure, gimme a sec
<zyga> mborzecki: I'm in standup
<mborzecki> zyga: joining
<mvo> mborzecki: hey, what was the outcome of the parallel install gnome discussion yesterday?
<mborzecki> mvo: i did no see anything off int he mounts, also couldn't reproduce that locally
<mborzecki> mvo: when ken discarded the mount ns and run the snap again, everything was ok
<mborzecki> mvo: so either some sort of race, or soemthing nonobvious in mount ns setup
<mvo> mborzecki: hm, ok - and also worrying we should try to get to the bottom of this, I have the feeling it will come back
<pedronis> zyga: I did a pass on #6502
<mup> PR #6502: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> pedronis: thank you! I will iterate on it now
<zyga> mvo: hey, we figured out why mborzecki's branch is failing
<mvo> zyga: tell me more please
<zyga> mvo: well, partially figured out: it is due to the service that bootstraps snapd from snap
<zyga> mvo: we run the compiler before snapd.snap is installed
<mborzecki> mvo: i had the a quick and dirrty install gedit_master && run && remove gedit_master gnome-... gtk-common-themes loop running for a while, but was not able to reproduce the problem
<mvo> zyga: btw, any idea about why the namespace reset yesterday helped with the gnome issue yesterday?
<zyga> mvo: so a quick question: how does the service operate? where is the snapd.snap mounted during the bootstrap process?
<zyga> mvo: oh? I don't know anything about that
<zyga> mvo: I recall some people discussing snap-discard-ns but not sure if that's the topic you refer to
<mborzecki> zyga: https://irclogs.ubuntu.com/2019/03/05/%23snappy.html ~16:25
<mvo> zyga: when snapd is run it will bootstrap itself, i.e. it will read seed and perform the actions
<mvo> zyga: so the bootstrap is literally just "mount snapd snap, run snapd and let it run"
<mvo> zyga: once the snapd snap is installed by the snapd binary it will restart itself and all is well defined
<zyga> mvo: right, but before seeding backends will initialize, snap-seccomp will be invoked from a path that doesn't (apparently, this is still a theory) does not exist yett
<mborzecki> mvo: when snapd is run, snap-seccomp will be in the same directory as /proc/self/exe of snapd, right?
<mvo> mborzecki: yes
<mvo> mborzecki: we actually should run snap-seccomp always from that dir, no?
<mborzecki> mvo: yes, just confirming things
<mvo> cool
<zyga> I see the conversation now: interesting, I would have to check some things
<mborzecki> mvo: seccomp backend initialization calls to snap-seccomp, we have a feeling that this fails, so backend fails to initialize and things break down
<zyga> perhaps interplay with mounting the instance name, the non-instatnce name and the content
<pedronis> mvo: ken said it was the oldest parallel installed snap he had
<zyga> I have a test in spread that shows how something similar fails
<mborzecki> zyga: something similar, as in mounts or snap-seccomp during bootstrap?
<zyga> is it reproducible?
<zyga> mborzecki: as in mounts
<mborzecki> zyga: i was not able to reproduce it yesterday
<zyga> https://github.com/snapcore/snapd/blob/master/tests/main/layout-symlink-bind-revert/task.yaml
<zyga> this encodes some of the problem (but you have to read deeply  about what goes on in an associated commit message)
<mvo> 6569 is green and should make tests green again
<mvo> (needs a second review)
<zyga> https://github.com/snapcore/snapd/commit/adf75238b85540d19027dc2f1c576bd266641af2#diff-a6e200ddb24754df8611a002020deccd
<zyga> mvo: anyway, I  will investigate
<mvo> thank you zyga
<ogra> ogra@nanopc-t4:~$ uname -a
<ogra> Linux nanopc-t4 4.19.20-dirty #1 SMP PREEMPT Tue Mar 5 16:58:29 CET 2019 aarch64 aarch64 aarch64 GNU/Linux
<ogra> ogra@nanopc-t4:~$ cat /proc/cpuinfo |grep -c ^processor
<ogra> 6
<ogra> ogra@nanopc-t4:~$ free -h | grep ^Mem
<ogra> Mem:           3.8G        124M        3.4G         11M        280M        3.5G
<ogra> :D
<zyga> ogra: raspberry pi 4? :D
<ogra> haha, no ... a rockchip 3399 board ... but it not only has 6 2GHz cores and 4G, it also has an M.2 SATA connector :D
<ogra> just trying to get lxd armhf images up and running ... then i'll likely have a home-builder thats as fast as the LP buildds ;)
<ogra> (minus the queue ;) )
<zyga> ogra: build libreoffice then :)
<ogra> once i have everything up i will ... images are here in case someone else has such a board http://people.canonical.com/~ogra/snappy/nanopc-t4/ :)
<pedronis> mvo: so seems we have the problem that on a classic system with reexec getting a base: core18 snap doesn't get you an auto-updating snapd
<pedronis> because we don't get core (nor the snapd snap)
<pedronis> mvo: https://forum.snapcraft.io/t/core18-snap-fails-to-run-on-16-04-cannot-locate-the-core-snap/10292/10
<mup> PR snapd#6569 closed: tests: check that apt works before using it <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6569>
<mvo> pedronis: yeah, still no 2.37.x in xenial :/
<mvo> pedronis: our SRU process is still slow
<pedronis> mvo: does 2.37 pull in core though?
<pedronis> it will fix that problem
<pedronis> but not the stale snapd
<mvo> pedronis: right
<mvo> pedronis: let me read the full thing, I thought this was about the bug that without core snaps won't run. but yeah, with only core18 we lose the re-exec right now
<thresh> how am I supposed to pass stuff between an unconfined app's /tmp/ and a confined app, like vlc?  https://trac.videolan.org/vlc/ticket/21558 is the ticket we got for VLC, where user wants to open an attachment from Thunderbird in a confined VLC.
<zyga> thresh: this would only work through XDG portals, something that is not widely available yet
<mborzecki> zyga: yay, no more import cycles, https://paste.ubuntu.com/p/X4vqjPsj85/ that's with the seccomp compiler wrapper under sandbox/seccomp
<zyga> mborzecki: nice, I think this is what we need :)
<thresh> zyga, ok, can you point me to the docs?
<mborzecki> zyga: similar wrapper for apparmor under sandbox/apparmor would be trivial too :P
<thresh> afaics, most of my users are on ubuntu 18.04
<zyga> thresh: there are no docs for this issue per-se, there's  the movement  to get document portal in place with snapd and with snaps but it is far from complete
<thresh> zyga, ah, I see, thank you.
<mup> PR core#102 closed: hooks: add force_turbo to PI_CONFIG_KEYS <Created by zyga> <Closed by pedronis> <https://github.com/snapcore/core/pull/102>
<mborzecki> zyga: https://github.com/bboozzoo/snapd/commit/07f3aeab765514a1e8e5501fb4490ffca273a1e2
<zyga> mmm
<mborzecki> tiny :)
<mborzecki> i'm finishing fixing up the tests and will stat looking into the spread test of core18
<mborzecki> zyga: got your comment, will add that
<zyga> mborzecki: +1
<zyga> mborzecki: I left one comment
<zyga> thanks!
<mborzecki> i'm heading home
<Chipaca> mo'in all
<Chipaca> back earlier than i feared, although I'll have to go out again this afternoon
<Chipaca> meanwhile, there's a user out there wondering why 'sudo umount -a' causes their snaps to stop working
<pedronis> pstolowski: I added some more highlevel considerations to 6562
<pedronis> Chipaca: hi, sorry for the slightly grumpy review of #6564 , the diff there is very hard to read
<mup> PR #6564: cmd/snap, tests: refactor info to unify handling of 'direct' snaps <Created by chipaca> <https://github.com/snapcore/snapd/pull/6564>
<pedronis> pstolowski: let me know if you have questions, need to lunch now though
<pstolowski> pedronis: yep, looking, thanks!
<Chipaca> pedronis: yeah
<pedronis> mvo: any particular reason to push #6570 to 2.38 ?
<mup> PR #6570: snapstate: only keep 2 snaps on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6570>
<mvo> pedronis: just to make foundations happy
<mvo> pedronis: fine to remove the milestone
<pedronis> mvo: I don't think it's risky, but is not a bug fix either
<pedronis> mvo: I removed it
<pedronis> mvo: we have just one thing open for 2.38
<pedronis> now
<Chipaca> pedronis: why is 'load' wrong, and why is 'examine' better, for a function that does cmd.ClientSnapFromSnapInfo(snap.ReadInfoFromSnapFile(snap.Open(...))) ?
<mvo> pedronis: having it in 2.38 makes sure it lands in time for 19.04 - but we can always pull it into 2.38.N if 2.39 does not make it in time
<pedronis> mvo: I understand
<pedronis> Chipaca: are we loading the snap?
<pedronis> do we use load for this anywhere?
<pedronis> Chipaca: the line you pasted has no verb load in it
<pedronis> it has a read
<pedronis> Chipaca: it would be good also to find something else than "direct"
<pedronis> Chipaca: examine had "?" after it, it was a proposal
<Chipaca> to me "load" is pretty close to "open and read", but I recognise that this might be a 'me' thing
<pedronis> Chipaca: yes, I think you tried to sneak it in somewhere else, but we don't use it that way
<pedronis> Chipaca: to me load  sounds like bring this entire thing into memory
<pedronis> Chipaca: I suppose the problem of that direct is shared by the other ones "local" and "remote", they are adjective used as names,  I think of the bunch direct is the one that sounds the most like it would be a bool
<pedronis> but maybe that's me
<pedronis> Chipaca: maybe we should turn them all into remoteSnap, localSnap and diskSnap ? don't lnow
<pedronis> Chipaca: I commented on this a bit more in the PR itself
<pedronis> Chipaca: wasn't this fixed already https://bugs.launchpad.net/snapd/+bug/1818306 ?
<mup> Bug #1818306: disabled daemons are started after refresh <snapd:New> <https://launchpad.net/bugs/1818306>
<Chipaca> pedronis: yes
<pedronis> Chipaca: the report is recent
<mup> PR snapd#6570 closed: snapstate: only keep 2 snaps on classic <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6570>
<mvo> 6418 needs a second review
<Chipaca> pedronis: we fixed it for refresh, not for install i guess?
<Chipaca> pedronis: what's the right behaviour for install?
<pedronis> for install?
<Chipaca> yes
<pedronis> degville: 3 is actually mentioned here  https://forum.snapcraft.io/t/getting-started/3876 under "snap revert" docs
<pedronis> mvo: ^
<degville> thanks pedronis!
<Chipaca> pedronis: actually I see the same behaviour on refresh
<Chipaca> need to dig a bit
<pedronis> Chipaca: ok
<pedronis> Chipaca: I think internally that install is a refresh
<pedronis> or not different to a refresh
<Chipaca> it should be, yes
<pedronis> Chipaca: anyway don't dig too much if you are doing something else
<pedronis> Chipaca: we made a card
<Chipaca> dunno if i'd complicate the services handling over it though
<Chipaca> pedronis: also https://forum.snapcraft.io/t/disabled-snap-gets-enabled-after-a-refresh/7457
<zyga> Chipaca: standup or  are you skipping?
<Chipaca> going
<Chipaca> pedronis: #5777 was never merged
<mup> PR #5777: wrappers/services.go: don't start disabled services <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/5777>
<pedronis> Chipaca: ah, so it's rally all tangled together as we discussed in Malta
<pedronis> *really
<feelextra> Hello! is there a Snap store besides Snapcraft's website? i thought Snap software can be distributed anywhere.
<roadmr> feelextra: what made you think that?
<feelextra> I watched this video that says: "snap stores are basically software repositories. of course canonical has their own snap store but anybody can have a snap store, and assuming your snap store is signed and secure you could technically pass it around in a PPA very similar to the way Ubuntu distros work today" source: https://www.youtube.com/watch?v=ixWuE1hhZfw
<feelextra> at around 1:00 into the video
<diddledan> feelextra: there is no currently available snap store implementation besides the official store which is proprietary.
<diddledan> you _can_ reimplement it but you also need to modify the snapd to be able to recognise the alternative store location
<feelextra> diddledan: thank you, that adds to my understanding of Snap!
<diddledan> at the moment snapd is hardcoded to only use the canonical-sponsored store
<diddledan> until there are alternative software to run your own store that's likely to remain as is
<feelextra> i see.
<Chipaca> there was a store implementation out there, but it lagged
<Chipaca> and pointing snapd at a different store is reasonably straightforward
<Chipaca> but it's not a federated system, at all
<Chipaca> you choose one store and stick to it
<Chipaca> using our staging store, for example, requires everything from scratch, even core
<Chipaca> (because the assertions are all different)
<Chipaca> stepping out for a while
<mup> PR snapd#6566 closed: interface: avahi-observe: Fixing socket permissions on 4.15 kernels (2.38) <Simple ð> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6566>
<mborzecki> zyga: i've updated #6485
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<zyga> looking
<mborzecki> zyga: our mocking setup feels super fragile
<zyga> mborzecki: yes
<zyga> especially across packages
<mborzecki> zyga: btw. https://forum.snapcraft.io/t/plans-for-sharing-a-gl-lib/10298
<zyga> oh, fun
<zyga> will you reply or shall I?
<mborzecki> zyga: go ahead
<mborzecki> zyga: oh, and core18 works now, but I haven't confirmed that we suspected was actually the problem
<zyga> what
<zyga> did you change anything relevant?
<mborzecki> zyga: there were some changes in the code that finds where snap-seccomp is
<mborzecki> zyga: the test is running now, i'll let it finish
<mborzecki> damn,  Failed for "golang.org/x/crypto/cast5" (failed to clone repo): exit status 128, rly?
<zyga> heh
<mborzecki> zyga: heh, it's only rebooting the node now, so maybe it still doesn't work
<zyga> archive woes :/ https://www.irccloud.com/pastebin/amKlkAyM/
<zyga> Chipaca: let's add ubuntu to the list of distros without reliable archives
<pedronis> zyga: please undo your change to 6418
<pedronis> it doesn't achieve the goal of the PR
<zyga> oh? can you tell me more?
<pedronis> zyga: we want to pivot
<pedronis> that code won't
<pedronis> zyga: I also tried to answer your other comments in the PR
<zyga> pedronis: I agree about the pivoting aspect
<zyga> pedronis: shall I revert or force push?
<pedronis> zyga: what is more convenient
<pedronis> zyga: anyway one of the comment explain a refactoring that is useful either way
<pedronis> for the clarity of snap-confine
<pedronis> this change (in principle) should be simple either place
<pedronis> it isn't
<zyga> about pivot, I'm again not sure what should happen, it's complex
<pedronis> zyga: it's not complex
<pedronis> or shouldn't be
<zyga> the code doesn't need to pivot if boot base is core16-like and base snap is core16-like
<zyga> for the maximum compatibility between core and core16
<pedronis> we don't want that
<pedronis> core16 is accepting to move forward
<pedronis> as a base
<zyga> I'm not sure of that, if you think about what happens in core today it may break working snaps
<pedronis> othewise those snaps will fail on core18 devices
<pedronis> in unexpected ways
<zyga> and I don't think we will give people to option to stay on pure core? (or will we?)
<pedronis> zyga: we are introducing "base: core" as well, remember
<zyga> core18 devices are new, those may not work _yet_, this may break stuff that does work now
<pedronis> zyga: ?
<pedronis> if a snap puts base: core16
<pedronis> in itself
<pedronis> is getting places
<pedronis> (that doesn't even work right now, remember, there is no stable core16)
<zyga> pedronis: if this changes pivot semantics (when we pivot vs when we not pivot); the deployed base of snaps on core devices (with core as boot base), however wrong or correct, function now. If we migrate those to core16+snapd over time their semantics will change
<pedronis> zyga: if you put base: core or no base
<pedronis> you'll get the previous semantics
<zyga> core16 was about unbundling snapd from core, this seems to make an extra assumption developers must be ok with
<pedronis> it's not, we cannot really let people make core16 based snaps
<pedronis> that don't work on core16 devices
<pedronis> sorry on core18 devices
<pedronis> no base snaps
<pedronis> are a greyer area
<pedronis> because of the choices we made
<zyga> I agree but they are a grey area that is yet unexplored
<zyga> I see your point of view but I'm worried core16 will break people more than it will help
<zyga> we could discard the non-pivoting mode entirely and see what happens
<pedronis> that is a different issue
<zyga> perhaps the whole argument is moot, I think we don't really know
<pedronis> anyway I don't see how making base: core16 potentially let you build snaps that don't work on core18
<pedronis> be progress
<pedronis> toward the goal or turning off pivoting completely
<zyga> pedronis: I think nobody will ship something that doesn't work
<zyga> pedronis: the difference is who pulls the trigger, is it us for the developers (core -> core16 + snapd) or themselves
<zyga> pedronis: I pushed a revert to the branch now
<pedronis> we will still pivot if the snap has no base
<pedronis> even on core16+snapd
<zyga> pedronis: I will look at making a refactor you suggested
<pedronis> (we'll need to code for that)
<pedronis> or might pivot
<pedronis> anyway that's part of the discussion how to get there
<zyga> pedronis: snaps always have a base as far as snap-confine is concerned, it is just the string "core" when it is not explicitly defined
<pedronis> option for base: core16 early
<pedronis> means something else
<pedronis> zyga: I know
<zyga> another aspect is that the branch feels like an optimization
<zyga> and we don't know what the correct mode is (or is it just me?)
<zyga> if this never lands we just pull in core16 in addition to core
<zyga> and then use base core16
<zyga> when snaps use core16 as their explicit base we will always pivot
<pedronis> zyga: we need to decide, we need a correct implementation either way to let people play
<zyga> (in the current code)
<pedronis> zyga: anyway my main take away for all of this, is this comment: https://github.com/snapcore/snapd/pull/6418#discussion_r263027927
<mup> PR #6418: many: allow core as a fallback for core16  <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<pedronis> we should do either way
<pedronis> because the current layering is not good(tm)
<zyga> yeah
<zyga> I agree
<pedronis> so that should be a separate prereq PR either way
<pedronis> zyga: mvo: you need to decide who would tackle that
<zyga> I'm attempting that refactor now
<carif> don't know what the ettiguette is for this, but I posted a question https://forum.snapcraft.io/t/is-there-a-list-of-currently-enabled-ubuntu-core-boards-by-architecture-and-model-number/10263
<carif> i read something in the forums that its the preferred approach to capture and discussions and answers. ty
<pedronis> carif: the best people to answer that were at some events last week
<carif> pedronis, ack, i can be patient. just wanted to learn the protocol, ty.
<mvo> zyga: thanks for tackling this
<zyga> pedronis, mvo: I pushed a small branch that begins  the refactoring while remaining readable https://github.com/snapcore/snapd/pull/6571
<mup> PR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>
<mup> PR snapd#6571 opened: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>
<pedronis> zyga: the user/groups ids vs the rest seems a bit different concerns (I see 3 calls to getresuid atm)
<mup> PR snapd#6572 opened: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
<mup> PR pc-i386-gadget#8 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/8>
<mup> PR pc-i386-gadget#9 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-i386-gadget/pull/9>
<mup> PR pc-amd64-gadget#12 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-amd64-gadget/pull/12>
<mup> PR pc-amd64-gadget#13 opened: Adding empty configure hook to enable configuration for gadget <Created by kubiko> <https://github.com/snapcore/pc-amd64-gadget/pull/13>
<zyga> pedronis: I wanted to keep the property of a  refactor, I'm neither addnig nor removing more calls
<zyga> pedronis: but I see your point, perhaps we should evacuate them from the struct
<zyga> pedronis: and pass them around separately?
<pedronis> zyga: yes, I just a fear getting that struct to the few other places that care will need huge changes
<pedronis> seems a separate concern
<pedronis> I mean care about those
<zyga> pedronis: so, what to do?
<pedronis> zyga: pass them separetly
<pedronis> as you said
<pedronis> in snap-confine.c
<pedronis> itself
<pedronis> at least for now
<zyga> ok
<pedronis> zyga: also do we use saved_uid/gid except printing them for debug?
<zyga> we use only three of those
<pedronis> seems down in the working bits we use only real_uid/gid
<pedronis> in snap-confine.c
<pedronis> itself
<zyga> pedronis: pushed
<zyga> the format is  silly, sorry about that, it's the indent style we use
<pedronis> zyga: thanks
<zyga> pedronis: I also merged this into https://github.com/snapcore/snapd/pull/6572
<mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
<pedronis> zyga: is apparmor passed around a lot?
<zyga> it's passed in a few places
<zyga> we need it to run helpers
<pedronis> zyga: grepping my feeling would be to carry it separately as well
<pedronis> so invocation is really things derived from arguments
<pedronis> (and further derived from those)
<pedronis> zyga: not a strong opinion either way
<zyga> pedronis: let's keep it inside for the purpose of this  mini patch-series, I can move it out after we start to  pass invocation around mount-support and ns-support
<zyga> pedronis: by then will have useful data
<pedronis> zyga: isn't it easier the other way around? I suppose it depends a bit how we got about it
<pedronis> zyga: the question is really is whether the depth sc_invocation should go is about the same of apparmor or deeper
<pedronis> as well
<zyga> pedronis: right now we pass it as a separate argument but the number of arguments to  enter_ is  already pretty large
<mup> PR snapd#6573 opened: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <https://github.com/snapcore/snapd/pull/6573>
<zyga> pedronis: I don't mind removing it if it makes sense, just wanted to reach the point of the refactoring we  were discussing initially
<zyga> pedronis: I think invocation should go as deep as it makes sense to avoid passing the same arguments over and over
<pedronis> zyga: well, as long as the target uses at least two things from it
<pedronis> zyga: I'm a bit surprised about the last patch
<zyga> I knew some of this code was a bit rusty but I was reluctant to change it without a path for rapid review and feedback cycle
<zyga> pedronis: I started using the invocation but it grew bigger so I proposed the intermediate step first
<pedronis> zyga: that's not the issue, can't we call sc_should_use_normal_mode in main ?
<pedronis> and put it in sc_invocation
<pedronis> we can then extract it down for now
<zyga> pedronis: ah, yeah
<zyga> pedronis: that won't explode the size of -3 yet
<zyga> actually
<zyga> pedronis: no :/
<pedronis> why ?
<pedronis> (genuine question)
<zyga> pedronis: because it must be probed after reassociate_with_pid1_mount_ns
<zyga> I can move that to main
<zyga> then move the check along with it
<zyga> the thing is, we only did this in the non-classic path for now
<pedronis> zyga: you can keep in the else path for now
<zyga> which I think should remain so
<pedronis> (but we have plans to make classic more like the rest)
<zyga> yeah, that's true
<zyga> just trying to limit possibility of fallout
<pedronis> yes, I agree
<zyga> one more idea
<pedronis> but we can find a middle ground
<zyga> we can make a classic invocation
<zyga> and a strict invocation (for lack of a better name)
<zyga> where classic is no-op empty
<zyga> and strict has more things inside and is intialized at the right time
<pedronis> do we need to?
<pedronis> I'm not sure it helps in itself
<zyga> I think it won't help much, just may make it clear that some fields are only used for strict path
<pedronis> yea, we can set normal_mode to false on the classic path
<pedronis> that's not the issue I think
<zyga> mmm, yeah
<zyga> let's do that
<zyga> it will also means the functions start to change the invocation but I think that's ok
<zyga> I started off with const because that's safer to explore
<pedronis> zyga: we could also have sc_invocation exist only in the else path
<zyga> yeah
<pedronis> given is the other path does nothing
<pedronis> and the code after calls just a couple of things
<pedronis> that could use it (but also not)
<zyga> we can solve it later when we do classic mount instances
<pedronis> yes
<zyga> I pushed the earlier suggestion to -3
<zyga> is_normal_mode is now in the struct
<zyga> https://github.com/snapcore/snapd/pull/6573/commits/c7633e9debfebe64dd320996c5ae4a373e0ea25e
<mup> PR #6573: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <https://github.com/snapcore/snapd/pull/6573>
<zyga> pedronis: are you happy with the direction so far in -1, -2 and -3?
<pedronis> zyga: yes
<zyga> pedronis: I think we can pass the invocation to the main places that currently carry the chain of arguments like snap name, base snap name, etc
<zyga> pedronis: we may (perhaps) split the invocation so that things that are static and dynamic are not mixed as much but we shall see how this looks like
<pedronis> as I said  I think it should be fine to send to anything that was taking at least two of the members
<zyga> pedronis: I would love to eventually marry this with the idea that for each security tag we can ask the system, reliably and without user injections, what is the base snap, classic confinement mode
<zyga> and drop the need for environment variables and arguments as trusted input
<zyga> which we do our best to validate but still cannot prove correct (e.g. call one snap's app with another snap's confinement)
<zyga> I need to break now, ttyl!
<mvo> Chipaca: can I interest you in the review of 6381? second review, hopefully boring :)
<zyga> stuff is failing on fatal: unable to access 'https://go.googlesource.com/net/': The requested URL returned error: 502
<zyga> any ideas?
<zyga> I need to EOD
<zyga> but if anyone is trying to land stuff, that's breaking all builds now
<ogra> zyga, FYI https://github.com/snapcore/pi3-gadget/pull/20 ... open since Nov
<mup> PR pi3-gadget#20: dots in interface names are not allowed, fix spi <Created by ogra1> <https://github.com/snapcore/pi3-gadget/pull/20>
<ogra> just merge it (or make sil2100 merge it ... )
<dot-tobias> Is there an ETA when snapcraft 3.2 will be available on launchpad builders?
<dot-tobias> (for core16-based snaps)
#snappy 2019-03-07
<mborzecki> morning
<mborzecki> zyga: mvo: https://paste.ubuntu.com/p/JtBVwYzqqH/ seems like the guess from yesterday was correct
<mborzecki> snapd snap in mounted at some tmp location, but the code locating snap-seccomp in seccomp backend only picks snapMountDir + .. or distro libexecdir
<mvo> mborzecki: nice find
<mvo> mborzecki: so we just need to make snapd look at its own exe location first?
<mvo> mborzecki: I think that makes sense anyway
<mborzecki> mvo: yes, we do it already for system-key
<mvo> mborzecki: \o/
<mborzecki> mvo: anyways, added a unit test and pushing a patch in a minute
<mvo> mborzecki: thank you
<zyga> Good morning
<mvo> mborzecki: curious why this is failing now - or is the PR doing more than "just" the on-changed compiling of the bpf?
<mborzecki> mvo: the PR tries to run snap-seccomp to get the version information when the seccomp backend is getting initialized
<mvo> mborzecki: aha, I see
<mvo> mborzecki: that makes sense
<mborzecki> mvo: afaik we haven't run any of the internal tools until now
<zyga> Aha!
<zyga> mborzecki: interesting
<mvo> mborzecki: yeah, bootstrap is very limited
<mvo> mborzecki: otoh, you could simply ignore seccomp missing, the first snap installed during bootstrap will be snapd and then snapd restarts
<zyga> Complexity :/
<mborzecki> pushed a patch
<mvo> can I interest someone in a second review for 6381? should be straightforward
<mborzecki> mvo: looking
<mborzecki> mvo: does it make sense to have a remodel when there are no changes to the kernel and required snaps, so that only set-model task runs?
<mborzecki> nvm, answered that myself :)
<pedronis> mborzecki: hi, we are still missing bits of snap connections ?   content[foo] is not there yet, right?
<mborzecki> pedronis: yes, it's not there yet
<pedronis> mborzecki: the idea was to have a followup right after
<pedronis> right now seems we will ship 2.38 without and 2.39 with?
<pedronis> mvo:  ^
<mvo> pedronis: if its easy we can pull it into 2.38 still
<mborzecki> pedronis: ah, ok, wanted to address soem feedback in selinux branches, but i can to that bit of connections first
<mvo> pedronis: we are only at ~pre1 yet
<pedronis> mvo: it should be contained
<mvo> yeah, having the full thing in 2.38 seems desirable
<mborzecki> ok, will look into that then
<mvo> ta
<pedronis> mborzecki: mvo:  from my POV  prioties are "snap connections" because 2.38, we are so close. SELinux because its going on since log. seccomp opts because it's 2.39 stuff anyway and it's an opt
<pedronis> s/log/long/
<pedronis> mvo: ^, reasonable?
<mvo> pedronis: +1
<pedronis> mborzecki: thanks
<pstolowski> morning
<pedronis> the seccomp PR has grown quite a bit :/ , the direction is good though
<zyga> Back from walk, Iâll be in the office soon
<mborzecki> aand #6485 is green!
<mup> PR #6485: interfaces/seccomp: regenerate changed profiles only <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6485>
<mborzecki> need to gram some coffee
<mvo> hey team - I updated the https://forum.snapcraft.io/t/the-snapd-roadmap/1973 roadmap page for 2.38 - if your favorite thing is missing please do let me know and I add it
<zyga> Thank you!
<ogra> ogra@nanopc-t4:~$ lxc launch ubuntu:16.04/armhf snapcraft-armhf
<ogra> To start your first container, try: lxc launch ubuntu:18.04
 * ogra scratches head ... why is it telling me the command i just used :P
<mvo> 6565 is an easy winâ¦
<mup> PR snapd#6567 closed: overlord/snapstate/backend: make LinkSnap clean up more <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6567>
<mup> PR snapd#6498 closed: cmd/libsnap: add cgroup-pids-support module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6498>
<zyga> mvo: https://github.com/snapcore/snapd/pull/6565#pullrequestreview-211672889 is ready
<mup> PR #6565: snap: remove obsolete license-* fields in the yaml <Created by mvo5> <https://github.com/snapcore/snapd/pull/6565>
<mvo> zyga: \o/
<mup> PR snapd#6565 closed: snap: remove obsolete license-* fields in the yaml <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6565>
<zyga> interesting feature: https://help.github.com/en/articles/about-pull-requests#draft-pull-requests
<mup> PR snapd#6574 opened: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<zyga> another interesting github feature https://help.github.com/en/articles/about-code-owners
<mup> PR snapd#6381 closed: devicestate: add initial Remodel support <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6381>
<ogra> sil2100, seems zyga just merged https://github.com/snapcore/pi3-gadget/pull/20 can you make sure we get a release of it into stable ?
<mup> PR pi3-gadget#20: dots in interface names are not allowed, fix spi <Created by ogra1> <Merged by zyga> <https://github.com/snapcore/pi3-gadget/pull/20>
<ogra> (this is actualyl one of the files that actually upgrade on gadget upgrades, so it is valuable even without new images)
<pstolowski> pedronis: updated https://github.com/snapcore/snapd/pull/6562
<mup> PR #6562: timings: base API for recording timings in state <Created by stolowski> <https://github.com/snapcore/snapd/pull/6562>
<pstolowski> pedronis: thanks for another pass on nestedvm PR
<sil2100> I need to finally sort out the branch ownership, was too busy with the point releases in  the last weeks
<sil2100> eh
<sil2100> ogra: will add that to my TODO list, will push it through as soon as possible but there's a lot going on right now
 * dot-tobias says hi
<pedronis> zyga: 6574 is a prereq for 6502 to actually work?
<dot-tobias> I can't seem to find an update which snapcraft version is currently used for launchpad builders (latest was https://forum.snapcraft.io/t/launchpad-now-builds-snaps-in-lxd-containers-in-support-of-build-snaps/2002/23 , question asked ~20 days ago in https://forum.snapcraft.io/t/snapcraft-version-used-by-launchpad-and-docker-images/9994)
<zyga> pedronis: correct
<pedronis> zyga: does it fail, or simply the checks always pass?
<pedronis> ah, the checks are not called yet
<pedronis> zyga: you should probably concetrate on landing a good chunk of your open PRs, I'm starting to get lost in them :)
<zyga> pedronis: it would say that there are some apps running but it is unable to say which so the check would fail
<zyga> fail as in prevent refresh
<zyga> ack
<zyga> pedronis: I updated https://github.com/snapcore/snapd/pull/6571 jus tnow
<mup> PR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>
<zyga> apart from hideous formatting I think it looks okay now
<zyga> pedronis: I also updated the remaining two branches from the invocation work
<mborzecki> pedronis: for the connection
<mborzecki> ah, damn, noticed that i switched to -internal with the paste
<dot-tobias> cjwatson: Can you please tell me the correct syntax for LP builds âSource snap channels for automatic buildsâ in snap package configuration? I want to use snapcraft from latest/stable and core16 from latest/beta, do I just use the channel name or full track/channel?
<pedronis> mborzecki: we might let you do with --dangerous but is a bit of special case
<pedronis> if they come from the store content needs to mathc
<pedronis> even just for connecting
<cjwatson> dot-tobias: either "latest/stable" and "latest/beta" or just "stable" and "beta" is fine
<cjwatson> dot-tobias: but do you really mean core16?  I think you probably mean core
<cjwatson> dot-tobias: AIUI core16 isn't really a thing yet
<dot-tobias> cjwatson: Thanks for the clarification! Seems the build errors are in fact because I specified core16 (currently only available on the beta channel), but want "core". Related question: I'm a bit confused by the âSeriesâ radio buttons up top in the same form â stating âBionic, for Ubuntu Core 16â. Does that mean it'll run a Bionic LXD container which then utilises the âcoreâ snap â¦?
<cjwatson> dot-tobias: We'll be cleaning up the confusing "Ubuntu Core 16" bit there in the near future since it doesn't make as much sense as it used to
<cjwatson> dot-tobias: In most cases now you should just select "Ubuntu Core 16" (without any explicit Ubuntu series) and let LP work out what to do for itself
<dot-tobias> cjwatson: Will do that, thank you very much!
<cjwatson> That causes it to dispatch to a container based on what "base" in snapcraft.yaml says
<cjwatson> So base: core18 dispatches to a bionic container, otherwise we dispatch to a xenial container
<cjwatson> dot-tobias: I've committed a patch to allow explicitly setting the channel for core16 (and for that matter core18), but it's not on production yet
<cjwatson> At the moment you can only select channels for core and snapcraft
<aleksander> hey! how can I make a confined snap "properly" access a unix abstract socket exposed by a process in the system?
<dot-tobias> cjwatson: Good to know. My use of âcore16â was more due to confusion between core and core16, so I think my snap will be fine with just âcoreâ for now. Only thing keeping me from upgrading to core18 is its reliance on a specific network-manager version
<aleksander> abeato: ^? (this is so that fwupd snapd can talk to a modem through the qmi-proxy socket)
<zyga> mvo: I added a small spread test to https://github.com/snapcore/snapd/pull/6574
<mup> PR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<Chipaca> aleksander: what provides the socket?
<aleksander> Chipaca: the socket is exposed by the "qmi-proxy" process, and the proxy process forwards QMI messages to a USB modem
<mvo> zyga: ta
<Chipaca> aleksander: but, how do you know that process is there when you install the snap?
<aleksander> Chipaca: well, that process is there when ModemManager is running
<Chipaca> aleksander: is modem manager in a different snap?
<aleksander> fwupd won't try to use the socket unless MM is running already
<aleksander> Chipaca: yes, ModemManager may be system-installed or in its own snap I guess
<Chipaca> aleksander: how does fwupd know mm is running?
<aleksander> actually, I'm not sure how libqmi/qmi-proxy are packaged, I guess they may be provided in the same snap as ModemManager? abeato should know
<aleksander> Chipaca: fwupd talks to MM via DBus
<Chipaca> it sounds like the modem manager interface should allow access to the qmi proxy
<aleksander> at the time fwupd talks to the modem through qmi-proxy, ModemManager knows nothing about the modem as fwupd "inhibits" the device
<aleksander> and I definitely wouldn't want to make ModemManager allow raw QMI commands anyway...
<zyga> small break for 3rd coffee
<zyga> are you guys also this sleepy lately
<zyga> or is it just me? :(
<zyga> is is the weather or is that the baby
<aleksander> zyga: haha, the newborn syndrome I guess? I feel that
<zyga> aleksander: I guess I got my answer :)
<aleksander> be prepared for years of sleep deprivation
<zyga> aleksander: yeah, constant wake-ups at night
<Chipaca> it's not that bad
<Chipaca> it gets better
<Chipaca> i'm told
<aleksander> hahaha
<zyga> yeah, I think it is only about three months
<aleksander> so I'm told as well, and I haven't had a full night of sleep in 3 years by now
<zyga> we're already 1/3rd of the way
 * Chipaca does some fast maths and reckons 14 years and counting
<aleksander> :D
<zyga> aleksander: oh really?
<Chipaca> zyga: it changes in nature
<zyga> in either way, COFFEE
<zyga> EAGAINCOFEEE
<aleksander> at 2.5 years old, the firl started to sleep better, which is when we had the baby boy, and back to square 1
<aleksander> the *girl started to sleep better
<Chipaca> aleksander: you should've paralellised
<zyga> Chipaca: lol
<aleksander> Chipaca: so back to the issue, is there any way to run this fwupd snap in a way that has access to the system-exposed unix abstract socket?
<dot-tobias> cjwatson: Just FYI, âcoreâ works fine but for whatever reason the ruby plugin only likes core16/core18
<dot-tobias> (https://github.com/snapcore/snapcraft/blob/ade7d65f0ba7870add2ed5ba5c016a93db2f88b8/snapcraft/plugins/ruby.py#L77)
<Chipaca> aleksander: not a priori, no
<aleksander> :(
<Chipaca> aleksander: is there already code in the snap that tries to do this?
<aleksander> in the fwupd edge snap channel, yes
<Chipaca> wait
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6571 is green
<Chipaca> aleksander: fwupd is classic
<mup> PR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>
<Chipaca> aleksander: i thought you said it was strict?
<aleksander> Chipaca: does this mean that fwupd as being a classic snap should be able to see abstract unix sockets without issues?
<Chipaca> aleksander: yes
<Chipaca> aleksander: 'classic' means 'as in a deb'
<aleksander> Chipaca: I may have assumed fwupd was confined, I'm still a bit lost on snap world :D (my first day actually, I'm learning...)
<Chipaca> aleksander: :-)
<aleksander> oh, that's fine then I guess? humm.. I wonder why I couldn't make that work
<Chipaca> aleksander: classic also means it won't work in the pure-snap world, as well as having security implications
<dot-tobias> kyrofa: Is there a reason that the ruby plugin only supports core16/core18, but not core as a base? (cf. https://bugs.launchpad.net/snapcraft/+bug/1794800)
<mup> Bug #1794800: Update the ruby plugin to be base aware <18.10-build-vm> <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1794800>
<zyga> aleksander: hey, I think we've met before, no?
<aleksander> Chipaca: I believe that's something that is taken for granted for the fwupd package
<Chipaca> a shame
<aleksander> zyga: hummmm not in the real world I think, but we discussed a long ago about a way to avoid MM poke TTYs
<ogra> IIRC theer was work started to eventually have a fwupd interface, no ?
<aleksander> (IIRC)
<zyga> aleksander: ahh, that's correct!
<zyga> aleksander: nice to see you here, welcome! :)
<aleksander> :D
<zyga> aleksander: if you have snap questions please ask us anything
<aleksander> zyga: we "fixed" the wrong poking of TTYs btw... :P
<zyga> oh? how does that work now?
<aleksander> zyga: only if we're very certain that a TTY belongs to a modem we do poke it, we have some heuristics in place to do that automatically
<vidal72[m]> is there a way to see which snaps use core18?
<aleksander> we've lost automatic detection of some old modems, but that's fine I guess
<pedronis> zyga: that series need at least a step 4, right? to pass sc_invocation at least to the functions changed in -3 to take is_normal_mode
<zyga> pedronis: yes, there will be more patches, depending on how big the PRs get
<zyga> pedronis: I'm making sc_invocation public now, so that we can easily pass it around
<pedronis> zyga: I'm happy to stop there to be clear, I don't think we need to do everything now
<pedronis> I mean at this step 4
<zyga> pedronis: OK
<zyga> pedronis: yeah, this should allow us to return to mvo's branch
<pedronis> yes
<zyga> pedronis: I'm happy to explore more refactoring and design once you have some interactive time
<aleksander> Chipaca: ok, I got more details about my issue with the proxy process... so, by the time fwupd wants to talk to the proxy, the proxy doesn't exist any more. fwupd is using libqmi/libmbim and this library is in charge of starting the process if it's not already running, so in this case, it's the fwupd snap the one trying to launch the proxy process, and failing
<aleksander> I think I'm going to just prepare a dirty hack to avoid this... :D
<abeato> aleksander, hey, just back from lunch
<abeato> aleksander, libqmi and libmbim are part of the MM snap
<aleksander> abeato: aha, I guessed that, and so the proxies as well?
<abeato> aleksander, if you need access to something from HW probably best to do is to modify the MM snapd interface
<abeato> aleksander, yes
<aleksander> abeato: so if there is any other app that wants to use QMI, it needs to rely on the MM snap somehow?
<abeato> aleksander, nope, you could bundle the library in that new snap
<aleksander> I have a feeling that the fwupd snap also has libqmi inside actually
<abeato> aleksander, in snaps in general we prefer to bundle most dependencies in
<aleksander> but the proxy is not there
<zyga> pedronis: is https://github.com/snapcore/snapd/pull/6571 something you want to review in detail again or are you waiting for the full series to review?
<mup> PR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>
<abeato> aleksander, hm, talking to the proxy from the MM snap could be tricky
<aleksander> abeato: and imagine this case: snap fwupd runs, uses libqmi and libqmi starts the proxy, then fwupd exits; what happens with the proxy?
<pedronis> zyga: I can review it,  it would be good to have also step 4 before starting landing things though
<abeato> aleksander, it should be stopped I guess
<aleksander> is it kept alive in the system, or no because it was run as part of the snap fwupd?
<aleksander> should or will? I mean, what will the snap setup do right now?
<abeato> aleksander, it will not do anything special unless instructed
<aleksander> oh ok ok
<zyga> pedronis: ok, I'll get that up
<abeato> aleksander, what I see is that there is a dependency here, I assume that ideally you will want to use the proxy from the MM snap to do the update
<abeato> aleksander, but the fw updater would run from a different snap
<aleksander> so I have several ways to fix this issue, I can make the proxy not exit after 30s (if no clients connected) and let it exit e.g. after 300s, and that would allow snap fwupd to do the upgrade properly using the proxy that was already running in the system; or otherwise I could package inside the fwupd snap the proxies as well, and let libqmi/libmbim start the proxies from within the snap if needed
<aleksander> at this point, I'm not even looking at the MM snap, I'm assuming there's a system-installed MM, truth be told
<aleksander> abeato: is the MM snap confined?
<abeato> aleksander, I think it is fine to assume MM is installed. Yes, was about to tell you that - the main issue is to be able to access the proxy from the fwupd
<abeato> if both are in different snaps
<aleksander> oh, so MM snap is indeed confined and the proxy within the MM snap runtime isn't accessible from other processes?
<abeato> correct
<aleksander> ouch :)
<aleksander> ok, won't tell anyone
<abeato> we do allow access to MM dBus interface
<abeato> which is the interface for the proxy? a socket?
<aleksander> yes, abstract unix socket
<Chipaca> abeato: two things
<Chipaca> abeato: one is that maybe access to that socket should be made part of the mm interface?
<Chipaca> abeato: second is that, given fwupd is classic, maybe they can access it anyway
<abeato> Chipaca, yeah, of a new interface
<abeato> s/of/or/
<Chipaca> abeato: of/or?
<Chipaca> heh
<aleksander> Chipaca: oh is that possible? can the socket be made part of the mm interface?
<Chipaca> there's already some qmi stuff in there
<Chipaca> so, maybe?
<Chipaca> dunno
<Chipaca> is it an interface to access mm, or is it an interface for mm to do its thing?
<aleksander> where's the mm snap interface defined?
<Chipaca> that is, is it a mm-client, or a mm-support?
<abeato> aleksander, https://github.com/snapcore/snapd/blob/master/interfaces/builtin/modem_manager.go
<aleksander> mm-support
<aleksander> provides shared access to the QMI port exposed by the kernel
<abeato> aleksander, not sure how familiar are you with slots/plugs. See https://docs.snapcraft.io/interface-management/6154 for an intro
<Chipaca> ah, so not that interface :-/
<Chipaca> abeato: is there a -client interface for mm?
<abeato> Chipaca, maybe it would make more sense to add a new interface instead of modifying mm's, as usually MM clients don't need direct access to the qmi proxy
<mborzecki> off to pick up the kids
<abeato> Chipaca, yes, used by mmcli and NetworkManager
<Chipaca> abeato: what interface do mm clients use to talk to mm?
<abeato> modem-manager interface
<Chipaca> hmmm
<Chipaca> abeato: but that's the interface that allows a snap to _be_ modem manager
<abeato> Chipaca, well, it defines a slot and a plug
<abeato> slot for MM, plug for users
<Chipaca> ah, i missed that bit :-)
<abeato> and maybe it would make sense to have a new interface, with the slot implemented by MM and the plug used by fwupd
<Chipaca> abeato: fwupd would need a whole new interface just for all the stuff it needs to do :-)
<abeato> Chipaca, agreed in deed :)
<cachio> mvo, hey
<cachio> https://paste.ubuntu.com/p/KXrkfp26WC/
 * pstolowski lunch
<cachio> this is an error I see in all the core systems
<cachio> is it intentional or it should exit 1 as it used to?
<mvo> cachio: this was requested by the mir team that apt should error - and it does make sense I think, its not usable afterall. is it causing problems for you?
<cachio> mvo, no, just a test failing
<mvo> cachio: which one? I though I fixed them
<cachio> mvo, ubuntu-core-apt
<cachio> it failed in all the executions yesterday
 * mvo looks
<zyga> pedronis: -4 is open https://github.com/snapcore/snapd/pull/6575
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<pedronis> zyga: thank you
<zyga> pedronis: I tweaked sc_invocation a little, there are many more cleanups that can be done on top but I think those are no longer on the critical path
<mup> PR snapd#6575 opened: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<zyga> pedronis: the new patches in that PR start with "cmd/snap-confine: make sc_invocation public"
<zyga> pedronis: please pay special attention to https://github.com/snapcore/snapd/pull/6575/commits/daa62250d09b01e59b66db203c31227202f22bbf
<mup> PR #6575: cmd/snap-confine: pass sc_invocation instead of numerous args around <Created by zyga> <https://github.com/snapcore/snapd/pull/6575>
<pedronis> zyga: that looks good, the param in the function could be const though no?
<pedronis> we just need to modify in enter ?
<pedronis> *functions
<zyga> pedronis: yes
<zyga> pedronis: though I would prefer to first solve the issue of ubuntu-core
<zyga> pedronis: where we modify the base snap name locally, see if we can make that properly earlier across the whole snap-confine invocation
<zyga> pedronis: or if we can move it away to snap-run
<zyga> pedronis: then we can make it constant with clarity
<pedronis> I'm doubtful about snap run
<pedronis> unless we want to do more than a refactoring
<pedronis> anyway it's clear that ubuntu-core fallback was broken
<pedronis> in more than one way
<pedronis> but is probably a good step to fix it as prep
<pedronis> anyway
<zyga> pedronis: after I'm done with current branches I can move that fallback earlier, and have it modify the invocation object before we pass the read only to other functions
<pstolowski> is google:ubuntu-14.04-64:tests/main/interfaces-daemon-notify failing a known issue / flaky test? i've been seeing it recently from time to time
<pedronis> zyga: yea
<mborzecki> pstolowski: the test is a little tricky, maybe some race between systemd/service and logs?
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479,
<mup> snapcraft#2482, snapcraft#2491, snapcraft#2492, snapcraft#2493, snapcraft#2494
<mup> PR snapd#6576 opened: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6576>
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2470, snapcraft#2473, snapcraft#2479,
<mup> snapcraft#2482, snapcraft#2491, snapcraft#2492, snapcraft#2493, snapcraft#2494
<Saviq> roadmr: hey, do we need one more vote on https://forum.snapcraft.io/t/track-request-multipass-core16/10192 ?
<roadmr> Saviq: yes, we do :/
<mup> PR snapcraft#2495 opened: Hide progress bar for dumb terminals - legacy branch <Created by eberkund> <https://github.com/snapcore/snapcraft/pull/2495>
<zyga> Saviq, roadmr: and now you have
<Saviq> zyga: thanks :)
<zyga> mvo: can you have another look at https://github.com/snapcore/snapd/pull/6574 please - I fixed a typo in the test and confirmed that it passes in qemu
<mup> PR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<zyga> (the typo was test-snapd.sh instead of test-snapd-sh)
 * zyga needs to run an errand
<kyrofa> dot-tobias, have you ever tried that? https://paste.ubuntu.com/p/kBmSrpQ89k/
<dot-tobias> kyrofa: No I did not, that's a very valid reason of course. Didn't want to imply an oversight or else, just wondering why a plugin might exclude a certain base (and because I hoped I could streamline my test/build workflow a bit :-) )
<kyrofa> dot-tobias, yeah there's sadly a bit of gap between using bases for core/core16 and using bases for core18. Core isn't seemingly a valid base, core16 isn't stable, so core18 is the only option if you're using a base. If you want to build for core, don't specify a base and you get the old snapcraft behavior
<dot-tobias> kyrofa: Will do, thanks for the clarification.
<kyrofa> dot-tobias, sure thing. Regarding your actual question though, we tend to only support bases we've explicitly tested. If Fedora were to make their own, the plugin would need to grow support for it and potentially work a little differently
<kyrofa> mvo, what kind of ETA are we looking at for the switch from core to snapd+core16?
<pedronis> #6571 needs a 2nd review
<mup> PR #6571: cmd/snap-confine: introduce sc_invocation <Created by zyga> <https://github.com/snapcore/snapd/pull/6571>
<mvo> kyrofa: is the context bases for snapcraft? we had a discussion about "base: none" during the malta sprint to unblock people
<kyrofa> mvo, indeed, good to know, thank you :)
<mvo> kyrofa: I need to step out for some minutes but maybe someone else from the team can summarize the idea, I can also when I'm back, we have notes and all that :)
<Chipaca> degville: https://forum.snapcraft.io/t/snap-epochs/10316
<degville> thank you Chipaca! I'll take a look.
<Chipaca> not super happy with it, feels like I should make a little graphic to make it clearer
<pedronis> Chipaca: ping wgrant about it as well
<Chipaca> wgrant: https://forum.snapcraft.io/t/snap-epochs/10316
<mup> PR snapd#6571 closed: cmd/snap-confine: introduce sc_invocation <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6571>
<zyga> jdstrand: FYI, replied on https://github.com/snapcore/snapd/pull/6574
<mup> PR #6574: cmd/snap-confine: track per-app and per-hook processes <Created by zyga> <https://github.com/snapcore/snapd/pull/6574>
<King_InuYasha> niemeyer, zyga: https://flocktofedora.org/
<King_InuYasha> Flock 2019 site is up :)
<pedronis> zyga: when you have time could you push master into -2 etc ?
<mup> PR snapd#6532 closed: daemon: allow downloading snaps blobs via .../file <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6532>
<zyga> pedronis: sure
<mwhudson> hm
#snappy 2019-03-08
<pstolowski> mornings
<pedronis> pstolowski: morning
<mvo> hey pstolowski and pedronis
<pedronis> pstolowski: when you have a moment could you review #6576 , is adding yet another attr merger, I wonder if it can reuse something or there is something to expose from else to avoid that
<mup> PR #6576: cmd/snap, client, daemon, ifacestate: show a leading attribute of a connection <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6576>
<pedronis> *elsewhere
<pstolowski> pedronis: looking at it right now
<pedronis> thank you
<pedronis> mvo: hi
<pstolowski> pedronis: i think we avoided attrs merger after all; it was floating around in the interface hooks PRs concerning policy check, but it eventually got replaced by implementation using Attrer interface and Lookup method, which looks dynamic/static attrs up without merging them physically
<pedronis> pstolowski: ah, I forgot
<pstolowski> pedronis: re that PR i'm wondering if we shouldn't leave merging to the client (instead of doing it api-side), more future-proof in case we ever want to distinguish them if the cli grows some new options (e.g. "show me only attributes set by hooks")
<pedronis> pstolowski: not sure, that sounds more like a debug thing
<pedronis> an attriute could be set statically or dynamically
<pedronis> it shouldn't matter too much
<pedronis> from somebody looking from outside
<mvo> pstolowski: hey, I remember you had a problem with check.DeepEqual going into a circular list and eating memory like crazy, what was the solution back then? it seems one of my tests has hit this now too
<pstolowski> maybe, probably. just a remark, when we do that it's set in stone as far as api is concerned, harder to change
<pstolowski> mvo: i've a fix proposed upstream, but upstream is silent. one sec
<pedronis> pstolowski: those set are supposed to be disjoint, right?
<pedronis> we don't let you override
<pedronis> if I remeber correctly
<pstolowski> pedronis: yes, we don't allow that
<pedronis> pstolowski: so we have options
<pstolowski> mvo: https://github.com/kr/pretty/pull/58
<mup> PR kr/pretty#58: Fix infinite recursion when diffing structs with cycles <Created by stolowski> <https://github.com/kr/pretty/pull/58>
<pedronis> anyway
<pedronis> pstolowski: like return a list of dynamic attr names
<mvo> pstolowski: ta
<pedronis> if needed
<pstolowski> mvo: i made a comment on that in the trello card as well a while ago.. perhaps we should move this into our tree
<pedronis> pstolowski: what I'm not sure though if the merging should happen in interface mgr or daemon
<pedronis> but that we can always change
<mvo> pstolowski: thank you!
<pstolowski> mvo: i recently helped Chipaca with this fix as well.. so seems to be recurring problem with tests
<mvo> pstolowski: yeah, I pinged in the PR again (the kr) one, but yeah, maybe we need to fork it :(
<pstolowski> mvo: yeah that would be unfortunate. let me know if the fix helps
<zyga> Hello
<zyga> If this continues I will start filing mornings off :/
<pstolowski> hey zyga, what happend?
<zyga> Homework late, kitchen cleaning late, bed time late, morning early kids prep. ENOSLEEP
<zyga> I woke up at 6 but fell asleep after kids went to school at 8
<pstolowski> aha
<pedronis> pstolowski: I did I think the last pass on 6562
<pstolowski> pedronis: ok, looking, ta
<pedronis> pstolowski: if the comments make sense, I can +1 it
<pedronis> pstolowski: as we discussed we can explore the Timing interface idea in a followup
<pedronis> #6572 needs a 2nd review
<mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
<pedronis> (it's part of a refactoring chain)
<pstolowski> pedronis: updated
<pstolowski> ah, updating description of the PR
<mvo> pstolowski: happy to look at the timings pr again as well, I'm excited about this (but I think I mentioned this before ;)
<pstolowski> mvo: ty :)
 * mvo just needs to finish his own PR first
 * zyga is slowly starting to work now
<zyga> mvo: I'll file the morning off
<zyga> sorry, I just feel so tired today
<zyga> https://github.com/snapcore/snapd/pull/6572 is an easy win
<mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
<cachio> mvo, hey
<cachio> is snapd 2.38 going to beta as well?
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/6568 is green and has two reviiews
<mup> PR #6568: overlord/snapstate: fix restoring of "old-current" revision config in undoLinkSnap <Created by stolowski> <https://github.com/snapcore/snapd/pull/6568>
<pstolowski> zyga: thanks; im not sure if pedronis would like to take a look?
<zyga> pstolowski: let's add him to the review
<mvo> cachio: yeah, 2.38~pre1 for the snapd snap should go into beta as well, once 2.37.4 for the snapd snap is in candidate I will arrange that
<mup> PR snapd#6577 opened: many: make Remodel() download everything first before installing <Created by mvo5> <https://github.com/snapcore/snapd/pull/6577>
<cachio> mvo, ok, I'll ask about what's missing
<cachio> I gave the +1 last friday
<pedronis> pstolowski: zyga:  is there something deep going on in 6568 ?  (I don't think I need to review everything)
<zyga> pedronis: I don't think so, just easier to get your qucik decision if you want to review it
<pedronis> the problem there is more that nobody has told us of this bug, maybe people don't expect the behavior
<pedronis> or maybe configure is not used a lot
<mvo> cachio: thanks, I just double checked and put the right 2.37.4 of the snapd snap into the beta channel - once that is validated please move it to candidate
<pstolowski> pedronis: i think the chances of hitting this were simply very very slim, not only you need to have configure hook, it also needs to change config to something new on refresh, and then you need to hit an error for undo to kick in
<pedronis> pstolowski: anyway I added John to review it
<pedronis> and removed myself
<pstolowski> ok
<zyga> mvo: do you have time for a quick review
<zyga> https://github.com/snapcore/snapd/pull/6572
<mup> PR #6572: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <https://github.com/snapcore/snapd/pull/6572>
<zyga> it is just taking a bit of code and wrapping it in a function
<mvo> zyga: meeting(s) now, after that yes
<mvo> zyga: thanks for looking into this why
<zyga> mvo: I'll take the whole day off, I'm just 100% useless today
<mup> PR snapd#6572 closed: cmd/snap-confine: populate enter_non_classic_execution_environment <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6572>
<dot-tobias> cjwatson: I just got this error on a LP builder while cloning a public Github repo: âReceived HTTP code 407 from proxy after CONNECTâ â couldn't find any forum entry, is this a known problem or should I just retry? Same snapcraft.yaml works fine on my local machine.
<cjwatson> dot-tobias: I need a link to the build in order to say anything useful
<cjwatson> Also we don't in general track Launchpad issues on the forum
<dot-tobias> cjwatson: https://launchpadlibrarian.net/414273477/buildlog_snap_ubuntu_bionic_armhf_wpe-webkit-mir-kiosk_BUILDING.txt.gz
<cjwatson> (Sometimes we post about major changes there)
<cjwatson> dot-tobias: Right, so the proxy gives two hours of internet access to a build; this is a rough cut-off to reduce things like potential botnet impact
<cjwatson> dot-tobias: The failure in this case was more than two hours into the build
<cjwatson> dot-tobias: So you need to take steps to ensure that your pulls happen generally towards the start of the build process, or at least not over two hours in
<cjwatson> dot-tobias: I think there are normally ways to do this by reordering parts
<dot-tobias> cjwatson: Ok, that explains it. Unfortunately, the wpe-webkit just takes a lot of time to build and I can't build the github part before wpe-webkit (or it would fail to find the libs).
<cjwatson> Can you use some kind of dummy part to pull it earlier and then have a subsequent part do the actual build?
<cjwatson> This is slightly more snapcraft wizardry than I possess myself, but I think I've seen people doing that kind of thing ...
<dot-tobias> cjwatson: May be an option, but I'll just put the checked-out tag in the snap source until the snap is finished. Just wanted to make sure its not something else ð Thanks!
<cjwatson> OK
 * cachio lunch
 * zyga woke up and pushed master into https://github.com/snapcore/snapd/pull/6573
<mup> PR #6573: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <https://github.com/snapcore/snapd/pull/6573>
<sergiusens> mvo: kyrofa pinging you as I saw your conversation flow through, had this in draft for over a week as I couldn't get to editing it before shutting y computer down: http://blog.sergiusens.org/posts/broader-use-of-bases-for-snaps/
<cjwatson> sergiusens: Ah, is LP going to need to look at build-base as well as base in order to work out what builder base images to dispatch to?  A bug would be appreciated if so to tell us what the priority order should be
<sergiusens> cjwatson: I will let the snapd folks timeline that, as the feature is only relevant once `base: none` is implemented on their side
<sergiusens> pedronis: mvo ^
<cjwatson> sergiusens: (see https://bazaar.launchpad.net/+branch/launchpad/view/head:/lib/lp/snappy/model/snap.py#L620)
<diddledan> do we know of any costs involved in layouts with many configured mounts?
<diddledan> this is where I'm heading... https://www.irccloud.com/pastebin/G7thrJLE/
<ijohnson> diddledan: it increases the call to apparmor_parser and generating the apparmor profile is proportional to the number of mounts last time I checked
<diddledan> I'm wondering which is faster and less resource intensive for runtime: either mounting everything up the wazoo or a huge launcher script
<ijohnson> diddledan: I think what you have there in that snippet is probably fine, I tried it with over 1000 layouts specified and apparmor crashed :-(
<diddledan> oops :-p
<ijohnson> I think layouts would be faster because you only pay that apparmor cost once, and then it's like those files are already there
<diddledan> I'm thinking about adding some of those into the gnome extension, you see, so I want to be sure it's better
<ijohnson> (because they are)
<diddledan> cc/ sergiusens
<sergiusens> diddledan: you should cc cmatsuoka and kenvandine instead ð
<diddledan> roger :-p
 * sergiusens is a plasma user
<diddledan> haha
<sergiusens> where less hacks are needed
<diddledan> this is my untested (yet) new launch script for mycroft - MUCH shorter! https://www.irccloud.com/pastebin/Vn6kaHm3/
 * cmatsuoka is a gnome user, but agrees with sergiusens 
<mvo> sergiusens: my memory is a bit hazy but I thought we said that snapcraft could simply script "base: none" from the snapcraft.yaml when generating the snap.yaml, am I misremembering that?
<sergiusens> mvo: that's for "base: core"
<sergiusens> base: none is an internally generated empty squashfs handled by snapd
<sergiusens> more useful for types base, snapd, kernel and gadget
<sergiusens> mvo: my post is short, skim through it :-)
<mvo> sergiusens: sorry, I was just reading to the last backscroll item, didn't see the other lines, I have the blog post now
<sergiusens> mvo: we had two discussions in parallel, one for use of base for other snap types and its implication and the other was how to get around core16 not being ready (which we agreed to support by allowing `base: core` in snapcraft.yaml and stripping it out from snap.yaml)
<sergiusens> mvo: cjwatson https://bugs.launchpad.net/launchpad/+bug/1819196
<mup> Bug #1819196: support for base: none and build-base <Launchpad itself:New> <Snapcraft:Triaged> <snapd:Triaged> <https://launchpad.net/bugs/1819196>
<cjwatson> ta
<mvo> sergiusens: thanks, I ponder over base: none, hopefully not too much work on our side
<diddledan> error: cannot validate snap "mycroft": layout "/opt/mycroft" uses invalid bind mount source "$SNAP_USER_COMMON/mycroft-core": reference to unknown variable "$SNAP_USER_COMMON"
<diddledan> aww
<diddledan> no fair :-p
<sergiusens> mvo: what i think was agreed to be a lot of work is supporting base for kernel and gadget
<sergiusens> base: none for a snap type of app shouldn't be that much work (just logic to generate an empty snap on the fly instead of downloading it from the store)
<sergiusens> anyways, lp and snapcraft need to wait for base: one to become a thing before we can do any work on that specific item
<sergiusens> for "base: core" in snapcraft.yaml I can work on now and IIRC from conversations, base: core is mapped in launchpad already
<sergiusens> ant that requires no work on snapd
<cjwatson> LP doesn't *have* to wait, but it may be wise to in case the definition changes
<cjwatson> base: core is dispatched to xenial base images and snapcraft from apt, yes
<cjwatson> same as no base
<sergiusens> cjwatson: right, it is the reason snapcraft waits too ð
<sergiusens> cjwatson: hmm, base: core needs to be dispatched to the snap though. I will look into where I slipped up in communication there as "base: core" is not even allowed today.
<cjwatson> err let me check what we actually did
<cjwatson> OK, indeed, base: core is dispatched to apt
<cjwatson> I mean, mainly by coincidence since we just needed a name for the default
<cjwatson> I'm at EOD but send me email or whatever with what the situation is actually supposed to be and I'll fix up the DB on Monday
<sergiusens> cjwatson: yeah, and I misread your statement. I will log a bug, thanks
<cjwatson> if "base: core" were dispatched to the snap then there'd be no difference between it and core16 from LP's point of view
<cjwatson> perhaps that's how it should be, I dunno
<sergiusens> cjwatson: yes, that is the proposal to get around the lack of a core16 coming anytime soon
<sergiusens> and it is all confusing as core is a base when at the same time, it is not
<sergiusens> I'll work it out in the bug, just EOD in peace
<cjwatson> will do :)
<mup> PR snapcraft#2494 closed: sources: handle network request errors <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2494>
<mup> PR snapcraft#2492 closed: store: handle invalid snap file errors <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2492>
<mup> PR snapcraft#2482 closed: docs: update pull request template <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2482>
<mup> PR snapcraft#1720 closed: kernel plugin: introduce kernel-channel to select from which channel â¦ <Created by piso77> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1720>
#snappy 2019-03-09
<mup> PR snapd#6573 closed: cmd/snap-confine: call sc_should_use_normal_mode once <Created by zyga> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6573>
<mup> PR snapcraft#2496 opened: many: support the use of build-aux/snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2496>
#snappy 2019-03-10
<luk3yx> Why do my snap's plugs not auto-connect if the core18 snap (the "base" one) is installed and the core snap isn't?
#snappy 2020-03-02
<marcustomlinson> hey guys, can snapd tell me if a particular snap has been installed and removed before?
<mup> PR snapcraft#2954 opened: cli: enable config file for base snapcraft command <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2954>
<ogra> sil2100, is vorlon not coming to the sprint ? i was hoping we could discuss some changes to ubuntu-image this week (i also wanted to talk to waveform about some pi-gadget breakage too, but i see he wont be here either)
<cjwatson> ogra: he's not
<ogra> cjwatson, yeah, just learned that in person from sil ...
<mup> PR snapcraft#2955 opened: repo: respect http proxy for apt update <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2955>
<mup> PR snapcraft#2794 closed: Add gnome 3 34 extension <Created by hellsworth> <Closed by hellsworth> <https://github.com/snapcore/snapcraft/pull/2794>
<mup> PR snapcraft#2945 closed: ci: only run docker builds for cron <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2945>
<mup> PR snapcraft#2956 opened: Add gnome 3 34 extension <Created by hellsworth> <https://github.com/snapcore/snapcraft/pull/2956>
<zyga> jdstrand: hello
<jdstrand> zyga: hey
<zyga> jdstrand: how are you doing? :)
<zyga> jdstrand: I'll try to progress on the session problem you highlighted this week, if I can
<jdstrand> zyga: I'm ok. it feels real weird not being there
<zyga> jdstrand: there are some empty-ish rooms around
<jdstrand> I heard
<zyga> jdstrand: not as a security review, but I was curious if https://github.com/snapcore/snapd/pull/8216 works on your system
<mup> PR #8216: tests: add session-tool, a su / sudo replacement <Created by zyga> <https://github.com/snapcore/snapd/pull/8216>
<zyga> can. you use it to spawn a shell as yourself
<zyga> and run snaps (with current snapd)
<zyga> I would like to eliminate the chance that there's something extra special about your system
<zyga> perhaps pam_apparmor
<zyga> or something like that
<jdstrand> zyga: is this for the transient scope issue I had?
<zyga> yes
<zyga> and a lot of other tests that effectively incorrectly run code as the "test" user
<jdstrand> zyga: so, the system in question was a default bionic desktop install in a vm
<jdstrand> (so no pam-apparmor
<jdstrand> )
<zyga> aha
<zyga> so it should work, I tested that case
<zyga> if you want to fire it up anyway feel free but not really needed
<jdstrand> I also don't have pam apparmor on my laptop
<jdstrand> zyga: I'm going to finish up some reviews today. when I am about to do those, I will try out 8216 and report problems, if any. if you don't herre from me, consider it fine. is that ok?
<zyga> jdstrand: that's great
<zyga> I'll push forward on getting to the bottom of the problem you uncovered
<mup> PR snapcraft#2955 closed: repo: respect http proxy for apt update <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2955>
<jdstrand> zyga: the next time you see mvo, can you let him know that I added comments to the Frankfurt sprint doc and various meeting invites?
<zyga> jdstrand: I will
<jdstrand> thanks
<zyga> jdstrand: he's here but we're in a meeting now
<jdstrand> zyga: it isn't urgent, just want him to be aware
<zyga> jdstrand: mvo now knows
<jdstrand> zyga: thanks! :)
<zyga> stgraber: do you think this bug is what you showed me a number of times
<zyga> https://bugs.launchpad.net/snapd/+bug/1865503
<mup> Bug #1865503: snapd (deb) fails to install snapd (snap) inside LXD on a buildd based image <core20> <snapd:Confirmed> <https://launchpad.net/bugs/1865503>
<zyga> stgraber: first snap installation fails in lxd
<stgraber> Yeah, run it again and it will succeed
<zyga> stgraber: right, it seems to be a bug at the intersection of udev and lxd
<zyga> stgraber: can you think of a reason why this fails, is it the sandbox lxd provides?
<zyga> stgraber: is there a way to detect LXD that's reliable
<zyga> stgraber: so that we could perhaps fix the base udev rules to not fail
<stgraber> /dev/lxd is usually a good bet, that or systemd-detect-virt
<zyga> stgraber: excellent
<zyga> stgraber: I'll run by foundations and check if this can be fixed
<zyga> rharper: can you please join a hangout, it should be in the invite
<rharper> y
<mup> PR snapd#8217 opened: o/devicestate: delay the creation of mark-seeded task until asserts are loaded <Bug> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8217>
#snappy 2020-03-03
<mup> PR snapd#8218 opened: [RFC] cmd/snapd, daemon/snapd: use multi call binary <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8218>
<mup> PR snapd#8219 opened: interfaces: use udev backend if udev socket exists <Created by zyga> <https://github.com/snapcore/snapd/pull/8219>
<zyga> jdstrand: hey
<zyga> jdstrand: will you dial in to the meeting?
<ijohnson> jdstrand: hey when you get a chance can you comment on https://forum.snapcraft.io/t/interface-request-cups-control-on-cups-snap-and-including-d-bus/15233? there's a desire to move this forward soonish, probably with a call in 2-3 weeks to account for traveling
<jdstrand> ijohnson: ack (this was actually one of the few things left in my mass push to clear out everything)
<jdstrand> assuming it is the topic I'm thinking of
 * jdstrand jotted it down
<ijohnson> thanks jdstrand!
<ackk> hi, does anyone know what could be wrong with  https://paste.ubuntu.com/p/v8YjXQZwrb/ ?
<mup> PR snapcraft#2957 opened: go plugin: do not remove install /bin directory before build <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2957>
<mup> PR snapcraft#2958 opened: dotnet plugin: use the new endpoint for releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2958>
<mup> PR snapcraft#2958 closed: dotnet plugin: use the new endpoint for releases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2958>
<mup> PR snapcraft#2959 opened: dotnet plugin: use the new endpoint for releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2959>
<mup> PR snapcraft#2959 closed: dotnet plugin: use the new endpoint for releases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2959>
#snappy 2020-03-04
<mup> PR snapcraft#2954 closed: cli: enable config file for base snapcraft command <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2954>
<mup> PR snapcraft#2957 closed: go plugin: do not remove install /bin directory before build <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2957>
<zyga> jdstrand: EHLO
<zyga> jdstrand: I have an idea to run by you
<zyga> jdstrand: we discovered that some containers do not run udev (they have it installed but udevd is down)
<zyga> jdstrand: this breaks interface setup
<zyga> jdstrand: I patched it to skip the entire udev backend
<zyga> jdstrand: and got feedback to write the files but not invoke udev as a safer way
<zyga> jdstrand: now the question:
<zyga> jdstrand: should we do that for all the backends, specifically apparmor
<zyga> jdstrand: write the profiles and not load them
<zyga> jdstrand: .
<mup> PR snapd#8210 closed: wrappers: add mount unit dependency for snapd services on core devices  <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8210>
<ogra> hmm
<ogra> ogra@localhost:~$ sudo ls -alh /root/snap/
<ogra> total 16K
<ogra> drwxr-xr-x 4 root root 4.0K Mar  4 10:56 .
<ogra> drwx------ 3 root root 4.0K Oct  3 12:09 ..
<ogra> drwxr-xr-x 6 root root 4.0K Mar  2 08:39 mir-kiosk
<ogra> drwxr-xr-x 4 root root 4.0K Oct  3 12:09 pc
<ogra> why do i have a dir for the gadget in /root/snap ??
<zyga> ogra: because it runs as root and has HOME=/root/snap/$SNAP_NAME
<ogra> zyga, "runs" ?
<ogra> its a gadget :)
<zyga> it must have a hook
<ogra> or is that from some hook
<ogra> ah
<mup> PR snapd#8220 opened: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8220>
<mup> PR snapd#8216 closed: tests: add session-tool, a su / sudo replacement <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8216>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/8220 is interesting
<mup> PR #8220: interfaces/seccomp: allow passing an address to setgroups <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/8220>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/8219 is a priority for 2.44 that came up during the sprint
<mup> PR #8219: interfaces: use udev backend if udev socket exists <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/8219>
<ogra> zyga, some cosmetics for you guys ... https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1866058
<mup> Bug #1866058: gadget hooks should not write to /root/snap by default <snapd (Ubuntu):New> <https://launchpad.net/bugs/1866058>
<zyga> ogra: aha
<zyga> ogra: hmmm
<ogra> full of assumptions :)
<ogra> if you think this is wrong, just close it though
<zyga> ogra: I think it's interesting but I don't know what to do about HOME in such a case
<zyga> ogra: I'll ask others for opinions
<ogra> yeah ... it is purely cosmetic anyway
<jdstrand> zyga: hey, ack. I'm going into a meeting but otoh not running the udev backend means the device cgroup isn't going to work right (too restrictive). disabling that results in degraded policy (some apparmor rules depend on the cgroup) which would mean PartialConfinement
<zyga> jdstrand: I'll be in the call
<jdstrand> not removing the cgroups should be 'ok' security-wise since it should just be too strict
<zyga> jdstrand: note that without udev /deve is really not populated
<jdstrand> but, I want to look at it more carefully and comment
<zyga> jdstrand: sure
<zyga> jdstrand: note that the PR has two approaches
<zyga> jdstrand: prior approach removed udev backend
<jdstrand> zyga: well, that is an assumption of container setup. what if this isn't a container and udev just happens to not be running, or a container in the same way
<zyga> jdstrand: and we changed that to avoid interacting with the system-key
<zyga> jdstrand: it's a container configured not to run udev (buildd) even if installed (we do install it as a snapd dependency)
<zyga> jdstrand: we are ready with the call
<jdstrand> zyga: but the code afaics isn't checking any of that
<zyga> jdstrand: can you clarify what is not being checked?
<jdstrand> zyga: well, so, I haven't read the PR closely, but the problem statement includes 'some containers don't have udev' but the PR will fire on 'any system that doesn't have udev'
<jdstrand> zyga: we aren't limiting the solution to containers in other words. I am not saying we should, but that is what I meant by 'not being checked'
<mborzecki> jamesh: commenting out the line that loads from local cache makes the fonts look ok, so mabe the cache format did change, just that now i'm skippinng my real $HOME/.cache/fontconfig ?
<jamesh> mborzecki: But if your default font came from /usr/share/fonts, you'd have the same problem with caches in /var/cache/fontconfig
<jamesh> it's not just the user's home dir
<mborzecki> jamesh: i think i need to run the bisect again, with adding the xdg path to the ~/.fonts.conf
<sil2100> ogra: hey! So I merged the --disable-console-conf change - one thing worth remembering though is to adjust it for uc20 once it's a thing
<sil2100> So that it always does what it's intended to
<ogra> yeah ... i havent tried UC20 at all yet but will roll an UC18 image to test and verify
<sil2100> ogra: it should land in edge soonish
<ogra> and my team owes you $BEER .)
<ogra> yeah
<zyga> jdstrand: I think this is fine, I only meant to say "we saw a system, namely a container, that didn't use udev"
<jdstrand> zyga: I'm looking at it now
<zyga> jdstrand: thank you
<zyga> jdstrand: that's correct
<zyga> ah
<zyga> sorry, my backlog moved
<zyga> I read your response from two hours ago
<mup> PR snapcraft#2960 opened: specification: base plugin and plugins for core20 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2960>
<mup> PR snapcraft#2927 closed: requirements: uprev lxml to 4.5.0 <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2927>
<mup> PR snapcraft#2942 closed: pluginhandler: do not search installdir or stagedir for dependencies <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2942>
<mborzecki> jamesh: so this is the commit that broke stuff: https://gitlab.freedesktop.org/fontconfig/fontconfig/commit/c4324f54ee16e648ba91f3e9c66af13ab3b1754c
<mborzecki> jamesh: feels like we've been there already
<mborzecki> jamesh: we were https://forum.snapcraft.io/t/snapped-app-not-loading-fonts-on-fedora-and-arch/12484/30
<jamesh> mborzecki: weirdly, the fontconfig inside the platform snap is from before all the UUID nonsense.  I would have thought that change effectively reverted to the old behaviour
<jamesh> mborzecki: thinking about it some more, the incompatibility is probably further back: it's just that the versions before that commit produce cache files the snap can't see
<jdstrand> zyga: ok, I spent a lot of time on PR 8219 and I wasn't thinking about it correctly up above. please see my PR comments
<mup> PR #8219: interfaces: use udev backend if udev socket exists <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/8219>
<zyga> jdstrand: ack, thank you
<cjp256> does the snap search cache get updated intermittently?
<cjp256> i search `flutter-gallery` and get no hits, but it installs fine
<mup> PR core20#26 opened: Disable emergency.target & debug-shell, unless kernel cmdline is dangerous <Created by xnox> <https://github.com/snapcore/core20/pull/26>
#snappy 2020-03-05
<mup> PR snapd#8221 opened: ovelord/snapstate: update only system wide fonts cache <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8221>
<mup> Bug #1866168 opened: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor <Snappy:New> <https://launchpad.net/bugs/1866168>
<mup> PR snapd#8222 opened: wrappers: import /etc/environment in all services <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8222>
<mup> Bug #1866168 changed: Calls to org.freedesktop.DBus.Introspectable get blocked by AppArmor <snapd:New> <https://launchpad.net/bugs/1866168>
<zyga> jdstrand: FYI, I noticed we have failures on opensuse that are not captured by spread (though IIRC the systems were disabled recently)
<zyga> https://build.opensuse.org/package/live_build_log/system:snappy/snapd/openSUSE_Tumbleweed/x86_64
<zyga> all related to seccomp
<jdstrand> zyga: did they update libseccomp or golang seccomp? if so, sounds like there might be a regression
<zyga> jdstrand: they might have, I left all non-ubuntu systems back home
<zyga> jdstrand: I'll file a bug to track this down next week
<zyga> jdstrand: just FYI in case this shows up in ubuntu
<jdstrand> cool, thanks
<jdstrand> iirc, they did but a new release
<jdstrand> (or are about to...)
 * jdstrand -> meeting
<zyga> oh
<zyga> oh boy
<jdstrand> zyga: https://github.com/seccomp/libseccomp/commit/fcb1395979f784387984e34752c07a5e8530c023
<zyga> hmm
<zyga> thanks
<zyga> doesn't seem like what we're seeing
<zyga> perhaps it's the kernel too?
<zyga> jdstrand: we should eventually look at enabling the binary tree optimizer https://github.com/seccomp/libseccomp/commit/a3732b32b8e67a5c466a625f0e1e0d0bfde5ee0b
<ackk> hi, isn't "snap stop --disable ${SNAP_INSTANCE_NAME" supposed to stop all services for the snap?
<zyga> ackk: what are you seeing happen?
<zyga> (if that's grammatically correct)
<mborzecki> zyga: wonder how different that optimizer is from the patches we've tried in https://forum.snapcraft.io/t/concerns-about-performance/12194/8 is it the same patch?
<ackk> zyga, I'm testing a change in the maas snap to split services. I have a "install" hook which ends with that stop command, but then I see: https://paste.ubuntu.com/p/H6V2vXKGCn/
<ackk> zyga, right after install
<jdstrand> zyga: can you have someone add a meeting link for the compression meeting?
<jdstrand> ijohnson: ^
<jdstrand> roadmr: ^
<ackk> zyga, side question, I assume there's no way (yet) to tell snapd not to autostart services on install?
<ijohnson> jdstrand: ack
<roadmr> jdstrand: yes, a sec
<jdstrand> I'm in
<jdstrand> thanks
<roadmr> jdstrand: O_o
<roadmr> jdstrand: still waiting for others to arrive (snapd folks)
<roadmr> I am apparently an idiot :)
<jdstrand> heh
<mup> PR snapcraft#2961 opened: build providers: remove over use of -i in sudo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2961>
<zyga> ackk: this is a question to ijohnson
<ijohnson> ackk whats the problem
<zyga> jdstrand: oh, sorry, I missed your ping
<ijohnson> also I'm at a sprint so intermittently available
<ackk> ijohnson, so my first question is whether this is the correct status (from snap info) when the install hooks runs "snap stop --disable $SNAP_INSTANCE_NAME" at the end: https://paste.ubuntu.com/p/H6V2vXKGCn/
<ackk> ijohnson, some services are actually running
<ackk> ijohnson, side question was whether it's possible to prevent them from starting up at all at snap install (I know it wasn't, just wondering if there's any progress in that direction)
<ijohnson> ackk: yes it is possible to stop services from starting at all
<ijohnson> ackk: what you do is call `snapctl stop --disable` exactly like you're doing during the _install_ hook specifically
<ijohnson> ackk: the install hook runs before any services are started
<ijohnson> ackk: also note that the install hook does not run on refresh, for that you need to use the post-refresh hook
<ackk> ijohnson, I'm doing that in the install hook
<ijohnson> ackk: are you testing this with the snap already installed ?
<ijohnson> the thing I am currently checking on for you is whether you can disable all services with just the snap name
<ackk> ijohnson, no, first install
<ijohnson> I don't remember if that works or is supposed to work
<ackk> ijohnson, I'm pretty sure services used to be started by default before install hook runs. but running stop --disable used to work stopping there
<ackk> not sure why it's not working in this case
<ijohnson> ackk: I don't think it has ever been the case that services were started before the install hook
<ijohnson> ackk: perhaps you're thinking of the configure hook?
<zyga> ijohnson, ackk: just thinking about what you guys are discussing, I wonder if there's anything we could learn from systemd presets that could be, somehow, represented in snapd
<ijohnson> ackk: AFAICT I don't think `snapctl stop --disable $SNAP_INSTANCE_NAME` should work, I think it always has to be `snapctl stop --disable $SNAP_INSTANCE_NAME.$SVC_NAME`
<zyga> even if there's just one preset and that preset is "the service is disabled"
<zyga> having a way to express that with a common language might be useful
<ackk> ijohnson, it used to work, we are using it elsewhere
<ijohnson> ackk: can you show me an example ?
<ackk> ijohnson, and indeed if you look at the paste services are all disabled
<ijohnson> of where it used to work ?
<ackk> ijohnson, just some of them aren't stopped
<ijohnson> I am confused how it could work
<ackk> ijohnson, why wouldn't it?
<ackk> snapctl runs those commands at the end of the hook
<ijohnson> ackk: because the install task is and always has been ordered before the start-snap-services task
<ijohnson> this is internal to snapd
<ijohnson> ackk: so I have tested and actually what you have with `snapctl stop --disable $SNAP_NAME` should work fine, indeed it does in my very simple example snap
<ijohnson> ackk: so since you say this isn't working, can you file a bug on bugs.launchpad.net/snapd ? I need to start another meeting shortly and will not be able to debug this much more with you unfortunately
<ackk> ijohnson, sure, I'll try to get more info and then file it
<ackk> ijohnson, thanks
<ijohnson> zyga: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1861177
<mup> Bug #1861177: seccomp_rule_add is very slow <patch> <server-next> <snapd:Triaged by anonymouse67> <libseccomp (Ubuntu):Triaged> <https://launchpad.net/bugs/1861177>
<jdstrand> ijohnson: hey, do you have different numbers tacked onto anonymouse dependent on the site login? :)
<jdstrand> anonymouse64, anonymouse67...
 * jdstrand is going to map these out
<ijohnson> jdstrand: yes, it's a long story
<ijohnson> I am both of those
<jdstrand> ijohnson: I've yet to meet anonymouse65. I've heard great things about that guy
<jdstrand> :)
<ijohnson> haha :-)
<mup> PR snapcraft#2961 closed: build providers: remove over use of -i in sudo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2961>
<mup> PR snapd#8223 opened: interfaces/u2f: Add Titan USB-C key <Created by stgraber> <https://github.com/snapcore/snapd/pull/8223>
<JuJUBee> I installed a snap application in an LTSP environment.  My user home dir is /home/admin.  My students are /homes/username  I can run the snap app but they cannot.
<zyga> JuJUBee: this is a known limitation
<zyga> JuJUBee: such home directories are sadly not supported
<JuJUBee> zyga, does https://forum.snapcraft.io/t/how-can-i-use-snap-when-i-dont-use-home-user/3352/2  suggest otherwise?
<zyga> JuJUBee: no, it's not, it talks about certain things that we could eventually do; today if you want a user to use snaps their home directory must really be (as in directory inode) in /home
<zyga> you can bind mount it or mount it there
<zyga> but it cannot be a symlink
<zyga> the rest about HOMEDIRS is irrelevant for /homes (note the plural) because /homes is invisible from the point of view of a snap application
<zyga> it's a long thread but I generally know what happens at runtime and I can only summarize that /homes/$LOGNAME is not supported
<JuJUBee> zyga, so should I just mount the disk that is /homes on /home instead?
<zyga> JuJUBee: yes
<zyga> JuJUBee: can you also leave me a message as to why you chose this layout
<zyga> we will try to support arbitrary home directories better
<zyga> but understanding the use cases helps
<JuJUBee> zyga, where would you like me to leave it?  pm?
<zyga> JuJUBee: just here
<zyga> I'm getting dinner in 5 minutes
<zyga> so I won't respond
<zyga> but I'm online 24/7 so I will read it and respond later, if you are available
 * zyga is AFK
<JuJUBee> zyga, OK, so I usually keep my users on a separate volume so upgrades are easier.  I used to use local_homes for the local admin account and /home for my users but it was easier to use /home during the install and mount the extra volume on /homes after the fact.
#snappy 2020-03-06
<clmsy> hi everyone. i don't know if this is the correct channel if not apologies... i have a question. through snapcraft i build a kernel and a gadget snap and get them together with ubuntu-image into an .img file.
<clmsy> i can boot into it by flashing into a usb no problems.  But how can i make that img file installable from a usb drive not just a live bootable usb
<mup> PR snapd#8224 opened: many: clean separation of bootenv mocking vs mock bootloader kinds  <Created by pedronis> <https://github.com/snapcore/snapd/pull/8224>
<mup> PR snapd#8190 closed: overlord, taskrunner: exit on task/ensure error when preseeding <Preseeding ð> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8190>
<ogra> clmsy, there will be an installer some day to flash to internal disk from external storage, but thats not there yet ... an interim solution is described at https://forum.snapcraft.io/t/installing-ubuntu-core-on-devices-with-internal-drives/5494
<clmsy> thx ogra :)
<ijohnson> zyga: https://bugs.launchpad.net/snapd/+bug/1860369
<mup> Bug #1860369: Python apps broken in MicroStack (a classic snap) after Jan 14 snapcraft update <core20> <snapd:Triaged by anonymouse67> <https://launchpad.net/bugs/1860369>
<mup> PR snapd#8225 opened: snapcraft.yaml: use sudo -E and remove workaround <Created by mvo5> <https://github.com/snapcore/snapd/pull/8225>
<mup> PR snapd#8226 opened: interfaces/policy/policy_test.go: add more tests <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8226>
<mup> PR snapcraft#2962 opened: Go: unable to build snap when using `go mod` and main package is not in the root <Created by pavel-d> <https://github.com/snapcore/snapcraft/pull/2962>
#snappy 2020-03-07
<mup> PR snapd#8227 opened: interfaces/audio_playback: Fix pulseaudio config access <Created by Erick555> <https://github.com/snapcore/snapd/pull/8227>
#snappy 2020-03-08
<mup> PR snapd#8228 opened: Feature/uc20 arm kernel extract prepare image <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8228>
