#snappy 2015-04-10
<JamesTait> Good morning all; happy Friday, and happy Siblings Day! :-D
<sergiusens> mvo: it's frameworks (list versus string)
<sergiusens> mvo: I was going to fix last night but got distracted fixing other things
<mvo> sergiusens: yeah, fixed
<mvo> sergiusens: no worries
<sergiusens> mvo: just removed the line a suppose
<sergiusens> mvo: btw, mind looking at my latest u-d-f mps?
<mvo> sergiusens: yeah, just removed it
<mvo> sergiusens: sure, do you have a url?
<mvo> sergiusens: I will need lunch first though
<sergiusens> pitti: fwiw, was just trying to know the status on ntp, not sure you were on top of it or who was
<sergiusens> mvo: https://code.launchpad.net/goget-ubuntu-touch/+activereviews
<pitti> sergiusens: we have timesyncd enabled by default now, AFAIK that was the intended ntp client for snappy?
<sergiusens> mvo: the ones from les that 24hrs ago :-)
<sergiusens> pitti: oh, it is, great!
<lool> sergiusens: how do I use your new beaglebone snap straight from the store?
<sergiusens> lool: call it by name
<sergiusens> lool: e.g.; beagleboneblack.sergiusens
<sergiusens> --oem beagleboneblack.sergiusens
<lool> sergiusens: sudo ubuntu-device-flash core \ --platform am335x-boneblack \ --size 4 \ --oem beagleboneblack.sergiusens --developer-mode --channel=ubuntu-core/devel-proposed -o bbb.img
<sergiusens> lool: --size is 4 by default
<sergiusens> lool: just sudo ubuntu-device-flash core --output bbb.img --channel edge --oem beagleboneblack.sergiusens is enough
<sergiusens> lool: I tried to apply sane defaults everywhere to type less
<lool> sergiusens: what defines "edge" as a channel?
<lool> sergiusens: and how does it figure --platform am335x-boneblack?
<lool> (I'd like to do the same for pi)
<lool> ok, found channel maps
<sergiusens> lool: platform is in the oem snap
<sergiusens> lool: the channel maps is a shorthand, (and some form of consistency with the snappy tool)
<lool> it kind of feels bad to have this in the tool rather than as server side aliases, but I can see why it's handier for now
<beuno> lool, sergiusens, started working on a spec: https://docs.google.com/document/d/1-BFwOcM7yq3feowdAL9SVW5UZkNHiE0q3duXBMUkkyY/edit
<sergiusens> lool: I was waiting for the system image rename to happen to make this easier
<lool> beuno: I guess you've already seen the naming of the chrome release channels
<lool> https://www.chromium.org/getting-involved/dev-channel
<lool> it seems we have the same number of channels, but with different names
<lool> (that's fine of course)
<beuno> lool, we have 1 more!  :)
<beuno> anyway, its subject to change, it captures the discussions we've had so far
<lool> (RaspberryPi2)ubuntu@localhost:~$ sudo snappy install docker_1.5.0.001_multi.snap
<lool> Installing docker_1.5.0.001_multi.snap
<lool> 2015/04/10 13:34:53 Signature check failed, but installing anyway as requested
<lool> mkdir /apps/docker/1.5.0.001/meta/framework-policy: permission denied
<lool> unpack docker_1.5.0.001_multi.snap to /apps/docker/1.5.0.001 failed with exit status 1
<lool> kickinz1: ^
<lool> mvo: ^ does the above sound familiar (snappy go version on image 220 on rpi2)
<fionnan> I'm trying to get docker to load a dockerfile on snappy but get the error `2015/04/10 13:32:38 open dockerfile.tar: permission denied` when I try to do it as the ubuntu user and get `sudo: docker: command not found` when I do it with sudo, anyone have any ideas what I could be doing wrong?
<kickinz1> fionnan, you need to have your Dockerfile in /home/ubuntu/apps/docker/1.3.xxx/
<fionnan> if anyone knows of any docs about using docker on snappy would be great too, I can't seem to find anything :(
<fionnan> kickinz1: cool, thanks!
<kickinz1> then in this dir you run docker buid...
<sergiusens> lool: I think Chipaca is dealing with this
<Chipaca> sergiusens: with what?
<lool> Chipaca: see above error when installing docker
<kickinz1> lool, hdstrand had this yesterday evening, but it was related to a bad docker-daemon.apparmor.
<lool> 15:35 < lool> mkdir /apps/docker/1.5.0.001/meta/framework-policy: permission denied
<lool> 15:35 < lool> unpack docker_1.5.0.001_multi.snap to /apps/docker/1.5.0.001 failed with exit status 1
<fionnan> kickinz1: that fixed it!
<lool> kickinz1: I've built the rootfs minutes ago against devel-proposed; how do I get the fix?
<Chipaca> lool: that does not look like something i'm doing, no
<Chipaca> lool: why did you get permission denied on mkdir?
<kickinz1> lool: I will upload a more recent one for you to test, but the one I sent to you was supposed to work
<Chipaca> ooh, wait, that might be me
 * Chipaca looks a bit deeper
<sergiusens> mvo: jodh I got this weird problem when upgrading from d-p to devel-proposed http://paste.ubuntu.com/10791611/
<lool> kickinz1: I have beagle up too
<Chipaca> lool: so, that error itself is not me afaict, but i'd be interested in knowing how you got there
<lool> ubuntu-core     2015-04-10 220
<Chipaca> lool: are the permissions in the docker tar wrong?
<lool> Chipaca: I dont know, I can check
<Chipaca> lool: please
<lool> Chipaca: look alright to me
<lool> Chipaca: http://paste.ubuntu.com/10791622/
<Chipaca> yep, those lok alright
<Chipaca> look*
<Chipaca> lool: do you have anything in dmesg?
<sergiusens> Chipaca: remember that snappy calls unpack with reduced privs
<Chipaca> sergiusens: but i don't see any reason for a mkdir at random to fail on unpack, which is what's reported here
<jodh> sergiusens: it's an upgrader bug resulting from the recent rework. Fixing...
<Chipaca> lool: so, i don't know where/how you're trying to make that work, but i just tested the docker thing locally and it installed without a hitch
<Chipaca> lool: so i'd really like to know more :)
<lool> [   64.460170] audit: type=1400 audit(1428673111.960:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="system-status.victor_system-status_1.0.3" pid=805 comm="apparmor_parser"
<lool> [   66.848594] audit: type=1400 audit(1428673114.348:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="pastebinit.mvo_pastebinit_1.4.0.0.1" pid=805 comm="apparmor_parser"
<lool> [   86.906565] audit: type=1400 audit(1428673134.408:8): apparmor="DENIED" operation="capable" profile="system-status.victor_system-status_1.0.3" pid=884 comm="system-status" capability=12  capname="net_admin"
<lool> are the only dmesg bits
<Chipaca> lool: dmesg -T will give you saner timestamps, for next time :)
<Chipaca> none of those seem relevant to docker
<lool> good to know
<lool> Chipaca: no
<lool> Chipaca: would also be surprized that snappy install would run confined
<lool> so mkdir failing is weird
<lool> Chipaca: I'll test on BBB in a few, with an updated snap
<Chipaca> lool: what are you testing on, here?
<lool> Chipaca: oh sorry, dmesg is from wrong board
<Chipaca> lool: is this the same vm that was saying "no space left on device"?
<lool> I actually reinstalled since
<lool> Chipaca: so yes, it is from same vm
<lool> Chipaca: and I think the issue is missing modules
<lool> [Fri Apr 10 13:00:10 2015] systemd-journald[458]: Failed to create new runtime journal: No space left on device
<lool> probably lack of tmpfs
<lool> right, lsmod is empty
<lool> the modules are there in rootfs, but not initrd
 * lool goes updating
<Chipaca> lool: so it looks like that vm is otherwise fubar'ed
<lool> yeah
<Chipaca> lool: if you can reproduce the issue with a vm that is not already broken let me know :)
<Chipaca> i really think we need a "sanity check" command in snappy
<Chipaca> ... but there's so much more stuff we need :)
<lool> bah I foobarded the initrd
<lool> /sbin/udevadm: line 2: ï¿½ï¿½HLï¿½Fï¿½kï¿½ï¿½ï¿½@ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½ï¿½
<lool> somehow not good
<lool> /sbin/udevadm: line 1: ELF: not found
<lool> ppisati: sorry, mind reminding me how to properly repack initrd? I gunzip-ed | cpio -i, and am repacking with find . | cpio --quiet --dereference -o -H newc | lzma -7 > ../new-initrd.lz
<lool> well, I'll start with gzip
<eltigre> is it possible to develop/tinker on snappy core on raspberry pi without a second raspberry pi running ubuntu?
<ogra_> lool, abootimg-unpack-initrd ... abootimg-pack-initrd
<ogra_> we have helpers for this ;)
<lool> ok, managed to repack initrd
<lool> ogra_: thanks
<lool> it was actually my unpacking which was incorrect
<lool> (forgot -d to cpio)
<lool> I still get [   50.591157] systemd-journald[399]: Failed to create new runtime journal: No space left on device
<lool> ppisati: so for some reason the modules dep were out of date
<lool> I still get the dreaded [   50.525271] systemd-journald[332]: Failed to create new runtime journal: No space left on device
<eltigre> I don't see any information about "cross compiling" or porting applications to raspi/snappy, so maybe it isn't that easy
<lool> eltigre: http://hypernephelist.com/2015/03/09/cross-compilation-made-easy-on-ubuntu-with-sbuild.html
<lool> eltigre: it depends *what* you're cross-compiling though
<lool> eltigre: I typically did all the MWC snaps with cross-compilation
<lool> go / C / C++ ones mainly
<lool> but sometimes it can be a pain
<eltigre> I would be using python
<lool> eltigre: are there native bits?
<eltigre> I think I will go the raspbian route for the foreseeable future
<eltigre> maybe
<lool> eltigre: I'm not sure why it would be any easier with raspian
<eltigre> it's pretty easy to run into C extensions you didn't expect in Python nowadays
<lool> *raspbian
<eltigre> it compiles stuff
<eltigre> slowly, but it does
<eltigre> and it has a package manager, unlike snappy
<lool> we do have a package manage, it's snappy!  :-)
<eltigre> no, that's an application manager
<lool> eltigre: right, we dont have snaps for a build environment
<eltigre> the difference being that you have to somehow get your dependencies in the app itself, as far as I understand it
<lool> that's right
<lool> kickinz1: ok, I managed to install docker on rpi2 now
<eltigre> which is on one hand a very good idea, but on the other... well... unfamiliar and currently much more work
<lool> eltigre: I think that's about right
<lool> it's less familiar and more work right now
<lool> but it pays off in the end
<lool> eltigre: you can have an Ubuntu chroot on a snappy install where you do the builds
<kickinz1> lool: ok, I have a new package for you then.
<lool> or a qemu-arm schroot on your desktop (above blog post) or cross-build stuff
<eltigre> problem is, I'm not that familiar with the chrooting stuff... I hardly even grokked docker
<lool> eltigre: now specifically for python, you'd want to grab barry who's worked exactly on this topic
<lool> eltigre: https://lists.ubuntu.com/archives/snappy-devel/2015-April/000428.html
<eltigre> thanks
<lool> kickinz1: does it intentionally have the exact same name as the previous one?
<lool> 2015/04/10 14:31:01 Signature check failed, but installing anyway as requested
<lool> open /apps/docker/1.5.0.001/meta/docker-daemon.seccomp: permission denied
<lool> unpack docker_1.5.0.001_multi (1).snap to /apps/docker/1.5.0.001 failed with exit status 1
<jdstrand> that's weird
<lool> kickinz1, jdstrand: The older snap installs fine though
<jdstrand> lool: this might be because you are installing the same version over other?
<kickinz1> lool: on bbb?
<lool> kickinz1: both on rpi2
<lool> jdstrand: maybe
<lool> jdstrand: I had snappy removed though
<jdstrand> lool: what is ls -l /apps/docker/1.5.0.001/meta/
<lool> right now after successful install of old snap: http://paste.ubuntu.com/10791980/
 * lool removes
<jdstrand> that looks fine
<lool> now /apps/docker exists but is empty
<jdstrand> lool: do ls -l after removal too
<jdstrand> ok, that is what I've seen
<lool> now installing again the new one
<lool> I've renamed it to drop the " (1)" in the filename
<lool> ah that worked
<lool> jdstrand: was just a filename issue
<jdstrand> ok cool
<lool> now I got http://paste.ubuntu.com/10791992/
<kickinz1> jdstrand seems ok on bb for me
<lool> kickinz1: ok, installed latest snap on pi2; what do I confirm?
<kickinz1> lool: docker run -it armbuild/ubuntu
<kickinz1> on the container just try some things like: "apt-get update && apt-get upgrade"
<lool> FATA[0000] Post http:///var/run/docker.sock/v1.17/containers/create: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
<kickinz1> then docker stop "id of the container"
 * lool removes docker, and grabs latest package
<kickinz1> lool, sudo systemctl status docker_docker-daemon_1.5.0.001.service
<lool> kickinz1: switching to your latest snap first
<kickinz1> lool ok
<lool> installing
<lool>   Process: 1347 ExecStop=/apps/docker/1.5.0.001/bin/docker.stop (code=exited, status=0/SUCCESS)
<lool>   Process: 1319 ExecStart=/apps/docker/1.5.0.001/bin/docker.start (code=exited, status=1/FAILURE)
<kickinz1> lool, can you paste the tailed output of "sudo journalctl -l"
<jdstrand> lool: you may have a stray docker running from before
<lool> kickinz1: cloud-init stuff only
<lool> jdstrand: yeah, that's what I think too
<lool> I dont see it in ps though
 * lool reboots
<lool> uh -bash: docker: command not found
<lool>    Loaded: not-found (Reason: No such file or directory)
<lool> I dont see the systemd service file under /etc/systemd/system
<lool> ok. trying BBB now
<lool> ok, docker is running
<lool> $ docker run -it armbuild/ubuntu
<lool> Unable to find image 'armbuild/ubuntu:latest' locally
<lool> Pulling repository armbuild/ubuntu
<lool> it's doign stuff
<lool> kickinz1: So not tested in full on BBB, but seems mostly working
<kickinz1> lool, ok, thanks!
<lool> would love some help debugging the isuse on rpi2
<lool> I'm removing docker snap, will search for stray files, and reboot
<lool>    Active: failed (Result: exit-code) since Fri 2015-04-10 15:01:17 UTC; 13s ago
<lool>   Process: 1033 ExecStopPost=/apps/docker/1.5.0.001/bin/docker.poststop (code=exited, status=0/SUCCESS)
<lool>   Process: 1003 ExecStart=/apps/docker/1.5.0.001/bin/docker.start (code=exited, status=1/FAILURE)
<lool> /apps/docker/1.5.0.001/bin/docker.start: line 14: /home/ubuntu/etc/docker.conf: No such file or directory
<lool> /apps/docker/1.5.0.001/bin/docker.start: line 32: docker: command not found
<lool> FATA[0000] open /var/run/docker.pid: permission denied
<lool> jdstrand: what's the magic to force regenerating the profiles? probably because I installed multiple snaps with same version
<lool> [Fri Apr 10 15:04:36 2015] audit: type=1400 audit(1428678276.674:17): apparmor="DENIED" operation="mknod" profile="docker_docker_1.5.0.001" name="/run/docker.pid" pid=1185 comm="docker.armhf" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<jdstrand> lool: sudo aa-clickhook -f ; sudo aa-profile-hook -f
<lool> thanks
<lool> jdstrand: I still get: [Fri Apr 10 15:05:58 2015] audit: type=1400 audit(1428678358.915:21): apparmor="DENIED" operation="mknod" profile="docker_docker_1.5.0.001" name="/run/docker.pid" pid=1209 comm="docker.armhf" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<jdstrand> kickinz1: ah-- ^
<lool> that's only on pi2 though
<jdstrand> we have this rule:
<jdstrand> /run/@{APP_PKGNAME}.pid rw,
<lool> jdstrand: note that I'm running this by hand because the job fails to start
<jdstrand> but APP_PKGNAME is 'docker-daemon'
<lool> aha
<kickinz1> jdstrand, I don't understand how it works on bbb as it is also running docker.armhf.
<jdstrand> that isn't the part
<jdstrand> name="/run/docker.pid"
<jdstrand> we have:
<jdstrand> @{APP_APPNAME}="docker-daemon"
<jdstrand> /run/@{APP_PKGNAME}.pid rw,
<jdstrand> oh wait
<jdstrand> no, that is right, I misread it
<lool> [Fri Apr 10 15:07:34 2015] device-mapper: table: 254:0: thin-pool: unknown target type
<lool> [Fri Apr 10 15:07:34 2015] device-mapper: ioctl: error adding target to table
<lool> that seems to be the actual error from the job
<lool> ppisati: ^
<jdstrand> oh this is the docker command
<jdstrand> kickinz1: hold on
<lool> jdstrand: I suspect it's non-fatal
<jdstrand> yes
<jdstrand> it is
<lool> so annoying, but systemd cleans things up
<ppisati> it refers to this: drivers/md/dm-thin.c:
<jdstrand> interesting that amd64 didn't need it
<lool> ppisati: is it built in your rpi2 kernel?
<ppisati> lool: do you have that module?
<ppisati> no idea
<lool> ppisati: what's the module name?
<lool> DM_THIN_PROVISIONING
<lool> ppisati: # CONFIG_DM_THIN_PROVISIONING is not set
<lool> ppisati: I blame it all on you!
<ppisati> obj-$(CONFIG_DM_THIN_PROVISIONING)      += dm-thin-pool.o
<ppisati> :)
<lool> ppisati: could you make sure this is part of our "Ubuntu standard options that always turned on"?
<ppisati> YES YES WHIP ME WHIPE!!! :D
<ppisati> yeppa
<ppisati> i can kick a new build
<ppisati> right now
<lool> ppisati: and coud you rebuild a rpi2 kernel with all interesting options we usually want turned on?
<lool> thanks
<ppisati> lool: we already have all the interesting options turned on
<ppisati> lool: this one wasn't part of it
<lool> kickinz1: so I think we wont hit the time for the pi2 demo, but we at least know how to get there and we seem close enough that we would have one, say, monday
 * ppisati goes and kick a new build
<jdstrand> lool: when did you see that? when the service was correctly running or when it wasn't?
<lool> jdstrand: that was on the rpi2
<jdstrand> was docker-daemon running?
<lool> jdstrand: trying to run the service by hand to trigger
<lool> jdstrand: no
<jdstrand> ah
<jdstrand> right, then that is correctly denied
<lool> jdstrand: actually on BBB I see *nothing*
<lool> jdstrand: so I guess it's not something you'd want to worry about
<lool> I guess side effect of me launching teh job by hand somehow
<jdstrand> lool: to start by hand, do sudo aa-exec -p docker_docker-daemon_1.5.0.001 -- /apps/docker/current/bin/docker.armhf ...
<lool> thanks
<jdstrand> lool: if you use 'docker' by hand, you get the 'docker cli command' and policy from /apps/bin
<lool> thanks
<jdstrand> lool: but you want to run docker as a daemon, so you need to start it under that profile
<jdstrand> kickinz1: nothing to be done
<jdstrand> at least policy wise
<lool> ppisati: poke when you have a new PPA kernel, I'll update my device tarball with it
<ppisati> lool: yep
<lool> ppisati: I can update the initrd too; not quite sure how to generate the modules dep without booting a pi2 and running depmod -a though
<ppisati> lool: but do you actually need the modules during boot? i don't think so
<lool> ppisati: I dont think so, but I'm trying to keep them up-to-date nevertheless
<lool> ppisati: besides, I'm including the deps in the device tarball rootfs part
<mvo> jdstrand: thanks again for the pointer to the unconfined profile, I created http://paste.ubuntu.com/10792277/ now, but it seems it does not like the last line I added "change_profile" - is the syntax here different?
<mvo> jdstrand: aha, it seems like "change_profile -> *" is the right one (?)
<jdstrand> change_profile -> *,
<mvo> thanks! that helped me a lot
 * mvo hugs jdstrand
<jdstrand> but, if you did want to confine this, you can do stuff like
<jdstrand> change_profile -> docker_*,
 * jdstrand hugs mvo back :)
<asac> ogra_: around?
<ogra_> asac, in a meeting, but around, yeah
<asac> ogra_: can you check in on #snappy-internal ?
<asac> for a moment
<kirkland> ogra_: hi, I'm here
<ogra_> hey kirkland
<kirkland> ogra_: okay, we're getting started
<ppisati> lool: it's baking - https://launchpad.net/~p-pisati/+archive/ubuntu/embedded/+packages
<jdstrand> beuno: hey, so in the store, you can upload a snap but there is no way to choose an architecture any more?
<jdstrand> beuno: kickinz1 is uploading docker and in the yaml it has: architecture: [amd64, armhf]
<jdstrand> beuno: that's fine. but then it comes up as arch all in the store, but it isn't 'all', it is 'multi' and only 'multi' for two archs, not all of them
<ppisati> jdstrand: same error i had for wget
<jdstrand> interesting
<jdstrand> maybe the store needs a little tweaking
<jdstrand> beuno (and kickinz1 and ppisati): I adjusted the review tools to match what the store is currently doing so this shouldn't happen again
<jdstrand> well, once the store is updated
<kickinz1> jdstrand, ok thanks
<ppisati> jdstrand: what are these tools?
<jdstrand> ppisati: they are the things that run during snappy build and what runs on the server
<jdstrand> lp:click-reviewers-tools
<ppisati> jdstrand: jdstrand that means i shall rebuild and resubmit? or do i still need for a store update? i guess the latter
<ppisati> *need to wait
<jdstrand> ppisati: no, you don't need to do anything
<jdstrand> the next time you upload, if the store has pulled in my change, you won't have that review tool error
<kirkland> ubuntu@localhost:~$ sudo snappy update
<kirkland> ubuntu-core    124 MB     [===================================================================================================================================================]    OK
<kirkland> I've been stuck after that for 10+ minutes now
<kirkland> help?
<kickinz1> kirkland on which board?
<kirkland> kickinz1: rpi2
<kickinz1> channel is devel-proposed?
<kirkland> kickinz1: how can I tell?
<kickinz1> kirkland: I don't have rpi2, sorry
<kirkland> kickinz1: how can I tell what channel?
<kickinz1> kirkland: cat/etc/syste-image/channel.ini
<kirkland> okay, it's applying now
<kickinz1> kirkland: if channel is ubuntu-core/devel
<kickinz1> kirkland, you will need to 'sudo mount -o remount rw /'
<kickinz1> kirkland, change channel to ubuntu-core/devel-proposed, then reboot, then update
<kickinz1> kirkland, but from me it is theory (as done on bbb), better have an anwer from an rpi2 owner
<kirkland> kickinz1: okay
<kirkland> kickinz1: can I just snappy install docker now?
<kickinz1> kirkland, if on new image : yes
<kirkland> kickinz1: okay, i'm updated now, rebooting
<kirkland> kickinz1: where can I just download the latest rpi2 image now?
<kickinz1> kirkland, but I don't know the status of docker on rpi2, I didn't get updates on that
<kickinz1> kirkland, what 'snappy list' looks like?
<kirkland> snappy: error: invalid choice: 'list' (choose from 'info', 'versions', 'search', 'update-versions', 'update', 'rollback', 'install', 'uninstall', 'tags', 'config', 'build', 'booted', 'chroot', 'framework', 'fake-version', 'nap')
<kickinz1> kirkland, ok old image
<kirkland> kickinz1: where can I get the new image?
<kirkland> kickinz1: why didn't snappy update get me the new image?
<kickinz1> kirkland, cause latest image is not yet promoted
<kickinz1> kirkland, I would go for channel change/ or backup solution is to use a docker-1.5.0-armhf for old image
<kirkland> kickinz1: channel: ubuntu-core/devel
<kickinz1> jdstrand, asac, ^
<kickinz1> kirkland, try this package:  https://mifamofi.net/owncloud/public.php?service=files&t=c2d37c5711ef8b323ac3da519142e21d
<sergiusens> kickinz1: kirkland rpi has no upgrade path until we have a proper kernel in our repos
<jdstrand> kirkland: someone said earlier it took 20 minutes
<kirkland> kickinz1: okay, I'm on devel-proposed now
<jdstrand> ok good
<jdstrand> if on devel-proposed, use the store
<asac> kirkland: lool has made an image prebuilt for you
<kirkland> asac: link?
<asac> in your inbox ;)
 * asac looks it up
<sergiusens> he sent an email
<kirkland> got it
<asac> kirkland: you cnanot update on the pi2 from alpha2 or even after because its nota  certified enablement
<asac> so just install the one you have
<asac> new builds at least dont try to update
<kirkland> 	custom.img	09-Apr-2015 16:01	3.6G
<asac> kirkland: wget http://people.canonical.com/~lool/pi2-device-and-oem/custom.img
<asac> dd it
<asac> yeah
<kirkland> asac: I don't have enough bandwidth to pull that here
<asac> kirkland: ok i can xz it
<asac> one moment
<asac> lool: i have to wget that because you are not on lillypitty?
<asac> weird
<asac> or you have weird permissions
<asac> lool: could you .xz this ... assuing it will be popular for the moment?
<asac> and put checksums ni place
<asac> kirkland: i am xz'ing here rifght now: http://people.canonical.com/~asac/tmp/pi2/
<asac> takes a it
<asac> bit
<jdstrand> asac: you don't have to wget it
<asac> i couldnt copy it from ~lool
<jdstrand> I logged into lillypilly and can see it
<asac> lool has always special permissions
<asac> hehe
<asac> ok
<jdstrand> I didn't try copying
<asac> maybe i mistyped
<asac> but i have it now anyway
<jdstrand> ok
<ogra_> "french permissions"
<jdstrand> hehe
<asac> man xz is so slow
<asac> i thinkk my 3.6G wget will finish before it finish packing
<kirkland> asac: okay, thanks
<kirkland> asac: is ogra_ still around, or gone?
<kirkland> asac: we're also trying the node-snapper stuff right now
<ogra_> kirkland, i'm here
<kirkland> ogra_: alright!!!
<ogra_> kirkland, moving to the living room though ... i.e. no internal channels anymore :)
<kirkland> ogra_: can you post your metadata.yaml from your node-snapper example?
<asac> lool: http://people.canonical.com/~asac/tmp/pi2/custom.img.xz
<asac> i think its fine
<asac> kirkland: http://people.canonical.com/~asac/tmp/pi2/custom.img.xz
<asac> err its finished
<asac> i will try too now
<asac> guess my bandwidth is faster so i know if it doesntw ork beffore you
<asac> kirkland: ogra will be around if you continue to engage him :)
<kirkland> asac: awesome, thanks
<asac> he is just sometimes falling asleep if he is idling too long :P
<kirkland> http://paste.ubuntu.com/10792912/
<kirkland> docker failed to install here ^
<asac> kirkland: on what machine?
<asac> what image?
<kirkland> asac: rpi2, devel-proposed, up to date
<kirkland> asac: I'm downloading your custom.img now
<asac> kirkland: how did you get it up tod date?
<asac> i dont think you can have that
<kirkland> asac: arg
<asac> because update doesnt work on pi2 by design
<asac> i think you have it just on the other partition, but still boot in the old one
<asac> kirkland: sure it will be better on the lools if its installing on the bbb latest
<asac> i am dding that custom one too now... lets see
<kirkland> asac: okay, in 7-8 minutes, the download will complete and I can write that image to the sdcard
<ogra_> kirkland, sorry, had to re-locate and now i'm missing backlog, you wanted the metadata.yaml ?
<kirkland> ogra_: yes, please
<asac> yeah i will hopefully be able to confirm by then... though its the first time i put this pi2 in action
<sergiusens> beuno: can oem snaps not require "departments" on upload?
<kirkland> asac: can you please pastebin it for us?
<sergiusens> beuno: and can we have a filter to search for package type?
<ogra_> kirkland, hmm, i dont have such a file ... i have a package.yaml though
<kirkland> ogra_: yes, that one, please
<asac> kirkland: what do you need pastebinit?
<kirkland> asac: package.yaml of a nodejs snap
<kirkland> asac: sorry, that was for ogra_
<asac> right
<asac> just wondered :)
<asac> ogra_: ^
<kirkland> ogra_: can you please pastebin your package.yaml
<ogra_> kirkland, http://paste.ubuntu.com/10792959/
<ogra_> kirkland, https://code.launchpad.net/~ogra/+junk/chatroom has allteh files btw (linkedfrom the blog)
<kirkland> asac: image downloaded
<kirkland> ogra_: okay, that branch is missing the arm tarball, right?
<kirkland> ogra_: I still need to unzip that?
<ogra_> yes, thats only the packaging data
<ogra_> the tarballs you crate with node-snapper
<ogra_> *create
<asac> kirkland: so i dded it
<asac> it boots
<asac> i am logged in
<kirkland> asac: I'm dd'ing now
<asac> (RaspberryPi2)ubuntu@localhost:~$
<kirkland> asac: can you snappy install docker?
<asac> mvo: http://paste.ubuntu.com/10793006/
<asac> kirkland: :(
<asac> kickinz1: ^^
<kirkland> asac: that looks exactly like what I saw before: http://paste.ubuntu.com/10792912/
<kickinz1> asac snappy list ?
<kickinz1> kirkland, yes but you had a snappy-python image
<mvo> asac: uff, let me look
<asac> lool: oem snap is also bogus
<asac> where is the soruce?
<asac> you have the xz data thingy
<kickinz1> asac, can you test docker-1.5.0-armhf for old image (https://mifamofi.net/owncloud/public.php?service=files&t=c2d37c5711ef8b323ac3da519142e21d)?
<asac> kickinz1: the old image i am not really interested in
<asac> many things wont work for folks there
<kickinz1> asac, ok sorry...
<asac> kickinz1: can you focus on the new one? does the new docker work on the bbb?
<asac> the one from store?
<kickinz1> asac, yes docker work on bbb from the store
<kirkland> asac: dd done
<asac> you wont be happy though
<kickinz1> asac, and I'm focused on the new image, I was just speaking of a backup on rpi2
<asac> i am tewsting now if the bbb works
<asac> right, but i think kirkland wont be happy with that because then lots of other issues will pop up
<sergiusens> mvo or jdstrand: when you have a minute please https://myapps.developer.ubuntu.com/dev/click-apps/2275
<asac> lool: where did you put your oem snap source? that needs to be rebuilt with latest snappy so i can create a new image
<asac> mvo: i dont get why docker is in the store as com.ubuntu...
<mvo> sergiusens, jdstrand: approved
<mvo> asac: me neither
<kirkland> asac: that image is not booting for me
<sergiusens> asac: I rebuilt lool's pkg here, I can upload it under my namespace for play if you want
<asac> kirkland: it does for me thats for sure
<asac> kirkland: it takes a while on first boot
<asac> because of funky cloud-init
<sergiusens> asac: or do it yourself, unpack it (dpkg-deb) and snappy build it again
<kirkland> asac: okay, i'll wait a bit
<asac> 2-3 minutes
<kirkland> asac: hmm, it's been more like 5
<asac> sergiusens: i want his .snap on people
<asac> sergiusens: not store
<asac> or is it in store?
<sergiusens> asac: right, but you can dpkg-deb -x it and snappy build it again, it will be very similar if not the same (timestamps differing)
<asac> sergiusens: just gimme the new snap
<sergiusens> asac: he asked me about that, not sure he uploaded
<asac> this one breaks trusty snappy soo i cannot see if a newer image works
<asac> its not
<asac> at least not as pi2.lool
<asac> mvo: well, but why does snappy install docker do the right thing?
<asac> do we have an alias there?
<asac> kickinz1: how do you upload the docker ?
<asac> whats in the metadata>?
<asac> you must not use com.ubuntu... anymore
<sergiusens> asac: there's the com.ubuntu.snappy hack for the py version in devel
<asac> sure
<sergiusens> it might be legacy
<asac> but it just works here on snappy latest
<asac> i type snappy install docker
<asac> and it starts downloading com.ubuntu...
<asac> so the store must have set an alias
<kickinz1> I just went to the store and updated the package from there....
<sergiusens> asac: I'm not sure kickinz1 has access to the .canonical part of the store; mvo and I do fwiw
<asac> kickinz1: do you have com.ubuntu.... in metadat?
<kickinz1> I didn'tknew there was an other way.
<kickinz1> asac: packlage.yaml?
<asac> yes
<asac> anyway
<asac> it seems to isntall here on bbb
<asac> fwiw
<asac> sergiusens: i need the new .snap
<asac> it seems that whatever image lool used isnt right
<kickinz1> http://paste.ubuntu.com/10793087/
<kirkland> asac: unplugged it, and plugged it back in again
<asac> kirkland: you have to remember that when dd finishes
<asac> you have to wait till IO buffer is done
<kirkland> see activity light, but nothing
<asac> run sync
<kirkland> asac: I ran sync 3 times
<asac> ok
<asac> thats odd
<asac> i had a few time taht a dd didnt work
<asac> usually i dded again and then it worked
<asac> and i jsut tell yopu that i never used this pi2 and dded it and it booted :)
<asac> it took long time before it upped ethernet
<asac> then it got network
<asac> and then it was there
<asac> kirkland: do you have ethernet?
<kirkland> yes
<asac> ok because until yesterday the image wouldnt boot without network
<mvo> fwiw, docker 1.5.0.002 installs fine for me in the latest image
<asac> sergiusens: i need snap :)
<asac> please!!
<asac> lools image is too outdated i am sure :)
<sergiusens> asac: uploading, I'm on a slow connection
<asac> sergiusens: sorry i rebuilt and now its going
<sergiusens> asac: 'dpkg-deb -x pi2*.snap x && snappy build x' might be faster
<asac> yeah
<asac> that was what i did
<sergiusens> ok
<sergiusens> I'll brb
<asac> sry for moron
<sergiusens> got into a coffee shop as rain took me by surprise
<sergiusens> asac: lol, no worries
 * genii 's ears perk up at the mention of coffee, then he wanders away again
<asac> oh coffee ... good idea
<asac> :)
<sergiusens> asac: I uploaded beagleblack.canonical btw
<genii> Heh
<asac> but i wait till i know if the new iamge just fixes the docker prob
<asac> if dd would just be faster :)
<ogra_> we need dd-diff ... that only applies the changed bytes :)
<asac> lol
<jdstrand> asac: meta/package.yaml is fine
<jdstrand> asac: it is that he uploaded to the old namespace in the store
<asac> right
<asac> jdstrand: what is in package.yaml? just docker>?
<jdstrand> name: docker
<kickinz1> yes : http://paste.ubuntu.com/10793087/
<jdstrand> the packaging is correct
<asac> goodie
<jdstrand> kickinz1: that is not the packaging you used
<jdstrand> kickinz1: that seems to be old
<jdstrand> I'm guessing your old armhf package
<kickinz1> sorry, wrong place (old docker)
<kickinz1> http://paste.ubuntu.com/10793165/
<kickinz1> jd strand yes, was on my old armhf package.
<jdstrand> well, that has 003, but yes
<kirkland> ogra_: hey
<kirkland> so can we get some help?
<kirkland> ogra_: hangout or something?
<jdstrand> this is what is in the store: http://paste.ubuntu.com/10793168/
<kickinz1> So I really need to go, kids are alone, I planned to update to new namespace, but not sure it is woth to do it now.
<ogra_> kirkland, can we do it here ... i cant really do hangouts from this place atm
<kirkland> ogra_: okay
<kirkland> ogra_: so we run snappy build .
<kirkland> ogra_: and we get a .snap
<kirkland> ogra_: we push it to the device
<kirkland> ogra_: and snappy installs it
<kirkland> ogra_: now what...
<kirkland> ogra_: how can we tell if it's running
<kirkland> ogra_: I can't telnet to the 6565 port chatroom.ogra_0.1-5_multi.snap
<ogra_> kirkland, well, journalctl should have a bunch of messages about it being started
<asac> kirkland: do you see the green light on the board blinking when it boots?
<ogra_> webdm should aalso have an entry and yu should be able to reach it on http://$ip:6565/
<kirkland> ogra_: ubuntu@localhost:~$ journalctl
<kirkland> No journal files were found.
<kirkland> asac: it blinked for a while, but not anymore
<asac> k
<ogra_> kirkland, sudo ;)
<kirkland> asac: I just re-wrote the image, again, sync sync sync
<kirkland> asac: and put it back in the rpi2
<ogra_> kirkland, sudo journalctl|grep chatroom
<ogra_> that should return some stuff
<kirkland> ogra_: okay, good, this helps, I'm debugging now
<ogra_> (or just pipe toless)
<kirkland> asac: okay, so we're not going to have docker on rpi2 today?
<kirkland> asac: if so, that's fine, I'll apologize and we'll cope
<ogra_> kirkland, note that the package is pretty old, i didnt update it since a while and snappy changed underneath ... might be there are issues now
<kirkland> asac: I'd much rather put all effort into solving one problem (packaging a nodejs app) than 2
<kirkland> ogra_: I'm confused a bit about one thing
<kirkland> ogra_: so I just untar that armhf tarball at the same level as the the meta/ and site/ dir?
<kirkland> ogra_: and snappy build just puts that in there?
<ogra_> kirkland, node-snapper generates two tarballs ... you unpack them in the toplevel of your package dir
<kirkland> ogra_: okay, we only care about armhf here
<ogra_> and should end up with an armhf and amd64 dir
<kirkland> ogra_: is that okay?
<ogra_> you need to adjust package.yaml
<kirkland> ogra_: can I just remove amd64 from the package.yaml
<kirkland> ogra_: okay, good done
<ogra_> yeah
<ogra_> so you unpack the armhf tarball in the toplevel ...
<kirkland> ogra_: okay, and then you just point a browser at :6565?
<ogra_> start-service.sh then checks for the arch and calls $arch/bin/nodejs site/server.js
<ogra_> right
<kirkland> ogra_: start-service.sh runs automatically?
<ogra_> it used to
<ogra_> not sure if the systemd service handling changed recently
<asac> kirkland: should do
<asac> if not you can try starting the service manually
<asac> have to find the right systemd name :)
<asac> we love systemd
<ogra_> sudo systemctl |grep chatroom
<ogra_> that should give you the service name
<kirkland> asac: okay, my rpi2 is now up with the new image
<asac> kirkland: really?
<asac> wow :)
<kirkland> asac: yeah, so can I install docker then?
<asac> kirkland: reflashed?
<kirkland> asac: yeah
<asac> no it wont work as i said above
<asac> i am trying
<asac> i think the image is too old :) ... i tested on bbb and it worked
<asac> with todays image
 * kirkland has to move downstairs now
<asac> yeah gimme a bit
<asac> i am confident that it will nto bail as it does with the lool image
<asac> just have to get it booting
<asac> had the same prob you had
<asac> jdstrand: http://paste.ubuntu.com/10792912/
<asac> can you think of a reason why that might be buggy with image from yesterday?
<asac> e.g. is there hope
<asac> it works with bbb from this morning for sure
<ogra_> did you check your clock ?
<asac> tyeah that was fine here
<asac> we have now ntp-like thing
<asac> so if network its good
<ogra_> ah, k
 * ogra_ lost track ... so much stuff on phone going on atm
<asac> yeah even more stuff going on here still :/
<asac> anyone has a good picture how to connect the serial pins on this pi2?
<asac> i would feel better if i could see whats going on
<asac> bah!!!
<ogra_> bah ?
<asac> reboot
<asac> udf doesnt work anymore
<asac> because i ctrl-c'
<asac> ed it
<kirkland> ogra_: I've been stuck here for ~10 minutes:
<kirkland> > utf-8-validate@1.0.1 install /node_modules/ws/node_modules/utf-8-validate
<kirkland> > node-gyp rebuild
<ogra_> there should be a spinner underneath
<ogra_> that usually takes a while, it compiles the modules
<ogra_> if yu dont see the spinner, ctrl-c and run it again ... it uses qemu-user-static for the cross building, thats not 100% reiable
<kirkland> ogra_: okay, ctrl-c'd, trying again
<ogra_> whats your host arch ?
<ogra_> i ran it only on amd64 machines
<ogra_> (and on nothing newer than utopic, though that sholdnt matter)
<asac> it was all lools fault again :) ... he didnt put --channel edge in his thingy so i tried to use the new device with devel :)
<asac> mvo: are we good on promotion?
<asac> i think that might help :_)
<kirkland> asac: heh
 * asac regenerates two images
<asac> one pi2
<asac> and pi2-docker with docker preinstalled
<asac> :P
<asac> not that it would help if apparmor falls over on first boot
<asac> hence i try the plain one first to see if it works :)
 * asac wont figure out how to connect serial
<mvo> asac: still on it :( its looking promising though
<asac> mvo: good!!
<mvo> asac: Chipaca is currently tsting BBB, I did some testing on amd64/kvm
<ogra_> asac, i'm not near my rpi ... :/
<ogra_> and i cant tell from the top of my head
<asac> ogra_: where are you?
<ogra_> downstairs ...
<asac> haha
<ogra_> :)
<asac> dont worry
<asac> i am confident that this flash run will rock
<kirkland> ogra_: okay, we made it past that step now
<ogra_> cool
<ogra_> asac, susie says: "cut the blue wire, not the yellow one"
<ogra_> (she jus asked why i laugh)
<asac> lol
<asac> mvo: do uyou know if james landed something that touches the initrd?
<asac> today?
<asac> or yesterday?
<mvo> asac: I don't think so but I don't know for sure
<mvo> asac: why do you ask?
<asac> just wondering if the device tarball of lool still has a chance to boot with an image 2 days later
<asac> dont worry
<asac> waiting for pi2 to start booting
<mvo> asac: so testing results are a bit sparse, should we just promote amd64 and armhf (assuming the test look good)
<asac> mvo: i am not sure what that excludes :)
<sergiusens> mvo: asac I can continue with testing now or addon to Chipaca if we can speed things up
<asac> i386 i dont care much
<Chipaca> sergiusens: selftest fails here
<Chipaca> sergiusens: http://pastebin.ubuntu.com/10793413/
<asac> so this one did never get a green light
<asac> me dds again
<kirkland> ogra_: http://paste.ubuntu.com/10793417/
<asac> i would very much love to be on a machine that doesnt do crazy automounting :)
<asac> i feel this induces99% of my bogus flash attempts
 * asac looks up this dbus --inhibit magic
<sergiusens> Chipaca: oh, that's why I mentioned "remove software" from package.yaml
<ogra_> kirkland, you dont have start-service.sh in your package
<asac> sergiusens: can udf still work with udisks --inhibit-all ?
<sergiusens> Chipaca: mvo I'll run the selftests with the beagleblack.canonical oem package
<kirkland> ogra_: oh, I thought you had everything in that branch
<ogra_> kirkland, did you actually follow the blog ... technically just copy/pasting the terminal commands should be enough
<sergiusens> asac: it should, there's no udisk involvement here
<kirkland> ogra_: I did the first time around;  the second time around, I just bzr branched your +junk branch
<ogra_> yeah, that should be enough ...
<ogra_> you should just need to unpack the tarball in the toplevel
<asac> kirkland: what do uyou have in /apps/ ?
<asac> ls /apps/
<jdstrand> asac: so, that paste is weird-- a number of things seem wrong. aa-clickhook failed gracefully, but systemd-snappyhook had some issues
<jdstrand> asac: is it still an issue? let me try from the store on an updated image
<asac> right i wanted to file it in the "snappy doesnt like namespaces, but that got fixed today" category
<asac> jdstrand: no its only on the lool pi2 image
<asac> i just want to know if its something underlying
<asac> or just outdated image
<asac> i totally get that anything can be possible because we rushed so many things in last few days
<asac> just wanted to feel better while i fiddle with stupid dd
<jdstrand> seems like maybe a filesystem issue?
<asac> really?
<asac> i dont have the paste anymore
<asac> rebooted
<jdstrand> cause that error from aa-clickhook is just about taking the json and outputting a text file
<jdstrand> asac: I'm guessing since I don't have access to the device
<jdstrand> maybe it was still read only?
<jdstrand> again, guessing
<asac> no clue
<asac> letse wawit
<asac> my latest dd seems to be at least truying to boot
<jdstrand> that's a good start :)
<asac> and it got an ip
<asac> also good news
 * asac waits for cloud-init do the groundwork to get me to ssh
<asac> ok so i am in the latest and greatest snappy userspace
<asac> on the amazing lool device tarball
<jdstrand> woo!
<kirkland> ogra_: okay, this looks good:
<kirkland> Feb 16 21:04:03 localhost.localdomain sudo[1062]: ubuntu : TTY=pts/1 ; PWD=/home/ubuntu ; USER=root ; COMMAND=/usr/bin/snappy install chatroom.ogra_0.1-5_multi.snap
<kirkland> Feb 16 21:04:32 localhost.localdomain systemd[1]: Started A simple WebRTC videochat.
<kirkland> Feb 16 21:04:32 localhost.localdomain systemd[1]: Starting A simple WebRTC videochat...
<kirkland> not getting anything though, if I point my browser at 192.168.1.115:6565
<asac> open /apps/docker/1.5.0.002/meta/package.yaml: permission denied
<jdstrand> that's less 'woo'
<asac> wtf
<asac> something is odd there
<asac> hmm
<asac> second time it worked :)
<jdstrand> ehh..
<asac> kirkland: what was the command that kickinz1|away said we should use?
<jdstrand> good?
<asac> for armhf docker?
<asac> the docker command is there :)
<kirkland> asac: you need an armhf docker image
<asac> yes he gave us a command
<asac> you have that?
<kirkland> asac: I'll have to look in scrollback here
<asac> i dont have it :(
<ogra_> kirkland, hmm, anything else in the logs ?
<ogra_> it should just work ...
<jdstrand> asac, kirkland: docker run -it armbuild/ubuntu
<jdstrand> asac: you might be interested in http://paste.ubuntu.com/10791782/
<kirkland> ogra_: netstat -an | grep 6565
<kirkland> ogra_: shows nothing
<jdstrand> asac: I guess if following that paste, you would change any of the 'ubuntu:' to be 'armbuild/ubuntu:'
<ogra_> kirkland, ps ax|grep node
<ogra_> does the nodejs process run ?
<jdstrand> asac: but I've never done that
<kirkland> ogra_: no node processes running
<ogra_> kirkland, hmm, but no errors in journalctl ?
<ogra_> that werid
<kirkland> ogra_: right, not anymore
<ogra_> *that's
<kirkland> ogra_: http://paste.ubuntu.com/10793547/
<kirkland> ogra_: there's a few snappy installs in there
<kirkland> ogra_: note the timestamps
<ogra_> Feb 16 21:02:40 localhost.localdomain systemd[995]: Failed at step EXEC spawning /apps/chatroom.ogra/0.1-5/start-service.sh: Exec format error
<asac> jdstrand: do those commands work for you on bbb?
<ogra_> are you sure you ship the armhf tarball ?
<kirkland> ogra_: how can I check?
<asac> jdstrand: i always get stuff olike:
<asac> FATA[0000] Get http:///var/run/docker.sock/v1.17/version: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
<kirkland> ogra_: fyi, I have to switch networks every time I move from IRC to the rpi, and back, so sorry for the long turnaround
<asac> jdstrand: when docker images
<asac> for instance
<ogra_> kirkland, does /apps/chatroom-test.ogra/0.1-5/armhf/bin/nodejs exist ?
<jdstrand> that's weird
<jdstrand> I've never seen that before
<jdstrand> http:///var/run/docker.sock/v1.17/version makes no sense
<asac> yeah something bad happened
<asac> jdstrand: do uyou have a beagle?
<asac> just try installing docker and see if docker images works
<jdstrand> is docker daemon running?
<asac> no
<jdstrand> not yet
<jdstrand> I just ordered one yesterday
<asac> hmm
<kirkland> ogra_: http://paste.ubuntu.com/10793573/
<jdstrand> I can say kickinz1|away tested bbb and amd64 and I tested various versions of amd64
<ogra_> kirkland, looks all fine to me ... hmm, perhap some env vars have changed, start-service,sh uses $SNAPP_  everywhere
<jdstrand> asac: what is the output of 'grep DEN /var/log/syslog'
<asac> doont have it anymore
<asac> something odd happend on first install
<asac> the rest might be cruft
<jdstrand> ok
<asac> so its not valid
<asac> i will now check on bbb
<asac> while installing my image that has docker preinstalled
<jdstrand> I think you are right to invalidate that test
<asac> i have the feeling my sdcard has problems
<jdstrand> that would possibly explain things
 * asac prepares to find a new one
<asac> i have that one in the pi2 since MWC
<asac> should be pretty good
<asac> pretty high quality
<jdstrand> sergiusens: hey, this is not important at all, but with udf, it might be nice to output the revision that was downloaded. eg: sudo ubuntu-device-flash  core --output ubuntu-core.img --channel ubuntu-core/devel-proposed -s 8 --enable-ssh
<jdstrand> sergiusens: ... New image complete (rNNN)
<asac> jdstrand: so same same
<asac> BeagleBoneBlack)ubuntu@localhost:~$ docker images
<asac> FATA[0000] Get http:///var/run/docker.sock/v1.17/images/json: dial unix /var/run/docker.sock: no such file or directory. Are you trying to connect to a TLS-enabled daemon without TLS?
<jdstrand> that's no good
<jdstrand> I'm going to try in kvm
<asac> jdstrand: who is supposed to start docker?
<jdstrand> systemd
<asac> jdstrand: there is no docker job in /etc
<asac> find /etc/systemd/ | grep docker
<asac> (BeagleBoneBlack)ubuntu@localhost:~$
<jdstrand> asac: what does /var/log/syslog say about the install?
<asac> dunno  installed it before i rebooted
<jdstrand> syslog is persistent
<asac> Apr 10 18:42:55 localhost click[586]: ERROR:root:Failed to create system unit for docker_docker-daemon_1.5.0.002: expected string
<sergiusens> jdstrand: I can get that in in a bit, sure
 * jdstrand taps fingers waiting for image to come up
<asac> http://paste.ubuntu.com/10793654/
<asac> jdstrand: ^
<asac> thats a grep
<kirkland> ogra_: alrighty, I'm up and running
<kirkland> ogra_: thanks for your help
<kirkland> ogra_: have a good evening, sir
<ogra_> kirkland, yay, what was it ?
<kirkland> ogra_: a bunch of little things
<kirkland> ogra_: I'll try to write them up
<ogra_> heh, k
<kirkland> ogra_: mostly, I didn't do the right things with start-service.sh
<jdstrand> asac: so, lool did mention earlier he was trying to start it manually... I wonder if he had the same issue
<jdstrand> sigh
 * jdstrand -> reboot
 * davmor2 shows jdstrand and image quickly
<ogra_> kirkland, well, theoretically you shouldnt need to do anything .... so i'l like to merge any needed changes
<asac> mvo: http://paste.ubuntu.com/10793654/
<kirkland> asac: poke me if docker on rpi2 comes around :-)
<asac> does that mean anything to you?
<kirkland> ogra_: honestly, if start-service.sh were part of your bzr branch, that would be great :-)
<ogra_> it is, no ?
 * ogra_ checks
<kirkland> ogra_: no, it's generated by your node-snapper script
<kirkland> ogra_: and then it has to be copied over
<kirkland> ogra_: and then manually edited
<ogra_> oh, right
<kirkland> ogra_: i did something wrong, somewhere in there
<kirkland> ogra_: finally, I just went back over all of your instructions again, from scratch, and it worked well enough
<ogra_> yeah, because it needs to create the LD_LIBRARY_PATH and friends
<kirkland> ogra_: so the instructions are good :-)  Just a little new/confusing the first time through
<mvo> asac: hm, that looks like something in docker, no? the click error comes after the unit fails to start
<ogra_> ok
<asac> mvo: why would click fail to create the unit ?
<asac> that should never fail imo
<mvo> asac: click should not generate it at all anymore :) its snappy-go that does that nowdays
<asac> so what is click doing here?
<asac> is that because he has com.ubuntu.snappy ?
 * asac still doesnt get why that just installs
<asac> if i run snappy install docker
<mvo> asac: its because the build still produces snappy compatiblity code
<asac> in which cases?
<asac> is that the problem?
<mvo> asac: when snappy build is called and yes, I think that is the problem
<asac> so his package is click still?
<asac> damn
<asac> :)
<asac> jdstrand: can you dpkg -x his docker
<asac> and snappy build . it fresh?
<asac> i dont have that .snap :(
<mvo> asac: nothing I can do against that yet, sorry, soon it will not be anymore
<asac> mvo: well, so i hear that he used an old snappy build ?
<asac> ok
<mvo> asac: not nesessarily, the current snappy still generates compatiblity code for the older images
<asac> so you think if we upload it as .canonical it might work?
<asac> odd thing is that on amd64 jdstrand says it works
<mvo> it works on my amd64 as well
<mvo> well, it installs and I can run docker and it prints stuff
<asac> i can do that too
<asac> run "docker images"
<asac> that bails out
<asac> the service is not running
<asac> the docker command is there
<asac> i really need the .snap :_)
<asac> jdstrand: can you get me the .sanp from store?
<asac> i want to try sideloading it
<asac> i am sure he sideloaded it during development
<asac> and it worked ;)
<asac> beuno: can yiou check if we have an alias set in store
<asac> for docker to com.ubuntu... ?
<mvo> http://paste.ubuntu.com/10793735/
<mvo> asac: -^ works on my amd64 install
<mvo> asac: do you run that on the BBB?
<jdstrand> man that was painful
<jdstrand> ok, I'm back
<asac> mvo: yeah its buggy there
<asac> mvo: can you give me the raw snap?
<asac> i have zero clue how to get that
<mvo> asac: sergiusens wrote a store-get command for this, I think we should have a hidden snappy download command for this
<jdstrand> meh, I lost my review copy cause I rebooted
<jdstrand> I can get it
<jdstrand> hold on
<asac> thx so much :)
<mvo> asac: go get github.com/sergiusens/store-get
<mvo> asac: $GOPATH/bin/store-get docker
<mvo> asac: that should work
<asac> i am not set up for go stuff :/
<asac> lets no solve that for now
<mvo> meh, ok
<asac> so seems snappy update is running ;) ... cant do more
<mvo> sorry
<mvo> but its really just sudo apt-get install golang-go and export GOPATH=~/go
<kickinz1|away> asac, did you try on bbb?
<asac> yeah
<asac> kickinz1|away: same problem
<kickinz1|away> it was working ok for me and for lool on bbb
<asac> kickinz1|away: http://paste.ubuntu.com/10793783/
<kickinz1|away> which image on bbb?
<asac> the one from this morning
<kickinz1|away> snappy list gives you what?
<asac> kickinz1|away: http://paste.ubuntu.com/10793787/
<asac> 221
<kickinz1|away> I'm on 220...
<kickinz1|away> Name        Date       Version   Developer
<kickinz1|away> ubuntu-core 2015-04-10 220
<kickinz1|away> docker      2015-04-10 1.5.0.002
<asac> kickinz1|away: did you install from store?
<asac> or sideload?
<kickinz1|away> install from store
<kickinz1|away> I did sudo snappy remove docker (that one was sideloaded)
<asac> yeah
<kickinz1|away> then sudo snappy install docker (that on came from store)
<asac> maybe that left over the parts that dont work from store
<kickinz1|away> then I tested
<asac> kickinz1|away: do you have the .snap still?
<kickinz1|away> yes
<asac> would like too try side loading
<kickinz1|away> https://mifamofi.net/owncloud/public.php?service=files&t=f837f7bc6787466c54c1467f43715987
<asac> mvo: how can i manually remove the docker?
<asac> it doesnt uninstall because the service is still running
<asac> err is not running
<asac> kickinz1|away: can you put that as a file up somewhere?
<asac> nevermind
<asac> i jsut dont like using browser download
<asac> have it now
<kickinz1|away> asac yes I just qhared the link before ^ : https://mifamofi.net/owncloud/public.php?service=files&t=f837f7bc6787466c54c1467f43715987
<kickinz1|away> ok
<jdstrand> asac: http://people.canonical.com/~jamie/docker_1.5.0.002_all.snap
<asac> ok so sideloading does the trick
<asac> i think its the com.ubuntu... fun thing
<asac> ok /me goes all in and preinstall the sideloaded docker :)
<asac> for pi2
<asac> jdstrand: you can upload for .canonical?
<jdstrand> fyi, I just did 'sudo snappy install docker' from the store and it is working
<jdstrand> on amd64
<asac> yeah i dont know why that is the case
<jdstrand> r377
<asac> i know that i just sideloaded it and it works on bbb
<asac> like our theory
<kickinz1|away> I'll update my bbb to 221 and check install from store
<asac> it didnt work on pi2 from store nor on bbb when i didnt have it instaleld before
<jdstrand> give me a minute
<asac> kickinz1|away: so be sure that you remove all stuff of docker
<asac> kickinz1|away: rm -rf /apps/docker/
<asac> kickinz1|away: rm -rf /apps/bin/docker*
<asac> kickinz1|away: rm -rf /var/lib/apps/docker/
<jdstrand> kickinz1|away: have you updated the docker branch?
<asac> kickinz1|away: and also the docker stuff in /etc/systemd/
<asac> kickinz1|away: so rm /etc/systemd/system/multi-user.target.wants/docker_docker-daemon_1.5.0.002.service
<asac> and rm /etc/systemd/system/docker_docker-daemon_1.5.0.002.service
<asac> then installing from store will explode
<asac> our theory because of the namespace\
<asac> i think our snappy remove does not clean the systemd jobs
<asac> is what i suspect
<jdstrand> remove seems to have some bugs
<asac> yeah
<jdstrand> I haven't had a chance to dig in and file them
<asac> the data is still there
<asac> not the systemd stuff
<asac> odd
<asac> guess next week is bug fix mode :)
<asac> and not that many features :)
<asac> wtf now from store worked too
<asac> sigh
<kickinz1|away> on bbb ?
<asac> yeah
<asac> very very odd
<kickinz1|away> after a sideload?
<asac> i installed 2 hours ago
<asac> no systemd jobs
<asac> (from store)
<asac> i manually cleaned all things and sideloaded -> worked
<asac> i manually cleaned and install from stored -> worked
<kickinz1|away> did you removed /var/lib/apparmor/docker related stuff?
<asac> oh no
<asac> that one i didnt
<asac> good point
<asac> i only did /var/lib/apps/docker
<asac> so that might be it
<jdstrand> there is also framework policy in /var/lib/snappy
<kickinz1|away> jdstrand still uploading, very slow bandwith...
<kickinz1|away> jdstrand just uploaded
<jdstrand> ok
<asac> jdstrand: can we maybe reupload kickinz1|away's snapp as .canonical ?
<jdstrand> there it goes
<asac> can you do that?
<asac> i think its worth a shot :P
<jdstrand> asac: that is what I am working on
<asac> we certainly prefer to not have com....
<asac> ah thanks
<asac> we need to find the store folks
<asac> a) shut down the smoser account
<asac> b) clean the docker :)
<asac> omg
<asac> there is so much stuff of docker in the FS
<asac> even in click directories taht shouldnt exist in my world view
<asac> spread everywhere
<asac> jdstrand: we really need to clean up the world where appamore spreads stuff :)
<asac> its everywhere
<asac> needs to be nicely in one place :P
<asac> know its not you
<asac> but just saying
<asac> its hooked in everywhere
<asac> kinda makes sense that we dont clean it nicely on remove
<asac> kickinz1|away: so i cant say that its really the sideloading
<asac> because my bbb was certainly not docker free when it suddenly started working
<asac> guess we have to find | grep docker and rm -rf manually
<asac> or on fresh flash which is awful
<asac> ok flashing fresh pi2 again
<asac> jdstrand: http://paste.ubuntu.com/10793979/
<jdstrand> asac: re apparmor, yes, that is part of what /var/lib/snappy is about. that is the new world. the old world still exists
<jdstrand> so we have click and snappy locations, so its weird
<asac> s i think i removed all fiels that had name docker
<asac> and sideloading still worked
<asac> so there is hope
<asac> but maybe i oversaw something
<jdstrand> there is also the issue that things are garbage collected when install fails, but not completely
<asac> yeah for sure
<jdstrand> ok, lp:~snappy-dev/snappy-hub/docker updated to what is in the store now
<jdstrand> now preparing 1.5.0.003 with .canonical
<jdstrand> ok, the snap looks good
<jdstrand> actually, I'm not sure what account is used for .canonical. is that on the mailing list?
<jdstrand> sergiusens: ^
<asac> INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
<asac> WARN[0000] WARNING: Udev sync is not supported. This will lead to unexpected behavior, data loss and errors
<asac> FATA[0000] Error running DeviceCreate (CreatePool) dm_task_run failed
<asac> kickinz1|away: ^^
<asac> so i think thats the problem
<sergiusens> jdstrand: I have creds and so does mvo
<jdstrand> I've got it now
<sergiusens> jdstrand: want it
<sergiusens> ah you got it
<jdstrand> thanks
<asac> root@localhost:/apps/docker/1.5.0.002# /apps/docker/1.5.0.002/bin/docker.start
<asac> INFO[0000] +job serveapi(unix:///var/run/docker.sock)
<asac> INFO[0000] Listening for HTTP on unix (/var/run/docker.sock)
<asac> WARN[0000] WARNING: Udev sync is not supported. This will lead to unexpected behavior, data loss and errors
<asac> FATA[0000] Error running DeviceCreate (CreatePool) dm_task_run failed
 * asac bets its kernel option missing
 * sergiusens watches the flood of asac
<asac> 21:42 < asac> FATA[0000] Error running DeviceCreate (CreatePool) dm_task_run failed
<asac> really would like to know what that tries to do
<asac> http://paste.ubuntu.com/10794076/
<asac> that looks suspicious
<asac> yeah this ioctl multiplies when i run docker
<asac> https://github.com/docker/docker/blob/dd786eefbbf286ca57b52374a6905c1ac8b8bd60/docs/sources/installation/kernel.rst
<crised_> Can I see the available packages for this distro?
<mfilipe> anyone here knows how is the progress to Digital Ocean accepts Ubuntu Core?
<kickinz1|away> bbb: updating from 3 -> 222 ;) (slow bandwidth used an already downloaded).
<jdstrand> sergiusens: "The uploaded package name (docker) does not use your namespace (canonical)"
<jdstrand> sergiusens: I thought we said I did not need .canonical in the name?
<jdstrand> the store may need an alias
<jdstrand> asac: please advise ^
<jdstrand> yaml has: name: docker
<jdstrand> upload resulted in "The uploaded package name (docker) does not use your namespace (canonical)"
<asac> ok found somethign
<sergiusens> jdstrand: that's not ready afaik
<asac> our kernel doesnt have enough options
<asac> CONFIG_BLK_DEV_DM
<asac> CONFIG_DM_THIN_PROVISIONING\
<asac> jdstrand: you know kernel packaging fu enough to maybe add those options ? and spin a ppa build?
<asac> https://launchpad.net/~p-pisati/+archive/ubuntu/misc/+files/linux-bcm2709_3.19.1-4.4.dsc
<jdstrand> sergiusens: if that's true, we should hold off on uploading this into the .canonical namespace
<jdstrand> tyhicks: can you take a look at that? ^
<jdstrand> tyhicks: at what asac mentioned
<asac> so i am cross checking https://github.com/docker/docker/blob/dd786eefbbf286ca57b52374a6905c1ac8b8bd60/docs/sources/installation/kernel.rst
<asac> with cat boot/config-3.19.1-4-generic-bcm2709  | pastebinit
<asac> http://paste.ubuntu.com/10794169/
<asac> and CONFIG_BLK_DEV_DM
<asac> missing makes lots of sense given the error we see
<asac> http://paste.ubuntu.com/10794076/
<jdstrand> let me see what snappy does if I do 'name: docker.canonical'
<asac> yeah
<asac> but the optioons are missing for sure
<asac> so missing from what i see is:
<asac> CONFIG_MEMCG_SWAP
<asac> CONFIG_DM_THIN_PROVISIONING
<jdstrand> I'm quite sure snappy is going to not dtrt with docker.canonical
<asac> CONFIG_BLK_DEV_DM
<asac> jdstrand: i think it will
<asac> unless we still install apps with .developer :_)
<asac> otherwise its tracked
<jdstrand> no, I don't think so
<jdstrand> it is going to install the framework policy incorrectly
<jdstrand> because frameworks are expected to be toplevel
<asac> kirkland: bad news... docker wont run on pi2 because we lack some kernel options... and i wont be able to give you a new kernel with those options
<asac> we might have some luck, but best focus on bbb and tell them that pi2 will behave the same
<tyhicks> asac: is there a git tree with the bcm2709 kernel source?
<asac> tyhicks: no clue
<asac> we really just need a one off
<asac> to bandaid
<asac> tyhicks: you can dget the dsc
<tyhicks> I've only ever built ubuntu kernels out of the kernel team's git trees
<asac> and dpkg-source -x it :)
<tyhicks> I can give the dsc a shot
<sergiusens> tyhicks: http://people.canonical.com/~lool/pi2-device-and-oem/
<asac> tyhicks: so there probably is one if you give me gitweb
<asac> i can search
<sergiusens> tyhicks: there's a link to a deb built by paulo
<asac> its ppisiati
<asac> who did that
<sergiusens> in a ppa
<asac> tyhicks: but i never can find gitweb
<sergiusens> asac: http://kernel.ubuntu.com/git
 * asac waits for the resource efficient gitweb app to figure what to display :)
<sergiusens> asac: http://kernel.ubuntu.com/git?p=ppisati/ubuntu-vivid.git;a=summary
<kirkland> asac: okay, no worries
<kirkland> asac: thanks a lot, I'll apologize to the guys here
<asac> kirkland: could be... but it makes sense now
<kirkland> asac: thanks to ogra, we have a nodejs app :-)
<asac> kirkland: so you can sideload it to bbb for sure
<kirkland> asac: we're happy enough with that
<asac> cool
<asac> well, i spend so much time of my friday night that i needed to spend on something else
<asac> that i really want this to work :)
<tyhicks> sergiusens: I'd need to build a new snappy image to provide an updated kernel?
<kirkland> asac: +1, go have a beer or 5
 * tyhicks is looking at the pi2-device-and-oem link
<asac> kirkland: well, if tyhicks can build a new kernel i might spin a new image for you tomorrow that will work
<asac> tyhicks: you cannot do that
<asac> tyhicks: if you have the kernel with those new options
<asac> talk to me :)
<asac> and i wil try to hack it into the device tarball and see if it works
<asac> its a bit of a nightmare :)
<tyhicks> ok
<asac> 21:55 < asac> CONFIG_BLK_DEV_DM
<asac> 21:56 < asac> CONFIG_DM_THIN_PROVISIONING\
<jdstrand> asac: fyi, https://bugs.launchpad.net/snappy-ubuntu/+bug/1442790
<asac> 21:57 < asac> and CONFIG_BLK_DEV_DM
<asac> tyhicks: those tree
 * tyhicks nods
<asac> three!!
<jdstrand> asac: (snappy remove doesn't remove everything)
 * tyhicks will give it a shot
<tyhicks> asac: I'm not going to do it in a ppa - that'll take too long
<asac> yeah
<asac> tyhicks: i need armhf image and modules deb
<asac> the rest i will just fiddle around from there
 * tyhicks nods
<asac> tyhicks: you migth want to heck if we enable those options as modules
<asac> or as y
<asac> in our normal kernel
<asac> just check on amd64
<asac> if its y
<tyhicks> right
<tyhicks> will do
<asac> maybe its just swapping the vmlinuz :)
<asac> that would be jackpot
<asac> at least i would just try to do that for bandaiding
<kirkland> asac: if so, give it to mahmoh
<kirkland> asac: he's supporting the hackathon tomorrow
<jdstrand> interesting: rm: cannot remove '/var/lib/apps/docker/1.5.0.002/aufs': Device or resource busy
<asac> kirkland: is he up to speed?
<asac> :)
<asac> kirkland: he isnt even online :(
<asac> i tried to find him all week
<asac> jdstrand: yeah thats all funny
<asac> tyhicks: sorry i posrted one config twice... the third i found on docker page is CONFIG_MEMCG_SWAP
<jdstrand> hopefully aufs is in said kernel too
<asac> but not sure if we needt hat... the first two are surely the ones matching the errors i get in dmesg
<asac> let me see
<asac> i think it is
<asac> cat boot/config-3.19.1-4-generic-bcm2709   | pastebinit
<asac> http://paste.ubuntu.com/10794241/
<asac> jdstrand: ^
<asac> jdstrand: thats odd
<asac> https://github.com/docker/docker/blob/dd786eefbbf286ca57b52374a6905c1ac8b8bd60/docs/sources/installation/kernel.rst
<asac> its not there
<asac> Note: as of 0.7 docker no longer requires aufs. AUFS support is still available as an optional driver.
<asac> jdstrand: ^^
<asac> read that page :)
<jdstrand> erf, I hit the darn useless logging bug and garbage collection on install
<asac> not sure why you have docker still using it though
<asac> :{
<asac> jdstrand: file them and we knock them out next week :)... bug fixing
<asac> maybe make a short list
<kirkland> asac: probably not, you'll need to send him a note
<kirkland> asac: I'm heading home tonight
<jdstrand> well, I only mentioned aufs cause that aufs file was not removable
<asac> kirkland: is he not around?
<jdstrand> asac: I filled them yesterday
<jdstrand> filed
<jdstrand> that is what kept people up late into the night
<mahmoh> asac: hi
<asac> hi mahmoh
<asac> kirkland: so what kind of stuff are they doing there and mind need support?
<asac> kirkland: maybe other channel
<kickinz1|away> asac: on my fresh bbb 222: http://paste.ubuntu.com/10794316/
<asac> kickinz1|away: yep see above
<asac> kickinz1|away: seems some bugs in snappy caused the bbb also to have troubles
<asac> kickinz1|away: it all seems to be kernel options missions
<asac> missing
<kickinz1|away> ok
<kickinz1|away> sorry
<asac> the basics definitely work on bbb
<asac> kickinz1|away: sorry for causing confusion :)
<asac> but friday night things go crazy
<asac> kickinz1|away: we meet on sunday!
<asac> go off
<kickinz1|away> asac, ok see you on sunday!
<asac> good to know that away is closer than afk :)
<crised_> Are the packages from ubuntu available to snappy???
<tyhicks> asac: CONFIG_BLK_DEV_DM is already 'y'
<tyhicks> asac: CONFIG_DM_THIN_PROVISIONING a module on amd64 - would you rather me build it in for this one-off kernel?
<tyhicks> (CONFIG_MEMCG_SWAP is built in on amd64 so I'll build it in for this kernel, too)
<asac> tyhicks: yeah if it can be just built in thats better
<tyhicks> will do
<asac> thin certainly makes sense as well with the dmest
<asac> dmesg :)
<asac> tyhicks: guess just give me vmlinuz :)
<jdstrand> asac: ok, so framework policy is not copied correctly with 'name: docker.canonical_client'. as a result, the docker cli command doesn't work (cause it references this policy). I could make it all work, but by definition frameworks are supposed to be toplevel
<asac> yeah
<jdstrand> asac: I think we should hold off on docker in the .canonical namespace
<asac> jdstrand: so what i dont understand is why the com.... works
<asac> jdstrand: i guess the alias?
<asac> thats fine
<jdstrand> asac: because there is a server side hack iirc
<asac> the .canonical will go away if we do switch
<asac> its the alias
<asac> i think
<jdstrand> maybe it is now an alias and not a hack
<asac> if i install docker
<jdstrand> we had hacks in december
<asac> right
<asac> its not clear to me how the fact that its an alias propagates
<jdstrand> me either
<asac> jdstrand: did you use docker.canonical in yaml?
<asac> i think dont do that
<asac> just use docker
<asac> and upload it as .canonical
<asac> and then its fine
<asac> i think store already implemented it
<asac> as origin
<asac> so we can kick it out of package.yaml
<jdstrand> asac: right, so, with 'name: docker' on upload I had the store tell me I messed up
<asac> this is why it works for what we did with com...
<asac> odd
<jdstrand> with 'name: docker.canonical' I see the policy issue
<asac> ok then the store hasnte finished work
<asac> lets not bother till they land that origin feature
<asac> i thought it was done
<asac> but maybe they are stilll doing something
<jdstrand> asac: when you say 'upload it as .canonical' what do you mean?
<jdstrand> adjust the filename?
<asac> jdstrand: its meant to be only something you do in the store
<asac> you package it up without namespace
<asac> and upload it as .canonical
<asac> then its all good
<jdstrand> yes, what does that mean?
<jdstrand> :)
<jdstrand> that is what I attempted to do first
<asac> this means you upload it as use that has namespace .canonical
<jdstrand> yeah
<asac> the store will just track that as "origin"
<jdstrand> ok, that didn't work
<asac> right
<asac> this is the only big thing we are missing
<asac> for next week
<asac> from what i know :)
<asac> besuides your security refinements
<jdstrand> I logged to the proper account, the store recognized (as seen through the error message) that I was in the .canonical namespace, but didn't like the package
<asac> yeah then they didnt land it ompletely
<asac> i know they were super close but had to migrate DB
<mvo> jdstrand: do we need a backport of the click-reviewers-tools in the ppa:snappy-dev/tools (and/or beta)?
<jdstrand> ok, that's fine
<asac> but wanted to do that over weekend or something
<jdstrand> mvo: so.. I was working on the review tools and then was asked to put them aside in favor of seccomp
<jdstrand> mvo: I have a lot of changes that need to land but they aren't quite ready yet
<jdstrand> this is for bugs and security yaml
<mvo> jdstrand: no problem, I was just curious
<asac> tyhicks: maybe the vmlinuz is already done (while it builds the module lot)?
<mvo> jdstrand: I personally think that the seccomp stuff is more important to land
<jdstrand> once I get through seccomp I'll pick that up again
<asac> crazy times :)
 * asac remembers the two weeks before first release for cloud
<jdstrand> so, for anyone interested, lp:~snappy-dev/snappy-hub/docker is up to date with what is in the store and tagged
<asac> thanks
<jdstrand> so if people want to change the packaging, just do: snappy build ./package-dir
<jdstrand> mvo: have I mentioned how I do snappy builds?
<jdstrand> mvo: I don't use the tools for snappy
<jdstrand> mvo: I fire up a snappy image then: scp -P 8022 ubuntu@localhost:/usr/bin/snappy /tmp ; /tmp/snappy build ...' :)
<jdstrand> mvo: I guess static linking is good for mething :)
<jdstrand> something
<mvo> jdstrand: haha, nice.
<tyhicks> asac: there were some file permissions related failures that stopped the build - it is running now
<mvo> jdstrand: thats good so you tested the snappy go builds already, excellent
<jdstrand> tyhicks: thank you for looking at that
<jdstrand> mvo: always! :)
<tyhicks> np
<jdstrand> mvo: I then run them through my review tools branch
<asac> tyhicks: local problems?
 * asac ignores
<tyhicks> asac: here you go: http://people.canonical.com/~tyhicks/bcm/linux-image-3.19.1-4-generic-bcm2709_3.19.1-4.4+kconfig1_armhf.deb
<tyhicks> asac: unpack the deb and pull out the vmlinux file
<tyhicks> asac: be sure to check your email - paolo was one step ahead of us and will have a more official build ready in a couple hours
<mvo> sergiusens: sorry, but any idea what http://paste.ubuntu.com/10794788/ means and how I can get rid of it?
<tyhicks> I'm not sure if you want to go through the image generation with my kernel or wait for his
<asac> tyhicks: right now i want to try copying it hard to /boot :)
<asac> not new image
<tyhicks> that makes sense
<asac> tyhicks: thanks! http://paste.ubuntu.com/10794885/
<asac> it works :)
<tyhicks> nice! :)
<asac> well they die
<asac> not sure whats going on :)
<mvo> nice, and really nice to see the raspi2 oem snap from lool
<asac> yeah
<asac> thats cool
<mvo> its comming togehter
 * asac waves and goes to semi weekend and then travel :)
#snappy 2015-04-11
<bernhard_> Hello Everybody!
<bernhard> Is there anybody, who can help me with cups and lexmark printers?
<bernhard> Or is this the wrong chat?
<devil> bernhard: what is your OS?
<bernhard> Ubuntu 14.04 LTS
<devil> bernhard: then #ubuntu is for you
<bernhard> i see, thank you devil
<bernhard> thank you very much
<devil> np :)
<bernhard> :)
<bernhard> what is this chat about, i am new, sorry for this question
<devil> this is snappy ubuntu, a lean OS fpr the cloud and IoT
<devil> for
<bernhard> oh ok, thank you for the answer
<mahmoh2> asac: kirkland: ping, it's mahmoh @ GE hackathon
<mahmoh2> need help
<mahmoh2> for a snap customer re: node snap actually, asac
#snappy 2015-04-12
<jchodyniecki> Hi Team. Just deployed an ova snappy image to virtual box, but the ubuntu/ubuntu password doesn't work. any ideas? It is late, so I could be doing something silly
<asac> mahmoh2: ogra_ is the one who knows node
<asac> mahmoh2: you should have texted me :(
<asac> mahmoh2: ah seems you got help from kirkland
<jchodyniecki> Hi Team. Just deployed an ova snappy image to virtual box, but the ubuntu/ubuntu password doesn't work. any ideas?
#snappy 2016-04-11
<johnorjias> Hello all :-) I am just wondering if anyone has instructions for enabling the ttyO1-O5 serial ports on the BBB in snappy
<dbrouwer> Hi John, I was about to sk the same question!
<johnorjias> haha hello doug :-)
<johnorjias> I think everyone is sitting idle at the moment I will keep an eye out for if anyone gets on and response to this
<zyga> goooood morning :)
<ysionneau> morning!
<ysionneau> what should I do to propose a patch for snapcraft? open a ticket on launchpad and append a patch? or open a pull request with my patch on GitHub ?
<ysionneau> or both
<dholbach> ysionneau, https://github.com/ubuntu-core/snapcraft/blob/master/CONTRIBUTING.md :)
<ysionneau> thx!
<ysionneau> I need to submit the "contributor license agreement"
<ysionneau> "Please add the Canonical Project Manager or contact" < who is it?
<ysionneau> -it+he
<ysionneau> or she
<ogra_> mvo, mind if i add "XB-Task: ubuntu-core" to the initramfs-tools-ubuntu-core package in the PPA ? seesm we end up without initrd in the rootfs if thats not there (breaking everyones custom kernel builds)
<mvo> ogra_: please do
<mvo> ogra_: all the packages from the weekend will hopefully get uploaded to xenial proper today
<ogra_> i have a check for that in livecd-rootfs trunk already
<mvo> ogra_: but please add it
<ogra_> mvo, and sorry for the clashes on the weekend ... i only got aware you were tinkering too very late :)
<davidcalle> zyga: hi, do you know when multiple plugs support is going to land? Right now, when I'm trying to use multiple ones (eg. home + network + something), I get "youtube-dl_2016.03.27_amd64.snap failed to install: only a single plug is supported, 3 found"
<davidcalle> jdstrand: ^
<mvo> ogra_: no worries
<dpm> ysionneau, I think the best person to add would be Jamie Bennet
<mvo> ogra_: I have some changes  pending locally that I need to commit proper but commiting must be done in sync with the new snappy upload so its all a bit circular
<ogra_> well, after all edge is allowed to break :)
<ogra_> mvo, i was wondering what we'll do with all the universe packages
<ogra_> there is still a good bunch
<ysionneau> ok dpm thanks
<mvo> ogra_: uh, thats bad, I thought it all got promoted, I was not looking closely :/
<ogra_> watchdog, libnss-extrausers, ubuntu-fan, ubuntu-core-libs, tpm-tools, opencryptoki, libopencryptoki0, libtpm-unseal1, ubuntu-core-config
<ogra_> that is what i see coming from universe in the image build logs
<mvo> ogra_: oh, ok. those are all for the image itself. ok
<zyga> davidcalle: it's already supported now but stay tuned :)
<zyga> davidcalle: I'm getting connect/disconnect to do something for real
<davidcalle> zyga: supported as in "landed"? See my error above
<zyga> davidcalle: and I also need to get auto-connect to work (for things as landed)
<zyga> davidcalle: it's landed and released last night but wasn't useful yet
<zyga> davidcalle: we need one more release
<ogra_> mvo, well, libnss-extrausers, ubuntu-core-libs and ubuntu-core-config are pretty essential i think ... not sure about the others though
<zyga> davidcalle: if your image is older than a few hours it needs to be rebuilt
<ogra_> mvo, writing a mail
<mvo> ta
<zyga> davidcalle: but note that before the next release it's all broken anyway
<zyga> davidcalle: and your snap won't get any permissions
<davidcalle> zyga, ok, do you ~know when is this next landing planned?
<zyga> davidcalle: when we get new things to work
<zyga> very soon
<ogra_> mvo, u-d-f fails with that latest snappy changes ...
<ogra_> bind mount failed for /tmp/diskimage643961727/writable/system-data/var/lib/snappy to /tmp/diskimage643961727/system/var/lib/snappy with: exit status 32 mount: mount point /tmp/diskimage643961727/system/var/lib/snappy does not exist
<mvo> ogra_: are you using the edge channel? i.e. what is your u-d-f commandline?
<mvo> ogra_: are you using u-d-f from my people.c.c page?
<sergiusens> kyrofa, hey, care to start reviewing https://github.com/ubuntu-core/snapcraft/pull/434
<sergiusens> examples tests fail as new infra was deployed, fgimenez is on it fwiw :-)
<ogra_> mvo, well, the same one i use since starting to use all-snaps ... from your people.u.c page, yes
<ogra_> mvo, oh
<ogra_> i didnt notice the update ... ignore me :)
<ogra_> mvo, works fine, sorry for the noise :)
<mvo> ogra_: thanks and no worries
<mvo> ogra_: its hard to keep track of non-pkgs :/ but soon we fix all this
<ogra_> yeah, we still have 10 days
<ogra_> :P
<ogra_> -
<ogra_> oops
<mvo> ogra_: *cough*
<mvo> ogra_: wasn't this the 16.06 release ? to honor 6.06?
<ogra_> lol
<fgimenez> sergiusens, it should be fixed now http://162.213.35.179:8080/job/github-snapcraft-examples-tests-cloud/545/console
<sergiusens> ty
<ogra_> hmm, unsquashfs doesnt work on pipes :(
 * ogra_ would like to pull the initrd.img out of the os snap without having to completely download it 
<ogra_> but piping a wget stream seems to not work :(
<johnorjias> Hello all :-) I am just wondering if anyone has instructions for enabling the ttyO1-O5 serial ports on the BBB in snappy?
<oparoz> Hello, how do we know which OS binaries we can use in a snap? I've had startup scripts fail because I wanted to use hostnamectl or sed -i and got denied by apparmor
<oparoz> I mean, I can call these just fine from the snap, but somehow I can't use them in a startupscript, so it takes a bit of trial and error to figure out what is allowed
<ysionneau> If anyone want to try doing snaps cross compilation, you can give this a try : https://github.com/fallen/snapcraft/tree/dev-alchemy-branch
<ysionneau> using this build system : https://github.com/parrot-developers/alchemy
<oparoz> ysionneau: Is there a bit more instructions on how to set it up?
<davidcalle> ogra_: how do you disable snappy auto-reboot on Xenial? Althgouh, it's very useful, when my desktop reboots unexpectedly, I know it's any-hour-past-ten :P
<ysionneau> oparoz: I should post an example :)
<ogra_> davidcalle, using snappy config ubuntu-core (i forgot the exact syntax, Chipaca` always knew it from teh top of his head though)
<oparoz> ysionneau: Yes, please. Per example I'm using an amd64 VM and I'd like to target arm, so I guess I must be able to define the targets somewhere, etc.
<davidcalle> ogra, can you get/set options from the cli or do I need to provide a new conf file?
<ogra_> you can pipe it somehow, thats the bit i was referring to for Chipaca`
<davidcalle> Ok, thanks :)
<davidcalle> ogra_: Chipaca` found it  "echo 'config: {ubuntu-core: {autoupdate: off}}' | sudo snappy config ubuntu-core -"
<ogra_> cool
<ysionneau> oparoz: https://github.com/fallen/hello_snappy_alchemy
<ysionneau> that's very early and beta stuff (the alchemy plugin, not the alchemy build system) but it does work for my uses for now
<ysionneau> + it's a bit hacky
<oparoz> Thanks for that ysionneau. Regarding snapcraft, do we need more than the alchemy plugin?
<ogra_> reading canonical-snapdragon-linux_0.snap/vmlinuz
<ogra_> 24026624 bytes read in 6534 ms (3.5 MiB/s)
<ogra_> reading canonical-snapdragon-linux_0.snap/dtbs/apq8016-sbc.dtb
<ogra_> mvo, ^^^ thats doesnt look correct ... where is the version gone ?
<ogra_> + snapcraft snap snap
<ogra_> Snapping canonical-snapdragon-linux_4.4.0-1009+20160411.11-57_arm64.snap
<ogra_> Parallel mksquashfs: Using 4 processors
<sergiusens> ysionneau, where is the alchemy plugin? :-)
<ogra_> the snap seems to have been built ok though
<sergiusens> ysionneau, fwiw, cross compiling is super easy, the problem we have from a snapcraft point of view are `stage-packages` and `build-packages`
<ogra_> wow, "snap list" on the dragonboard takes nearly 30sec to tell me about the 3 packages
<ogra_> ah, subsequent runs are slightly faster
<ogra_> (still a lot slower than snappy list was)
<zyga> ogra_: looks like socket activation
<ogra_> did that get tested on all arches ?
<ogra_> (i would suspect armhf to actually be a lot slower than arm64 here )
<zyga> ogra_: it was always socket activated
<ogra_> snappy list did use sockets ?
<zyga> snappy list is gone, snap list uses sockets
<ogra_> i thought the reply came directly from the snappy binary
<ogra_> zyga, well, snap list is there since today
<ogra_> and is definitely lots slower than snappy list was ... in the first incarnation at least
<zyga> ogra_: no, it was there for a while, but now snappy list is not there
<ogra_> zyga, it wasnt there until michael landed it on the weekend
<zyga> ogra_: well, in any way, snap list was in the source for months
<ogra_> i dont care about the source :P
<zyga> ogra_: snappy list was taking global lock; snap list should be faster down the line
<zyga> well, sorry :)
<ogra_> it is definitely an odd user experience if you knew snappy list before though
<zyga> (snap list won't read the FS soon)
<ogra_> (it should at least print something that tells you the initial run can take ages
<ogra_> )
<zyga> currently it still does
<zyga> ages?
<zyga> each snap command should print that?
<ogra_> 30sec to 1min ... i didnt actually stopwatch it
<zyga> I think that's not reasonable, we'll just get it faster
<zyga> what did you test this on?
<ogra_> dragonboard
<zyga> I run on pi2 all the time and it's a few seconds at most
<ogra_> i.e. the fastest arm arch we have
<zyga> wow, measure your card, maybe it's the cause
<ogra_> i use the same cards everywhere ... 48MB/s throughput
<ogra_> this is with todays image ... i.e. the first one that has all bits in place
<zyga> odd, I will give it a try with the next image tomorrow
<zyga> not everything is in place yet
<daker> hi guys snapcraft questions :
<daker> 1- how can i tell snapcraft to not pull git submodules ?
<daker> 2- snapcraft snap don't produce a .snap, any ideas why ?
<daker> doesn't*
<zyga> daker: try just "snapcraft" for 2
<daker> zyga: (y) thanks!
<daker> for 1) i saw that it is harcoded
<zyga> daker: patch snapcraft; no other way
<ysionneau> sergiusens: https://github.com/fallen/snapcraft/tree/dev-alchemy-branch in the plugins directory :)
<ysionneau> 16:00 < oparoz> Thanks for that ysionneau. Regarding snapcraft, do we need more than the alchemy plugin? < what do you mean?
<netphreak> Hi, guys!
<ysionneau> 16:24 < sergiusens> ysionneau, fwiw, cross compiling is super easy, the problem we have from a snapcraft point of view are `stage-packages` and `build-packages` < last time I asked the only way to cross compile was to use qemu-user with a debootstrap of arm userspace?
<ysionneau> did the situation evolve ?
<netphreak> Is it possible to to setup the snappy jdk plugin to pull in a jdk for a specific architecture not the same as the build machine?
<sergiusens> ysionneau, that's not cross compile (qemu-user), that is native compile in an emulated environment :-P
<ysionneau> yeah :p
<ysionneau> sure
<ysionneau> when you say "cross compiling is super easy" does it mean it is now possible to do it?
<sergiusens> ysionneau, only for the kernel; I haven't solved `stage` and `build` packages as I mentioned
<netphreak> ?
<sergiusens> netphreak, not as it is right now
<daker> sergiusens: any idea what would be the appropriate keyword for the git recurse-submodules ?
<netphreak> :/
<netphreak> makes idk and java a bit more complex to handle.. /
<netphreak> jdk
<netphreak> is it something that is on the todo list?
<netphreak> or is there somewhere i can pull down a precompiled jdk for Xenial from for armhf i can use?
<netphreak> ffrom snap
<dbrouwer> Are there instructions for enabling the ttyO1-O5 serial ports on the BBB in snappy?
<daker> Hi guys again store questions: what does Snap name stand for ? and which Series should i target ?
<zyga> daker: snap name == just a name
<daker> i didn't it's says invalide name :D maybe it should be lowercase ?
<daker> i did*
<daker> beuno: can you help please ?
<beuno> daker, sorry, what's the context here?
<beuno> what are you tryi ng to do?
<beuno> snap name is indeed the name of the snappy package
<beuno> it'll be what people type in the command line, so yes, lowercase and no special characters
<daker> so "MicroPython" is an invalid name ?
<daker> ah ok
<zyga> daker: yep, micro-python or micropython will work
<daker> beuno: because the indicator on the right is green with "MicroPython"
<daker> and the helptext doesn't mention lowercase at all
<beuno> daker, I'll get that fixed, thank you
<beuno> beowulf, ^
<daker> beuno: thanks!
<qengho> You Ubuntu guys should sell some crash-reporting service for snaps.
<daker> zyga: one last question: i see people uploading different arch, what arch should i build againt
<zyga> daker: what do you want to target?
<beowulf> daker: beuno: thanks, will fix
<beuno> daker, as many as you can?  :)
<qengho> daker: Why not all of them?
<beuno> I think amd64 and armhf will get you the vast majority though
<daker> beowulf: thanks! just avoid the confusion :D maybe also add a text under the input explaining what snap name means
<qengho> (and PowerPC users try to weep some more from their dessicated tear ducts.)
<beowulf> daker: good idea, thanks
<daker> beuno: and how it will served via the store ? like someone on an rpi trying snapp install mysnapname and i only have an amd64 snapp on the the store
<beuno> daker, they won't see snaps for architectures that aren't their own
<beuno> thanks beowulf
<daker> beuno: i mean how does the store knows the arch, is it via the snap name ex : "forbar_version_i386.snap"
<beuno> daker, no, it ignores the name. It parses it out of the snap.yaml
<daker> beuno: ah i see
<jkridner> hi sergiusens
<sergiusens> hi
<sergiusens> jkridner, and you have kyrofa
<kyrofa> jkridner, hey there
<jkridner> thanks sergiusens and kyrofa
<ysionneau> sergiusens: with which python package did you test your commit? the debian package (python-magic)? or the pip one?
<ysionneau> it's just a matter of being consistent, I don't care which one you chose
<sergiusens> ysionneau, the debian one
<ysionneau> allright, then let's just commit with this one
<ysionneau> it's ok for you if I change the pip line ?
<ysionneau> (the one in .travis.yml)
<netphreak> hi, guys!
<zyga> hi
<netphreak> Is there anyway i can pull down a architecture specific java jdk (not using the jdk/maven plugin)?
<zyga> I don't know, sorry
<netphreak> problem is jdk/maven plugins download an jdk matching the build machine's architecture :/
<zyga> netphreak: I don't know if cross compiling is supported yet
<netphreak> well, i suppose the jdk is exist in allready compiled state -ready to be pulled in?
<zyga> netphreak: I think there are some requests for cross architecture snapcraft but you'd have to check that yourself
<zyga> (even if bits are already built snapcraft would need to understand that you are targetting a different arch)
<dbrouwer> Can someone give me some guidance? How do I enable  the ttyO1-O5 serial ports on the BBB in snappy?
<zyga> dbrouwer: I don't think you can do that yet, you'd have to create a snap that listens on those ports and you'd have to pass the hardware to that snap
<zyga> dbrouwer: come back in two weeks
<zyga> dbrouwer: then it should be doable
<dbrouwer> All right. Thanks! That at least gives me some hope!
<oparoz> Is there a snap package builder status page to know when to avoid requesting builds?
<oparoz> Maybe that's a question for #launchpad...
<qengho> oparoz: what would make you avoid it?
<daker> anybody know what's does : Unexpected output from click-review.
<daker> stand for ...
<oparoz> qengho: https://bugs.launchpad.net/launchpad/+bug/1569023
<ubottu> Launchpad bug 1569023 in Launchpad itself "Snap builder fails to pull files (violation of protocol)" [Undecided,New]
<oparoz> qengho: If the dashboard shows lots of builds failing, there is no point in overloading the system. It doesn't seem to be the case here though
<qengho> daker: hrm. I'd check  https://myapps.developer.ubuntu.com/  . It could be the package verifier had a complaint, but the client you are running didn't understand it. (That would be a bug, but not your problem.)
<daker> qengho: that's the automated review
<qengho> daker: I assumed you just uploaded a package, that is?
<daker> yes .snap
<qengho> Sweet! daker, check the automatic review.
<daker> the automated review says : Unexpected output from click-review. :D
<daker> and the package is refused
<qengho> Whoa.
<daker> hi beuno sorry the noise, can you pleas help ?
<daker> for*
<beuno> daker, hi
<daker> beuno: https://i.imgur.com/0WWnKzx.png
<beuno> daker, it seems to think it's a click and not a snap
<beuno> daker, did you upload it to Ubuntu Core?
<beuno> https://myapps.developer.ubuntu.com/dev/click-apps/?format=snap
<daker> beuno: yes
<daker> https://i.imgur.com/906B4bw.png
 * beuno looks
<daker> id: 4841
<daker> beuno: https://i.imgur.com/Iixkk7h.png
<beuno> the review tools aren't happy:
<beuno> beuno@beuno-desktop:~/canonical/click-reviewers-tools$ python3 bin/click-review ~/Downloads/micropython.daker_1.7_i386.snap
<beuno> ERROR: could not find required 'hooks' in manifest:
<beuno> {'architecture': ['i386'],
<beuno>  'description': 'MicroPython is a lean and efficient Python implementation for '
<beuno>                 'microcontrollers and constrained systems.',
<beuno>  'framework': 'ubuntu-core-15.04-dev1',
<beuno>  'icon': 'meta/icon.png',
<beuno>  'installed-size': '481',
<beuno>  'maintainer': 'Adnane Belmadiaf <daker@ubuntu.com>',
<beuno>  'name': 'micropython',
<beuno>  'title': 'A lean and efficient Python implementation for microcontrollers.',
<beuno>  'version': '1.7'}
<beuno> daker, how did you build it?
<daker> yes that's i saw :D
<daker> snapcraft snap
<daker> then snapcraft
<daker> $ snapcraft -v
<daker> snapcraft (1.1.0).
<oparoz> 1.1.0 ? :-O
<daker> from the ppa :D
<oparoz> Ah :D
<daker> on 14.04
<beuno> so, at this point, I'm not sure
<beuno> I'm missing the people who know snapcraft and the reviewers tools today!
<beuno> daker, I'll chase this up for you tomorrow with jdstrand
<daker> beuno: thanks, i'll give it another try
<daker> beuno: do you want to me fil a bug ? just in case you forgot
<beuno> daker, sure, that'd be useful to track
<stgraber> jdstrand: lxd 2.0 final sent to the snappy store
<stgraber> beuno: thanks!
<beuno> :)
<daker> beuno: https://bugs.launchpad.net/snapcraft/+bug/1569041
<ubottu> Launchpad bug 1569041 in Snapcraft "ERROR: could not find required 'hooks' in manifest" [Undecided,New]
<kyrofa> daker, I don't think snapcraft ever included hooks in the manifest. Note also that you're using 2.x yaml on a 1.x snapcraft
<daker> kyrofa: oh! really
<kyrofa> daker, you need to be using this: https://github.com/ubuntu-core/snapcraft/blob/1.x/docs/snapcraft-syntax.md
<kyrofa> daker, specifically referring to your use of `apps` instead of `binaries`
<daker> i see
<daker> kyrofa: what's the recommended version ? 2.x ?
<kyrofa> daker, it depends on what your target-- are you wanting to ship snaps targeting 15.04 or 16.04 Snappy ubuntu core?
<daker> 15.04
<kyrofa> daker, then you're made the right choice. Note however that 15.04 will reach end-of-life soon
<kyrofa> Man I can't type today. you've*
<daker> :)
<kyrofa> daker, basically, Snapcraft 1.x targets pre-xenial, Snapcraft 2.x post-xenial
<daker> i see
<daker> kyrofa: anyidea if this is correct https://paste.ubuntu.com/15768257/ ?
<daker> this result in No such file or directory: '/home/daker/Work/micropython-snappy/snap/bin/micropython'
<daker> the binary is in /home/daker/Work/micropython-snappy/snap/usr/local/bin/
<kyrofa> daker, yeah that looks correct. Do any parts place the `micropython` executable in bin/
<kyrofa> ?
<kyrofa> Ah
<kyrofa> daker, well then, not correct-- use /usr/local/bin/
<kyrofa> Rather, usr/local/bin/
<kyrofa> (I can't remember if that's automatically added to the path)
<kyrofa> You can try just specifying micropython on its own, see if it is
<daker> yes testing
<daker> click-review crashed :D
<daker> kyrofa: can you please check if the syntax is correct https://paste.ubuntu.com/15768597/ ?
<daker> Yay it works :D
<daker> beuno: found the issue
<daker> well actually kyrofa did
<kyrofa> daker, very good :)
<daker> kyrofa: and the snap is waiting for review :D
<daker> thanks!
<kyrofa> daker, no problem. Is that snapcraft bug invalid, then?
<daker> kyrofa: yes fixed
<Swami_> hi
<kyrofa> Hey Swami_, welcome
<Swami_> Hi Kyrofa,
<Swami_> just wanted to check if this is the irc channel for #snappy?
<Swami_> from ubuntu core team
<kyrofa> Swami_, it is indeed!
<Swami_> thanks, this is my first time here.
<Swami_> never used irc before.
<kyrofa> Swami_, we're here for questions, though I'll warn you that most people are typically here a bit earlier in the day
<Swami_> has anyone tried porting from source (custom kernel) to create their own ubuntu snappy image for a generic amd64 device, just as a first step?
<Swami_> I was going through the mail digest for the past year and going through. Is there a list or some kind of writeup if someone has as there are not much info. available in snappy developer website for bringing up a custom kernel.
<Swami_> Thanks Kyrofa.
<kyrofa> Swami_, the kernel snaps are pretty new
<kyrofa> Swami_, but yeah, you should be able to use the kbuild/kernel plugins in Snapcraft to build your kernel snap, then use ubuntu-device-flash to generate an image configured with it
<kyrofa> Swami_, thing is, this only applies to xenial, which isn't released yet so it's still changing
<kyrofa> Swami_, feel free to play with it, but keep that in mind
<Swami_> I was reading through that I need some Apparmor changes, if I wanted to use my custom kernel. say for eg., I downloaded the kernel source from kernel.org and is it possible to use this kernel source to build for snappy's kernel image?
<Swami_> sure, got it. I am not there yet. still new to snappy. haven't explored latest releases yet.
<kyrofa> Swami_, I'd say it depends on the version
<kyrofa> Swami_, I'm afraid I'm also not familiar with how much apparmor has been upstreamed
<Swami_> I see. Is there a link which I can refer to build a custom kernel for my own engineering snappy image. Rather than picking the device tar ball from ubuntu server and then just using ubuntu-device-flash for just creating the image using the device tar file.
<kyrofa> Swami_, perhaps this will be helpful: http://blog.sergiusens.org/posts/Snapcrafting-a-kernel/
#snappy 2016-04-12
<Swami_> sure thanks kyrofa. if you are around
<Swami_> will get back and look through it
<stgraber> beuno, jdstrand: Just uploaded a tiny fix for LXD 2.0.0 to the store (use the old lxcbr0 bridge as we don't have lxdbr0 on snappy yet)
<stgraber> folks upgrading didn't have any issue with rc9 or 2.0 final, but folks doing a clean install would have got broken networking, this will fix new installs
<stgraber> cyphermox: ^
<cyphermox> stgraber: thanks
<davidcalle> Hi snappers, when using the snap find command, I don't see the fully qualified app name, how can I install apps without it?
<davidcalle> Anyone, zyga maybe? ^
<davidcalle> "when using the snap find command, I don't see the fully qualified app name, how can I install apps without it?"
<zyga> davidcalle: store bug
<zyga> davidcalle: and it's snaps, not apps
<davidcalle> zyga =) ty
<mvo> davidcalle: beuno mentioned the other day they are working on automating this, for now we may need to set aliases for the store apps (worst case manually until this is automated). but I'm not sure what the status is, maybe its fixed already, beuno will know
<ogra_> ubuntu@localhost:~$ snap install webdm
<ogra_> error: access denied
<ogra_> mvo, can we make that message a bit more user friendly ?
<ogra_> (it used to tell me i should use sudo etc)
<oparoz> Any idea why this doesn't compile on arm? https://github.com/kyrofa/mdns-publisher/blob/master/main.go
<davidcalle> mvo: thanks
<oparoz> Actually, that's wrong, it compiles, but fails in the stripping phase
<mvo> ogra_: yes, I think we should
<ogra_> Building dependency tree...
<ogra_> E: Unable to locate package ubuntu-core-libs
<ogra_> P: Begin unmounting filesystems...
<ogra_> mvo, s390x and ppc64el fail with that ^^^
<ogra_> do we not build that package there ?
<oparoz> https://bugs.launchpad.net/snappy/+bug/1569280
<ubottu> Launchpad bug 1569280 in Snappy "Snapcraft fails to strip go binaries on arm" [Undecided,New]
<mvo> ogra_: I'm surprised by that, I think that worked before :/
<ogra_> mvo, did we ever buikld images for them ?
<ogra_> (i just added both arches and started a testbuild)
<ogra_> OH !
 * ogra_ wasnt aware it is a meta package :P
<mvo> ogra_: I don't think we did images for them
<ogra_> right
<ogra_> where the heck do the seeds live for that package ?
<ogra_> ah, found them
<daker> kyrofa: hi sorry for the noise, store question : if i have rev1 of v1.0 of my snap that's have been automatically rejected, i need to upload v1.0.1(for ex) ?
<attente> is there a reason the names of the binaries in /snaps/bin don't match the ones in the snaps themselves?
<ogra_> attente, got an example ?
<attente> ogra_: ubuntu-calculator-app for example
 * ogra_ never used that 
<ogra_> i meant an example of the binary names :)
<ogra_> vs what you expect
<attente> ogra_: maybe a better question is what is the canonical way of launching a snap
<ogra_> packagename.binary-name
<ogra_> i.e. in my nethack snap i defined "run" ... to start my game i now need to exec nethack.run
<attente> ogra_: so in ubuntu-calculator-app, i think the Exec line of the desktop file is incorrect possibly
<ogra_> well, i thought dpm has tested that
<attente> ogra_: it just has the line 'Exec=ubuntu-calculator-app
<ogra_> and there is no binary of that name in the snap ?
<ogra_> (not sure if .desktop files are simply handled differently)
<ogra_> i never used them :)
<attente> ogra_: no, there's only /snaps/ubuntu-calculator-app.ubuntucoredev/current/usr/bin/ubuntu-calculator-app
<ogra_> then thats fine i guess
<attente> ogra_: but /snaps/*/current/usr/bin isn't in the user's path
<attente> only /snaps/bin is
<attente> so it finds /snaps/bin/ubuntu-calculator-app.calculator instead
<ogra_> well, i dont exactly know how ,.desktop files are operated in snappy ... but i guess it is only run inside the confined env ... where that path will be exported by the launcher
 * ogra_ assumes /snaps/bin/ubuntu-calculator-app.calculator is a script
<attente> yes
<ogra_> then it will likely set the path correctly
<attente> ogra_: so i should probably not be using the desktop file at all and just using the script in /snaps/bin directly?
<attente> since it seems like the desktop file refers to the binary in the snap itself and not /snaps/bin
<ogra_> you should use the ,.desktop files from GUIs obviously ... :)
<ogra_> no idea how the integration works with that though
<ogra_> from commandline you shoudl always just run ubuntu-calculator-app.calculator
<tsimonq2> ogra_: can you make metapackages with Snappy or does it have to all be in the package?
<tsimonq2> whoops, snap, not package :)
<ogra_> tsimonq2, whats the difference ?
<ogra_> :)
<tsimonq2> heheheh
<ogra_> a snap *is* essentially a metapackage :)
<tsimonq2> well
<tsimonq2> oh I see
<ogra_> containing all the bits and pieces
<tsimonq2> so let's say I want to make the bob metapackage, and include like 20 deb dependencies, would that work smoothly?
<tsimonq2> ooh, could I get it from upstream instead if I wanted to?
<ogra_> sure, you would just define all the debs in your snapcraft.yaml and snapcraft would include them
<ogra_> and yes, you could as well use the upstream source
<tsimonq2> are the debs only from Ubuntu or can they be from Debian as well?
<ogra_> for one or even for all your deps
<ogra_> only from ubuntu
<tsimonq2> oic
<tsimonq2> is there a tutorial I could follow to do this?
<tsimonq2> or is it really simple?
<ogra_> there are examples in the snapcraft-examples package
<tsimonq2> is that a deb package that I could install now, or a snappy package? :D
<ogra_> snapcraft is a deb package ... note though that you need xenial if you build for xenial snappy
<tsimonq2> I'm on Xenial :)
<ogra_> good
<ogra_> well, "sudo apt install snapcraft"
<ogra_> ;)
 * tsimonq2 does sudo apt update && sudo apt -y install snapcraft snapcraft-examples
<tsimonq2> :)
<ogra_> create a workdir ... create a snapcraft.yaml file ... run "snapcraft" in the workdir and if your yasml file is correct you get a working snap ;)
<ogra_> *yaml
<tsimonq2> where are the examples then? :)
<ogra_> i guess in /usr/share7doc
<tsimonq2> also, can I upload snaps to PPAs?
<ogra_> dpkg -L snapcraft-examples will tell you as usual ;)
<ogra_> no
<tsimonq2> that would be an awesome feature
<ogra_> you can use launchpad to build snaps from a snapcraft.aml in a bzr branch
<ogra_> and you can upload them to the store
<ogra_> snaps *are* PPAs ... like they are metapackages ;)
<tsimonq2> oh okay :)
<tsimonq2> so let's say I have my snap built and all ready to go, how do I test it?
<ogra_> in xenial you shoudl actually be able to install it directly on your system ...
<ogra_> at least after release, not sure what bugs are still there
<tsimonq2> it would replace packages and cause a big huge mess, I would prefer a VM :)
<ogra_> alternatively you can run a complete snappy in kvm or on i.e. a raspberry pi
<ogra_> no, it wouldnt cause any mess
<tsimonq2> KVM? I thought there was a guide somewhere for that...
<ogra_> snappy on classic installs is a feature of xenial :)
<ogra_> installing a snap will "just work" ... snaps live in their own filesystem space, they wont mess up anything
<ogra_> (it shoudl already work if your xenial system is up to date, ubuntu-snappy-cli should be installed)
<oparoz> ogra_: What's the strategy when we need to ship a firewall, log rotater, etc. It's not really efficient to add it to every single snap part of a solution
<ogra_> you would creater a library snap that all your other snaps (only yours though) can consume
<oparoz> ogra_: Ah, good. Is there doc on that already?
<ogra_> not sure
<tsimonq2> ogra_: if I create a snappy package from upstream, will it automatically pull in updates from there?
<tsimonq2> for example GitHub
<ogra_> if you re-build it
<tsimonq2> that seems a bit tedious :|
<tsimonq2> is it easy to rebuild and reupload?
<ogra_> if your snapcraft.yaml is correct it should be one click in launchpad
<ogra_> (modulo build failures that the upstream changes introduce indeed ...)
<tsimonq2> can you set up daily builds?
<ogra_> i think launchpad receipes are supported ... not sure though
<tsimonq2> I'll try later today :)
<tsimonq2> then to update everything is sudo snappy update?
<ogra_> sudo snap update
<ogra_> the "snappy" command is dead
<tsimonq2> why?
<tsimonq2> 2 extra letters? :P
<ogra_> dunno
 * ogra_ wasnt involved in that discussion :)
<tsimonq2> alright, thank you ogra_, I'm off for a few hours, have a nice day. :)
<ogra_> you too
<dholbach> kyrofa, sergiusens: can you maybe advise on https://bugs.launchpad.net/click-reviewers-tools/+bug/1569226?
<ubottu> Launchpad bug 1569226 in click-reviewers-tools (Ubuntu) "click-review crashed with KeyError in check_apps_plugs_mapped_oldsecurity(): 'plugs'" [Medium,New]
<dholbach> I don't know what the right fields and stuff are
<kyrofa> Hey dholbach!
<dholbach> hey hey - how are things?
<sergiusens> morning
<ogra_> eeek !
<ogra_> sergiusens, !
<ogra_> sergiusens, all our initrds use lzma now ... seems the kernel plugin has no check about the compression method and just assumes gzip
<sergiusens> ogra_, well, not really; it said we only supported that for now
<sergiusens> lzma or lzma2 or xz?
<ogra_> bug 1569337
<ubottu> bug 1569337 in Snapcraft "snapcraft kernel plugin needs to check compression method of the initrd before trying to unpack it" [Undecided,New] https://launchpad.net/bugs/1569337
<sergiusens> ogra_, thanks
<sergiusens> ogra_, probably an EOW thing
<ogra_> yeah
<kyrofa> dholbach, things are frantic, haha
<kyrofa> dholbach, any chance that bug relates to the removal of old-security from snappy?
<dholbach> kyrofa, I don't know which fields are current and which old fiels should still be allowed
<dholbach> but this breaks store reviews right now
<kyrofa> dholbach, join the club, things are changing fast :(
<kyrofa> dholbach, I believe old-security is gone and one needs to use the actual interface names now. But then I heard maybe that would come back
<kyrofa> dholbach, zyga would know more on that one
<zyga> old-security is gone now
<zyga> but we'll probably bring it back later, for now use real interfaces
<zyga> they are listed in docs/interfaces.md
<zyga> note that only auto-connecting interfaces really work as connection/disconnection commands are not wired to the backend yet
<zyga> that will land today though so all the interfaces will be fully functional
<dholbach> ok... I guess I need to talk to jdstrand to find out what policy should be in this case... reject snaps which don't have proper interface names?
<kyrofa> dholbach, I guess so. I thought we had old-security as a migration plan, but I guess not?
<zyga> dholbach: snappy validates that internally
<zyga> kyrofa: it's all crazy :)
<kyrofa> zyga, I've noticed :)
<zyga> kyrofa: I want to add old-security back but that's not top-priority
<zyga> top priority is fully functional REST api for managing interfaces
<kyrofa> zyga, I'm not sure it's necessary since everyone is broken now-- everyone will have to move to interfaces if they want stuff to work
<zyga> kyrofa: true
<zyga> kyrofa: but some edge cases need old security
<dholbach> zyga, right... but the store needs to check it too
<zyga> sergiusens: can you release snapcraft that allows something other than old security today?
<zyga> dholbach: no
<zyga> dholbach: the store doesn't have to check it in any way
<oparoz> zyga there is no docs/interfaces.md in snapcraft
<zyga> dholbach: we'll add some checks via assertions but that's not today
<kyrofa> oparoz, that's snappy
<sergiusens> ppisati, fwiw ogra_ logged a bug about the gzip issue
<zyga> oparoz: sorry, look at snappy
<zyga> oparoz: github.com/ubuntu-core/snappy/ docs/interfaces.md
<dholbach> zyga, what if somebody uploads an old style app to the store
<sergiusens> zyga, today? wow
<oparoz> Thanks guys
<dholbach> zyga, with no plugs defined
<zyga> dholbach: nothing
<zyga> dholbach: it will just run without any extra permissions, fully confined
<zyga> dholbach: snappy ignores unknown or invalid interfaces
<sergiusens> zyga, we can, but we need old-security replacements for our examples
<zyga> sergiusens: I'd be fine with a half-broken release that lets people snapcraft non-broken snaps without old-security
<zyga> sergiusens: I suspect that most of those can just use normal interfaces but I didn't check
<sergiusens> zyga, right, but we won't be able to know if snapcraft itself is working
<sergiusens> or doing the right thing
<zyga> sergiusens: ideas welcome, right now you cannot build a snap that uses unity7 + x11 plugs
<zyga> sergiusens: I don't know snapcraft as well as you do, what would be the best way forward?
<sergiusens> zyga, 1st; is there an os image in edge that works already?
<zyga> sergiusens: mvo built a package, the image is soon after that I bet
<sergiusens> zyga, 2nd; do we have replacements for everything in `examples` wrt interfaces?
<zyga> sergiusens: I don't know what's in all the examples
<sergiusens> zyga, 3rd; is old-security coming back or gone forever?
<sergiusens> if it is gone, I'd rather have it gone forever
<zyga> sergiusens: 3 not sure, I can implement it but if powers that be demand it gone, what can we do?
<zyga> sergiusens: https://github.com/ubuntu-core/snappy/blob/master/docs/interfaces.md
<zyga> sergiusens: that is what we have today
<dholbach> thanks... I'll just catch the error if no plug is defined
<dholbach> think that should be fine
<sergiusens> zyga, create a snapcraft bug and I'll work on a branch; kyrofa heads up, we might release today
<kyrofa> sergiusens, thanks for the heads up
<kyrofa> sergiusens, though that probably means we need to do the examples as well
<zyga> sergiusens: sure; I'll open the bug in a moment
<attente> has something changed with the /run/snapd.socket api in the past day? i seem to only be getting 404 errors now
<zyga> attente: many things were removed
<zyga> attente: look at docs/rest.md (it has been updated AFAIK)
<zyga> attente: which endpoints were you calling
<attente> zyga: for example GET /2.0/snaps?sources=local
<attente> zyga: docs/rest.md was removed too?
<attente> zyga: ok, i'll take a look, thanks for the pointer
<zyga> attente: no, it is still there?
<zyga> https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#v2snaps
<zyga> attente: the prefix changed so you just have to update your client code
<attente> zyga: ok, thanks. is the api going to be frozen at some point?
<zyga> attente: when we release 1.0 I suspect
<zyga> attente: though there will be less changes made now
<zyga> attente: you can expect additions rather than changes
<jdstrand> zyga: fyi, there are checks that the review tools need to do in the absence of assertions
<zyga> jdstrand: perhaps but I don't know what the plan is for that
<jdstrand> zyga: I will handle the review tools
<jdstrand> dholbach: ^
<zyga> jdstrand: thank you!
<jdstrand> but there is no point in changing them atm until we have a working system
<jdstrand> so, perhaps later this week
<zyga> jdstrand: do you know where we are today?
<jdstrand> not yet
<zyga> jdstrand: we got auto-connection feature landed, also for x11 and unity7
<zyga> jdstrand: I'm working on some tweaks to connection control so that it persistst properly and that users are in control
<jdstrand> zyga: x and unity7 are autoconnecting? can you explain what you mean by autocontrol?
<zyga> jdstrand: x11 (it was renamed)
<zyga> jdstrand: it gets connected to os snap on install
<jdstrand> I understand what that means
<jdstrand> that also is a security hole
<jdstrand> so we had the idea that there would be some sort of prompting
<jdstrand> what happened with that?
<jdstrand> beuno: ^ ?
<zyga> jdstrand: there's no propmpting for that as there's no UI for install
<jdstrand> I didn't mean an install prompt
<zyga> jdstrand: oh?
<jdstrand> what I suggested was no autoconnect on install. then on first use, prompt the user somehow, letting them know the app wants privileged access to the user's session. the user says yes or no. if yes, there is an interface connect
<jdstrand> this prompt could be done via zenity, or anything really. mvo was in agreement on the approach
<jdstrand> there is a card on the idea, but I think beuno was shopping it around
<zyga> jdstrand: that's not realistic today
<zyga> jdstrand: we'll improve it with SRUs
<jdstrand> maybe not 'today' but interface connect is surely something for 16.04 release?
<zyga> jdstrand: yes
<mvo> jdstrand: quick question, we don't need ubuntu-core-security-{apparmor,seccomp,utils} anymore, correct?
<jdstrand> so it should be realistic for 16.04 release
<jdstrand> mvo: correct
<mvo> ta
<jdstrand> mvo: they should be removed from the archive too
<zyga> jdstrand: there will be no prompting for 16.04
<zyga> jdstrand: we can explore that after the release
<jdstrand> zyga: why? who decided that? we are making announcements for this. where was this discussion?
<zyga> jdstrand, mvo: FYI we only run apparmor_parser but templates seem to refer to included files
<jdstrand> zyga: the prompt can be as simple as updated the shell script
<jdstrand> zyga: the includes don't come from ubuntu-core-security. they come from apparmor
<zyga> jdstrand: there are no APIs to implement the prompt
<jdstrand> we don't need it
<zyga> jdstrand: it's not just the UI
<jdstrand> all we need is interface connect foo unity7
<jdstrand> or whatever the api is
<zyga> jdstrand: yes and that's not ready yet
<zyga> jdstrand: I'm trying to get it ready
<jdstrand> zyga: but you said a moment ago it would be for 16.04 release
<zyga> jdstrand: auto connect is internal
<zyga> jdstrand: connect/disconnect requires an API
<jdstrand> I don't care about *today* so much as when someone tries to use this thing on release day, people see the choice
<zyga> jdstrand: I'm trying to implement the API so that we can use it but it's not working as of this second yet
<zyga> jdstrand: the goal is to get it working today (API) but I don't think we can manage a GUI at this stage
<jdstrand> a gui is a zenity prompt
<jdstrand> snappy sees if x11 or unity7 interface (or home) is requested. oh, it is, insert this zenity prompt in the shell script
<zyga> jdstrand: can you implement one quickly? perhaps we can manage that?
<zyga> jdstrand: note that there's a REST API there
<jdstrand> I need beuno to confirm it is ok
<zyga> jdstrand: so it's not a simple sequential client
<jdstrand> zyga: where is the rest api?
<zyga> jdstrand: you'd have to install the snap, inspect available plugs
<zyga> jdstrand: deamon/api.go, the docs are in docs/rest.md
<zyga> jdstrand: then see if your new snap has x11 or unity7 plug
<zyga> jdstrand: and then offer a quick prompt (even without zenity, just a simple stdin prompt)
<zyga> jdstrand: and then call .Connect()
<zyga> jdstrand: note that there are GO bindings for the api (look at client/interfaces.go)
<zyga> jdstrand: I think someone could look at doing that but I need to finish connect/disconnect first
<zyga> jdstrand: also note that you need to work with cmd/snap/cmd_ops.go (AFAIR) because that's where install is
<zyga> jdstrand, mvo: can tell you more
<jdstrand> when I spoke to mvo before he said that he thought this was all managable. that was a few weeks ago
<zyga> jdstrand: I thnk that explains it
<zyga> jdstrand: there were many things that got us busy
<jdstrand> sure, I understand
<jdstrand> I'm not upset about that or anything-- I just want to make sure this is handled in some way
<zyga> jdstrand: I understand, I'm sorry if I seem defensive :-) I'm just tired and we're all racing to get bits in place
<jdstrand> no worries
<jdstrand> mvo: can you ping me when you adjust the seeds for ubuntu-core-security?
<dholbach> jdstrand, thanks
<beuno> jdstrand, I'll follow up on the notify-when-x
<jdstrand> thanks!
<elopio> ogra_: any news about the new archs? I'm digging all the emails from yesterday but haven't seen anything.
<ogra_> elopio, well i got no mails (probably olli forgot to forward something) ... but i have the rootfs snaps building (sadly they arent published yet because i still need to teach livecd-rootfs to not try to build kernel snaps for them)
<ogra_> https://launchpad.net/~ubuntu-cdimage/+livefs/ubuntu/xenial/ubuntu-core-system-image/ both fail right after creating the ubuntu-core os snap
<elopio> the image PPA is still not building for s390x. mvo: can you enable that? or do you know who can?
<elopio> noise][: can you help me with spi? I'm getting 401 checking for the results of the run I launched. https://paste.ubuntu.com/15793410/
<mvo> cjwatson: who should I talk to about s390x builds for https://launchpad.net/~snappy-dev/+archive/ubuntu/image/+packages ? is that something you could enable or do I need to ask IS? or can I do it myself if I find the right knob :) ?
<mvo> elopio: I ask someone who knows everything ;)
<mvo> elopio: I think I can not do it myself
<noise][> elopio: hey.. that's odd
<cjwatson> you can't do it yourself because s390x has no virtualised builders yet, so it lacks sandboxing
<cjwatson> but I see that PPA is already devirtualised
<cjwatson> mvo: done
 * ogra_ cureses about livecd-rootfs code ....
<cjwatson> mvo: new builds aren't auto-created, but if you want to create new builds of an existing source in that PPA without reuploading, you can copy the source over itself including existing binaries and that has the side-effect of creating missing builds
<ogra_> feels like i painted myself into a corner, skipping kernel creation for one arch is really hard now :/
<cjwatson> mvo: (also obviously only xenial, since s390x didn't exist before that)
<mvo> cjwatson: \o/
<mvo> cjwatson: thanks a bunch
<cjwatson> np
<elopio> cjwatson: mvo: thanks!
<ppisati> sergiusens: saw it
<elopio> noise][: here in the dragonboard section is all I did, in case it helps: http://pad.ubuntu.com/spi
<ppisati> sergiusens: i'm a bit nervous about the 'snappy login' step, i bet there's no way to skip it
<zyga> ppisati: snap login, snappy is gone
<ppisati> zyga: snapcraft login i mean
<zyga> ah
<ppisati> zyga: what does it do btw?
<zyga> ppisati: I'm not quite sure
<ppisati> sergiusens: ^
 * ogra_ guesses it logs you in
<ogra_> :P
<ppisati> ogra_: ok, but why it needs to log me into UU build a kernel/snap?
<ogra_> heh, no idea ... i was just stating the obvious :P
 * ogra_ doesnt even know where to it logs you in
<ppisati> ah ok
<ogra_> i assume "snapcraft snap" should still work without login though
<ogra_> (it does on the livefs builders ... and we wouldnt be able to use any kind of login there(
<noise][> elopio: can you try to query the results w/o the test opp query param?
<noise][> just https://spi.canonical.com/products/$PRODUCT_ID/tests/events
<ppisati> ogra_: nope, it requires the login
<ppisati> http://pastebin.ubuntu.com/15794106/
<ppisati> btw i thought 'snap' was the default target
<ogra_> ppisati, well, it has to be skippable, else we cant build images
<ogra_> zyga, sergiusens ^^^
<ogra_> there is no way we can add credentials on the image builders, nor can they see the store
<sergiusens> ogra_, ppisati the login is to download the os.snap. I wasn't sure it was possible to download without being logged in
<ogra_> sergiusens, just grab it from cdimage :P
 * zyga doesn't know what login is for in the long term, cannot comment
<ppisati> sergiusens: does it store my credentials somewhere?
<sergiusens> ppisati, yes, in the form of oauth; not the password
<sergiusens> ppisati, ~/.config/snapcraft/snapcraft.cfg
<ogra_> sergiusens, how would that work for i.e. a launchpad based build ?
<sergiusens> it is only the kernel plugin
<ogra_> where you simply dont have these credentials
<sergiusens> ogra_, ^
<sergiusens> only the kernel plugin
<sergiusens> kernel plugin is experimental
<ogra_> sure, but what stops me from using the kernel plugin ibn an LP build
<sergiusens> nothing is set on stone
<sergiusens> and as I said multiple multiple multiple multiple times
<sergiusens> this download thing goes away as soon as snappy does the initrd dance the correct way
<sergiusens> ogra_, ^ what stops you is the fact that you need to login
<ogra_> (i doubt that will happen before next LTS :P )
 * ogra_ is obviously very pessimistic wrt the SRU process of massive architectural changes :)
<elopio> noise][: same result.
<noise][> elopio: hmm, and is that repeatable? starting w/a new product?
<elopio> noise][: let me try that.
<elopio> noise][: I can't create it anymore. Now I get 401 on the first step.
<elopio> oh, wait, no there was a typo.
<elopio> going on...
<sergiusens> zyga, I logged https://bugs.launchpad.net/snapcraft/+bug/1569452 since I am impatient
<ubottu> Launchpad bug 1569452 in Snapcraft "Update snapcraft to use new interfaces" [Undecided,New]
<elopio> noise][: reproduced again, I created everything from scratch, made a POST on the images endpoint and got 201. But when I query the tests/events, I get 401.
<noise][> elopio: ok, I don't have time to dig at the moment, but can try to repro later this afternoon
<sergiusens> jdstrand, zyga can you check if I made as "an accurate as possible" translation of things here https://github.com/ubuntu-core/snapcraft/pull/441/files
<sergiusens> I am aware some things will just not work
<sergiusens> like busybox which would need a read_path of / at least
<zyga> looking
<sergiusens> not sure what `network-management` was for, I hope it was covered by `network-bind` and also not sure I need `network` if I have `network-bind`
<kyrofa> sergiusens, I was just about to ask that question :P
<sergiusens> nor if `network-service` is covered in any way
<kyrofa> network-service is now network-bind, I believe
<sergiusens> my gut says it would
<sergiusens> or anything needing network-bind would need network
 * sergiusens is sad for removing all those tests though
<zyga> sergiusens: network-management is more like "I want to be network-manager"
<zyga> network == client; network-bind == server)
<sergiusens> zyga, ok, so for something that listens on a port and also talks to the network I need both?
<zyga> it won't hurt
<zyga> but I suspect network-bind gives you network
<zyga> jdstrand: can clarify
<sergiusens> zyga, I'll wait for your first pass
<zyga> we should add those kind of FAQs to the docs :/
<zyga> sergiusens: I reviewed it already
<sergiusens> oh; yeah, the docs aren't really all that complete ;-)
<sergiusens> zyga, the mosquitto one, elopio can you look ^
<sergiusens> zyga, if you look at how the listener plug is defined it seems to indicate it needs `network` and not `network-bind`
<zyga> sergiusens: sorry, I'm so drained today I feel like I'm about to fall asleep right here;
<zyga> my comments were based purely on the names
<jdstrand> sergiusens: network-management was network-admin on 15.04
<jdstrand> sergiusens: it is network-control now
<jdstrand> sergiusens: network-bind and network client are not the same. network-bind currently gives you all of network, but there is no guarantee that will always be the case
<kyrofa> jdstrand, good to know, thank you
<sergiusens> jdstrand, ok, so my shout client I should add network and network-bind (basically a web irc bouncer)
<sergiusens> shout app (not client)
<jdstrand> sergiusens: gopaste technically would need network-control for a 1-1 mapping, but I think gopaste is suffereing from bug #1465724
<ubottu> bug 1465724 in Snappy "net_admin apparmor denial when using Go" [High,Confirmed] https://launchpad.net/bugs/1465724
<jdstrand> sergiusens: I would, yes
<sergiusens> jdstrand, yeah, most likely the case for gopaste
<jdstrand> sergiusens: it is safe to leave network-control out for gopaste and just live with the denial until we can fix the kernel
<sergiusens> jdstrand, what is your suggestion for it?
<sergiusens> ok
<jdstrand> tyhicks: iirc, that is the current recommendation, right? ^
<tyhicks> jdstrand: yes
<tyhicks> I think I know the proper fix for the denial now
<tyhicks> I'll have another look at it soon
<jdstrand> tyhicks: oh nice :)
<dholbach> elopio, thanks for the update on bug 1569478 and everything
<ubottu> bug 1569478 in Snappy "integration tests fail on armhf and s390x" [Undecided,New] https://launchpad.net/bugs/1569478
<attente> are there any plans to add some api for extracting the metadata out of a snap that isn't yet installed?
<kyrofa> attente, a store API already exists. Are you talking about a local snap, though?
<attente> kyrofa: yeah, for sideloading
<kyrofa> attente, not that I know of, but feel free to log a wishlist bug for it
<attente> kyrofa: sure, thanks
<ogra_> You can mount the snap or use unsquashfs to get the snap.yaml
<ogra_> (it is just a squashfs file after all)
<kyrofa> ogra_, hardly an API, but yeah
<kyrofa> attente, if you're just scripting something, that may be a good direction
<ogra_> Well, yaml iis kind of an api :P
<kyrofa> ogra_, hahaha
<kyrofa> attente, may I specifically call your attention to `unsquashfs -e`
<kyrofa> attente, even more specifically: `unsquashfs -e meta/snap.yaml`
<attente> yeah, i was just wondering if maybe there should be some friendlier tooling for it
<attente> kyrofa: cool
<kyrofa> attente, can you explain your use-case?
<kyrofa> attente, though I guess you should do that in the bug anyway-- no need to make you repeat yourself :)
<attente> heh
<oparoz> Is it possible to merge unsquashed snaps and resquash the result?
<beuno> oparoz, you'd have to unpack them, and re-pack them
<beuno> what are you trying to do?
<oparoz> beuno build parts on different machines
<sergiusens> zyga, seems even after changing to interfaces I still have failing tests
<jdstrand> meh, the security policy is messed up for the path renames
<jdstrand> $ focuswriter.run
<jdstrand> mkdir: cannot create directory â/home/jamie/snap/focuswriterâ: Permission denied
 * jdstrand takes a look
<tsimonq2> can I make a snap part that just consists of a package from the Ubuntu archives?
<tsimonq2> or does it *have* to be from source?
<jdstrand> oh no, that wasn't hit. I hit the old ~/snap owned by root bug
<jdstrand> sigh
<jdstrand> but the path rename broke the apparmor system unit
<jdstrand> tyhicks: hey, have you uploaded already?
<jdstrand> we need better integration tests
<tyhicks> jdstrand: I haven't yet
<jdstrand> tyhicks: ok, can you add a super-quick change? just need to update a path. let me get you a bug and details
<tyhicks> jdstrand: yes, this is good timing
<jdstrand> tyhicks: https://bugs.launchpad.net/snappy/+bug/1569573
<ubottu> Launchpad bug 1569573 in apparmor (Ubuntu) "recent snapd path renames causes apparmor to not load profiles on boot" [Critical,Triaged]
<oparoz> Is SNAP_FULLNAME going away?
<tyhicks> jdstrand: uploaded
<sergiusens> jdstrand, tyhicks is that also the reaosn for what I pastebined not working?
<sergiusens> <sergiusens> zyga, jdstrand it seems that with these new interfaces I can't create files in SNAP_DATA http://paste.ubuntu.com/15800694/
<sergiusens> that just in case ^
<zyga> sergiusens: thanks for noticing this. I don't recall us removing this explicitly. I will look at the apparmor template we use
<zyga> I see
<zyga> looks like another victinm of moving files around
<zyga> sergiusens: https://github.com/ubuntu-core/snappy/pull/910
<zyga> after the dust settles we should use ... variables for that :P
#snappy 2016-04-13
<popey> on 16.04, my laptop tells me the snappy command doesn't exist anymore, and if i try to run it i get told to install snappy or ubuntu-snappy-cli - ubuntu-snappy-cli is the latest version (1.9.1.1)
<popey> has the snappy command completely gone now?
<davidcalle> popey: yep
<davidcalle> popey, snappy -> snap
<popey> ah! I see the issue
<popey> snap install foo.snap (for sideloading) goes looking in the store.
<popey> you have to snap install ./foo.snap
<davidcalle> popey: indeed, on it's way to being fixed
<davidcalle> its*
<popey> yay
<Gunther_> Hi everyone! May I ask the question, how to build a kernel snap if the ubuntu app store is not available and therefore the download step in the snapcraft plugins fails.
<ogra_> Gunther_, heh, good question, i guess you would have to hack up the kernel plugin to use a local initrd.img file that you grab before building the snap
<ogra_> sounds like a good wishlist bug :)
<Gunther_> ogra_, I thought so ...
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ has the os snaps for all arches
<ogra_> you can either loop mount it or use unsquashfs to pull the initrd out of /boot from there
<Gunther_> Cool. I will try to extend the kernel.py plugin with an according option
<ogra_> you might hit bug 1569337 btw
<ubottu> bug 1569337 in Snapcraft "snapcraft kernel plugin needs to check compression method of the initrd before trying to unpack it" [Undecided,New] https://launchpad.net/bugs/1569337
<ogra_> (recent initrds use lzma, the plugin hardcodes gzip)
<Gunther_> I already patched this: https://bugs.launchpad.net/snapcraft/+bug/1569337/comments/2
<ubottu> Launchpad bug 1569337 in Snapcraft "snapcraft kernel plugin needs to check compression method of the initrd before trying to unpack it" [Undecided,New]
<Gunther_> but since the download fails, I cannot test iut
<ogra_> yeah :/
<popey> is there some magic to getting X apps to run inside a snap?
<zyga> popey: use the 'x11' plug
<popey> it's like it can't see the xserver, do we need to do the old export DISPLAY?
<popey> oh, got an example zyga ?
<zyga> popey: you shoudn't have to
<zyga> popey: just stick this into your snapcraft.yaml
<zyga> plugs:\n  x11:
<zyga> and reinstall it
<popey> okay, will try, thanks
<popey> it doesn't like that
<popey> argument of type 'NoneType' is not iterable
<zyga> popey: maybe update snapcraft
<zyga> popey: that's the right syntax
<zyga> (this should be reported to sergio)
<popey> i have 2.7
<Gunther_> ogra_: thanks for your help, my prototype kernel.py with local os.snap seems to work
<popey> zyga: odd, I can find no reference to x11 in the snapcraft source I just pulled from github
<zyga> popey: it's a bug, it seems that the validator tries to iterate over None
<zyga> popey: foo: (with the colon at the end) is an empty collection but it sesems it gets parsed to None
<zyga> popey: you can try plugs:\n x11:\  interface x11
<zyga> sergiusens: ^^
<zyga> popey: mind the spaces (precisely)
<popey> Issues while validating snapcraft.yaml: The 'x11' property does not match the required schema: 'interface x11' is not valid under any of the given schemas
<popey> http://paste.ubuntu.com/15807938/ is my yaml
<sergiusens> zyga, popey I haven't released the latest snapcraft yet; I am still waiting for a good snapd binary that works with https://github.com/ubuntu-core/snappy/pull/910 for our examples tests to pass
<zyga> sergiusens: I see
<sergiusens> this branch isn't merged yet https://github.com/ubuntu-core/snapcraft/pull/441
<popey> ok
<popey> thanks
<sergiusens> I tried to manually test locally and it still doesn't work (given snapd in the archive doesn't work either)
<zyga> sergiusens: what were the failures?
<sergiusens> zyga, the one you fixed last night
<sergiusens> zyga, I also don't have replacement logic for `snappy services`
<zyga> sergiusens: that's rm -rf'd now
<zyga> sergiusens: it's coming back after a redesign after release
<zyga> sergiusens: how does snapcraft uses it?
<sergiusens> zyga, so I don't know how to see the failures if services started or not
<sergiusens> zyga, to see if our services started
<sergiusens> zyga, how can I see this from the desktop for a service running inside snappy?
<sergiusens> systemctl doesn't cut it
<zyga> sergiusens: you'd have to use systemd yourself :/
<sergiusens> or please upload a new ubuntu core to the store
<sergiusens> zyga, yeah, systemctl from desktop does not list things in ubuntu-core
<zyga> sergiusens: why is systemctl not sufficient? AFAIR that's what we used internally
<sergiusens> so tell me how to call it
<zyga> hmm?
 * zyga doesn't understand something
<zyga> are we talking about cross-host testing?
<sergiusens> zyga, no
<sergiusens> if you try what i say you will see
 * sergiusens starts babysitting hour
<Gunther_> Hmmm is it possible to build a kernel.snap from a binary linux-image-xxx.deb package?
<ogra_> yes, it is, but you need to do it maunually
<Gunther_> I understand
<kyrofa_> Good morning
<ogra_> Gunther_, line 370-595 ... http://bazaar.launchpad.net/~ubuntu-core-dev/livecd-rootfs/trunk/view/head:/live-build/auto/build (that does tarballs alongside though)
<ogra_> you can do it withour a chroot by simply using "dpkg -x" to unpack the deb and manually create a snap.yaml and meta dir
<Mikaela> When and how will I be able to install snaps on normal Xenial? https://insights.ubuntu.com/2016/04/13/snaps-for-classic-ubuntu forgets to mention it.
<kyrofa_> Mikaela, by the time it's released, I'd say
<Mikaela> I see, thanks
<ogra_> shouldnt that work already ?
 * ogra_ thought all bits are in place with mvo's latest landings
<ogra_> sergiusens, your latest G+ post is private
<mvo> Mikaela, ogra_ it is possible today :) we just don't have a lot in the store yet
<Mikaela> nice, does it come by itself or should I install some package?
<zyga> Mikaela: just wait a few days or apt-get install snapd
<zyga> Mikaela: we're still making improvements
<Mikaela> ok
<ogra_> zyga, ubuntu-snappy-cli rather ;)
<sergiusens> ogra_, yeah, not sure why that is the default now
<ogra_> (that is what also was seeded recently)
<zyga> ogra_: no? it was renamed to snapd
<sergiusens> ogra_, mvo jdstrand btw, don't we want to rename the ubuntu-core-launcher package to snap-launcher?
<ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$ grep snappy desktop
<ogra_>  * (ubuntu-snappy-cli)
<ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$ grep snappy server
<ogra_>  * (ubuntu-snappy-cli)
<ogra_> ogra@anubis:~/Devel/seeds/ubuntu.xenial$
<ogra_> zyga, ^^^
<ogra_> (it depends on snapd though)
<ogra_> sergiusens, you have 8 days :P
<zyga> hmm, I wonder what's the point of both packages
<zyga> one still ships some directories
<ogra_> well, if we want top rename we need to do it now ... there is no way to change the seeds after release
<ogra_> (except by hacking meta packages directly and getting them out of sync with the world)
<ogra_> mvo, infinioty uploaded a new livecd-rootfs ... do you need any of the changes from the PPA version ? (they will be overridden for the next image build)
<dpm> so dholbach, popey, davidcalle, just read the omgubuntu article, captures snaps on the desktop pretty accurately and nicely :)
<popey> yeah, i sent him a tweet. he was worried it was all over the place and untidy, i reassured him that he'd "got" it
<popey> also, sa bdfl shared it, so it must be fine ã
<dpm> popey, indeed, I think it's really good
<dpm> dholbach, davidcalle, so as I said on the e-mail the /desktop page is published, but I've held off to publishing the subpages until the examples work
<dholbach> dpm, sounds good
<dholbach> dpm, yeah, it's a nice article
<dpm> dholbach, just going through your e-mails now
<niemeyer> zyga, jdstrand: Can we merge https://github.com/ubuntu-core/snappy/pull/802?
<niemeyer> The idea is getting interfaces in very quickly when necessary, or rejecting them.. we cannot leave these reviews hanging around
 * sergiusens migrates to coffee shop to re supply
<Gunther_> Another silly question (just because looking at kernel builds is sooo boring). Is it possible to extend an existing kernel.snap with a custom kernel module? In this case a device driver for a pci measument board.
<Gunther_> The sources for the driver are available but they are not part of the linux kernel
<dpm> dholbach, what's the new LP team you created again?
<jdstrand> niemeyer: I had not been looking at that very closely since my first review because interfaces code wasn't working yet and I didn't quite know how things were changing
<jdstrand> but I can take another look
<jdstrand> (ie, there was no way to test it)
<jdstrand> zyga: are interfaces supposed to be autoconnecting with snapd that is in xenial now?
<jdstrand> zyga: cause focuswriter from the desktop examples is not getting unity7 autoconnected. dholbach's doc on desktop examples also seems to have things that are not autoconnecting
<dholbach> dpm, ~snappers
<dpm> cool, thanks
<zyga> jdstrand: I haven't tried packaged snapd today.
<zyga> jdstrand: autoconnection is merged but I'm not sure when the release was cut
<zyga> jdstrand: we're aiming for one more release today
<zyga> jdstrand: with full control over connect/disconnect
<jdstrand> it says '19 hours' ago
 * zyga tries focuswriter
<dholbach> mvo said he'd do an upload soon
<jdstrand> I see
<dpm> JamesTait, on bug 1555569, is this now supposed to be fixed on the store side?
<ubottu> bug 1555569 in gnome-software (Ubuntu) "[snaps] Show human-readable names for store apps" [Medium,Triaged] https://launchpad.net/bugs/1555569
<jdstrand> zyga: if I do: 'snap interfaces', all I see is 'slot plug'. how do I connect things? (even if that is in the pending upload)
<zyga> jdstrand: snap connect
<zyga> jdstrand: snap disconnect
<zyga> jdstrand: and snap interfaces
<zyga> jdstrand: that's broken today (it has little effect)
<zyga> jdstrand: it doesn't setup security of anything yet
<jdstrand> zyga: so I (will) need to specify both the plug and the slot for each connection?
<zyga> jdstrand: see --help
<zyga> there are some shortcuts
<zyga> jdstrand: some may not fully work but some do
<jdstrand> ah, --help
<zyga> jdstrand: I'll polish that and get it to spec with the first SRU release
<jdstrand> I tried 'help' and '-h'
<JamesTait> dpm, I don't actually know what the current state of that is - the summary field from the manifest will be surfaced directly in the API, so it won't be used as title.
<JamesTait> dpm, nessita would probably be your best bet.
<dpm> thanks JamesTait
<jdstrand> zyga: is 'snap interfaces' supposed to list available interfaces or just connected interfaces?
<zyga> jdstrand: available and connected
<zyga> jdstrand: what do you see?
<zyga> jdstrand: you have to snap install ubuntu-core
<jdstrand> I literally see 'slot plug'
<zyga> jdstrand: (it is not auto installed yet)
<jdstrand> that is it
<zyga> jdstrand: UX could be improved there :-)
<jdstrand> $ sudo snap interfaces
<jdstrand> slot plug
<jdstrand> $
<jdstrand> zyga: I have ubuntu-core installed
<jdstrand> $ snap list
<jdstrand> Name         Version    Developer
<jdstrand> focuswriter  0.1        sideload
<jdstrand> ubuntu-core  16.04.0-24 canonicalubuntu-core  16.04.0-24 canonical
<zyga> jdstrand: can you restart snapd?
<jdstrand> whoops, that pasted twice
<jdstrand> sudo systemctl restart snapd?
<zyga> jdstrand: anyway; that part still needs love
<zyga> jdstrand: yep
<jdstrand> $ sudo snap interfaces
<jdstrand> slot plug
<mvo> zyga: there is a git tag for 1.9.1 if you want to double check what went in and what did not
<zyga> mvo: thanks, good idea
<mvo> dholbach: there will be one today, maybe even two, I ask in the standup
<zyga> jdstrand: ok, the version you have doesn't have the REST API wired to anything
<jdstrand> that would explain that
<zyga> jdstrand: interfaces/connect/disconnec all operate on a separate repo
 * zyga focuses on finishing this last essential bit
<jdstrand> zyga: is that repo going to be in mvo's upload?
<zyga> jdstrand: yes, that has landed since
<zyga> jdstrand: but connect/disconnect working hasn't
<zyga> (I'm still hacking on it)
 * jdstrand notes that he is being asked about this stuff a lot (not sure why they aren't asking here, but, there you go...)
<zyga> jdstrand: no worries :-)
<dholbach> mvo, go go go!
<jdstrand> zyga: what repo should I be looking at? I need to fix confinement for a few things
<nessita> dpm, hi!
<jdstrand> and testing the desktop snap examples, etc, etc
<nessita> dpm, about the title and summary, there is a thread that summaries all the details, let me get you the details
<dpm> nessita, I'm on that thread
<dpm> nessita, but I was wondering if the bug report needs updating
<dpm> as by the status of it it seems no one is working on it, which from the mailing list thread, you guys are
<nessita> dpm, have the link handy?
<dpm> nessita, sure -> https://launchpad.net/bugs/1555569
<ubottu> Launchpad bug 1555569 in gnome-software (Ubuntu) "[snaps] Show human-readable names for store apps" [Medium,Triaged]
<oly> hi, i have just been trying out snappy for apps everything went well until i uploaded a snap
<oly> package contains external symlinks: usr/lib/x86_64-linux-gnu/libmvec.so lint-snap-v2_external_symlinks
<nessita> dpm, basically summary is that we have completed the work on summary/description, and for title we are now using the snap name "moon-buggy", until snapcraft and snap grow capabilities for defining a Title section
<oly> any ideas what i can do with that error ? this is a very basic python app with one dependancy on python-gi
<zyga> jdstrand: hmm repo?
<jdstrand> zyga: I used your word
<zyga> jdstrand: you can just build snapd locally yourself
<jdstrand> 07:49 < zyga> jdstrand: interfaces/connect/disconnec all operate on a separate repo
<zyga> jdstrand: (interfaces.Repository is an internal code construct)
<oly> also can i try and run snaps locally in a VM
<zyga> jdstrand: use snapd from master from now
<zyga> jdstrand: that will show you what's connected
<jdstrand> zyga: ok, that's fine
<zyga> jdstrand: won't let you conenct yet
<zyga> jdstrand: you can always look at /var/lib/snapd/{apparmor,seccomp}/profiles to see what's "live"
<jdstrand> zyga: ah, master is what I was looking for. I thought you meant some other fork/branch
<jdstrand> zyga: well, I can manually edit /var/lib/snapd/{apparmor,seccomp}/profiles if I have to. I was trying to get a picture of how stuff works for myself, devs, etc
<jdstrand> I guess that will have to wait a bit longer
<vances> Q: What is the proper method to enable IP forwarding?  I did 'sudo mount -o remount,rw /' and edited '/etc/sysctl.conf' to set 'net.ipv4.ip_forward = 1'.
<zyga> vances: hmm interesting question, you can have a snap that just toggles the /proc filesystem directly
<zyga> vances: it would have to use one of the interfaces that allow that
<vances> Although the above method gets the kernel parameter set after a reboot it still doesn't seem to forward IP between interfaces.
<vances> Routing table looks fine.
<vances> iptables is all ACCEPT
<vances> Is there some additional security I need to deal with?
<Mikaela> minor bug: /etc/profile.d/apps-bin-path.sh comment talks about /snaps/bin when in reality it uses /snap/bin and /snaps doesn't even exist. Should I report this or see if it's already reported or is mentioning here enough?
<zyga> Mikaela: yes, please report it
<Mikaela> ok, doesn't seem to be reported at https://bugs.launchpad.net/ubuntu/+source/snapd
<zyga> vances: I'm sorry I cannot help you today
<davidcalle> dpm: thanks for updating the /desktop page, I've pushed the new /snappy one out as well today
<davidcalle> dpm: with great difficulty if you've seen my email
<ysionneau> sergiusens hi! Any idea about my udf issue? https://lists.ubuntu.com/archives/snappy-devel/2016-March/001668.html
<Mikaela> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1569892
<ubottu> Launchpad bug 1569892 in snapd (Ubuntu) "/etc/profile.d/apps-bin-path.sh comment talks about /snaps/bin (which doesn't exist) when in reality it uses /snap/bin" [Undecided,New]
<dpm> davidcalle, I've seen it, good work!
<jdstrand> dholbach: hi! B5 in your known issues should not be green as of this second.
<jdstrand> dholbach: that is what I was just discussing with zyga
<dpm> davidcalle, the db issue seems to be a bit of a concern. We might as well talk to upstream about it
<Mikaela> also nmap complained about `can not find a snappy os` until I installed `ubuntu-core`, not sure how I should report it, but I assume that is known issue?
<dholbach> jdstrand, is this a fix which landed somewhere?
<jdstrand> dholbach: they said autoconect landed in master
<jdstrand> dholbach: but it isn't in the archive yet
<dholbach> ok
<dholbach> I'll note that down then
<dholbach> zyga, which PR was this?
<zyga> dholbach: fix for what?
<ogra_> Mikaela, hmm, that is supposed to happen autonmatically
<ogra_> mvo, isnt it ? ^^^
<Mikaela> it seems it didn't for me for some reason
<dholbach> zyga, autoconnect
<zyga> dholbach: I don't really remember but it was merged in 1.9.1
<dholbach> oh...
<dholbach> jdstrand, just said that it's in master but not in the archive yet
<dholbach> or was it a fix for autoconnect?
<zyga> dholbach: no, that's not the same
<zyga> dholbach: that's connection visibility
<ogra_> Mikaela, well, "supposed" ... i'm not sure it is there yet
<zyga> ogra_: its not
<davidcalle> dpm: we have a few ideas of things to try before going upstream, I'd also like Robin's advice
<jdstrand> oh, sorry I misunderstood
<ogra_> technically your first "snap install" should install ubuntu-core ahead of anything else
<dholbach> zyga, jdstrand: can we add a line for this then, so we can track it separately?
<jdstrand> dholbach, zyga: I can say 100% certain autoconnect is not in 1.9.1
<dholbach> I'm losing track :)
<zyga> jdstrand: hmmmmmm
<zyga> jdstrand: and master?
<jdstrand> zyga: unity7 is suppoosed to autoconnect?
 * zyga cares less about 1.91
<jdstrand> let me uninstall and install
<zyga> jdstrand: yes
<dholbach> can we file a bug for what exactly is not working right now and track it there?
<zyga> dholbach: many things are not working
<dholbach> zyga, one example we look at together :)
<zyga> dholbach: filing abug before i'm done is not useful yet
<zyga> dholbach: wait until today evening
<dholbach> ok... it's just that jdstrand asked for the list of known issues to be updated and I couldn't quite figure out what exactly had changed
<jdstrand> dholbach: I think it is sufficient to say it is not fixed in 1.9.1.1
<dholbach> ok
<jdstrand> I don't want to distract zyga
<jdstrand> I just want the spreadsheet to reflect reality :)
<jdstrand> cd
<dholbach> wfm! :)
<jdstrand> cd meh
<jdstrand> heh
<jdstrand> that kinda summarizes how I feel (cd meh :)
 * dholbach hugs jdstrand 
 * jdstrand steps away for a moment
 * jdstrand hugs dholbach :)
<Mikaela> where can I find the bug reports for specific snaps? /snap/bin/tmux returns "Bad system call" and /snap/bin/nmap is unable to resolve localhost or ping 127.0.0.1 "Socket creation in sendConnectScanProbe: Permission denied (13)". I think they are known, but I would like to follow their statuses and cannot wait for snappy to become production ready (nmap and tmux there already report being newer versions than
<Mikaela> the Xenial repo ones)
<ogra_> Mikaela, yxou can contact the author https://uappexplorer.com/app/nmap.joetalbott (see the "support" tab)
<ogra_> (same goes for https://uappexplorer.com/app/tmux.shawn111 )
<beuno_> josepht, you have a fan!
<beuno> shawnwang, so do you
<ogra_> it is up to the snap creator to provide a bug url in the store data
<jdstrand> dholbach: fyi, apparmor 2.10.95-0ubuntu2 is out of proposed and should fix policy loads on reboot
<ogra_> if they didnt, direct mail is the best bet
<Mikaela> I see
<ogra_> https://uappexplorer.com/apps?sort=relevance&type=snappy is pretty helpful until the store has a proper web ui on its own
<Mikaela> I think it's probably enough that the authors were pinged on IRC :)
<josepht> Mikaela: I'll take a look at nmap.
<josepht> Mikaela: is that the armhf or amd64 version?
<shawnwang> Mikaela, thanks, let me check it
<Mikaela> amd64
 * ogra_ assumes the security system simply changed underneath them ...
<josepht> Mikaela: can you give me a paste of 'snappy list -v' please?
<ogra_> josepht, no more "snappy"
<ogra_> it is "snap" now
<Mikaela> josepht: snap says "error: unknown flag `v'"
<ogra_> (everything changed within the last week)
<Mikaela> ah, so that is why everyone talks about snappy :)
<ogra_> yeah :)
<josepht> ogra_: did that change not come as an update?
<ogra_> it did
<shawnwang> Mikaela, SNAP=/snaps/tmux.sideload/current /snaps/tmux.sideload/current/command-tmux.wrapper
<dholbach> jdstrand, excelltn
<dholbach> jdstrand, hum... not on archive.u.c yet?
<shawnwang> Mikaela, you can try this to avoid the launcher issue
<Mikaela> shawnwang: zsh: tiedostoa tai hakemistoa ei ole: /snaps/tmux.sideload/current/command-tmux.wrapper
<Mikaela> (file or directory does not exist)
<shawnwang> Mikaela, SNAP=/snaps/tmux.shawn111/current /snaps/tmux.shawn111/current/command-tmux.wrapper
<shawnwang> Mikaela, sorry, wrong path
<Mikaela>  shawnwang same error even when I correct /snaps to /snap
<jdstrand> dholbach: it is getting there: https://launchpad.net/ubuntu/+source/apparmor/2.10.95-0ubuntu2
<jdstrand> probably just need a publisher run
<sborovkov> Hello. I am on snappy on RPI 3. With latest kernel and os snap. Previously I could install snap with this command snappy install screenly-....snap to install from file. Now that does not work. can someone tell me how I can install snap from local file now?
<dholbach> jdstrand, cool
<Mikaela> shawnwang: I am on Ubuntu Classic (MATE) 16.04 amd64, in case that wasn't clear and you are giving me instructions for some other platform
<shawnwang> Mikaela, yes... I run it on Ubuntu Classic 16.04 amd64
<Mikaela> shawnwang: is it possible that you could be missing some updates?
<shawnwang> Mikaela, you still got "Bad system call"?
<ogra_> sborovkov, use "snap install"
<ogra_> the "snappy" command is gone
<sborovkov> ogra_: I did. When I pass filename, it says snap not found
<sborovkov> When I gave it full path it returned this error
<Mikaela> shawnwang: with your commands I get "no such file or directory", if I run /snap/bin/tmux directly I get the bad system call
<sborovkov> error: unable to find task with id "52c91e31-7113-26bb-1804-5980e7d74de1
<Mikaela> shawnwang: I don't have /snaps and in /snap I see directories: bin  nmap  tmux  ubuntu-core
<shawnwang> Mikaela, apt-cache policy ubuntu-snappy, maybe we use different version of ubuntu-snappy
<mvo> Mikaela: if you freshly installed snapd then the $PATH is not quite correct, needs a one time login. the bad systemscall is probably because the tmux does not quite have the right security profile yet
<mvo> Mikaela: dmesg also often has some useful information
<Mikaela> shawnwang: if you mean snapd 1.9.1.1
 * Mikaela reboots to see if that changes anything
<ogra_> shawnwang, ubuntu-snappy-cli ... you do not want ubuntu-snappy installed
<ogra_> (it was a mistake that it was seeded initially, remove it if you have it)
<shawnwang> ogra_, Mikaela, let me upgrade my ubuntu-snappy-cli
<Mikaela> After reboot /snap/bin/tmux and /snap/bin/nmap throw me `aa_change_onexec failed with -1. errmsg: No such file or directory`
<shawnwang> Mikaela, could you try SNAP=/snap/tmux/current /snap/tmux/current/command-tmux.wrapper
<Mikaela> shawnwang: works, except that it has decided that my tmux.conf has unknown option utf8 twice
<shawnwang> Mikaela, nice
<Mikaela> set -g utf8 & set-window-option -g utf8 on ==> I guess that if new tmux says that these options don't exist, I am just going to remove them from my tmux.conf
<shawnwang> Mikaela, https://github.com/shawn111/tmux.snap/blob/master/snapcraft.yaml
<shawnwang> Mikaela, here is my snapcraft.yaml
<Mikaela> shawnwang: I fear I don't understand that as I am not a developer
<niemeyer> jdstrand: About the bluez interface, understood.. I'm just concerned about introducing a streamlined way to introduce new interfaces
<niemeyer> jdstrand: This is a major blocker for anyone trying to use snappy, so we need to be agile handling such requests
<shawnwang> Mikaela, maybe I missing some config
<niemeyer> jdstrand: It's better to introduce something basic and the polish it, than to block for an undetermined amount of time
<shawnwang> ogra_, is it a right way to call snap command? like SNAP=/snap/tmux/current /snap/tmux/current/command-tmux.wrapper
<shawnwang> ogra_, or, should I use /snap/bin/tmux directly?
<zyga> dholbach: what's that snap I should try to instal
<zyga> dholbach: I have a branch locally, I'd like to test any desktop snaps you can give me
<dholbach> zyga, I don't know which problem you solved and which might be working now... jdstrand?
<ogra_> shawnwang, no idea, i never run them directly since that breaks :)
<zyga> dholbach: anything you have
<ogra_> you need the env the ubuntu-core-launcher sets up
<dholbach> zyga, jstrand: focuswriter from lp:snappy-desktop-examples?
<shawnwang> ogra_, yep, like mvo mention I might miss security profile
<zyga> dholbach: k, I'll try
<zyga> FYI: I fixed a few bugs that would be breaking stuff earlier
<jdstrand> niemeyer: I totally agree and we'll get there
<jdstrand> zyga: fyi, someone mentioned you recommended modifying files to not use the launcher to work around lack of unconfined and/or developer mode. I suggest instead modifying the apparmor profile to be in complain mode and the seccomp profile.
<josepht> I see the same issue as sborovkov when sideloading a snap or trying to install a snap from the store (ubuntu-core in this case)
<ogra_> joyeah, seems sideloading is gone atm ...
<zyga> jdstrand: snappy will refresh those profiles
<ogra_> josepht, ^^^
<zyga> jdstrand: won't refresh the wrappers
<zyga> ogra_: sideloading is not gone, should work okay
<ogra_> josepht, there is supposed to be a --developer-mode option to the install command ...
<ogra_> but thats not there yet
<ogra_> zyga, how
<zyga> ogra_: yep, it's not there yet :/
<zyga> (but just UX issue)
<ogra_> :)
<zyga> ogra_: snap instal ./path/to/some/snap.snap
<josepht> ogra_: same happens with a store snap
<ogra_> oh
<ogra_> that sounds rather like a bug :)
 * zyga has a still-crazy branch that is relatively stable for controling interfaces
<zyga> dholbach: none of the snaps work though
<zyga> dholbach: only cap-test
<zyga> dholbach: I tried scummvm with home plug connected
<zyga> dholbach: focuswriter starts but nothing shows up
<zyga> (it doesn't crash, just has no windows)
<dholbach> :-/
<zyga> although...
<zyga> kwi 13 17:10:42 zyga-thinkpad-w510 audit[11161]: SECCOMP auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=11161 comm="focuswriter" exe="/snap/focuswriter/0/usr/bin/focuswriter" sig=31 arch=c000003e syscall=55 compat=0 ip=0x7f0edad24e2a code=0x0
<zyga> jdstrand: ^^ is that a seccomp denial?
<ogra_> yes
<zyga> dholbach: ^^ fix that and maybe it will run
<zyga> that looks like getsockopt
<zyga> missing network plug?
<dholbach> zyga, how?
<zyga> dholbach: identify why that syscall is not allowed, put it in an interface
 * zyga tries with network
<jdstrand> zyga: yes
<jdstrand> on amd64:
<jdstrand> $ scmp_sys_resolver 55
<jdstrand> getsockopt
<jdstrand> (you need to run scmp_sys_resolver on the target arch so if not amd64, run it on the device)
<elopio> ogra_: the job that takes the os snap from cdimage is ready, triggered when the snap changes. But there are a couple of problems. The upload fails a lot because of the store, so I have to retry it like 4 times. And once it's uploaded it needs a manual review to go into the edge channel.
<jdstrand> zyga: mvo mentioned getsockopt is needed for nvidia systems. see the thread I just responded to
<zyga> ah
<zyga> I have an nvidia GPU here
<jdstrand> there you go
<elopio> everything we could automate is already automated. So I'll be dealing daily with the manual parts for now.
<jdstrand> you may have some other issues
<jdstrand> (again, see thread)
<ysionneau> hmm zyga here I get Apr 13 15:21:21 localhost kernel: [ 6322.540900] audit: type=1326 audit(1460560881.937:63): auid=1000 uid=1000 gid=1000 ses=1 pid=2081 comm="ld-linux-armhf." exe="/snaps/libshdata.sideload/LWKbJCCgHVhJ/lib/ld-linux-armhf.so.3" sig=31 arch=40000028 syscall=289 compat=0 ip=0x76ef44d6 code=0x0
<ysionneau> is it seccomp denial?
<ysionneau> (I'm on RPI2)
<ysionneau> it's written audit...
<zyga> maybe
<ysionneau> and in the user space console logs I get 'bad syscall'
<ysionneau> 289 is "send"
<ysionneau> although, I've put syscalls: [send] + network-client/network-listener/network-service caps
<zyga> ysionneau: that's not supported
<zyga> ysionneau: that's old-security
<zyga> ysionneau: you need plugs: [network]
<zyga> ysionneau: or plugs: [network, network-bind]
<ysionneau> oh, old-security isn't supported anymore?
<ysionneau> I can still see them in the snapcraft/examples
<pmp> hi, I'm using snappy on raspi2
<pmp> following a snappy update yesterday it refused to boot on the newly installed kernel (4.4.0xxx vs 4.3.0)
<pmp> this was a nice way to see snappy working well, when a kernel update has failed
<pmp> is this expected behaviour
<pmp> I mean the new kernel not working well?
<pmp> It stops right after "uncompressing kernel"
<ogra_> pmp, is that a 16.04 image ?
<pmp> yes
<ogra_> (it needs an updated gadget snap too, could be that your old snappy is not capable of updating that yet)
<ogra_> so either roll back, or re-flash
<ssweeny> zyga, hate to be a pest but is there an ETA for review of my bluez PR?
<ogra_> snappy uis still changeing a lot ... especially the images
<zyga> ssweeny: today
<ssweeny> zyga, awesome :)
<zyga> ssweeny: sorry, fighting one last fire
<pmp> ogra_: the roll-back is done automatically, but after each boot it tries to update
<ssweeny> zyga, no worries. just getting queries from my team since we finish a sprint today
<pmp> ogra_: my original image dates from I'd say 4 weeks ago, is that too old?
<ogra_> yeah, snappy was nearly completely re-done (once again) and the big changes only landed last week or are still in flux
<pmp> ogra_: iirc I grabbed the udf from ~mvo somewhere, is that still the right place to fetch the image for rpi2?
<ogra_> i'd actually build my own, i dont think mvo  had the time to update them
<ogra_> but yes, you need the latest u-d-f from his dir
<pmp> ogra_: yes that scary part: downloading a 11MB binary from somewhere and execute it
 * pmp is fearless
<pmp> ogra_: thx for the hint
<ogra_> mvo is a totally trustworthy person though ... (you will notice he only takes so much from your bank account after you ran his binaries)
<ogra_> ;)
<zyga> zyga@zyga-thinkpad-w510:~/work/src/github.com/ubuntu-core/snappy/cmd/snap$ focuswriter.run
<zyga> Qt: Session management error: None of the authentication protocols specified are supported
<zyga> dholbach: ^ focuswriter
<zyga> dholbach: closer but no idea what's next
<zyga> kwi 13 17:59:22 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1460563162.514:194): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=25780 comm="focuswriter" exe="/snap/focuswriter/0/usr/bin/focuswriter" sig=31 arch=c000003e syscall=49 compat=0 ip=0x7f983a472d37 code=0x0
<ogra_> moar syscalls .... yay
<zyga> sys_shmctl
<davidcalle> mvo: ogra_ zyga, is snappy-remote still a thing?
<zyga> davidcalle: nope
<ogra_> nah
<davidcalle> Thanks :)
<davidcalle> kyrofa_: do you know when we can expect an updated https://github.com/ubuntu-core/snapcraft/blob/master/docs/get-started.md ? At first glance, snappy-tools, snappy try and snappy-remote need to go.
<dholbach> zyga, thanks for looking into this
<dholbach> I need to run now - have a good one everyone!
<kyrofa> davidcalle, we have a bug for it-- we can crank it out pretty quickly, though aren't people using developer.ubuntu.com?
<davidcalle> kyrofa: we import the doc from you guys :) I've just removed them from there, though, with the announcement.
<davidcalle> https://developer.ubuntu.com/en/iot/build-apps/get-started
<kyrofa> davidcalle, oh! I didn't know that import was up and running
<davidcalle> kyrofa: it's not, we run a manual thing :)
<kyrofa> davidcalle, ah :) . Yeah we'll move that one closer to the top of the pile, thanks for the reminder
<davidcalle> kyrofa: no worries, we'll sync with you next time we manually import or land the actual importer.
<kyrofa> davidcalle, please do, I'm looking forward to that
<netphreak> Hi, guys!
<netphreak> I'm having trouble getting a homebuilt snap package start after install.
<netphreak> http://paste.ubuntu.com/15818026/
<kyrofa> netphreak, is this on the desktop?
<ogra_> netphreak, snap install ubuntu-core
<ogra_> (probably sudo ;))
<netphreak> yes, i'm on desktop
<elopio> noise][: any news about my 401? Should I report a bug somewhere maybe?
<netphreak> thx solved the issue ;)
<netphreak> One step closer - i now get the following error:
<netphreak> http://paste.ubuntu.com/15818225/
<netphreak> my snap craft looks the following:
<netphreak> http://paste.ubuntu.com/15818261/
<michaelrose> so question since snappy packages are limited as far as access to the filesystem how do they manage to open your files
<michaelrose> ex a pdf reader, suppose I could open a file via the terminal via xdg-open or via direct invocation of the program, by clicking on the pdf in my file manager, by selecting the book in calibre
<ogra_> michaelrose: most likely similar to what happens on the phone today ... via a system service
<ogra_> (called the content-hub on the phone)
<ogra_> but thats not yet existing
<ogra_> (for desktop)
<swami_> need help on downloading kernel source from ubuntu.com and its kicking me out each time. I am behind the firewall; but has the set proxy correctly and able to download kernel.org's or some others without issue
<swami_> anyone can help?
<swami_> for eg: http://kernel.ubuntu.com/git/ppisati/ubuntu-vivid.git/log/?h=snappy_v3.18, how to download this using git clone? any othe settings?
<zyga> swami_: I don't think there are any; perhaps download it without the proxy in the way
<swami_> dont think proxy is an issue. because I am able to download others from external website. Am I missing something?
<josepht> swami_: git clone git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git
<zyga> swami_: works for me, try without a proxy
<swami_> hmm, thanks zyga.
<swami_> I tried this josepht
<swami_> have tried git:// http:// and https://
<swami_> is there any git/ssh settings that I should consider about?
<zyga> swami_: it looks like your proxy is just broken
<zyga> swami_: if it is any consent, I have never seen a corpo proxy that didn't break everything apart from websites
<zyga> s/consent/comfort/ (I guess)
<swami_> when I tried the above command, it shows me this:
<swami_>  git clone git://kernel.ubuntu.com/ppisati/ubuntu-vivid.git Cloning into 'ubuntu-vivid'... fatal: unable to connect to kernel.ubuntu.com: kernel.ubuntu.com[0: 91.189.94.216]: errno=Connection timed out
<swami_> got http, it shows: Cloning into 'ubuntu-vivid'... fatal: repository 'http://kernel.ubuntu.com/ppisati/ubuntu-vivid.git/' not found
<swami_> *for
<josepht> swami_: only git:// and https:// work for me.  I imagine http:// isn't being served.
<swami_> for git, connection timed out. for https, below. :(
<swami_> Cloning into 'ubuntu-vivid'... fatal: unable to access 'https://kernel.ubuntu.com/ppisati/ubuntu-vivid.git/': gnutls_handshake() failed: The TLS connection was non-properly terminated.
<jdstrand> beuno: hey, could someone sync review tools r627? this removes old-security, fixes a couple bugs and makes sdoc stuff work ok again
<JanC> sounds like a broken proxy indeed...
<swami_> thanks. how to verify that proxy is working? some other ways to check
<michaelrose> so regarding the content hub, A) what does that mean for non ubuntu machines B) does that mean that the content hub replaces xdg-open et al C) does that mean all of the above ways to open the pdf still work seamlessly or do they have to be rewritten to take it into account
<beuno> jdstrand, sure
<michaelrose> reading this https://developer.ubuntu.com/en/phone/platform/guides/content-hub-guide/ sort of looks like I couldn't just open a file from the filesystem with an arbitrary app seems like I would have to open the owning app, say the gallery app for pictures
<michaelrose> and pic an app to share it with kind of android style
<michaelrose> although the receiving app can use say the gallery app is a file picker
<michaelrose> mostly what I'm wondering is how easy it will be to rip apart a snappy package and use it on a non ubuntu system that doesn't have content hub or any of that junk
#snappy 2016-04-14
<General-Beck> Who can tell what kind of error? http://paste.ubuntu.com/15822298/
<kyrofa> General-Beck, looks like that error is specific to the service you're trying to install
<kyrofa> General-Beck, and it's restarted several times fast enough that systemd just stopped trying
<General-Beck> the fact that the restart is clear, but the error indicated `ubuntu-core-launcher ERROR: Error upgrading parity data: CannotLockVersionFile`
<General-Beck> code https://github.com/ethcore/parity-snappy/tree/master/snap
<General-Beck> I think I know the reason
<test> ping elopio
<Guest70089> ping elopio
<Guest70089> ping elopio
<netphreak> hi, guys!
<ypwong> installed snapd and ubuntu-clock-app-mvo, but when launching ubuntu-clock-app-mvo.clock it complains "can not find a snappy os"
<ypwong> What do I miss?
<Mikaela> ypwong: some snap which started with ubuntu, which name I don't remember, something about core or base
<ypwong> Mikaela, you're right, install ubuntu-core snap and now it can be run
<ypwong> but now got "QXcbConnection: Could not connect to display :0"
<zyga> good morning
<zyga> mvo: telegram seems to be down
<zyga> mvo: I've posted a trivial branch https://github.com/ubuntu-core/snappy/pull/936
<zyga> mvo: and I found a bug (maybe) when we install the 1st snap and automatically install ubuntu-core with it, we don't seem to have a task for setup-snap-security
<zyga> mvo: so iface manager doesn't ever see ubuntu-core
<zyga> mvo: so we don't add implicit slots and get all the auto-connection magic to happen
<mvo> zyga: interessting, the code should do exactly the same as for the first download, hmmm
<zyga> mvo: try it, wipe your state, then install hello-world
<zyga> mvo: and list interfaces
<zyga> mvo: (on master)
<zyga> mvo: (maybe merge the branch above so that it's not painful if snapd doesn't start
<zyga> mvo: then restart snapd and it will see ubuntu-core interfaces (I do a scan on startup)
<mvo> zyga: I'm not disputing that you see this :) I'm just puzzled why it happens
 * zyga would love _some_ logging to be there for tasks 
<mvo> zyga: yeah, I think we need a verbose mode in the taskrunner for exactly this, at least see what is in the queue and running etc
<zyga> mvo: yeah, I think we could just log all runner activity in general, by default, it's not like it's going to hurt
<zyga> mvo: and now it's walking blind all the time, I have a patch that sprinkles logging everywhere for development but it's silly to need such a thinig and not have it merged
<zyga> mvo: fyi, telegram sends every other message I wrote; I'll switch to irc for now
<zyga> (the remaining messages are marked as queued)
<davidcalle> Morning o/
<davidcalle> zyga: Telegram has finally realized this group was using half of its bandwith ;)
<zyga> davidcalle: and 90% of the cat photo traffic ;)
<davidcalle> zyga, quick question about something I'm not sure to fully understand with Snappy. Why do we have "ack" and interfaces connectivity commands since snaps should be doing this on their own at install time? Is it for testing?
<zyga> davidcalle: snappy auto-connects certain interfaces that are deemed safe or important, e.g. network, network-bind, x11 and unity7
<zyga> davidcalle: for other interfaces we will add auto-connection when assertions are in place
<zyga> davidcalle: because those interfaces give a lot of power
<zyga> davidcalle: and lastly users still can disconnect anything they want
<davidcalle> I see
<zyga> davidcalle: later on with hardware interfaces you will need to pick stuff, e.g. which GPIO pin goes to "mr blinky" snap
<zyga> davidcalle: this is why plugs and slots have interface type -- there will be multiple interoperable ways to connect snaps to hardware
<davidcalle> Yeah, makes sense then
<zyga> davidcalle: e.g. a rasbperry pi 2 camera slot could be connected to only one snap at a time and you can pick which one gets it
<fgimenez> good morning
<zyga> fgimenez: morning :)
<fgimenez> hey zyga :)
<fgimenez> hi @mvogt :) it seems that today udf doesn't accept origins/developers for generating images, ie each snap flag without the '.canonical' at the end, is that going to stay, should we change integration tests and snappy-cloud-image?
<fgimenez> mvo, ^
<mvo> fgimenez: I think that is a store change that triggered this behavior. you need to always use the short name now, right? only "ubuntu-core" works but not "ubuntu-core.canonical". is that what you see?
<fgimenez> mvo, yes, "sudo ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pc-linux --gadget canonical-pc --developer-mode  -o /tmp/tmp.HBTcxb4rHN/udf.raw" works
<mvo> fgimenez: ok, please modify it for now so that it uses the short names. at some later point we will support long names again but thats not a concern right now (this will happen once publisher != developer which is not the case right now)
<fgimenez> mvo, ok thx, on it
<morphis_> ogra_`: do we alreay support the raspberry pi 3 with snappy today?
<zyga> fgimenez: hmm, I should update ubuntu-image then
<mvo> yay, tests are green again
<mvo> once https://github.com/ubuntu-core/snappy/pull/938 gets merged
<zyga> mvo: merged
<zyga> mvo: can you run "go test" in daemon/ for me it seems to hang...
<zyga> ah, no it's just slow
<zyga> sorry :)
<zyga> mvo: latest u-d-f fails to find OS snap
<zyga> ah, ignore me
<Gunther_> Good morning
<Gunther_> If a snapcraft.yaml contains multiple 'parts', is it possible to refer from 'part2' to the build or install directories of 'part1'?
<didrocks> Gunther_: hey! you can if set you parts2 to be "after: parts1" (this is withing the stenza of parts2) and set for instance with the copy plugin: files: file1: ../../parts1/build for instance
<Gunther_> didrocks: thanks I will try that
<didrocks> yw! keep us posted :)
<Gunther_> didrocks: My idea is to use this to separate a kernel build from the build of a customized device driver. The device driver (part2) refering to the kernel source tree (part1)
<didrocks> Gunther_: yeah, that should be doable this way then.
 * zyga has connect + security working, fights through mock layers to let daemon tests go
<zyga> mvo: I have a simple daemon branch for review, do you have a moment?
<zyga> Chipaca: ^ ditto
<zyga> https://github.com/ubuntu-core/snappy/pull/942
<zyga> mvo: https://github.com/ubuntu-core/snappy/pull/943/files
<morphis__> ogra_: ping
<zyga> morphis__: once you know about pi3 support please ping me, I'd like to support it in ubuntu-image
<morphis__> zyga: will do :-)
<zyga> mvo: around?
<zyga> mvo: (I don't know if you see my pings on telegram)
<ogra_> zyga, morphis, there is still a bug  that makes the serial console on the pi2 unusable with the pi3 enabled uboot ... not sure we'll get that fixed before 16.04 release (but luckily nothing in the gadget comes from the archive so we will surely get it fixed by snappy release) http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
<morphis> ogra_: sounds great!
<ogra_> long term plan is to have the 32bit image work on both ... and eventually have a 64bit img additionally
<morphis> ogra_: one other thing, is http://cdimage.ubuntu.com/ubuntu-snappy/daily/current/ supposed to be the new place for daily snappy images?
<ogra_> morphis, well, the store is ... but yes, these snaps go to the store
<morphis> ogra_: for snaps, yes, the store is the place, but talking about .img files I can flash
<ogra_> ah
<ogra_> no, thats a 15-04 dir ...
<ogra_> sorry missed that you had the wrong path in there
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> thats the path for the roilling dailies
<ogra_> we will release underneath http://cdimage.ubuntu.com/ubuntu-snappy/ though ... in a 16.04 subdir
<ogra_> (with img files)
<morphis> ogra_:  ok, so what do I take from daily-preinstalled to flash? xenial-preinstalled-core-amd64.tar.gz   for example?
<ogra_> sudo ../ubuntu-device-flash core --developer-mode --channel edge --os xenial-preinstalled-core-amd64.os.snap  --kernel  xenial-preinstalled-core-amd64.kernel.snap --gadget canonical-pc.canonical -o test.img
<ogra_> that creates test.img which you can flash
<ogra_> you need the u-d-f from http://people.canonical.com/~mvo/all-snaps/ for that
<morphis> ogra_: so u-d-f with support for that wasn't yet released?
<ogra_> oh, there is a "rolling" missing in the command
<ogra_> sudo ../ubuntu-device-flash core rolling --channel edge --os xenial-preinstalled-core-amd64.os.snap  --kernel  xenial-preinstalled-core-amd64.kernel.snap --gadget canonical-pc.canonical -o test.img
<ogra_> sadly not ... mvo is planning an SRU i think
<morphis> hm
<ogra_> (effectively there is a new tool in the works but that wont make the release most likely)
<morphis> ogra_: tool to replace u-d-f-?
<ogra_> kernal and gadget snaps are still supposed to be re-designed in the next weeks as well, so the code will still change in u-d-f
<ogra_> yes, a tool to replace u-d-f
<morphis> interesting
<morphis> ogra_: however, will we end up with actual .img files for the release?
<ogra_> perhaps :)
<morphis> ok
<ogra_> (it doesnt make much sense to have imgs when the gadget and kernel snaps are comepletely redesigned ... perhaps in an incompatible way so that you need to re-flash)
<morphis> I see
<daker> ogra_: hi, anyidea how can i compile an armhf snap ?
<ogra_> daker, do you have an armhf board ?
<daker> yes rpi2 & bbb
<ogra_> with a snappy install ?
<daker> not yet
<daker> does snappy/snapcraft comes with the ubuntu-core img ?
<daker> snapcraft 1.x i mean :D otherwise i have to rewrite the snapcraf yaml again
<ogra_> oh
<ogra_> 1.x
 * ogra_ hasnt used that in ages :P
<ogra_> thats a bit tricky ... you need to compile natively ... in 16.04 we have the classic shell on the snappy image for that
<ogra_> (you can then just apt-get what you need and build your stuff)
<ogra_> i suspect in 15.04 you need to grab an ubuntu-core tarball (not the snappy one) and do it in a chroot in there
<ogra_> from http://cdimage.ubuntu.com/ubuntu-core/daily/current/
<Gunther_> hmm is someone interested in reviewing a kmodule.py plugin for snapcraft? http://paste.ubuntu.com/15826883/
<zyga> Gunther_: send it to sergiusens_ on github
<Gunther_> ok
<Gunther_> zyga: as pull request?
<pedronis> niemeyer: telegram is not quite working for european people atm, they said it was fixed but seems back to not working again
<niemeyer> pedronis: Ah, I thought everybody was taking a good rest :-)
<niemeyer> zyga: Some feedback on #943
<niemeyer> zyga: 942 is in
<niemeyer> zyga: 943 has a few comments
<niemeyer> mvo: 941 is missing update-pot it seems
<mvo> niemeyer: let me fix that
<mvo> niemeyer: thank you
<Gunther_> is there an easy way to look into a .snap package?
<ogra_> Gunther_, mount it ... it is a squashfs file ;)
<Gunther_> too much work :)
<ogra_> haha
<ogra_> you can also use unsquashfs indeed
<ogra_> i think "unsquashfs -l" lists the content without unsquashing
<Gunther_> mounting worked great :)
<zyga> re
<zyga> niemeyer: hey!
<zyga> niemeyer: looking, thanks
<zyga> niemeyer: refreshed https://github.com/ubuntu-core/snappy/pull/943
<zyga> niemeyer: have a look please, we can get connect/disconnect security working after that :)
<niemeyer> Looking
 * zyga worries that communication breaking down today is the most unfortunate thing that could have occured; is telegram working for anyone?
<niemeyer> zyga: Yeah, most people are in I think
<zyga> niemeyer: I pinged mvo, pedronis and Chipaca without effect
<zyga> maybe just not looking at irc notificaction (desktop integration)
<niemeyer> zyga: I see their messages, but not your pings
<zyga> niemeyer: I also tried in snappy-internal
<zyga> niemeyer: as long as I can talk to you we're good :)
<niemeyer> zyga: I don't see your pings in snappy-internal either
<zyga> hmmm
 * zyga restarts irc
 * zyga loves technology
<niemeyer> zyga: I think it'd be trivial to have SetupCallback  recording the calls instead of the fake public value
<niemeyer> zyga: But it's okay to do that later
<zyga> irc should have a "no emergency calls" disclaimer
<zyga> niemeyer: yes, I agree, I'll try to do that today after all the feature work is in place
<niemeyer> zyga: It's okay, let's focus on the release.. this is an easy TODO for next week after things have calmed down
<niemeyer> zyga: It's in
<zyga> perfect, now for the meat
<zyga> niemeyer: https://github.com/ubuntu-core/snappy/pull/948
<zyga> niemeyer: that's getting us 90% there
<zyga> niemeyer: I'll work on setup-snap-security to be fully operational
<zyga> niemeyer: and on remove-snap-security
<zyga> niemeyer: along with some tests for both
<zyga> niemeyer: _after_ that I'd like to get developer mode working
<zyga> niemeyer: and switch connect/disconnect to async REST
<zyga> niemeyer: and lastly kill bits needed only for old security (some branches for that are already up, I have more but I didn't finish it)
<niemeyer> zyga: I can do the async rest thing immediately
<zyga> niemeyer: please do, thanks!
<niemeyer> zyga: Will look at the branch first
<zyga> niemeyer: does the plan above look good, anything to shuffle or change?
<niemeyer> zyga: What's still pending about setup-snap-security?
<zyga> niemeyer: we still disconnect and don't reconnect
<niemeyer> zyga: In which sense?
<zyga> niemeyer: there's a TODO in the code that needs to be changed; to support upgrades we disconnect and remove the snap from the repo; then add it back (the new one) and autoconnect but we don't restore connection that were made explicitly
<zyga> niemeyer: and perhaps auto-connect should not reconenct something that was disconnected by the user
<zyga> niemeyer: that's all for setup (plus tests)
<zyga> niemeyer: for remove AFAIR we don't remove the connection from the state (+ tests)
<zyga> niemeyer: I feel I can do those very quickly with the testing helpers I now have
<niemeyer> zyga: Sounds good.. quite a few items there.. best to do those piecemeal
<zyga> yep, that's my plan!
<niemeyer> zyga: For autoconnect,
<niemeyer> zyga: Indeed we shouldn't reconnect.. it's easy to do that by, before disconnecting the former snap, obtaining a list of all the interface which are automatic but not established
<niemeyer> zyga: Then, use that as a blacklist when reconnecting
<zyga> niemeyer: mmm, yep, that sounds doable
<niemeyer> zyga: Also an easy fix after it's all working
<zyga> yep
<zyga> niemeyer: I have setup-snap-security, how about we land https://github.com/ubuntu-core/snappy/pull/948
<kyrofa> Good morning
<zyga> kyrofa: hey
<kyrofa> Hey zyga :) . How are things going?
<zyga> kyrofa: irc/telegram is flaky today
<zyga> kyrofa: almost all interface features are implemented, just last few bits and I'm happy
<kyrofa> zyga, excellent!
<kyrofa> zyga, we're releasing snapcraft with that interface change pretty quick (if not already done)
<zyga> kyrofa: sounds like a good day :)
<kyrofa> zyga, indeed!
<sergiusens_> kyrofa, zyga it just passed adt, so it is making its way out of proposed
<kyrofa> sergiusens_, morning! Thanks for the update :)
<zyga> sergiusens: great news
<zyga> niemeyer, mvo: what is the release plan for today?
<sergiusens> kyrofa yeah, and I just built shout irc and running it in the snappy dimmension :-)
<sergiusens> chatting from a browser now :-)
<kyrofa> sergiusens, nice-- so the network interfaces are working now?
<mvo> zyga: definitely
<mvo> zyga: a release
<mvo> zyga: later today, evening most likely. anything I should wait for?
<zyga> mvo: I should be done with essentials in < 1 hour (all implemented, pending review)
<zyga> mvo: I'll do more apparmor work and I'll try to get developer mode in
<ogra_> sergiusens, hah, now install my ircproxy snap and chain them :P (wont work, fully relies on snappy config :/ )
<zyga> niemeyer: all done on https://github.com/ubuntu-core/snappy/pull/948
<mvo> zyga: sounds great
<sergiusens> kyrofa seems so
<sergiusens> ogra_ I want to install shout on some server somewhere eventually (but I need to solve https without snappy config)
<zyga> with developer mode we could at least install some desktop snaps in devel mode and see what's missing to get them fully confined
<ogra_> sergiusens, yeah, it is rather awful to lose snappy config :/ ... only one of my packages doesnt use it
<kyrofa> ogra_, yeah when I saw that email I immediately thought of you
 * ogra_ hopes it will be back soon
<mvo> zyga: yes
<sergiusens> kyrofa so now more cleanups ahead
<kyrofa> sergiusens, the example tests still fail-- have you tried shout on snappy instead of snappy dimension recently?
<sergiusens> kyrofa we need a new `ubuntu-core` for that
<kyrofa> Ah, okay gotcha
<zyga> niemeyer: https://github.com/ubuntu-core/snappy/pull/948/commits/bf0ce588cace658bd20a09850a453e2ef973911e
<zyga> niemeyer: https://github.com/ubuntu-core/snappy/pull/948/commits/ec305bef724e84519150160265ecdcbe3e3240ab
<zyga> niemeyer: both done  (perhaps stale browser diff?)
<zyga> niemeyer: ^^ I don't know if you saw those two commits above
<zyga> niemeyer: is that what you meant earlier or is something missing still?
<niemeyer> zyga: Did you get my comments in Telegram?
<niemeyer> zyga: Or are you still having connectivity issues/
<niemeyer> ?
<zyga> niemeyer: no
<zyga> niemeyer: apparently so
<niemeyer> Gustavo Niemeyer, [14.04.16 09:56]
<niemeyer> @zyga_pl We don't have any logic at all that does per snap backends, I believe, and it doesn't even sound like a great idea
<niemeyer> Gustavo Niemeyer, [14.04.16 09:56]
<niemeyer> @zyga_pl The boilerplate being added everywhere as a side effect is unnecessary
<niemeyer> Gustavo Niemeyer, [14.04.16 09:57]
<nothal> niemeyer: No such command!
<nothal> niemeyer: No such command!
<niemeyer> @zyga_pl So securityBackends can actually be simply []interfaces.SecurityBackend, no function calls
<nothal> niemeyer: No such command!
<niemeyer> nothal: shh!
<ogra_> poor bot :)
<zyga> niemeyer: ahh
<zyga> niemeyer: you are right, this will be killed with old-security
<niemeyer> zyga: The comments described that
<niemeyer> zyga: Even with code :)
<zyga> niemeyer: if you want I can do it right now
<niemeyer> zyga: Yeah, I think it'd be useful
<niemeyer> zyga: As I see it growing legs elsewhere
<zyga> niemeyer: it is one of the places that still had connection to old-security having special needs
<zyga> one moment
<daker> ogra_: thanks i will test that
<zyga> niemeyer: pushed
<sergiusens> zyga jdstrand hey, would it be sensible to allow something like $EDITOR?
<zyga> sergiusens: what do you mean?
<zyga> sergiusens: for a snap to run $EDITOR?
<sergiusens> zyga shout has this facility where it you can do `shout config` which just runs `$EDITOR <path-to-config>` which is sort of nice given snap directories
<zyga> hmmm
<jdstrand> that isn't going to work great
<zyga> sergiusens: we cannot expand $EDITOR that the user has
<zyga> sergiusens: we'd have to whitellist a range of editors but that would never work reliably
<jdstrand> cause EDITORs write all over the place
 * jdstrand agress with zyga 
<sergiusens> jdstrand right, so my solution is to provide a minimal editor in my snap and set $EDITOR up to use that, right?
<jdstrand> that is why we don't allow it now
<zyga> sergiusens: it could be done with an editor interface
<jdstrand> sergiusens: sure, you could do that
<zyga> sergiusens: not sure if the UX for that would be good though
<jdstrand> sergiusens: you then can configure the editor to point at whatever files are in your snap/writable by your snap
<sergiusens> zyga and editor interface (or a vim.tiny or nano one) which only allows read/write to SNAP_<dirs> if possible would be great
<jdstrand> I did something like that for a personal snap of mine
<jdstrand> I shipped vim and setup all the various .vimrc, etc to look in the right places
<zyga> sergiusens: then the OS snap would create a range of slots of type 'editor' and you could pick the one that gets to run but without hooks that'd still suck
<jdstrand> well
<jdstrand> that interface would require support from the os snap
<sergiusens> jdstrand ok, sounds good, I'm going to see if I can find something more light weight and less dep heavy
<sergiusens> yeah, longer term, it would be nice to think of something for this, I don't mind today
<jdstrand> ie, if nano and vim.tiny, then we'd have to ship nano and vim.tiny in the os that worked under the confinement provided by the interface
<jdstrand> I guess the snap could ship its own nano or vim.tiny
<jdstrand> but then what good is the interface. just set your editor to work in your writable areas
<zyga> mvo: around?
<zyga> I need a 2nd +1 on https://github.com/ubuntu-core/snappy/pull/948
<sborovkov> Hi. How do I debug application in the snap? Do I have to bundle gdb-server with snap, and run it instead of application? Or is there some simpler way?
<jdstrand> dholbach: I'm making some updates to https://docs.google.com/spreadsheets/d/1xBHxFwBNk3HjomnxzOjrohy-E3eyjAGX8ZLvXPqOG84/edit#gid=0
<dholbach> thanks a lot jdstrand!
<jdstrand> dholbach: I see a lot of old-security in the snap-playpen, so fixing that as I come across it
<zyga> jdstrand: I have 90% of security side of interfaces implemented; should be released today
<dholbach> jdstrand, thanks... most of the contents of the branch is old... it's from last week!
<zyga> jdstrand: I'll try to get developer mode as well
<dholbach> dpm, ^
<zyga> jdstrand: can you quickly review https://github.com/ubuntu-core/snappy/pull/933
<zyga> jdstrand: (trivial)
<dpm> awesome, thanks jdstrand!
<zyga> jdstrand: without old-security I'd like to simplify that futher still but this needs to land first
<halfline> hey i have some questions about snappy if anyone is game !  1) it's like a container system for applications right?  2) is the underlying technology different for server apps and desktop apps, or is it all the same under the hood?
<ysionneau> sergiusens: hi! sorry to bother you with this again but any idea on my ubuntu-device-flash issue I posted on the mailing list?
<zyga> halfline: 2) same thing 1) not exactly (we don't use most namespaces AFAIR)
<halfline> zyga: and how does it relate to docker? similar technology but different implementation ?
<zyga> halfline: it has the same perception; we don't put apps in a container
<zyga> halfline: we use apparmor and seccomp to sandbox them
<halfline> zyga: ah okay thanks
<zyga> halfline: we use some namespaces but just for confinement
<halfline> but not a chroot
<jdstrand> halfline: the reason why is we want snaps to be more integrated into the system (but in controlled ways) than a docker or lxd container. note that docker and lxd work great on snappy if you like those technologies
<jdstrand> we do not use a file namespace-- apparmor handles that
<halfline> jdstrand: gotcha ! thanks much
 * zyga will start collecting FAQs
<zyga> jdstrand: can I also remove (harcode) /snap as INSTALL_DIR or is that used by any of the include files?
<jdstrand> zyga: INSTALL_DIR is used by policy. I suggest not removing it unless you want to update the policy files to sub in a go variable. I don't think there is any benefit to doing that work
<zyga> jdstrand: right, I remember something like that being mentioned, fine with me
<zyga> jdstrand: can I at least drop /gadget from it?
<jdstrand> zyga: if /gadget no longer exists
<zyga> niemeyer: ^^ opinion on keeping /gadget in the policy as a place where snaps can be installed? (I think it's not needed but I'd like to check)
<jdstrand> I don't know the status of what gadgets are doing
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/955
<zyga> jdstrand: (without any changes to INSTALL_DIR)
<jdstrand> zyga: btw, autoconnect is working nice in 1.9.2
<sergiusens> kyrofa https://github.com/ubuntu-core/snapcraft/pull/451
<zyga> jdstrand: cool!
<niemeyer> zyga: Huh
<niemeyer> zyga: What's /gadget?
<zyga> niemeyer: it's a directory where snaps can be installed to according to the apparmor template
<zyga> niemeyer: it feels like some really old leftover
<jdstrand> in days past, gadget snaps were installed in /gadget
<jdstrand> aiui
<jdstrand> if all snaps are in /snap, then fine to remove /gadget
 * jdstrand just didn't know the status of gadget snaps
 * zyga has huge lag on internal IRC
<Gunther_> Could somebody provide me with a snapcraft.yaml for a standard xenial kernel (amd64)? Mine is currently stuck after grub with "grep: /proc/device-tree/model: No such file or directory"
<noizer> Hi, is there any news over the new stable version?
<noizer> Or will it be next week the release?
<niemeyer> zyga, jdstrand: Yeah, let's kill it
<zyga> niemeyer: ack, will do
<ogra_> noizer, snappy images will happen later
<niemeyer> fgimenez, elopio: Any news about the int tests?
<niemeyer> FileNotFoundError: [Errno 2] No such file or directory: '/home/jenkins-slave/workspace/github-snappy-integration-tests-cloud/jenkins-github-snappy-integration-tests-cloud-1676/output/artifacts/results.subunit'
<ogra_> noizer, all focus for the 16.04 release is to make snaps fully work on desktop and server ... then the focus turns back to images
<fgimenez> niemeyer, yep, they are currently broken because of scalingstack failures, IS is already looking into it
<niemeyer> fgimenez: Super, thank you
<noizer> ogra_: Ok
<fgimenez> niemeyer, yw, i'll ping you when ready
<niemeyer> fgimenez: Appreciated, thanks!
<noizer> ogra_: Wil the image be ready this month for the raspberry pi 3?
<zyga> niemeyer: while we wait for unit tests to pass on the other branch: https://github.com/ubuntu-core/snappy/pull/955/files
<Gunther_> Other question: I installed a defect kernel.snap. The system boot fails, but grub successfully returns to the last kernel. When I try to remove the defect kernel snap, I get "snappy package cannot be removed"
<zyga> niemeyer: this is just removal of old security and changes to internal-only apparmor variables to make more sense
<ogra_> noizer, no promises ... but yeah, pi3 is on my prio list
<ogra_> it will definitely be ready by snappy release
<noizer> Ok
<zyga> niemeyer: and (more importantl actually) we can now look at this :-) https://github.com/ubuntu-core/snappy/pull/950/files
<noizer> ogra_: Will libsnaps be available in the stable release?
<ogra_> libsnaps ?
<sergiusens> ogra_to compress ;-)
<zyga> niemeyer: https://github.com/ubuntu-core/snappy/pull/958
<noizer> ogra_: I though i heard about a snap where you can put all your libraries in and that your snaps can uses this libraries
<sergiusens> Chipaca do you have your branch handy where you worked on the store api changes? I need to do the same
<ogra_> noizer, you mean snapcraft ?
<noizer> ogra_: nono :p Ok I imagined it. So maybe a good thing to add later on. So that maybe make an other type of snap. the meaning of this snap can be a Library snap so that an other snap can use this library. this can be as an advantage that the developer dont need to download always the library thats he needed when he making different snaps
<zyga> noizer: that will be done wtih interfaces
<zyga> noizer: but it's not supported yet
<ogra_> noizer, oh, that ... i think thats already possible ... but only for your own snaps
<ogra_> ah ... zyga is surely more up to date here :)
<zyga> noizer: we will probably prototype that with the SDK runtime
<zyga> noizer: I don't know now
<edsiper> hi, where are the Snappy images for the Dragonboard 410c ?
<zyga> edsiper: you can use https://github.com/zyga/devtools but I don't think we guarantee that they work this week
<noizer> zyga: ogra_ Will there be later on in the development of snappy.  be possible to share it with other users that develops snaps?
<elopio> fgimenez: I'm following the discussion in #ubuntu-on-air. It's interesting.
<zyga> noizer: perhaps not, use snapcraft for that, we don't want to get into deb dependency
<ogra_> yeah, very unlikely
<noizer> zyga ogra_ ok thx for the information.
<noizer> ogra_: zyga I needed this information because i have tomorrow a meeting with Maarten Ectors. Do you know him?
<ogra_> not personally ... but yeah
<zyga> noizer: sorry, I'm busy now I cannot help you; we're working on the release still
<noizer> ogra_: zyga Ok keep up the good work!
<almejo> I guys. :D I have a technical question. I develop an app for desktop. This app is started from the browser when the user clicks a button. For this I developed a plugin in c++ to start my app. I can not use firefox addons becouse it needs zero interaction of the user. My question is: can I bundle a Firefox plugin and a Gui App in a single snap package? Can firefox plugins be bundled in a snap?
<edsiper> zyga, ok, thanks
<zyga> almejo: this was just answered by beuno in ubuntu-on-air
<almejo> yes.. I was writing here just when he was talking and lost half of the answer :(...
<almejo> thanks guys for your time
<dholbach> sergiusens, Running snapcraft for one package seems to fail because of apt issues (404, or some less secure hashes, etc.), when I try 'snapcraft cleanbuild' I get: http://paste.ubuntu.com/15832645/
<dholbach> I guess I'm doing something wrong, I ran 'sudo lxd init' and lxd is working for autopkgtest stuff for me
<dholbach> or kyrofa ^ :)
 * kyrofa jolts awake
<sergiusens> dholbach I need to see what broke since the latest lxd release and why this stopped working
<sergiusens> dholbach I think I am creating instance names that are too long
<sergiusens> dholbach about the 404; check your sources lists or run with `--enable-geoip`
<kyrofa> dholbach, yeah can you use apt okay?
<dholbach> sergiusens, I think it's because of PPAs and stuff like that
<jdstrand> dholbach, davidcalle, popey, mhall119: fyi, I went through a bunch of the apps in https://docs.google.com/spreadsheets/d/1xBHxFwBNk3HjomnxzOjrohy-E3eyjAGX8ZLvXPqOG84/edit#gid=0 and updated the bzr trees for snapcraft.yaml for various things of yours
<jdstrand> dholbach, davidcalle, popey, mhall119: and I updated the notes and pastebins when things were different
<dholbach> jdstrand, wow wow wow!
<dholbach> thanks a lot
<dholbach> sergiusens, with enable-geoip it now works
<zyga> jdstrand: https://github.com/ubuntu-core/snappy/pull/962
<zyga> jdstrand: simplified version of earlier approach
<popey> jdstrand: thanks
<sergiusens> dholbach that means that one of your apt sources is not in perfect condition wrt gpg keys ;-)
<dholbach> ok
<morphis> jdstrand, zyga: I am currently trying to get the network-manager snap back working and also create a itnerface definiton for it, however I see the small bash script we have in fron of starting the actual daemon causing a segfault
<zyga> niemeyer, mvo: I have all the essentials and I can now work on developer mode CLI or on respecting disconnect when looking at auto-connection
<morphis> jdstrand, zyga: https://paste.ubuntu.com/15833025/
<zyga> morphis: looking
<sergiusens> jdstrand mind looking at https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/6/
<morphis> jdstrand, zyga: I am wondering if that is due to not having any confinement in place
<zyga> morphis: BTW, can you look at the bluez template and update it to match changes made here: https://github.com/ubuntu-core/snappy/pull/955
<morphis> ssweeny: ^^
<zyga> morphis: [    7.637370] audit: type=1400 audit(1460649837.912:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="network-manager.sideload_nmcli_LWMlnkcXLVbp" pid=711 comm="apparmor_parser" ?? how did it get unconfined
<zyga> morphis: how are you testing this?
<zyga> morphis: with 1.9.2?
<morphis> zyga: 1.9.2?
<ssweeny> zyga, morphis I'll take a look after my current meeting
<zyga> which version of snappy
<zyga> ssweeny: thanks
<morphis> zyga: where do I find the version?
<zyga> morphis: can you try with master now? it has connect/disconnect support
<zyga> morphis: if dpkg then it's too old
<zyga> morphis: until we release again
<jdstrand> sergiusens: that's a funky snap name
<zyga> morphis: you may want to merge in a few branches:
<morphis> zyga: mazon.de
<sergiusens> jdstrand shout? :-)
<morphis> narf
<morphis> zyga: https://git.launchpad.net/~morphis/+git/nm-snap/tree/ is what I use
<jdstrand> Download: ts3xPzy5QRvFDfdApSp1SPRIsqQGQbok_6.snap
<morphis> zyga: I suspect the old-security stuff doesn't work anymore
<jdstrand> sergiusens: approved
<ogra_> jdstrand, i see that everywhere now
<zyga> morphis: no, I mean, latest version of snappy itself
<zyga> morphis: correct, you need to make an interface now
<morphis> zyga: ok
<zyga> morphis: old-security is officially dead
<morphis> ok
<morphis> zyga: so where do I find the snappy version?
<morphis> snappy --version doesn't exist
<jdstrand> zyga: in a call and then an appt. will review 962 after
<zyga> morphis: if it is installed from dpkg/apt then it is probably too old
<zyga> morphis: you have to build from source or wait for today's release
<zyga> jdstrand: thanks
<morphis> zyga: no, running a kvm x86 instance here with an image created by u-d-f
<zyga> morphis: hmm, then use my devtools to put more recent snappy inside
<morphis> zyga: can you give me the link again?
<zyga> morphis: that should at least eliminate issues related to snappy being out of date
<zyga> morphis: sure, github.com/zyga/devtools
<zyga> morphis: look at refresh-bits --help
<zyga> morphis: note that this assumes you can built snappy with "go build" (gopath set, deps pulled, etc)
<morphis> I see
<sergiusens> jdstrand ty; btw the checks say "valid click package"; is that known?
<zyga> morphis: if you want to track bleeding edge that helps
<zyga> morphis: if you want more stability then wait one more day but this would let you develop the interface right now so I think it is useful
<niemeyer> zyga: devmode would be my vote
<morphis> zyga: absolutely
<niemeyer> zyga: Hmm
<zyga> niemeyer: I'm already on it
<morphis> let me get started with this
<niemeyer> zyga: Cool
<Chipaca> sergiusens: yes, 1 sec
<jdstrand> sergiusens: that is a store thing. beuno, see sergiusens question ^
<Chipaca> sergiusens: it's not a pretty branch
<sergiusens> Chipaca thanks, my os.snap download logic broke in snapcraft :-)
<sergiusens> Chipaca there is no such thing as useful and pretty code ;-)
<Chipaca> sergiusens: https://github.com/ubuntu-core/snappy/pull/928
<sergiusens> dholbach my suspicion is you installed the bluejeans deb ;-)
<sergiusens> Chipaca ty!
<dholbach> sergiusens, I didn't
<beuno> jdstrand, sergiusens, hm
<Chipaca> sergiusens: I mean, it's not at all clear from looking at the branch what is the important change and what is dross
<josepht> Mikaela: nmap 7.12SVN-0.4 should fix your issue
<beuno> roadmr, hi!
<roadmr> hey :)
<jdstrand> beuno: fyi: https://myapps.developer.ubuntu.com/dev/click-apps/3989/rev/6/
<beuno> 12:12 < sergiusens> jdstrand ty; btw the checks say "valid click package"; is that known?
<beuno> 12:14 < jdstrand> sergiusens: that is a store thing. beuno, see sergiusens question ^
<jdstrand> beuno: under '3 passes': OK Is a valid click package
<beuno> roadmr, seems our code has "click" hardcoded there
<roadmr> beuno: let me check the strings
<beuno> thanks roadmr
<Mikaela> josepht: stupid question, but how do I update?
<beuno> Unexpected output from click-review. click-review
<beuno> also, maybe we should rename that  :)
<josepht> Mikaela: for me it was 'snap refresh --channel edge nmap'
<roadmr> beuno: they do, yes.
<Mikaela> josepht: thanks, I will check soon
<beuno> roadmr, can you queue that up, without panicking anyone?  :)
<zyga> roadmr: hey, long time no see, how are you
<roadmr> beuno: so should it say it's a valid $TYPE package, where $TYPE in ['click', 'snap'] ?
<roadmr> zyga: hey!
<Chipaca> sergiusens: if I had to sum it up in a single line diff, it'd be:
<Chipaca>  -   curl -s -H "accept: application/hal+json" -H "X-Ubuntu-Release: 15.04-core" https://search.apps.ubuntu.com/api/v1/package/8nzc1x4iim2xj1g2ul64.chipaca
<Chipaca>  +curl -s -H "accept: application/hal+json" -H "X-Ubuntu-Release: rolling-core" -H "X-Ubuntu-Device-Channel: edge" 'https://search.apps.ubuntu.com/api/v1/search?q=package_name:"8nzc1x4iim2xj1g2ul64"'
<Chipaca> sergiusens: oops, add a /edge after the .chipaca in the - line
<sergiusens> Chipaca so search 15.04 first? or was that a typo?
<Chipaca> sergiusens: in 15.04, do that; in 16, do this
<Chipaca> sergiusens: s/rolling-core/16-core/ if you wish :-)
<Chipaca> sergiusens: basically we never hit the details uri, now; just do an exact search by name
<Chipaca> sergiusens: then shout if you get anything other than 1 package in the results
<Chipaca> sergiusens: and where you used to be able to specify channel in the query, now it goes in a header
<sergiusens> Chipaca but package_name looks like a hash in that example :-P
<sergiusens> ack on channel
<Chipaca> sergiusens: don't diss the famous 8nzc1x4iim2xj1g2ul64.
<sergiusens> oh, right!
<Chipaca> :-)
<zyga> niemeyer, Chipaca: the API for side-loading snaps just shoves the snap across the connection, is there a way to pass developer mode flag there? multipart? different endpoints?)
<Chipaca> zyga: it already passes other flagas
<Chipaca> flags*
<zyga> Chipaca: oh? Where?
<Chipaca> zyga: two different ways :-)
<Chipaca> zyga: give me a mo'
<zyga> Chipaca: I'm looking at client.InstallSnapFile
<zyga> Chipaca: shall I use headers for that?
<Chipaca> zyga: https://github.com/ubuntu-core/snappy/blob/master/daemon/api.go#L764
<Chipaca> zyga: ah, look at daemon.sideloadSnap
<Chipaca> zyga: the flags might not be exposed to the client
<Chipaca> zyga: there are two ways of side-loading a snap, and only one of them is "just shoving it across" :-)
<niemeyer> zyga: We'll probably want to distinguish between discard-snap-conns and disable-snap-security
<Chipaca> zyga: the other involves following an rfc :-D
 * niemeyer looks at some more code
<sergiusens> Chipaca I don't see a download_url when I run curl -s -H "accept: application/hal+json" -H "X-Ubuntu-Release: rolling-core" -H "X-Ubuntu-Device-Channel: edge" 'https://search.apps.ubuntu.com/api/v1/search?q=package_name:"ubuntu-core"'
<zyga> Chipaca: client is just pushing one across, how should I pass a flag there? header?
<zyga> Chipaca: it seems that current client doesn't use multipart
<sergiusens> Chipaca I do if I follow the href in there though
<zyga> niemeyer: what do you mean by discard-snap-conns?
<Chipaca> sergiusens: ah
<Chipaca> sergiusens: you'll need to specify all the fields you want
<niemeyer> zyga: Please finish your conversation with Chipaca first.. we'll need some focused attention on this
<zyga> ok
<nessita> sergiusens, you can request specific fields, with: https://search.apps.ubuntu.com/api/v1/search?q=package_name:"ubuntu-core"&fields=package_name,download_url,binary_size
<Chipaca> sergiusens: we have to do some fun things with reflect, but from python it's probably just "".join($type.__dict__.keys()) :-p
<nessita> etc
<sergiusens> nessita do we still have an anon download url for ubuntu-core? or can we download using download_url without a login?
<Chipaca> zyga: https://github.com/ubuntu-core/snappy/blob/master/docs/rest.md#input
<Chipaca> zyga: headers
<zyga> Chipaca: thanks!
<nessita> sergiusens, we still have the anon url, but that will be removed soon for new snaps, all downloads needs to be authenticated
<nessita> sergiusens, so yes, we still have the anon url, but hopefully no code relies on that
<sergiusens> nessita even ubuntu-core? I thought beuno said the os snap would not require a login
<Chipaca> nessita: that's not right
<Chipaca> i think?
<Chipaca> nessita: or your definition of "soon" is more generous than mine :-D
<nessita> Chipaca, tell me more
<nessita> Chipaca, soon == as soon as matiasb work lands?
<Chipaca> nessita: any snaps that come with the system need to be updated with just the system's creds, which does not (yet) count as authenticated
<Chipaca> nessita: because if nobody has authenticated, we still want to update whatever is on there
<nessita> Chipaca, yes, there is a hand waving in there; we expect this to be the minimal amount of cases
<Chipaca> right
<sergiusens> right, things in the model assertion shouldn't require auth
<Chipaca> sergiusens: well, the model assertion should count as auth maybe :-)
<Chipaca> *handwaving intensifies*
<nessita> sergiusens, "the final plan" assumes there will be a device authentication in all cases
<Chipaca> nessita: but it being minimal does not mean we should delete the code that does it :-D
<Chipaca> unitl device authentication is a thing
<Chipaca> until*
<nessita> and user authentication for most cases
<nessita> Chipaca, yes, agreed, and I understand you are being so explicit due to recent events, and I thank that
<Chipaca> nessita: no, it's just me being my usual ornery self
<niemeyer> Chipaca: It'd probably be nicer to offer a consistent JSON document either as the header or as one of the parameters..
<niemeyer> Chipaca: So we can have a parameter in the InstallSnap(File)..
<nessita> Chipaca, removal of anon, if any, will be announced and coordinated. What I was trying to warm sergiusens is not to rely on that for the common case (as a concept)
<niemeyer> Chipaca: (which is consistent with everything else..)
<niemeyer> Not sure if I can get to that today..
<Chipaca> sergiusens: nessita: https://github.com/ubuntu-core/snappy/blob/master/store/snap_remote_repo.go#L390
<Chipaca> sergiusens: nessita: that's what snap is doing today
<Chipaca> niemeyer: sorry, i'm tracking n+1 conversations, where n is the number i can track
<Chipaca> niemeyer: what was this about? sideloading?
<niemeyer> Chipaca: Sorry, yeah..
<Chipaca> niemeyer: sending json as a header sounds like a bad idea
<niemeyer> Chipaca: The form, feels a bit off from everything else
<niemeyer> (in the API)
<Chipaca> niemeyer: it's the only method that isn't json, because sending binary in json would be zany
<niemeyer> Chipaca: Well, the multipart seems fine and elegant
<nessita> Chipaca, where/who shall I contact about a few comments on that code?
<nessita> I see some issues but would not like to increase to n+2 your current conversations
<ogra_> nessita, ho would i do a port to a new SoC if i cant obtain the ubuntu-core snap unauthenticated ?
<Chipaca> nessita: matiasb might already have code that changes that i pointed at
<Chipaca> nessita: maybe start there
<nessita> ogra_, hi! what is a SoC?
<Chipaca> nessita: s/that i pointed/what i pointed/
 * ogra_ thinks the os snap should be excluded from auth reqs. 
<asac> ogra_: how does the overlay dtb feature work on pi2?
<ogra_> nessita, a new "board"
<asac> we put the dtbs in the /boot/ dir and then it automatically picks it up?
<niemeyer> nessita: System on Chip, Summer of Code, Something of Curiosity
<ogra_> asac, you need to extract the tarball in /boot
<ogra_> asac, err /boot/uboot
<ogra_> asac, then you can define it in config.txt
<nessita> ogra_, so there are (will be) 2 levels of authentication: device and user. The former will be (when available) mandatory for all opertaions
<ogra_> nessita, the point is that for bringing up new hardware i need to be able to freely create my gadget and kernel snaps and combine them with the os snap ... for that i somehow need to get the os snap
<niemeyer> zyga: Some comments on 958, including a high-priority one
<asac> ogra_: how do we define that in config.txt?
<nessita> ogra_, for anything that is not check for updates for existing snaps (and download those) user authentication will be required
<asac> cant see a field with list of dtbs
<nessita> ogra_, I understand there is a factory process that solves this, but not 100% familiar with the details
<ogra_> asac, https://www.raspberrypi.org/documentation/configuration/config-txt.md
<nessita> ogra_, as in, the board will be shipped with an initial snap that will be updateable with device auth only
<ogra_> asac, or rather https://www.raspberrypi.org/documentation/configuration/device-tree.md
<ogra_> nessita, as some home guy who wants to get his favourite board supported i wont use some factory process
<ogra_> there needs to be some community friendly process
<zyga> niemeyer: looking
<Chipaca> ogra_: "factory process" does not mean for a factory
<Chipaca> ogra_: necessarily
<Chipaca> ogra_: and all these steps need to be fleshed out still
<ogra_> Chipaca, yeah, i got catched by the buzzword :)
<niemeyer> zyga: Is 955 ready for merging? It looks good, but was it tested for real?
<niemeyer> zyga: Lots changing on the core template there
<ogra_> Chipaca, sounds like a sprint topic :)
<nessita> ogra_, I don't have the fine details for that use case, (nor sure anyone has)
<Chipaca> ogra_: yeap
<ogra_> nessita, well, that usecase is my everyday job ;)
<Chipaca> ogra_: also, you might be interested in chasing up on "embryonic state", if my memory serves
<niemeyer> Why do we not have integration tests for 955?
<zyga> niemeyer: I thin 955 is okay, bulk of the changes are automatic
<zyga> niemeyer: I'll give it a round of real testing with and without developer mode and if anything is off we can still correct that today
<niemeyer> zyga: Okay, I'll merge because integration test infrastructure is on holiday today, but please verify that in practice so mvo doesn't pack something broken
<zyga> niemeyer: understood
<zyga> niemeyer: https://github.com/ubuntu-core/snappy/pull/958#discussion_r59752350
<zyga> niemeyer: I just want to clarify if I understand the proposed tasks correctly
<dpm> jdstrand, thanks a lot for looking into this! Would you mind expanding on "the other issues are due to packaging"? On bug 1570435, that is
<ubottu> bug 1570435 in Snappy Desktop Examples "Desktop example ubuntu-clock-app is broken" [Undecided,New] https://launchpad.net/bugs/1570435
 * zyga wonders what is the difference between os snap and core snap
<ogra_> is there one ?=
<sergiusens> Chipaca nessita I get 401s when trying to download
<Chipaca> sergiusens: you're doing it wrong then :-)
 * sergiusens ponders just downloading from cdimage
<ogra_> sergiusens, i'd do that
<Chipaca> sergiusens: what're you trying to download? (or how?)
<ogra_> Chipaca, ubuntu-core
<ogra_> the os snap
<niemeyer> zyga: See reply
<Chipaca> ogra_: ok; from where?
<Chipaca> sergiusens: ?
<ogra_> srote vs http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<ogra_> *store
<Chipaca> right
<Chipaca> that's what i'm wanting to know
<ogra_> cdimage is indeed a little newer
<Chipaca> that thing that's on the right of the vs? is a url
<Chipaca> i want that, for the left of the vs
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ vs store
<ogra_> better ?
<ogra_> :)
<Chipaca> ogra_: I'm going to send you a weaponized emoji
<Chipaca> ogra_: :-D
<ogra_> lol ... you telegram kiddos ... so spoiled
<sergiusens> Chipaca https://github.com/ubuntu-core/snapcraft/pull/452
<Chipaca> sergiusens: you're using download_url without being authenticated
<nessita> sergiusens, what URL is giving you 401?
<Chipaca> nessita: download_url :-)
 * ogra_ notes how good it feels to have everyone back in one place :) (sad that telegram will work again at some point and yall will be gone again *sniff*)
<nessita> Chipaca, great answer
<sergiusens> Chipaca I am authenticated
<Chipaca> sergiusens: get anon_download_url as well, and/or do the dance
<Chipaca> sergiusens: no you're not :-p
<sergiusens> nessita I am authenticated
<nessita> sergiusens, then your credentials are likely incorrect/expired
<sergiusens> Chipaca I just uploaded a snap
<sergiusens> nessita ^
<nessita> sergiusens, are you using staging or prod?
<sergiusens> prod
<ogra_> sergiusens, the question is ... did your money transfer arrive yet
<sergiusens> right
<nessita> sergiusens, what package did you upload?
<sergiusens> shout
<sergiusens> 30 minutes or so ago
<nessita> noise][, can you confirm CUD is working fine in prod for authenticated snap downloads?
<nessita> sergiusens, checking
<Chipaca> sergiusens: what revision?
<zyga> niemeyer: read and replied; I don't know what should happen right now;
<Chipaca> sergiusens: anyway, nessita and you can figure it out
<Chipaca> i've got to start thinking about dinner
<niemeyer> zyga: The problem is actually rather simple, I think
<noise][> nessita: should be, but lemme double check
<niemeyer> zyga: We can have multiple snaps with the same name but different revisions installed in the system at any one point
<zyga> niemeyer: yep, agreed
<niemeyer> zyga: When a user sets up connections for a given snap, the natural expectation I think is that it will last for the duration of that snap being in the system
<nessita> sergiusens, any chance you can print your request with the url and headers?
<noise][> nessita: looks good from what I can tell. Note that download-snap will redirect
<nessita> noise][, yes, but sergiusens says he got a 401
<niemeyer> zyga: Imagine you've just installed firefox 2 and 1 is still installed.. if we remove firefox 1 for whatever reason, should we kill the connections for firefox altogether, despite the fact that firefox 2 is not only available but active (!)?
<zyga> niemeyer: yes, that I agree with; what I don't know what to do about is the fact that don't keep multiple profiles (per revision) so remove-snap-security task is not scoped correctly (neither is setup-snap-security)
<nessita> sergiusens, you 100% is a 401 and not a 302?
<sergiusens> nessita no I am not fwiw
<sergiusens> I'm not familiar with this api pindonga used
<niemeyer> zyga: We don't need multiple profiles per revision. that would also be awkward..
<sergiusens> anon download url seems to work fine
<niemeyer> zyga: Imagine you ask to drop a connection for firefox 2.. and then for whatever reason in two weeks decide to use firefox 1 again
<nessita> sergiusens, I was referring to the download request; is that something that pindonga did as well?
<niemeyer> zyga: I switched the revision, not my authorization
<niemeyer> zyga: I'd not expect interface connections to be magically given back to the snap because I rolled back
<sergiusens> nessita I did the download request, it is in the branch I shared above
<zyga> niemeyer: right, I understand this; what I'm saying is that I don't quite understand what the tree tasks you've listed are responsible for
<niemeyer> zyga: What we need right now is really simple: we need to disentangle the discarding of user-driven connection information from the removal of a particular snap from the system
<nessita> sergiusens, yes, but I'm asking if you can retry and print the exact url you are hitting and the headers you are passing
<niemeyer> zyga: Okay, again
<nessita> sergiusens, not the code, but the specific values you are sendinf
<zyga> niemeyer: that sounds like interfaces are not a part of that, if you remove a snap that is not the one that's active, security is not affected
<niemeyer> zyga: setup-profiles.. put the profiles in the system
<niemeyer> zyga: remove-profiles.. remove profiles from the system for a given snap
<noise][> nessita: sergiusens: FYI, auth on CUD is still oauth unless i have missed something
<niemeyer> zyga: discard-conns.. drop connection information for a given snap
<zyga> niemeyer: okay
<zyga> niemeyer: how would remove-profiles be used by $ snap install $ snap remove and $ snap refresh?
<niemeyer> zyga: setup-profiles and remove-profiles will _just_ add and remove profiles to the system
<zyga> niemeyer: right, I understand what you mean, I'm trying to match that to snap operation
<zyga> *operations
<niemeyer> zyga: setup-profiles will also auto-connect, actually, because that's a handy place to do it
<niemeyer> zyga: I see
<sergiusens> nessita noise][ ok; fwiw this worked fine 2 days ago
<niemeyer> zyga: on snapstate.Remove, if len(SnapSetup.Sequence) == 1, add discard-conns to the end of the pipe
 * sergiusens blames python
<sergiusens> ;-)
<ogra_> just use cdimage :P
<nessita> sergiusens, we can definitely help you more debugging this if you can print the URL you are hitting, the headers you are sending, and the response code you are getting
<niemeyer> zyga: On discard-conns itself, double-check to ensure len is 1, just in case
<niemeyer> zyga: Or rather, zero (or no state)
<sergiusens> nessita yeah, I need to read the docs and figure out how to do that, one sec
<niemeyer> zyga: Makes sense?
<zyga> re (sorry, IRL interrupt) catching up
<nessita> sergiusens, thanks!
<zyga> niemeyer: so I disagree with what you said here:
<sergiusens> nessita it is indeed a 401
<zyga> niemeyer	zyga: on snapstate.Remove, if len(SnapSetup.Sequence) == 1, add discard-conns to the end of the pipe
<sergiusens> nessita http://paste.ubuntu.com/15835131/
<zyga> niemeyer: if you have two versions of firefox and you run remove-snap-security task for a revision you are not using, it will break the one you are using
<nessita> sergiusens, "GET /download-origin/local/canonical/ubuntu-core.canonic..." is not the store
<zyga> niemeyer: you said that remove-profiles should just remove the profiles
<nessita> sergiusens, that is something in snappy code, before the download server is hit (or after, but 401 may be a lie)
<zyga> niemeyer: but those are global, they are not scoped to a snap revision
<zyga> niemeyer: so I'm must be missing something or this is not going to do the right thing
<zyga> s/remove-snap-security/remove-profiles/
<sergiusens> nessita there is no snappy in this code
<niemeyer> zyga: What does it mean for it to be global?
<niemeyer> zyga: and about the first quote, that's exactly what I mean! :)
<zyga> niemeyer: not being scoped to a revision, remove-profiles is really simple, it just looks at the snap name and kills all the profiles of that snap *name*
<niemeyer> zyga: THat's why we don't want to remove connections there
<zyga> niemeyer: I think I understand connections now
<niemeyer> zyga: I see, yes
<zyga> niemeyer: can you give me a quick example that shows how two revisions of a single snap would interact?
<zyga> niemeyer: wrt CLI commands and tasks?
<niemeyer> zyga: But I don't see the disagreement.. remove-profiles just removes profiles for the given snap, okay
<nessita> sergiusens, ok, let me rephrase: the store does not provide any /download-origin/local/canonical/ API, so that is not the store
<niemeyer> zyga: We still want that
<zyga> niemeyer: sure, that's okay :-)
<nessita> sergiusens, is something else, and once identified, we could use knowing what URL is that hitting, which headers, and what actual return code is getting
<niemeyer> zyga: Yes, remove-snap-security for firefox when removing firefox.1, drops all connections
<zyga> niemeyer: if that's good in snapstate then there is no disagreement; I'm just confused as to how having multiple snaps with the sname name (and different revision) really works today
<niemeyer> zyga: activate firefox.2
<noise][> nessita: that's the redirect in CUD
<niemeyer> zyga: Where are the connections I set up for it previously?  GONE!
<nessita> noise][, oh, now you make me look bad :-D
<zyga> AHHH
<zyga> niemeyer: I'm dumb :)
<zyga> niemeyer: I get it
<niemeyer> zyga: \o/
<niemeyer> ;)
<noise][> for CDNs - and currently we redirect to "local", which is /download-origin/â¦ with a token for auth
<zyga> niemeyer: sorry for taking so much of your time on this, I understand
<nessita> noise][, is the signature validated before ther redirect?
<zyga> niemeyer: I'll make that happen quickly
<niemeyer> Cheers!
<noise][> nessita: yes, oauth is validated in download-snap, then redirect to download-origin w/that token to allow the actual download
<noise][> and is working fine for me in my tests
<zyga> niemeyer: can you look at https://github.com/ubuntu-core/snappy/pull/950
<zyga> niemeyer: while the topic is still hot
<zyga> niemeyer: this is reload in setup-snap-security
<zyga> niemeyer: (see the TODO it removes)
<noise][> not sure what's different for sergiusens
<sergiusens> nessita so don't lie to me please ;-) http://paste.ubuntu.com/15835258/
<nessita> sergiusens, yes, this was my bad, things are changing too fast
<nessita> sorry
<sergiusens> download_url I get back from the store points to https://public.apps.ubuntu.com/download-snap/canonical/ubuntu-core.canonical/ubuntu-core.canonical_16.04+20160409.16-42_amd64.snap
<zyga> niemeyer: I think this is okay, no changes (apart from loooooooong test function names) are needed based on the conversation above
<sergiusens> so I am either missing a header or something else
<nessita> noise][, so, how can we debug why sergio is getting a 401?
<sergiusens> zyga anon download url works fine for downloading the os snap ;-)
<zyga> sergiusens: and the core snap?
<zyga> sergiusens: what's a core snap?
<sergiusens> zyga that's what I'm trying to get, `ubuntu-core`
<zyga> sergiusens: ubuntu-core is currently an OS snap AFAIR
<sergiusens> yes
<ogra_> sergiusens, 16.04+20160409.16-42 ?
<ogra_> thats ancient
<nessita> noise][, can we assume that if download-snap was a 302, the Oauth was a success?
<sergiusens> zyga don't get confused because people shorten names and use the name half complete and the type interchangeably
<beuno> so
<beuno> I know what it is!
<sergiusens> ogra_ it is what the store gives back to me :shrug:
<beuno> +
<nessita> oh, a martin
 * ogra_ wonders why sergiusens gets such an old version in return
<noise][> nessita: correct, so no clue why the subsequent token would be bad
<beuno> 16.04+20160409
<beuno> using + in URLs messes things up
<ogra_> 16.04+20160414.05-00
<beuno> it gets urlencoded in some layer, things to match
<beuno> boom, etc
<ogra_> thast the current one
<ogra_> so the search is also returning the wrong thing
<beuno> I'm looking forward to us switching to revisions for URLs  :)
<beuno> quick fix, re-upload with a less whacky version
<beuno> proper fix, we switch to revisions for urls
<sergiusens> beuno is there a reason the anon download works and the auth requiring one doesn't?
<ogra_> the version is generated by cdimage
<beuno> maybe disallow +'s until we do
<noise][> aha
<beuno> sergiusens, because oauth
<beuno> and comparing URLs
<beuno> and layers
<sergiusens> oh
<beuno> and software developers are terrible
<sergiusens> ic
<beuno> all of us
<sergiusens> I know; I doubt myself every second!
<noise][> good catch beuno
<ogra_> beuno, so i need to re-do the cdimage code ?
<sergiusens> so is upload automated?
<ogra_> not yet
<sergiusens> for ubuntu-core
<sergiusens> who does that, is it you ogra_ or mvo?
<ogra_> i was holding back because elopio said he could do it super easy with his jenkins instance
<sergiusens> beuno since you are here, is anon download supposed to go away for ubuntu-core?
 * noise][ has to go pickup food, bbiaf
<beuno> sergiusens, it'll go away when there's device auth
<ogra_> all i could do it to use the click-toolbelt ... since i cant run snapcraft on the 12.04 cdimage server
<beuno> until then, it'll likely stay around just for the OS snap
<noise][> sergiusens: note we are going to be doing this same redirection thing to anon- as well
<noise][> likely by monday
<ogra_> beuno, could we keep it for the os snap even later ?
<sergiusens> beuno the definition and resolution of the word "then" makes my path different for this
<beuno> ogra_, why so?
<sergiusens> as this download of the os snap is a hack until the kernel snap is redefined
<ogra_> beuno, makes porting easier ... a sa porter you need to have the os snap around
<sergiusens> beuno enablement I guess
<sergiusens> but then again ogra can run snapcraft login and forget about it
<beuno> right
<beuno> that's the idea
<ogra_> sergiusens, i cant
<ogra_> sergiusens, unless you port snapcraft to 12.04
<ogra_> our cdimage server is ooold
<beuno> ogra_, well
<beuno> that's what needs fixing then
<beuno> ;)
<sergiusens> ogra_ to download the os snap, not upload!
<ogra_> you wont get IS to move
<sergiusens> to upload you need auth no matter what!
<ogra_> sergiusens, oh
<beuno> ogra_, we'll just go on a hunger strike
<ogra_> sergiusens, right, but that adds an extra hurdle for someone wanting to port
<beuno> yes, I think it's an acceptable hurdle though
<beuno> gets you in the right mindset
<ogra_> if i just want ot evaluate snappy for my new shiny board i probably dont even want to have or iuse an account at a canonical server
<ogra_> which will simply make me go to bitbake and yocto ... done
<beuno> it sounds like a pretty small hurdle  :)
<ogra_> for you and me perhaps :P
<beuno> if that's what's going to tip the scales, the scales are probably already tipped
<ogra_> not for the enbedded people i talk to
<beuno> the problem with exceptions is that they are essentially technical debt
<ogra_> (which is why i send them off to cdimage anyway, sionce there they can get the same thing without any authentication)
<beuno> there are areas like authentication where technical debt is a bit worst than others
<beuno> but
<beuno> there's a sprint coming up, and you'll be there
<ogra_> right
<beuno> so keep this in your back pocket  :)
<ogra_> i definitely will ... especially sicne i expect gadget and kernel changes to be discussed there too
<ogra_> i really think all three of these snaps should go without any auth for the community images we provide
<beuno> hold on
<ogra_> (totally fine to have the auth req. for oem products )
<beuno> device auth is automatic
<beuno> you don't need an SSO account
<ogra_> once you have a working port, yes
<beuno> well, that can be bridged by snapcraft
<ogra_> if i sideloaded all three snaps, then there will likely not be device auth
<beuno> anyway, the requirement is auth one way or another
<beuno> devices can be created in the fly
<beuno> so it could be a transparent process
<beuno> as long as you use snapcraf
<ogra_> so snapcraft will replace u-d-f ?
<ogra_> or how do i get a new board ported
<ogra_> (my focus is realyl on creating an initial image for not yet supported devices)
<beuno> or u-d-f could create a device
<beuno> whatever  :)
<sergiusens> ubuntu-image!
<ogra_> thats a merger of snapcraft and u-d-f ?
<ogra_> :)
<zyga> ogra_: and it will be written in ruby, between python and go ;)
<ogra_> zyga, wrapped in .net i hope
<ogra_> so it runs on windows too
<zyga> ogra_: with perl 6 installer
 * zyga goes back to wrok
<ogra_> as long as that has a TkTcl GUI i'm all fine
<kyrofa> zyga, ogra_ ahhhh ruby
<ogra_> yep ... in ayear from now we'll all be hipsters !
<kyrofa> Haha, that's been one of my favorites for a long time now
<kyrofa> I guess I'm a hipster :P
<ogra_> hah
<ogra_> and you didnt convince sergiusens yet to rewrite snapcraft ?
<kyrofa> ogra_, it would probably involve bundling rvm somehow :P
<ogra_> just snap it !
<kyrofa> dpm, a docs update if you want to review: https://github.com/ubuntu-core/snapcraft/pull/454
<dpm> thanks kyrofa
<kyrofa> dpm, ah, that was meant for davidcalle, sorry about that. But it got to the right place :)
<dpm> :)
<zyga> ssweeny: bluez merged, please open a new pull request if you need changes
<ssweeny> zyga, thanks! will do
<MichaelTunnell> are there any plans for other flavors to get Snappy? I assume 16.04 won't but do we know about 16.10 yet?
<MichaelTunnell> Kubuntu, Ubuntu MATE, Xubuntu, etc
<MichaelTunnell> is what I meant
<MichaelTunnell> QUESTION: what if someone were to install a DEB for an app and then a SNAP becomes available? Will there be a process for SNAPs to overwrite the DEBs or would it be a case of "uninstall DEB and install the SNAP"?
<beuno> MichaelTunnell, the snap will win over the deb when run
<beuno> they can both be co-installed
<beuno> but when you run the app, it'll run the snap
<MichaelTunnell> beuno: ahh nice so it just uses a priority structure
<beuno> right
<beuno> MichaelTunnell, flavours can pull in snaps today, if they wanted
<beuno> dpm might know more about what their plans are
<beuno> you can also ask them directly  :)
<MichaelTunnell> I asked Kubuntu but so far their unsure too :)
<MichaelTunnell> I figured that would be the case but worth asking :)
<dpm> MichaelTunnell, essentially all flavours can already use the command line interface to install/remove/manage apps. The question is whether they decide to go the full integration route and add a plugin to their software installer to talk to the store
<beuno> MichaelTunnell, so we're both in wait and see mode!
<dpm> for those that already use gnome software, they'll get the full story already
<MichaelTunnell> beuno: :)
<MichaelTunnell> dpm: so Ubuntu GNOME could transition super easy in theory?
<dpm> I know at least MATE already put the CLI tools in their seeds, and others are interested
<dpm> MichaelTunnell, yeah, it'd be a matter of having the right packages put to their seeds to have it preinstalled (optimal situation) - or flavour users can also install the packages manually
<davidcalle> kyrofa, thanks for the quick update! I'll have a look when I'm not on mobile
<MichaelTunnell> was about to answer the user part . . . again you read my mind
<MichaelTunnell> scary
<MichaelTunnell> ask* the user part
<MichaelTunnell> dpm: how well would Snappy work in a VM like if I were to install Snappy now could I demo everything in a VM?
<MichaelTunnell> and by install Snappy I mean 16.04 Daily
<dpm> MichaelTunnell, I've not tried it, but I guess it should work with no issues. In any case, if you're on 16.04 already, you can already try it today on your desktop. However, there is only a small subset of apps available and not all work atm, which is what we're right now trying to fix before we publish the documentation
<crash_> how do you know in the gnome-software which package is a snap or just a regular deb?
<popey> MichaelTunnell: yes, you should be able to use snappy in a vm running 16.04 in that vm
<popey> a good test actually as you'll be able to snapshot it, test it, revert and then do a demo live "on camera"
<popey> better than screwing your man pc up ã
<MichaelTunnell> popey: thats a good idea. I wanted to have a stable recording of it so hence a VM but the rollback idea is great. :)
<bhdouglass> hey guys, popey sent me here for some help with the click store api in relation to snappy packages. Currently uApp Explorer is only getting one architecture for most snaps even when they have more than one. I played around with the api and it looks like I need to explicitly specify the arch in the request in order to show anything different. I was hoping that uApp Explorer could get all the supported archs per package in one reque
<dduffey> is the correct command to sideload a local snap in 16.04:
<dduffey> sudo snappy install file:///home/ubuntu/blahlbah.snap?
<MichaelTunnell> dduffey: snappy is gone basically, look at the man stuff for snap
<MichaelTunnell> snappy the command is gone I mean :)
<popey> yeah, sudo snap install ./foo.click
<dduffey> popey, thanks "snappy package not found"
<popey> did you do ./ in front?
<dduffey> yep, but this is a .snap
<dduffey> not a .click
<popey> oh, duh
<dduffey> brb
<popey> yeah, sorry
<dduffey> but still
<dduffey> fails when I give it a local file
<popey> odd
<popey> dduffey: what does "snap list" show?
<code1o6> Hey has anyone since manik?
<zyga> popey: list of installed snaps
<popey> zyga: yeah, that was aimed at dduffey :)
<dduffey> popey, sorry not in a position to cut and paste... but is says "unkown command list" and wanst ack, activate, cok...
<dduffey> popey, ah, got some more info ... snappy install ./blah.snap says
<popey> not snappy install... snap install
<dduffey> "unkown header: "!<arch>\ndebian-binar"
<popey> ah, known bug
<dduffey> popey, work-around?
<popey> I don't know, sorry.
<popey> I'm a user, not a dev
<dduffey> popey, okay, thanks
<dduffey> apparently this snappy image / snap worked last week ... so not sure what changed or they knew a work-around (they are out this week)
<zyga> FYI, snappy (the command) was replaced by snap
<sergiusens> dduffey <arch>\ndebian-binar" means you are trying to install a 15.04 snap on 16.04
<mariogrip> can i build arm python2 apps with snapcraft on amd64?
<mariogrip> if yes, how?
<MichaelTunnell> cross architecture compiling? I doubt it. You could have the snappy build server do it
#snappy 2016-04-15
<qengho> mariogrip: You might be able to. snapcraft is gaining the functionality, though not many plugins support it yet. The python plugin probably does the right thing (if no compiling!), but doesn't signal that it's right.
<qengho> mariogrip: How involved do you want to get?
<qengho> mariogrip: If not compiling, you can hack into the python2.py a new function.  def set_target_machine(self, machine): pass
<qengho> That probably makes recent snapcraft work for you.
<mariogrip> qengho: I tried architectures: [amd64, armhf] but when I try to install it on my rpi2 it fails to install
<mariogrip> missing /tmp/* folder somehow
<qengho> mariogrip: was that with "--target-arch armhf" ?
<mariogrip> qengho: no I added  architectures: [amd64, armhf]  to snapcraft.yaml file and it made myapp_0.1_multi.snap
<mariogrip> myapp_0.1_multi.snap failed to install: open /tmp/read-file088244561/unpack/meta/package.yaml: no such file or directory
<qengho> mariogrip: Oh. Hrm. Sorry -- that is a bit of a mystery to me. I thought you were creating a specific arch snap from a different arch.
<mariogrip> qengho: oh, I first thought i had to do that, since it outputted just amd64.snap when I ran it the first time
<qengho> mariogrip: My suggestion above might not work, but I think it has a decent chance.  "snapcraft --help" and add that function to the python2 plugin.
<qengho> that function is "set_target_machine".
<qengho> ^^^^^^
<mariogrip> qengho: I'll give it a try
<qengho> mariogrip: My suggestion also implies removing the "architectures:" line from snapcraft.yaml .
<qengho> ...I think.
<qengho> mariogrip: I'm not an expert in this.
<mariogrip> qengho: no difference, still says octoprint_0.1_multi.snap failed to install: open /tmp/read-file015824556/unpack/meta/package.yaml: no such file or directory when i try to install it :( but thanks anyway :)
<qengho> mariogrip: that "multi.snap" part sounds suspicious, like you didn't change snapcraft.yaml, and did you use --target-arch ?
<mariogrip> no, it was just an old copypaste i had, it says _amd64
<mariogrip> I did not use --target-arch
<qengho> :\
<mariogrip> I haven't tried it on amd64. so it might be broken there also
<mariogrip> the command snappy does not exist after an update for some reason
<mariogrip> on my host
<qengho> mariogrip: if your filename isn't "myapp_0.1_armhf.snap", then it's not going to work on an armhf machine, I bet.
<qengho> mariogrip: "snappy" name is dead. Use "snap".
<qengho> Bed time! Zzzz.
<mariogrip> oh, i use snappy on my rpi... that might be why
<mariogrip> the "new" snap uses xz tarballs....
<qengho> The new new snap doesn't use tarballs at all.
<mariogrip> that's might be why snappy install does not work with my app...
<mariogrip> it worked with snap
<qengho> mariogrip: Are you using 16.04 images?
<mariogrip> yes
<mariogrip> then, how do i make snap packages for snappy install
<qengho> Your snapcraft should be v2. It should make squashfs images. They should install with "snap" (not snappy) on 16.04 snappy images.
<qengho> mariogrip: A lof of that^ is new as of the last 6 weeks or so.
<mariogrip> how do i build v1 packages?
<qengho> I don't know. I think you need the kind of snapcraft and snappy that was in 15.10.
<qengho> I don't think a v1 package would be good for very long. It was a kind of rough draft.
<mariogrip> ah, ok. ill see if i find newer rpi images that has snap insted of snappy
<mariogrip> qengho: thanks for your help :)
<qengho> mariogrip: Welcome! I'm sorry it wasn't obvious. When your snapcraft v2 is making files with "armhf" in the name, you should be able to install those on rpi machines that have a "snap" command. That's what I think. Good luck.
<NAto> good evening, anybody home?
<netphreak> hi, guys!
<dholbach> good morning
<Gunther_> Good morning! Sorry to bother irc with this, but can anybody help me with this: https://lists.ubuntu.com/archives/snappy-devel/2016-April/001729.html ?
<davidcalle> Morning o/
<shuduo> morning.
<shuduo> i try to use u-d-f all-snaps version from ~people/mvo but it can't found gadget snap today. may i know what's wrong?
<zyga> good morning
<mvo> shuduo: there is a store bug currently that prevents u-d-f from working, sorry for that
<mvo> shuduo: we are working on a fix or workaround currently
<noizer> good morning
<shuduo> mvo, may i know if there is an ETA for fix? we have some customers are evaluating 1604 image
<mvo> shuduo: we aim for a fix/workaround by the end of today (so ~12h or so)
<mvo> shuduo: unfortunately its not entriely trivial to fix
<shuduo> mvo good to know. thanks!
<shuduo> mvo: good luck
<asac> o/
 * asac wonders if the 4.4 kernel got ever rolled to stable channel for pi2 or if its a bug that i dont get that update
<davidcalle> Trying to run snaps today results in "unable to bind /snap/ubuntu-core/current//lib32 to /lib32. errmsg: No such file or directory"
<davmor2> ogra_: I just did snap install ubuntu-clock-app should I now see it somewhere on the system?
<mvo> shuduo: I pushed a new u-d-f with a workaround for the store issue. note that you will need to build "edge" images with that and e.g. firstboot is not fully working yet
<shuduo> mvo: okay. let me try it
<ogra_> davmor2, afaik it shold install a.desktop file so you should find it in a dash search
<davmor2> ogra_: nope
<ogra_> asac, 16.04 never had an actual stable release
<ogra_> you want the edge channel, that has 4.4 since months
<shuduo> mvo: unfortunately new u-d-f does not work too. I ran it few times. once it report TLS timoeout. rest outputs same msg
<mvo> shuduo: what commandline do you use?
<shuduo> sudo ../ubuntu-device-flash core rolling --channel edge --gadget canonical-pi2.canonical --kernel canonical-pi2-linux.canonical --os ubuntu-core.canonical --verbose --developer-mode --enable-ssh -o rp2-test.img
<mvo> shuduo: please drop the ".canonical" from the snaps and try again
<ogra_> and you dont need --enable-ssh anymore
<ogra_> (it is always enabled atm)
<shuduo> mvo: it is working now. so no more .canonical in future? then I need update such information to others
<ogra_> yes, there are a lot docs that need updating now :(
<mvo> shuduo: yes
<shuduo> mvo, will you update another version in next few days? then I can update all-working version to customer later since today is Friday. :)
<mvo> shuduo: I am working on the fix right now, maybe in some minutes
<shuduo> mvo good
<ogra_> mvo, on that note, should we perhaps do a snapshot of all snaps to stable so we have at least an alpha quality image by release ?
<ogra_> (i think we released one chunk to stable a few months ago which keeps people like asac stuck on old versions
<ogra_> )
<mvo> ogra_: yes, I think we should do that plus new alpha images
<ogra_> mvo, i see there is still a snapd issue ... so after that landed ?
<mvo> ogra_: which one?
<mvo> ogra_: oh, the store bug
<mvo> ogra_: yes
<mvo> ogra_: that needs to land
<ogra_> mvo, no, the migration
<ogra_> http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd
<mvo> shuduo: please try again
<shuduo> mvo: okay
<mvo> ogra_: yeah, this is a issue because the autopkgtest environment does not allow access to the store
<ogra_> mvo, right, i was just thinking we want the latest snapd in the images :)
<ogra_> bfore pushing any buttons
<mvo> yes
<ogra_> ppisati, any chance that we see https://launchpad.net/ubuntu/+source/linux-meta-snapdragon/4.4.0.1009.1 land before the weekend ? there are livecd-rootfs changes that need to happen alongside to not forcefully pull from the PPA
<cjwatson> mariogrip: Sounds to me like you might be better served by getting Launchpad to build the snap for you, since it supports all the combinations you're looking for.
<ppisati> ogra_: it's more of an archive thing
<ogra_> you mean some AA reviewing it ?
<ppisati> ogra_: try to hassle an AA guy
<ppisati> ogra_: it looks like it's in proposed
<ogra_> yes
<ogra_> since a while already
<ppisati> ogra_: so it needs to be copied
<ogra_> i just want to get rid of the hack in livecd-rootfs before release :)
<ppisati> yeah, i understand
<ppisati> ogra_: as soon as rtg / infinity show up, try to hassle them
<mvo> !
<ogra_> ?
<ogra_> ppisati, hmm bug 1567379 is referred to by the excuses page ... and there is still a Canonical Kernel Team task that is only Confirmed
<ubottu> bug 1567379 in Kernel Development Workflow "linux-snapdragon: 4.4.0-1011.11 -proposed tracker" [Medium,In progress] https://launchpad.net/bugs/1567379
<shuduo> mvo: i download again but seems it's same as previous one. md5sum is 4d582e995383d5a83f58e2e4a166ae19. can you let me know if it's that one?
<mvo> shuduo: I pushed an updated version of the os snap that fixes the network failure I had in the previous image build
<shuduo> mvo: may i know if it's for RPi2 only or also solved problem in x86?
<mvo> shuduo: sorry, only amd64, let me fix rpi2
<shuduo> mvo: okay.
<mvo> shuduo: try now
<mvo> shuduo: please
 * mvo gets lunch
<shuduo> mvo: still edge? will stable be fixed soon?
<ogra_> shuduo, see above ... we'll do an alpha release to stable before release day
<ogra_> (release is next week, so within the next 7 days)
<shuduo> ogra_: okay. thanks.
<ogra_> note though that there are still tons of changes pending for the next months (currently networking wont be configured because the config interface is completely gone til a re-implementation is ready)
<ogra_> so the alpha you will get in stable might behave worse whan the months outdated stable image you would get today
<ogra_> s/whan/than/
<dholbach> davidcalle, looks like clock app can't connect to network manager or geoclue
<dholbach> but that's about it
<dholbach> mvo, nice work!
<davidcalle> mvo: \o/
<popey> dholbach: so kodi now produces a ton of apparmor denials.
<popey> which is different
<popey> davidcalle: also, thanks for telling me about apparmor notify
<dholbach> and it didn't before?
<popey> no, it would black screen and libgl error
<popey> i added the opengl plug and now it fails with apparmor, I pastebinned into the snap this sheet for the record
<popey> (I class this as progess)  ð
<ogra_> ARGH !
<ogra_> where is sergio
<davmor2> ogra_: hiding from you
<ogra_> yeah :(
<zyga> ogra_: what's up?
<ogra_> snapcraft 2.8 breaks image builds on s390x
<ogra_> http://paste.ubuntu.com/15848428/
<kyrofa> Good morning
<ogra_> morning kyrofa
<ogra_> kyrofa, do you know if sergio is out today ?
<kyrofa> ogra_, I don't believe so, but he may be sleeping in a little-- it's been a long week!
<ogra_> yeah
<ogra_> sadly he broke snapcraft on s390x :(
<ogra_> (which makes images fail)
<kyrofa> 2.8?
<ogra_> yeah
<kyrofa> Trying to install cross-compilers?
<ogra_> the issue looks liek it is trivially missing the arch name
<ogra_> http://paste.ubuntu.com/15848428/
<ogra_> KeyError: 's390x'
<kyrofa> ogra_, ah, easy fix. And good timing, we're about to crank out 2.8.1 (2.8 sadly broke on several archs)
<ogra_> heh, image builds only broke on that one arch ... all others are happily building along
<kyrofa> ogra_, hmm... that's interesting. My run on arm busted trying to install cross compilers that didn't exist
<ogra_> are they a hard dependency ?
<kyrofa> ogra_, no, it was a bug
<ogra_> i only run "apt-get install -y snapcraft" in the builds
<kyrofa> ogra_, ah, no it's determined at runtime
<ogra_> and then call "snapcraft snap snap"
<ogra_> (for a pre-created dir structure)
<ogra_> so that doesnt hit me then :)
<kyrofa> Oh, that's probably it then
<kyrofa> You already have the dir
<ogra_> yeah
<kyrofa> Lucky ;)
<ogra_> for os snap thats easier to do :)
<kyrofa> ogra_, mind making a bug fo rme? I'll make sure this is in 2.8.1
<ogra_> ok
<kyrofa> Morning sergiusens :)
<ogra_> kyrofa, bug 1570835
<ubottu> bug 1570835 in Snapcraft "snapcraft 2.8 fails on s390x" [Undecided,New] https://launchpad.net/bugs/1570835
<kyrofa> Thanks ogra_!
<kyrofa> And sorry about that
<ogra_> no worries
<ogra_> (i doubt that arch has many users :P )
<shuduo-afk> ogra_, mvo i ran the new amd64 image in virt-manager. i can see snappy command exist but just snap. is it a new change? then how to use classic dimension?
<ogra_> shuduo, yes, the snappy command is effectively gone (there are more bits that just vanished with this change for the moment ... they will come back in the next weeks)
<ogra_> to use the classic dimension "sudo snap enable-classic" should still work
<ogra_> stgraber, that reminds me, where do we stand with arm64 support for snappy classic ?
<shuduo> ogra_: snap tell me enable-classic is unknown command...
<shuduo> error: Unknown command `enable-classic'. Please specify one command of: ack, connect, disconnect, find, install, interfaces, known, list, login, purge, refresh or remove
<ogra_> oh ? that usedf to work for me two days ago ... perhaps it has also been dropped then
<ogra_> you are on the edge channel, right ?
<shuduo> ogra_: yes
<ogra_> (stable is pretty much useless atm)
<zyga> jdstrand: I got devel mode to work :)
<jdstrand> zyga: yay! did you use @complain for seccomp?
<zyga> jdstrand: chceking :)
<zyga> jdstrand: I ran hello-world.evil :)
<zyga> jdstrand: yes, first line of seccomp is @complain
<zyga> jdstrand: then the normal profile follows
<zyga> jdstrand: I guess we have a winner :D
<jdstrand> I ask cause I did an upload for ubuntu-core-launcher to support @complain (currently a synonym for @unrestricted until we can work out how to make seccomp actually complain)
<jdstrand> this way you don't have to change snappy
<zyga> jdstrand: yep, I saw the changelog
<jdstrand> cool
<shuduo> ogra_: so snappy and classic will come back in next week*S*. that means all customers evaluation be blocked in next weeks. :(
<zyga> jdstrand: I think this will be a good release WRT security and interfaces
<zyga> jdstrand: I'll try to spare a moment on the bluez interface when this lands
<jdstrand> oh, it made it into the archive
<jdstrand> nice
<zyga> jdstrand: but I still have a few TODOs
<zyga> jdstrand: do you know if anything that is in the store that didn't work before is public?
<zyga> jdstrand: can I install something (without sideloading) that would show this to work?
<zyga> jdstrand: (for x11 stuff, hello-world.evil works already)
<jdstrand> zyga: 'this' meaning bluez?
<jdstrand> what are we talking about?
<zyga> jdstrand: no, I mean devel mode still
<zyga> jdstrand: I;d like to see x apps working, with devel mode
<jdstrand> I don't think anything in the store would work
<jdstrand> because they are all using old-security
<jdstrand> actually
<jdstrand> that may work
<jdstrand> since old-security gives you default confinement without unity7
<jdstrand> zyga: ubuntu-calculator-app?
<ogra_> shuduo, well, the "snappy 1.0" release is still a bit away and all fiocus has been moved to snappy on server/desktop installs for the 16.04 release ...
<zyga> ohh
<zyga> good idea
<zyga> though that will work with confinement AFAIR
<jdstrand> it shouldn't
<jdstrand> unless you brought back old-security
<jdstrand> the last I looked the uploads used security-template to get them to work
<zyga> ah, right
<zyga> I faked it to have unity7
<zyga> :D
<zyga> last Friday
<jdstrand> ah
<zyga> but that's gone now
<shuduo> ogra_: yes, i understand. but we have few customer want to demo pre-release snappy early
<ogra_> i definitely still have snap enable-classic here on an install from the 11th
<ogra_> ubuntu@localhost:~$ snap
<ogra_> error: Please specify one command of: ack, connect, destroy-classic, disconnect, enable-classic, find, install, interfaces, known, list, login, purge, refresh, remove or shell
<shuduo> ogra_: i just use latest u-d-f to generate fresh new image from edge channel
<ogra_> yeah, must have been dropped within the last few days
<shuduo> ubuntu-core        16.04+20160415.05-01
<ogra_> i dont really see that mentioned in any of the changelogs though
<shuduo> ogra_: that's fine. i will communicate with customer a little more about "we are working on make snappy back" :)
<josepht> ogra_: 9025e4b56b425ee11bc37216ff8551ce17101135 seems to be the commit that removed enable-classic.
<ogra_> josepht, hmm, no changelog entry in the package
<jdstrand> popey: what app did you try with opengl?
<popey> jdstrand: kodi
<popey> jdstrand: and Love
<popey> jdstrand: basically copied your unity7/opengl plug entries for those two (and pushed)
<jdstrand> popey: great. I updated the notes for kodi just now
<jdstrand> popey: can you paste the apparmor denial (if any) for love in the pastebin in the spreadsheet?
<popey> jdstrand: done
<popey> also tried mame, which the mame.ini I can fix, not sure about the fontconfig
<jdstrand> that's what I was afraid of
<jdstrand> popey: I updated the love Notes
<qengho> Isn't there a newer rpi2 image tham mvo's 4-February?
<popey> jdstrand: against what? apparmor?
<jdstrand> popey: I don't know how to solve /var/cache/fontconfig either. I think we need a desktop person to comment
<ogra_> qengho, just build one yourself :)
<qengho> Ah, ogra, you have a pi3 image! That's better.
<jdstrand> popey: cause allowing 'w'rite access to a directory that the user can't write to is wrong (/var/cache/fontconfig/ unix perms won't allow writing to it)
<jdstrand> popey: no, against snapd
<qengho> Hmm, build one myself. Okay!
<jdstrand> the interface needs to be updated
<jdstrand> popey: ((almost) all apparmor policy is in snapd now)
<ogra_> qengho, sudo ../ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux --gadget canonical-pi2  -o test.img
<ogra_> (with the latest u-d-f from mvo's all-snaps dir
<ogra_> )
<mvo> hey jdstrand, good morning
<jdstrand> mvo: oh yes, you had something for me to look at
<jdstrand> mvo: hi!
<mvo> ogra_: with todays upload we should be able to do new images (once that upload is in the archive and we have os snaps from it)
<mvo> jdstrand: yeah, no rush, its probably a sru at this point
<ogra_> mvo, is enable-classic gone completely now ?
<mvo> ogra_: just disabled for now, will come back RSN
<ogra_> (thats rather bad for developers i guess)
<ogra_> ok
<mvo> yes, sorry, scarifices had to be made
<ogra_> heh
 * ogra_ wishes they had been made a month or two ago :P )
 * mvo hugs ogra_
 * ogra_ hugs mvo 
<popey> jdstrand:
<popey> gah, jdstrand https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1570860
<ubottu> Launchpad bug 1570860 in snapd (Ubuntu) "Love2D needs udev access" [Undecided,New]
<zyga> jdstrand: ubuntu-calculator-app works
<jdstrand> zyga: works in developer and does not without developer?
<zyga> jdstrand: developer mode
<jdstrand> nice
<jdstrand> niemeyer, zyga: fyi, bug #1570860. while we can talk about the bug itself, I wanted to nail down the process for updating/adding interfaces. should there be a bug tag (eg, snapd-interfaces?). If a tag, we should all three of us subscribe to it
<ubottu> bug 1570860 in snapd (Ubuntu) "Love2D needs udev access" [Undecided,New] https://launchpad.net/bugs/1570860
<kyrofa> mvo, is SNAP_ARCH stable in the wrappers? And available on the desktop?
<zyga> jdstrand: do we do anything with the device cgroup when we see @complain ?
<zyga> jdstrand: as in, not jail the process from real devices?
<jdstrand> zyga: no. @complain is a seccomp only thing like '(complain)' is an apparmor thing
<mvo> kyrofa: yes, its fine, we do not plan to change the environment vars at this point, if its not in the deprecated sections its golden
<zyga> jdstrand: right, so developer mode will be incomplete
<zyga> jdstrand: for lots of stuff :/
<zyga> jdstrand: I just tried it and a sample game doesn't start
<zyga> jdstrand: what could we do to make that work still?
<jdstrand> zyga: each security subsystem will need to do its own complain thing. a simple way to do it with udev is to comment out the rules in /etc/udev/rules.d/... for the app in complain mode
<zyga> jdstrand: I don't understand how that would work, can you give me an example/
<zyga> jdstrand: as in, how can I put *all* devices into a cgroup/
<zyga> jdstrand: so that effectively, the app can always open anything in /dev
<jdstrand> don't do that
<jdstrand> remove the cgroup handling
<zyga> jdstrand: wait, there is no cgroup handling right now
<zyga> jdstrand: we don't make a default udev rule
<jdstrand> remember, cgroups are only used if there is a udev assignment for the app in /etc/udev/rules.d
<zyga> AAAH
<jdstrand> zyga: right
<zyga> okay
<zyga> hmm, that's worrying then :)
<jdstrand> so, complain mode is simply comment those rules
<zyga> because the app still doesn't work
<zyga> but at least I will see why
<zyga> thanks for explaining thta!
<jdstrand> np
<kyrofa> Thanks mvo :)
<jdstrand> is there an image with ubuntu-core-launcher 1.0.25.1?
<jdstrand> mvo: maybe that is a question for you ^
<jdstrand> zyga: are there denials? how is the app complaining?
<mvo> jdstrand: the latest ubuntu-core snap should have it, let me double check. you can build the image yourself or I can upload one
<zyga> jdstrand: the app just doesn't start
<zyga> jdstrand: it's an opengl/openal game
<zyga> jdstrand: as for syslog...
<zyga> one sec
<mvo> jdstrand: hm, not yet, let me build one
<jdstrand> zyga: in addition to syslog, application output
<zyga> jdstrand: no app output
<zyga> jdstrand: I'd have to trace it to see
<zyga> jdstrand: one sec
<jdstrand> zyga: is there a seccomp kill?
<jdstrand> perhaps you don't have seccomp 1.0.25.1
<jdstrand> err
<jdstrand> ubuntu-core-launcher 1.0.25.1
 * jdstrand is wildly guessing
<zyga> jdstrand: http://pastebin.ubuntu.com/15849375/
<jdstrand> zyga: what game?
<zyga> jdstrand: FEZ
<zyga> jdstrand: I have a snap if you want to see it in private
<jdstrand> yes, that would be good. between that and mvo's image, I can help
<mvo> zyga: opengl? you are not on an nvivia system, are you?
<zyga> mvo: I am
<zyga> mvo: ah, I need something fresher (core?)
<jdstrand> also, I noticed that the opengl interface doesn't have a test case
<mvo> zyga: nvidia (with nvidia proprietary drive)
<davidcalle> zyga: do you happen to have a snapcraft.yaml for it?
<zyga> mvo: with free drivers
<mvo> zyga: ok, that should work, let me try that
<zyga> davidcalle: yes but it depends on having access to FEZ binary from humble bundle
 * zyga should find a smaller example
<davidcalle> zyga: yeah, I imagine, but it will be a great desktop example for dev.ubuntu.com, please share :) (I don't need the bin - I have it)
<zyga> davidcalle: sure
<zyga> davidcalle: I plan to snap about a dozen games I have
<mvo> jdstrand: I have not looked at the tests in detail but when I looked last I found them to be duplicating what was already tested in the commonInterface code, i.e. nothing new was tested but maybe that has changed from when I looked last
<davidcalle> zyga: :)
<zyga> davidcalle: http://paste.ubuntu.com/15849436/
<zyga> davidcalle: there's also a setup/ directory with
<zyga> oh
<zyga> i wonder if we generate desktop files
<davidcalle> zyga: we supposedly do, haven't seen one, though
<zyga> yep
<zyga> I don't see one either
 * zyga looks at what is needed
<zyga> davidcalle: I'll share it when I have something really working :)
<davidcalle> zyga: sure :)
<jdstrand> mvo: I think that might be a discussion point for interface development
<zyga> mvo: I think that we could drop most of the tests for commonInterface-using interfaces
<mvo> jdstrand: yeah, happy to talk about it when the releas e is out
<mvo> zyga: that was my feeling too, but its not important at this point :)
<zyga> yep
<mvo> just wanted to explain why I did not add new ones for this particular code
<mvo> zyga: hm, the opengl using snap, could you push that somewhere?
<mvo> zyga: so that I can try to reproduce the issue you see?
<zyga> mvo: I use git to manage i, do you have a place I can stick a 350MB git repo?
<zyga> a private launchpad git repo perhaps
<mvo> zyga: hmmm, let me think for a sec
<zyga> could be useful for storing games for development
<zyga> this just for work *cough*
<zyga> ;-)
<popey> zyga: might be worth snappifying open source ones first
<popey> rather than going for ones that are hard for others to contribute to
<mvo> dholbach: could someone upload a new ubuntu-clock-app with the unity7,opengl interfaces ? that would be great
<niemeyer> jdstrand: Having a tag sounds good
<mvo> dholbach: and same for the calculator
<zyga> popey: this was just a personal snap, I agree that using an open source one would be better but this one was useful for me and I had the game around; I'm not aware of any open source games actually (except openttd which is heavy on plugins)
<popey> I've been snappifying a few
<zyga> mvo: calculator now works with --devmode :)
<ogra_> tuxracer :)
<popey> zyga: in fact I find it preferable to hit things that have bigger impact, like frameworks
<popey> or emulators
<popey> because they add multiple games all at once.
<popey> e.g. MAME and Love2D are the ones I looked at.
<popey> along with Minetest
<zyga> popey: I totally agree :)
<popey> should my app have read access to $SNAP?
<popey> because I put an ini file in there, but the app can't seem to see it. no apparmor denials
<zyga> I think snapcraft has a bug somewhere
<zyga> http://paste.ubuntu.com/15849583/
<zyga> this is find . from the snap/ directory
<zyga> what is $HOME/.../lib and lib64 doing there?
<zyga> any snapcraft hackers around ^^^
<mvo> zyga: nice
<jdstrand> niemeyer, zyga: I added 'snapd-interface' to the bug. I just went to https://bugs.launchpad.net/ubuntu/+subscriptions and added a subscription to subscribe to the snapd-interface tag
 * jdstrand does the same for https://bugs.launchpad.net/snappy/+subscriptions
<zyga> jdstrand: how do I do that?
<zyga> jdstrand: I don't see anything reltated to tags there
<zyga> jdstrand: ah, I see
<zyga> :)
<jdstrand> zyga: select 'are added or changed in any way', then select 'bug must match this filter'
<zyga> jdstrand: yep, I got that now
<zyga> neat
<zyga> I've been using launchapd since day one and I never sawthat
<jdstrand> yeah, it wasn't there on day one :)
<jdstrand> I forget when it came along, but I jumped on it when it did
<zyga> snapcraft also generated this wrapper:
<zyga> export LD_LIBRARY_PATH="$SNAP$SNAP/fez/lib:$SNAP$SNAP/fez/lib64:$LD_LIBRARY_PATH"
<zyga> note the $SNAP$SNAP
<zyga> 2nd snapcraft bug, the game may not launch simply because of those things
<popey> davidcalle: got 5 mins to cast an eye on my mamedeb snap (latest snappy-playpen)? Dunno what I'm doing wrong here
<popey>  /snap/mame/0/bin/launcher: 14: exec: /snap/mame/0/usr/games/mame -v -inipath /snap/mame/0: not found
<morphis> jdstrand, zyga: started to confine network-manager now, but also getting
<morphis> Apr 15 14:09:02 localhost.localdomain ubuntu-core-launcher[1180]: appname snap.network-manager.NetworkManager not allowed
<davidcalle> popey: looking
<morphis> jdstrand, zyga: suspect there is something wrong with the name but don't see what
<jdstrand> hmm
<jdstrand> can I see your snap yaml?
<zyga> morphis: you cannot use dashes?
<jdstrand> dashes have always been allowed
<zyga> morphis: ah, no
<morphis> jdstrand: sure
<qengho> I use dashes. Confirmed they work.
<zyga> morphis: all-lowr-case
<zyga> morphis: use network-manager
<zyga> morphis: and perhaps cli as 2nd ap
<kyrofa> zyga, looks like whatever you snapped has an ldd linking to that lib, so snapcraft copied it in for you
<zyga> morphis: this will give you network-manager (just like that) as the main app and network-manager.cli as a 2nd app
<morphis> zyga, jdstrand: https://paste.ubuntu.com/15849745/
<zyga> kyrofa: via rpath?
<zyga> kyrofa: thanks, that's neat, just unexpected :)
<kyrofa> zyga, the strip step crawls ldd
<kyrofa> for every elf
<jdstrand> const char *whitelist_re = "^[a-z0-9][a-z0-9+._-]+$";
<jdstrand> we aren't allowing caps
<morphis> I see
<morphis> but if I remember well that worked before
<qengho> "x----------------" is okay?
<morphis> so the calculate of the appname must have changed
<jdstrand> it may have
<zyga> qengho: no, AFAIR it won't be allowed by snappy itself
<kyrofa> zyga, yeah in most cases if you're using library-only stage-packages you can get rid of them and just use the -dev as a build-package and it'll be taken care of
<zyga> kyrofa: this is a prebuilt game
<zyga> kyrofa: I'm just packaging the binary bits as they are
<morphis> jdstrand: thanks
<qengho> zyga: is that wildcat, proof of concept, or Officialâ¢?
<zyga> qengho: ?
<kyrofa> zyga, mind pastebining ldd of whatever is linking to fez/lib/libmono?
<qengho> zyga: that F game. Just curious.
<zyga> qengho: ah, just a private snap for local testing
<zyga> qengho: faster then downloading snaps all the time
<jdstrand> morphis: so, right now use lower case
<jdstrand> docs/meta.md is silent on the issue of if caps should be allowed
<jdstrand> (for 'command')
<zyga> kyrofa: http://paste.ubuntu.com/15849806/
<morphis> jdstrand: ok
<zyga> kyrofa: looking at the elf file now...
<zyga>  0x000000000000000f (RPATH)              Library rpath: [$ORIGIN/lib64]
<zyga> hah
<kyrofa> zyga, yeah, is that an rpath with origin?
<kyrofa> Ah
<zyga> so $ORIGIN is fooling snapcraft
<zyga> :D
<kyrofa> Indeed it is
<kyrofa> Please log that bug
 * zyga loves quirky elf features
<kyrofa> Though I'm curious how we're going to deal with that...
<zyga> kyrofa: there are more things like ORIGIN :)
<zyga> kyrofa: I'd readelf the header myself
<kyrofa> zyga, yeah we may have to
<davidcalle> popey: when building the launcher part: No such file or directory: '/home/david/Desktop/snappy-playpen/mame/mamedeb/parts/launcher/build/mame.ini'
<zyga> kyrofa: or assume that $ORIGIN expands to $(cwd) and undo the translation
<zyga> anyway, I need to focus on my last branch for snappy today that's not started :
<zyga> kyrofa: on github or lp?
<kyrofa> zyga, LP please
<davidcalle> popey: do you have a mame.ini you need to bzr add?
<jdstrand> so, validateField is not correct for command
<kyrofa> zyga, https://bugs.launchpad.net/snapcraft
<popey> davidcalle: ahh, balls i need to add that to bzr
<popey> one moment
<davidcalle> popey: no bin/launcher either
<morphis> zyga: are dashes allowed in interface names?
<zyga> morphis: yes
<morphis> ok
<popey> davidcalle: it's launcher, it gets copied to bin/launcher
<popey> it is there
<davidcalle> Oh right :)
<popey> davidcalle: pushed mame.ini
<davidcalle> ack
<popey> davidcalle: note the app works fine if you run it manually, outside of confinement with "/snap/mame/0/usr/games/mame -v -inipath /snap/mame/0"
<zyga> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1570895
<ubottu> Launchpad bug 1570895 in Snapcraft "Rpath with $ORIGIN fools snapcraft library bundling mechanism" [Undecided,New]
<kyrofa> Thanks zyga :)
<zyga> kyrofa: my pleasure :)
<zyga> I'd like to snap my collection of GOG games
<zyga> I think that would be a nice demo for some people
<kyrofa> ogra_, if I were cross-compiling an s390x kernel what would I use as the ARCH? Just s390x?
<qengho> Where's the bugtracker for myapps site?
<davidcalle> popey: same error hee, your launcher lgtm :(
<qengho> Oh, nevermind.
<popey> davidcalle: odd, isn't it?
<ogra_> kyrofa, i guess so
<kyrofa> ogra_, how about the triplet on that system?
<ogra_> i have no clue :)
<ogra_> ask xnox perhaps
<kyrofa> ogra_, heh. I've never even heard of this arch :P
<ogra_> its a big black cabinet ;)
<kyrofa> Hahaha
<jdstrand> morphis (fyi mvo): bug #1570914
<ubottu> bug 1570914 in snapd (Ubuntu) "inconsistent apps/key validation" [Undecided,New] https://launchpad.net/bugs/1570914
<xnox> kyrofa, $ dpkg-architecture -as390x
<kyrofa> xnox, perfect thank you :)
<xnox> kyrofa, also note the https://wiki.debian.org/ArchitectureSpecificsMemo
<kyrofa> xnox, favorited
<kyrofa> ogra_, any chance you're in a position to try out a snapcraft branch?
<kyrofa> ogra_, or is it all automated?
<ogra_> i have no idea how you guys land snapcraft usually :)
<ogra_> if there is a PPA build, we can copy it into the image PPA to do a test build
<ogra_> (of an image)
<kyrofa> ogra_, we just land to xenial universe nowadays
<ogra_> well, the image PPA is my onlÃ¶y way to inject something into the build
<kyrofa> ogra_, can I download whatever you're trying to snap?
<kyrofa> Oh but it's running on a different arch, scratch that
<ogra_> right
<ogra_> it runs natively on x390s
<ogra_> to test it we need to upload a newer snapcraft to the PPA and run an image build
 * kyrofa wishes he had ssh access to one machine of every arch we support
<jdstrand> beuno: can someone pull r630 to the store for bug #1570914
<ubottu> bug 1570914 in ubuntu-core-launcher (Ubuntu) "inconsistent apps/key validation" [High,Confirmed] https://launchpad.net/bugs/1570914
<jdstrand> beuno: any time before release is fine
<code1o6>  Hey guys I'm looking for manik
<code1o6> has anyone seen him
<beuno> roadmr, ^^^
<roadmr> let's see
<roadmr> beuno, jdstrand : sure, I'll get that rolling. It being a Friday, is it OK if this hits prod on e.g. Monday?
<beuno> roadmr, yeah, of course
<kyrofa> ogra_`, mind taking a look at https://github.com/ubuntu-core/snapcraft/pull/461 when you're able? Just to make sure those values look sane
<roadmr> ok, working on it
<ogra_`> kyrofa, hmm, dont you still want the gcc- prefix there ?
<kyrofa> ogra_`, for the prefix? Isn't is the prefix _before_ "gcc" ?
<ogra_`> (also, isnt it powerpc64el ?)
<ogra_`> err
<ogra_`> le
<ogra_`> i see gcc-powerpc-linux-gnu gcc-powerpc64le-linux-gnu (on wily though)
<kyrofa> ogra_`, yeah I get these from gcc-powerpc64-linux-gnu on xenial... but you're right, there are others as well
<kyrofa> Hmm...
<ogra_`> apt-cache search linux-gnu|grep ^gcc-[a-z]
<kyrofa> ogra_`, yeah you're right
<kyrofa> ogra_`, I need the el/le whatever one
<ogra_`> yeah
<kyrofa> Good catch!
<ogra_`> :)
<kyrofa> The rest look okay?
<ogra_`> is there more than the one line ?
<kyrofa> ogra_`, mainly the s390x entry
<ogra_`> oh ... wasnt on the discussion page
<kyrofa> ogra_`, here: https://github.com/ubuntu-core/snapcraft/pull/461/files#diff-4ce66781f48931ad7dc4792aaf9cbf9aR58
<mvo> thanks jdstrand! are you on a fix for this already or shall I have a look?
<kyrofa> ogra_`, now that I know the ppc stuff is totally broken I'll extract into another bug
<ogra_`> kyrofa, the s390x part looks ok to me
<kyrofa> ogra_`, okay very good, thank you!
<mvo> jdstrand: the latest os snap in edge has the right ubuntu-core-launcher now
<mvo> jdstrand: 1.0.25.1
<jdstrand> mvo: woohoo! thanks :)
<jdstrand> mvo: fyi, I just uploaded 1.0.26 for bug #1570914
<ubottu> bug 1570914 in snapd (Ubuntu) "inconsistent apps/key validation" [High,Confirmed] https://launchpad.net/bugs/1570914
<mvo> jdstrand: \o/
<jdstrand> mvo: there needs to be an input validation change in snapd that I wasn't planning on doing now (feel free to pick it up). see the bug for details
<jdstrand> I think with the review tools change it would be ok to pick up in sru
<jdstrand> so if you are working on urgent stuff, I suggest doing that instead
<mvo> yes, I think so too
<jdstrand> cool
<jdstrand> mvo: curious, when is udf in the archive going to be updated for all snaps?
<technocaveman> when was snappy ubuntu core released
<technocaveman> ?
<kyrofa> technocaveman, snappy ubuntu core 15.04 was released back with 15.04, but the newest version is based on 16.04 so it's technically not yet released
<technocaveman> ok thanks i just needed to know for an assignment in which i mention it !
<mvo> jdstrand: once the kernel/gadget yaml is finalized, so via an sru
<ogra_`> jdstrand, in time for 18.04 ;)
<morphis> jdstrand: thanks for filing that bug
<ogra_`> mvo, we shlould perhaps also disable the system-image stuff ... else people will use the udf from the archive and wonder why they have so broken images :)
<ogra_`> (though that can as well happen right after release)
<zyga> jdstrand: recvfrom is not in network?
<zyga> hmm, it is
<zyga> hmm
<zyga> jdstrand: kwi 15 18:32:35 zyga-thinkpad-w510 kernel: audit: type=1326 audit(1460737955.225:449): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=25760 comm="TerrariaServer." exe="/snap/terraria-server/0/TerrariaServer.bin.x86" sig=31 arch=40000003 syscall=45 compat=1 ip=0xf7786f19 code=0x0
<zyga> jdstrand: is that recvfrom or are my eyes fooling me?
<mvo> ogra_`: the one from older archives you mean? good idea. xenial is fully disabled I think
<ogra_`> mvo, yeah, we should delete the whole rolling subdir on the server though
<mvo> +1
<ogra_`> the last 16.04 images there are from jan 12 :)
<jdstrand> zyga: recvfrom is in x11, bluez, firewall-control, network-bind, unity7 and network
<zyga> jdstrand: yep, I've checked
<jdstrand> zyga: scmp_sys_resolver 45
<jdstrand> recvfrom
<zyga> jdstrand: hmm
<jdstrand> this is on amd64?
<jdstrand> seems something didn't connect?
<zyga> jdstrand: no, it connected, it was in the generated profile
<zyga> jdstrand: anyway, ignore this
<zyga> jdstrand: we'll tweak this later
<jdstrand> morphis: np
<morphis> jdstrand: working my way now through getting the network-manager snap back working, will come with some questions next week :-)
<jdstrand> great :)
<jdstrand> mvo: fyi, I just tried ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160415-bbb.img --gadget canonical-bbb --kernel canonical-bbb-linux --os ubuntu-core stable. is that supposed to work?
 * jdstrand wonders what --size should be with bbb and rpi2 images
<jdstrand> ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160415-pi2.img --gadget canonical-pi2 --kernel canonical-pi2-linux --os ubuntu-core stable didn't work either
<jdstrand> I feel like I'm looking in the right part of the store...
<jdstrand> oh maybe those need .canonical?
<jdstrand> oh, no, I used 'stable' by mistake
<jdstrand> nm
<jdstrand> actually, --gadget canonical-bbb --kernel canonical-bbb-linux doesn't work
<popey> are we going to get an official rpi3 image soon?
<zyga> popey: ogra said "maybe"
<jdstrand> mvo: both canonical-bbb and canonical-bbb-linux are in the store but seems they aren't published (they show yellow instead of green in the Progress column)
<ogra_> popey, well, images are still a post 16.04 thing since gadget and kernel will be completely re-designed
<ogra_> i might update it next week though
<ogra_> (the one we have)
<popey> awesome.
<popey> look forward to updating my pis
<kyrofa> ogra_, you still around?
<ogra_> yep
 * ogra_ is upgrading his laptop to xenial ... i might unconditionally disconnect from my ircproxy :) 
<kyrofa> ogra_, I want to test out the kernel plugin. Any chance you know of a tree already setup for building kernel snaps that I can clone?
<ogra_> only the 96boards one that is used in the example
<kyrofa> ogra_, yeah that's the only one I know of as well
<ogra_> but theoretically any kernel tree should work, no ?
<kyrofa> Theoretically, yes
<kyrofa> I'll go download the firmware for the 96boards one, since it's a known working one
<ogra_> yeah
<ogra_> bah, crap
<ogra_> no more xchat in xenial !
 * ogra_ has to live with the uglyness of xchat-gnome :((((
<kyrofa> ogra_, nooooo
<ogra_> crap ...
<kyrofa> ogra_, any idea why?
<ogra_> i think it is dead upstream and nobody ported it to a recent gtk version
<kyrofa> Ah, too bad
<mdeslaur> ogra_: try hexchat, it's an xchat fork
<ogra_> this gnome thing has really to much white around it for my taste
<ogra_> mdeslaur, will it just read my old config ?
<mdeslaur> ogra_: I'm not sure, perhaps just need to rename the directory
 * mdeslaur uses xchat-gnome
 * ogra_ hugs mdeslaur 
<ogra_> copying some files around and i have my old colorscheme in hexchat
<mdeslaur> nice
<zyga> hexchat?
<zyga> ogra_: have you tried snapping it?
<ogra_> heh, no
<ogra_> hmm, a bit irritating that it actually adds real transparency ... xchat only had a fake mode
<ogra_> suddenly there are icons :P
<ogra_> (the few on my desktop)
<mvo> jdstrand: yes, we have no canonical-bbb, just a beagleblack.mvo
<jdstrand> mvo: huh, I saw something called canonical-bbb in the store
<ogra_> jdstrand, not published
<ogra_> it idles around there along with a bunch of other zombies
<ogra_> (under the shared store account)
<ogra_> sadly there is no remove button in the UI ...
<jdstrand> I see
<jdstrand> ogra_: is there a bbb kernel snap?
<ogra_> jdstrand, the generic armhf one
<ogra_> grmpf ... so virtulbox doesnt run anymore
<jdstrand> cool, I'll update our docs
<ogra_> dunno what the exact name is now
<ogra_> http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/xenial-preinstalled-core-armhf.kernel.snap would be the input file for it
<mvo> jdstrand: yes, I uploaded it without knowing that we do not want it with this publisher
<mvo> jdstrand: and yeah, I wish there was a remove button
<ssweeny> It seems the snappy-debug snap needs to be updated: ubuntu@localhost:~$ sudo snap install snappy-debug
<ssweeny> [-] Mount snap "snappy-debug"
<ssweeny> error: cannot perform the following tasks:
<ssweeny> - Mount snap "snappy-debug" (info failed for /tmp/snappy-debug383863688: open /tmp/read-file693482311/unpack/meta/snap.yaml: no such file or directory)
<jdstrand> ogra_, mvo: ok (sorry, just trying to update the security team's documentation): this generated an image (didn't try to boot yet): ../udf/ubuntu-device-flash core --size=8 --enable-ssh --channel=edge --output=snappy-20160415-bbb.img --gadget beagleblack --kernel ./xenial-preinstalled-core-armhf.kernel.snap --os ubuntu-core rolling
<jdstrand> ogra_, mvo: great! I was wondering if ./xenial-preinstalled-core-armhf.kernel.snap is in the store?
<mvo> jdstrand: there is linux-armhf(.mvo ) in the store
<mvo> jdstrand: that should work, not sure how recent it is though, I'm a bit behing with the image maintenance
<jdstrand> mvo: sure, that's fine
<jdstrand> mvo: do we expect linux-armhf to be regularly updated once things settle down?
<ogra_> mvo, do i need to generate a different snap.yaml so you can use the cdimage snap ?
<mvo> ogra_: probably, it does not have to be linux-armhf.mvo, it could be anyoneâ¦
<josepht> mvo: you should be able to at least unplublish it, right?
<mvo> jdstrand: a good question
<mvo> jdstrand: I think so, but having something group maintained would be much better
<mvo> josepht: yes, I can unpublish it
<jdstrand> mvo: iirc, that is something of a community kernel. it seems that if there was automation that took security updates to the Ubuntu generic kernel and autosnapped these linux-foo kernels, that could be pretty painless for you and useful for people
<ogra_> jdstrand, that is what the cdimage snaps are for
<ogra_> there is just no autoupload yet
<jdstrand> ogra_: ah, sounds like it is all in hand then :)
<jdstrand> nice :)
<mvo> jdstrand: yeah, exactly, its just a manual upload at this point
<jdstrand> we are getting out of the me documenting things and into I'd like to use my bbb territory here :)
<ogra_> elopio sid he has an easy jenkins way of uploading ... still need to talk to him about that
<jdstrand> ok, well, it is late where you are-- don't let me distract you
<jdstrand> have a nice rest of the evening and weekend ogra_ and mvo :)
<ogra_> thanks, you too !
<mvo> jdstrand: thanks, you too!
 * mvo hugs jdstrand
 * jdstrand hugs mvo and snaps ogra_ in the process
<jdstrand> :)
<ogra_> :)
<jdstrand> oh heh
<jdstrand> snags*
<jdstrand> clearly I have been doing a lot of snappin' lately :)
<ogra_> we all have :)
<seb128> mvo, hey, is snap install supposed to create a .desktop in /var/lib/snappy/desktop? it doesn't do it it seems but I don't know if that regressed or if that should only be done when using the UI
<mvo> seb128: its in /var/lib/snapd/desktop nowdays
<mvo> seb128: which means we need to update our XDG bit, dang. thanks
<seb128> mvo, XDG_DATA_DIRS has the wrong value then
<seb128> right
<seb128> yw!:
<seb128> mvo, also it doesn't seem to work, I installed "ubuntu-calculator-app" and don't have any .desktop in there
<mvo> seb128: fix on the way
<seb128> the dir exists but is empty
<mvo> seb128: I suspect the calculator is not shipping an desktop file
<seb128> mvo, it does
<mvo> seb128: try sudo snap install cap-test
<mvo> seb128: the desktop file needs to be in meta/gui/
<mvo> seb128: https://github.com/ubuntu-core/snappy/blob/master/docs/meta.md#dekstop-files
<seb128> mvo, find says it has /snap/ubuntu-calculator-app/2/usr/share/applications/ubuntu-calculator-app.desktop
<mvo> seb128: https://github.com/ubuntu-core/snappy/pull/1003
<seb128> mvo, I see
<mvo> seb128: yes, wrong location, sorry
<mvo> seb128: we can fix this in the desktop-examples branch probably before the release
<mvo> seb128: cap-test is a good example, small, simple and should fully work
<mvo> (just not very sexy)
<seb128> mvo, yeah, indeed works
<seb128> oh well, that was not pointless
<seb128> we found the wrong XDG env
<seb128> mvo, thanks for fixing!
<mvo> seb128: yeah, absolutely, thanks a ton for this
 * mvo hugs seb128
<seb128> yw :-)
 * seb128 hugs mvo back
<dpm> seb128, mvo, the calculator app does not ship a desktop file via snapcraft. I didn't get to put it under meta/gui. What it is incidentally shipping is the desktop file built as part of the upstream build, but that's as you've noticed in the wrong place
<seb128> dpm, right
<jdstrand> hrm
<jdstrand> the network-bind plug isn't autoconnecting
<jdstrand> this might've been what zyga was seeing
<jdstrand> and I can't seem to make snap connect do what I want
<jdstrand> I'll followup on monday
<willcooke> in theory.... could SDoC work on Vivid
<seb128> willcooke, define "theory", if vivid was updated to xenial? ;-)
<kyrofa> seb128, hahaha
<kyrofa> willcooke, I think it's pretty systemd heavy. That wasn't in vivid, was it?
<willcooke> yeah it's in there
<seb128> right, which is my comment about updating to xenial
<seb128> it's not recent enough for snappy iirc
<willcooke> kgunn ^
<seb128> would need never kernel/systemd
<kgunn> ack
<seb128> newer even
#snappy 2016-04-16
<netphreak> hi, guys!
<Matesito> hey guys, a quick question: where can I find the most up to date roadmap for Ubuntu Snappy Core development? I've found the trello board, is it still in use? https://trello.com/b/L9aazEwO/snappy-core-roadmap
<popey> Matesito: i dont think that trello board is used anymore
 * ogra_ hugs kyrofa 
<pmp> I'm trying to build an updated version of a rpi2 image, but I don't know how ;-)
<pmp> I have this shell script which worked beginning of March
<ogra_> you grab the ubuntu-device flash from http://people.canonical.com/~mvo/all-snaps/ ...
<pmp> done
<ogra_> sudo ../ubuntu-device-flash core rolling --channel edge --os ubuntu-core --kernel canonical-pi2-linux  --gadget canonical-pi2 -o test.img
<ogra_> that creates test.img from the latest bits in the store
<ogra_> err
<ogra_> sudo ./ubuntu-device-flas
<ogra_> (one dot)
<ogra_> if you want it even newer you can grab the daily snaps from http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/ ...
<ogra_> xenial-preinstalled-core-armhf.os.snap instead of ubuntu-core for the --os arg ... and xenial-preinstalled-core-armhf.raspi2.kernel.snap instead of canonical-pi2-linux for --kernel
<ogra_> (note that wont be upgradeable though)
<pmp> I was so close, thx, I ran: --os ubuntu-core.canonicalll
<pmp> -ll
<pmp> running your command fails with failed to install "canonical-pi2" from "edge": canonical-pi2 failed to install: exit status 2
<pmp> I'm sure I'm missing a tool on my installation, but which ...
<pmp> http://paste.ubuntu.com/15875972/
<pmp> how could I have possibly found the names for the os, gadget and kernel snap?
<pmp> I mean canonical-pi2-linux
<daker> hi ogra_ does the snappy rpi2 works on the rpi3 ?
<daker> snappy img*
<pmp> it's failing with the images from cdimages as well
<ogra_> daker, the latest one should, yes
<ogra_> (i.e. if you buld one yourself )
<daker> ah :D
<daker> then i'll just use the rpi2
<ogra_> there is also http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/
<daker> i see
<daker> ogra_:  "dd: opÃ©rande Â«syncÂ» non reconnu", anyidea ?
<daker> sync unknown operand :/
<ogra_> sync ?
<ogra_> what was the exact command you used to get that ?
 * ogra_ always uses:
<ogra_> xzcat /path/to/img.xz | sudo ss of=/dev/sdc bs=64M
<ogra_> err
<ogra_> xzcat /path/to/img.xz | sudo dd of=/dev/sdc bs=64M
<ogra_> not sure where you get that sync error (or why you would)
<daker> the docs says : xzcat ubuntu-15.04-snappy-armhf-raspi2.img.xz | sudo dd of=/dev/sdc bs=32M sync
<ogra_> that seems broken
<ogra_> you can call sync ... but only after dd finished
<daker> https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<daker> ah
<ogra_> and on that page the sync is indeed on a new line :)
<daker> so i think they should add $ to the begin of each command
<ogra_> yeah
<daker> i though that it's one command
<vijaikumar> hey fellas. any python project samples / tutorials for getting started ?
<ogra_> in the snapcraft-examples package
<vijaikumar> tks
<daker> ogra_: my snappy installation doesn't seem to connect via wifi
<daker> even via a simple hotspot
<daker> wlan0 doesn't appear on the list of devices
<daker> hmm wlan0 doesn't appear on the list of devices
<claudioandre> Hi guys, I'm building a new package and I have some doubts. For example, I have one bin and one docs folder. The way to deal with it is using filesets?
<claudioandre> I'm posting an example
<claudioandre>     filesets:
<claudioandre> binaries:
<claudioandre> - build/run/*
<claudioandre> docs:
<claudioandre> - build/docs/*
<claudioandre> stage:
<claudioandre>   - $binaries
<claudioandre>   - $docs
<claudioandre> snap:
<claudioandre>   - $binaries
<claudioandre>   - $docs
<jsejcksn> Quick Q: Does anyone know the status of snappy on RasPi 3?
<jsejcksn> Or where I can find more info about progress?
<claudioandre> Is this the right way to go? I mean, a good approach to create/install a doc folder + the bin folder ?
<daker> jsejcksn: https://paste.ubuntu.com/15882535/
<jsejcksn> daker: Thanks for the link. What does it mean "if you buld one yourself"?
<daker> build the image yourself
<daker> from the sources
<jsejcksn> Like build on a Pi 3?
<jsejcksn> So the image won't work, but building a new one will as long as I build on the Pi 3?
<jsejcksn> daker: is the link in the paste that you sent me a working image or do I need to build it myself?
<daker> jsejcksn: well i think you have to build one or just wait for the release day i guess
<daker> jsejcksn: ogra_ can give you more details when he is back
<jsejcksn> daker: OkâI'll check back later. Thanks for the lead.
<daker> yw
<ogra_> daker, yeah, sorry, the wlan firmware is still missing
<ogra_> you need to use wired network for the moment
<daker> ogra_: ah that's why :D
<jsejcksn> ogra_: If I use the image at http://people.canonical.com/~ogra/snappy/all-snaps/rpi3/ then everything will work except wifi... and bluetooth?
<ogra_> jsejcksn, except that it is rather outdated, yes
<jsejcksn> ogra_: ok, cool. Thanks
<jsejcksn> Cheers, guys
<ogra_> i'd recommend following the README to get something newer
<ogra_> (note i just updated it since the command was outdated too)
<claudioandre> Anyone has a working snapcraft.yaml that has a doc folder (plus a readme file)? All examples in github seems very simple. Thanks
<claudioandre> Ladies and gentleman, I need to make a silly question. Please, point me where is the best place to put such a question.
<claudioandre> I can go up to a 'snapcraft build'. Everything works fine. Now, I need to tell wich files have to be used/copied to the final package.
<claudioandre> I can't tell wich files to use. I'm really sorry, it is a 'read the documents stupid' question, I know.
#snappy 2016-04-17
<claudioandre> I tried to use the copy plugin, but it tries to find the files in the wrong place.
<claudioandre> If i try to use the 'source:', it creates a symlimk, and things doesn't work.
<claudioandre> What I need to do is pretty simple.
<claudioandre> Inside parts/<part-name>/build/run I have a few executables I need to package.
<claudioandre> And Inside parts/<part-name>/build/doc I have a few text files.
<claudioandre> Please, point what I have to read, or a more complex example to guide me.
<claudioandre> Thank you!
<claudioandre> I cheated and I got a package (I would love to hear how smart people solve this). But, have anyone seen this before?
<claudioandre> Developer profile is missing short namespace
<popey> claudioandre: might want to come back during the european / us working week
<popey> it's quiet here in the late night weekends
<claudioandre> Ok, thank you.
<popey> claudioandre: alternatively post your question on askubuntu and tag it ubuntu-core
<claudioandre> Ok
<netphreak> hi, guys!
<netphreak> Anyone know how i use the copy plugin to copy from a local maven repository - using a path like this:
<netphreak> ~/.m2/repository/
<netphreak> i keep getting "local source is not a directory" error
<netphreak> hi, guys!
<guest0915362> hi
<guest0915362> could anyone of the snap related devs please go into the KODI forums and help convincing the KODI devs to switch from PPAs to Snap packages
<guest0915362> ?
<guest0915362> here's the thread:
<guest0915362> http://forum.kodi.tv/showthread.php?tid=269812
<guest0915362> as you can see, they seem to think Snaps make no sense or whatever
<guest0915362> ...
<guest0915362> would be nice if someone could help out
#snappy 2017-04-10
<tvoss> good morning
<morphis> tvoss: morning!
<tvoss> o/
<tvoss> @pedronis happy new week :) would be great if you would find some time for https://github.com/snapcore/snapd/pull/3130
<nothal> tvoss: No such command!
<mup> PR snapd#3130: overlord/devicestate: switch to keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<Mirv> thresh: ah, good that it's reported. I believe it may require some snapcraft changes to be able to properly bypass the problem, like having conditional packages.
<stub> /usr/lib/snapd/snap-confine: error while loading shared libraries: libudev.so.1: failed to map segment from shared object
<stub> ^^ anyone know what is going on there?
<stub> Inside a xenial lxd container, hosted under xenial
<stub> Its a classic snap, so it should certainly be able to access stuff. And the same snap was working two weeks ago.
<mup> Bug #1681328 opened: classic snap now failing with udev errors <Snappy:New> <https://launchpad.net/bugs/1681328>
<seb128> morning distro
<zyga> good morning seb128
<seb128> hey zyga ;-)
<seb128> distro->snappy (in fact I was typing on another channel, don't do that when xchat-gnome loads, it moves focus to newly joined channel as it does)
<zyga> hey ara
<ara> hey zyga
<tvoss> zyga: good morning. I'm seeing a test failure for main/static, with the test complaining about CGO being unexpected for overlord/devicestate. where would I need to adjust the build/test setup to change that expectation?
<zyga> tvoss: good morning
<zyga> tvoss: not sure I understand, can you please post a log?
<zyga> mvo: good morning
<tvoss> zyga: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170410_072000_9284e@/log.gz
<mvo> hey zyga
<zyga> tvoss: hmmm
<zyga> tvoss: I honestly don't know
<tvoss> zyga: okay, the test checks that snapd can be built without cgo. that's certainly not true anymore :)
<zyga> tvoss: ah, I just had a look at the test
<zyga> tvoss: yes, feels like something that should be removed now
<tvoss> zyga: okay, let me remove it and see what the infrastructure thinks
<pedronis> tvoss: I will look
<tvoss> pedronis: thx
<morphis> Son_Goku, zyga: looks like all packages are published now
<zyga> morphis: nice, I had issues with f26 installation on Friday but I will give it a test as well and commit the changes to ship tab completion
<morphis> zyga: what kind of issues?
<zyga> morphis: with f26 installer, not with snaps
<morphis> ah
<zyga> morphis: not sure, it would freeze; I rebooted a few times before it finished
<morphis> Son_Goku: you want to blog about this today?
<mvo> Chipaca: hey, good morning! I had a look at the hashsum issues this morning because quite a few of the current branches fail with it - I suspect we just don't handle an EOF during download not correctly, i.e. we do not set the right resume point. I think somehting like http://paste.ubuntu.com/24353432/ help - what do you think? is that something you invesitgated yet?
<morphis> zyga: if I remember well I had problems last week too with F26
<mvo> Chipaca: i.e. I hope I did not duplicate some reaseach :/
<Chipaca> mvoâ heh. I was just starting with this.
<zyga> mvo: nice!
<Chipaca> mvoâ that does seem correct to me :-)
<mvo> Chipaca: it needs a test to be certain but I don't see that we handle the seeking but maybe I'm wrong
<Chipaca> mvoâ we do a SEEK_END i think
<mvo> Chipaca: yeah, I think the problem is that we don't do the hashsum update, its some lines above. without a test just a theory for now
<mvo> Chipaca: whats funny is that all the hash errors are the same, wonder if there is a too-short file on some of the cdn server somewhere
<Chipaca> mvoâ oh?
 * zyga eats breakfast, sorry for not coding yet, I was checking email all morning
<mvo> Chipaca: e.g. https://github.com/snapcore/snapd/pull/2833#issuecomment-292874676  matches the one in https://forum.snapcraft.io/t/hashsum-failures-during-tests/198
<mup> PR snapd#2833: many: allow core refresh.schedule setting <Created by mvo5> <https://github.com/snapcore/snapd/pull/2833>
<Chipaca> mvoâ maybe it's the hash of "503 Go away I'm Comfy"
<mvo> Chipaca: haha, possible
<mvo> Chipaca: I'm writing a test, lets see how that goes
<davmor2> Chipaca: no more like Oh not you again, what do you want now?
<morphis> mvo, zyga: if I define in my spread.yaml a new system debian-9-64 is spread/linode able to spawn up a machine with the right image just with this automatically or do we need someone adding an image on the Linode setup itself?
<mvo> morphis: you will need niemeyer to create this machine for you AFAIK
<morphis> mvo: ok
<zyga> mvo: I'm not so sure, with our credentials we can spawn any machine
<zyga> morphis: just try it
<mvo> zyga: nice! I was not aware of that
<morphis> zyga: lets see ..
<morphis> zyga, mvo: https://github.com/snapcore/snapd/pull/3156
<mup> PR snapd#3156: WIP: debian support for spread testing <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<mup> PR snapd#3156 opened: WIP: debian support for spread testing <Created by morphis> <https://github.com/snapcore/snapd/pull/3156>
<zyga> morphis: do you know you can try it locally?
<zyga> morphis: with spread linode:...
<morphis> zyga: if I would have an API token, yes
<morphis> zyga: need to ask niemeyer for one
<zyga> morphis: ah, definitely
<morphis> qemu sucks for these things
<zyga> morphis: s/qemu/network at home/
<morphis> yeah both
<morphis> mvo, zyga: 2017-04-10 09:04:12 Allocating linode:debian-9-64...
<morphis> looks like its working
<zyga> morphis: I don't think qemu is any worse than linode
<mvo> morphis: nice
<morphis> ah no
<morphis> 2017-04-10 09:04:24 Cannot allocate linode:debian-9-64: no Linode image or distribution for "debian-9-64"
<zyga> morphis: quick idea: add internal snap command like `is-confined` or `is-forced-devmode` or something like that
<zyga> morphis: and use that in spread tests to skip confinement parts
<morphis> zyga: yeah I was thinking about the same
<zyga> morphis: this way we don't have to maintain the exclusion lists
<zyga> morphis: and we can really test a lot of useful functionality at the same time (only parts of each test would be skipped)
<mup> PR snapd#3152 closed: store: make hash error message more accurate <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3152>
<zyga> morphis: I think you got the ID of the system wrong, drop the kernel line and give me a sec, I'll give you the right ID
<morphis> zyga: followed what is described on https://github.com/snapcore/spread
<tvoss> zyga: would you mind restarting the travis run for https://github.com/snapcore/snapd/pull/3130
<mup> PR snapd#3130: overlord/devicestate: switch to lib(open)ssl for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<tvoss> zyga: timedout
<zyga> morphis: there's no `debian-9-64`, you can do `debian-8` (sans -64)
<morphis> zyga: were we do not support debian-8
<morphis> however worth a try
<zyga> morphis: yeah, I'm just telling you that's what is supported on linode now :/
<morphis> yeah, we may have to do our own debian-9 image
<morphis> same for fedora 24 and 26
<zyga> morphis: fedora 24 is available AFAIR
<zyga> morphis: but yeah,
<morphis> https://www.linode.com/distributions doesn't have f24
<morphis> maybe there is an outdated image still and not listed there
<zyga> morphis: https://blog.linode.com/2016/06/22/introducing-fedora-24/
<zyga> I think the distributions page is outdated
<zyga> morphis: maybe we could reach out to linode and ask
<zyga> morphis: e.g. add a debian-9 image, fedora-25 image
<zyga> morphis: maybe they will refuse
<zyga> morphis: but maybe it's cheap for them and they will just do it
<morphis> zyga: just checked, they have on for f24 but listed under "old"
<morphis> zyga: you can easily do your own images on linode
<morphis> so linode doesn't have to care at all
<zyga> morphis: it's easier if someone else cares :)
<zyga> morphis: but I think we will need our images anyway
<morphis> zyga: it is :-)
<Chipaca> mvoâ you wouldn't happen to have the whole journalctl output of one of those hashing failures would you?
<mvo> Chipaca: of course
<mvo> Chipaca: https://travis-ci.org/snapcore/snapd/builds/219559725#L1320
<mvo> Chipaca: and https://travis-ci.org/snapcore/snapd/builds/219416996#L994
<Chipaca> cheers
<mvo> Chipaca: I struggle a bit with the test, I can get a test working but I need to send enough data that the first batch of data is commited to disk so that we trigger the rety. when I do that I get a strange errTrailerEOF error when I cut the connection in the middle (might be a new go 1.7 thing, I'm on zesty :/)
<Chipaca> mvoâ how're you injecting the failure?
<mvo> Chipaca: http://paste.ubuntu.com/24353606/ is the test with a small amount of data, the amount is too small to get flushed to the local tempfile so when I check what position we are in our temp file I still get "zero"
<mvo> Chipaca: i..e I use a full mock server and close the client connections (trying to be close to the real problem)
<Chipaca> mvoâ what's missing there is that you're not setting the ContentLength, you're letting go do that
<mvo> Chipaca: I tried that too, but maybe not hard enough - let me do that again
<mvo> Chipaca: hm, making progress with the test now (yay) but look like the resume case is actually handled down below, so its not that
<Chipaca> mvoâ i think it properly is the cdn returning some error page instead of the content
<Chipaca> but I'm not sure
<Chipaca> mvoâ do we check the response status before hashing?
<mvo> Chipaca: yeah, actually I think you are right, its probably something like "range-requests are not supported"
<pedronis> that should be some 4xx though?
<pedronis> are we really not checking error codes?
<Chipaca> hence my question about whether we check the status before just hashing
<Chipaca> :-)
<pedronis> tvoss: done
<Chipaca> i'm afraid we've made the download code too smart
<pedronis> heh
<zyga> re
 * zyga is grumpy today, woke up at 5:00 AM
<zyga> why I know?
<zyga> because modem company resets modems at 5AM
<mup> PR snapd#3157 opened: store: add more logs around retry in download <Created by mvo5> <https://github.com/snapcore/snapd/pull/3157>
<zyga> and the relay clicking woke me up for some reason
<mup> PR snapd#3158 opened: store: add download test with EOF in the middle <Created by mvo5> <https://github.com/snapcore/snapd/pull/3158>
<mvo> Chipaca: my theory is wrong, I think our code is fine. unless I miss someting in -^
<tvoss> pedronis: thx
<pstolowski> mvo, thank you very much for this test! btw, just in the meantime there was a comment on this bug: https://bugs.launchpad.net/snapd/+bug/1677557
<mup> Bug #1677557: EOF not properly retried under some circumstances <snapd:Confirmed for stolowski> <https://launchpad.net/bugs/1677557>
<pstolowski> mvo, I'm going to look at provoking 'unexpected eof' in the test and retrying it
<zyga> mvo: can you have a look at https://github.com/snapcore/snapd/pull/3154
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<mvo> pstolowski: wait a sec
<mvo> pstolowski: there is a new ranch comming
<mvo> branch
<zyga> mvo: I'm trying to come up with a fix for the clashing plugs, as you know
<zyga> mvo: I was thinking about spitting this branch so that connections are in separate PR
<pstolowski> mvo, sure... not going to look at this today, maybe tommorrow-ish
<zyga> mvo: as it may not land in the end
<zyga> (specifically this one https://github.com/snapcore/snapd/pull/3154/commits/a69290f0c7836738c41da6f87f859e2971576630 )
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<mup> PR snapd#3159 opened: store: retry once on hashsum mismatches in a Download() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3159>
<mvo> pstolowski: -^
<mvo> pstolowski: but I think the EOF case in download() is hanlded, no? the test at least indicates it is
<mvo> pstolowski: or is EOF and unprovoced eof different?
<mvo> zyga: sure, I have a look after lunch, I was under the impression you are discussing this with gustavo still, what the best fix is. or is there agreement?
<zyga> mvo: gustavo discussed if the fixup function should be public or private so I made it private at his request
<zyga> mvo: as for my feeling on how this should be fixed, we can do it without touching state at all if we pull out the patch I referenced above
<mup> PR snapd#3160 opened: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160>
<zyga> Chipaca: hey, I'm seeing this timeout in completiontest
<zyga> Chipaca: is this something expected of all expect-based tests?
<zyga> Chipaca: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/amd64/s/snapd/20170406_130441_94744@/log.gz
<Chipaca> zygaâ
<Chipaca> no
<Chipaca> wtf
<Chipaca> zygaâ how does a telephone get in there
<zyga> ????
<zyga> wat?
<Chipaca> snap buy
<Chipaca> hah
<Chipaca> maybe it's my browser being silly
<zyga> browsers are like humans
<Chipaca> zygaâ there's a real bug somewhere
<zyga> we see faces in ascii, browsers see calendar events and phone numbers
<Chipaca> zygaâ expect times out when it fails to match something
<Chipaca> so all epect errors are timeouts
<Chipaca> you need to look at the output to determine what didn't match
<Chipaca> zygaâ that's the same error
<Chipaca> zygaâ that test is checking that "snap buy " tab-completes with purchasable snaps
<Chipaca> zygaâ and it's not
 * zyga reads the output carefuly
<zyga> aha
<Chipaca> zygaâ so somehting's broken (probably something changed in the store?)
<zyga> so is that a store bug, snapd bog?
<zyga> Chipaca: can we log from tab completion handlers
<zyga> Chipaca: adding a debug section that collects such logs could be useful
<Chipaca> zygaâ the snapd-side of completion looks just like a regular search
<Chipaca> zygaâ and that will be in the journalctl output
<zyga> Chipaca: aha, perfect, let me read the debug section then
<zyga> : DEBUG: Retrying https://search.apps.ubuntu.com/api/v1/snaps/details ...
<zyga> maybe it is just another EOF
<zyga> finished after 1 retries, elapsed time=136.412205ms, status: 200
<Chipaca> zygaâ what store is it looking at? and does that store have a purchasable test-assumes and test-snapd-tools?
<zyga> pstolowski: ^ does that mean we got what we asked for or that we didn't and we gave up?
<zyga> Chipaca: I don't know how to check
<Chipaca> right now me neither
<zyga> Chipaca: this is just tests/main/completion
<Chipaca> (meaning it requires some more context that i haven't loaded)
<zyga> the logging would be easier to grok if it said "after 1 try and 0 retries" for instance
<Chipaca> Apr 06 12:44:13 autopkgtest snapd[5022]: 2017/04/06 12:44:13.129725 daemon.go:176: DEBUG: uid=0;@ GET /v2/find?name=test-%2A 5.359029622s 200
<Chipaca> *five seconds*
<Chipaca> a query to the store took *five* *seconds*
<zyga> Chipaca: aha, I see it
<zyga> but the reply is 200
<ogra_> stop using GSM
<zyga> ogra_: but I like my nokia :D
<ogra_> :D
<zyga> Chipaca: so do you think this is it?
<zyga> Chipaca: store having a unbelievably slow reply?
<ogra_> if it comes to core you can drop "unbelivable" from that sentence
<Chipaca> zygaâ that test's expect timeouts at exactly 5 seconds
<Chipaca> anything over 5 seconds will fail
<zyga> Chipaca: interesting, thanks
<Chipaca> realistically, any response from the store over ~200ms is too slow
<zyga> Chipaca: I'll open a store thread about this
<ogra_> rendering the myapps.u.c page for core can easily take a min, there are simply many revisions ... processing them takes a while
<ogra_> so i wouldnt be surprised if the download request takes longer too
<Chipaca> ogra_â myapps.u.c is a different service though
<ogra_> same backend, no
<Chipaca> nope
<ogra_> ?
<ogra_> ah, k
<Chipaca> the thing we hit for searches is a wrapped elasticsearch
<ogra_> probably to elastic then :P
<ogra_> (so elastic, it streches time)
<Chipaca> ogra_â I think I need to have lunch to appreciate your sense of humour :-)
<zyga> https://forum.snapcraft.io/t/chasing-unreliable-tests/158/8
<ogra_> heh
<zyga> Chipaca: thanks for your assistance!
<zyga> fg
<pstolowski> zyga, yes, 1 retry and 200 means we got the data
<mvo> zyga: 3160 is also needed for 2.24 ? are all of your PRs that deal with the connection thing marked?
<Son_Goku> morphis, did you request whatever golang library does the progress thing to get updated in Fedora?
<Son_Goku> I recall zyga mentioned something about an issue with that in the bodhi updates
<pedronis> zyga: are all your PRs needed?  also having them split out, doesn't that mean the testing is only partial?
<mvo> zyga: so what needs to land? the core PR that renames the plugs on the core side and your three PRs?
<zyga> mvo: I think it may not be needed in the end
<zyga> mvo: the question is this, when we revert, do we auto-connect the reverted snap?
<zyga> mvo: is it just like an install?
<mvo> zyga: I think we do but we need to double check
<zyga> mvo: if it is just like an install then we can land this branch, it matters little in practice because other branches will automatically connect core plugs anyway
<zyga> mvo: and on refresh new connections will be made
<zyga> mvo: I left it out specifically because it is a gray area and just a cleanup on top of the rest
<mvo> zyga: it sounds like something we can test relatively easily? even a manual test would help to give me confidence in this
<mvo> zyga: so its 3145,3154 and 3153 that we need to land for 2.24?
<zyga> mvo: checking
<mvo> zyga: could you make the forum entry for this a wiki ? then I can add a checklist
<zyga> mvo: 3145 yes, for sure, 3154 (gee that was super confusing for my mind that swaps last two things around) yes; 3153 yes but I think it can only land after the others have helped
<zyga> mvo: done, https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184 is now a wiki
<icey> a snap I've been working on in bits for a while is now stuck with: https://pastebin.ubuntu.com/24354062/
<zyga> mvo: are you going to edit it or should I?
<mvo> zyga: please go ahead
<icey> the very first line of my main() function should also print out: "Main!" to stdout
<zyga> icey: this is a bug in golang
<mvo> zyga: a todo with the minimal fix we absolutely need for 2.24 would be great
<icey> such fun, it's running a compiled Rust binary :-/
<icey> zyga: any ETA on a fix for that?
<zyga> icey: it's fixed in ubuntu now I think but it needs to be fixed in other places that use go
<zyga> icey: I think Chipaca is the person to ask
<zyga> mvo: doing now
<mvo> zyga: people ask about 2.24 and its not fully clear to me what we need to do now for the fix and what we can do later
<icey> zyga: in ubuntu now == 17.10 on Thursday?
<mvo> zyga: thank you
<zyga> icey: not sure really, sorry
<icey> 17.04 rather
<icey> zyga: talking about releases too much today
<icey> zyga do you know what version of snap it's fixed in? https://pastebin.ubuntu.com/24354069/ is what I'm on now
<pedronis> mmh, getting this kind of errors in autokpkgtest atm:  error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.
<zyga> mvo: I'm seeing a lot of tihs
<zyga> Cloning into '/tmp/go/.cache/govendor/gopkg.in/mgo.v2'...
<mvo> zyga: also is https://github.com/snapcore/snapd/pull/3145#discussion_r110329005 still relevant in 3145? i.e. do we need those plugs on the core snap afterall? or will the followup branches DTRT? sorry that I have so many questions
<zyga> error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<pedronis> context: # cd .; git clone https://gopkg.in/mgo.v2 /tmp/go/.cache/govendor/gopkg.in/mgo.v2
<pedronis> Cloning into '/tmp/go/.cache/govendor/gopkg.in/mgo.v2'...
<pedronis> something wrong with gopkg.in?
<zyga> mvo: yes, I think we still want to rename them, the internal rename in snapd is just a fixup but we should correct the actual yaml on disk later
<zyga> pedronis: ha
<zyga> pedronis: funny that we both reported it :)
<zyga> yes, looks like something wrong, what is mgo.v2
<mvo> zyga: so the internal rename does not have to be in sync with the core snap? so 3145 is fine as is?
<zyga> mvo: yes
<zyga> mvo: collecting PRs
<zyga> mvo: only one left
<pedronis> zyga: mgo.v2, mongo driver but actually where we get bson encoding support from , I think was added recently
<zyga> mvo: please check https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184 again
<pedronis> see errtracker stuff
<zyga> pedronis: aha, makes sense
<zyga> right, I remember that
<zyga> mvo: have a look at that and tell me if it makes sense
<zyga> mvo: trivial fix on https://github.com/snapcore/core/pull/32#pullrequestreview-31819934
<mup> PR core#32: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
 * Chipaca back from lunch
<Chipaca> icey, zyga, what's the question again?
<zyga> Chipaca: golang bug with clone+exec
<icey> Chipaca: https://pastebin.ubuntu.com/24354062/
<zyga> Chipaca: pthread_create doesn't work while execing
<Chipaca> iceyâ what're you running there?
<icey> Chipaca: alacritty :)
<icey> a snap I've been working on in bits for a while now
<Chipaca> alright
<Chipaca> iceyâ so, *most* of that family of errors are just warnings
<icey> it builds fine, but hangs when running; if I leave it long enough, I get that output
<Chipaca> iceyâ but not all of them :-(
<icey> if I run the binary itself without snapd, it runs fine
<icey> the confined version never runs the first line of the main() function
<Chipaca> iceyâ but none of it involves hanging
<icey> this particular binary also does exciting things with opengl and such
<icey> and is a classic snap
<Chipaca> iceyâ that is: either it'll work (sometimes printing a spuriouos warning) or it won't (with something silly about permissions)
<icey> yeah, this one will literally hang forever (as far as I can tell) and periodically output that line
<Chipaca> iceyâ so, the pthread warnings are *probably* ignorable; you're probably getting denies in dmesg
<icey> Chipaca: with a classic sna? :-/
<zyga> icey: with any kind IMO
<Chipaca> iceyâ any snap can get denies
<Chipaca> classic just means the jail is built differently (wider, roomier, but still a jail)
<Chipaca> even decmode, hah (but harder to do)
<icey> zyga: Chipaca I'm getting https://pastebin.ubuntu.com/24354169/ in dmesg every time I start it
<zyga> icey: are you connected over ssh?
<icey> zyga: I'm running locally
<zyga> hmmm
<zyga> odd
<icey> bash on laptop
<icey> I don't think this would work well over ssh, it
 * zyga looks at the leet PID
<icey> it is a terminal using GPU acceletarion :)
<icey> acceleration*
<zyga> icey: can you please report that bug
<zyga> icey: it feels like something else now
<zyga> icey: I recall seeing this somewhere, I'll talk to the security team about it
<icey> zyga: what data would you like on the bug? this dmesg output?
<zyga> icey: please open a bug on launchpad.net/snap-confine
<zyga> icey: that denial is key, please describe the context, maybe how to reproduce it
<zyga> icey: does it happen with other snaps?
<zyga> icey: or just this?
<icey> zyga: not that I have experienced. This snap has hit show-stopping bugs every time I've tried to move forward with it :)
<Chipaca> iceyâ have you looked at snappy-debug.security scanlog?
<icey> Chipaca: ... no ... ?
<icey> Chipaca: how can I do that :)
<Chipaca> iceyâ snap install snappy-debug
<Chipaca> iceyâ snappy-debug.security scanlog your.service
<Chipaca> iceyâ then start the service
<Chipaca> iceyâ see if it says anything
<Chipaca> jdstrandâ ping
<Chipaca> iceyâ or, snappy-debug.security --help
<Chipaca> iceyâ for more details
 * zyga AFK for a moment
<Chipaca> although, the aduit log being on snap-confine might mean that it's bug#1672819
<icey> Chipaca: running "snappy-debug.security scanlog alacritty", followed by starting `alacritty` in a new tab shows no output
<mvo> zyga: 3154 has test failures that look real
<Chipaca> ahem
 * Chipaca pokes hal
<Chipaca> bug 1672819
<mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):In Progress by colin-king> <https://launchpad.net/bugs/1672819>
<Chipaca> mupâ thank you
<Chipaca> iceyâ and you get that audit log every time?
<icey> as requested zyga: bug 1681421
<mup> Bug #1681421: snap-confine dmesg error and snap hangs <Snappy Launcher:New> <https://launchpad.net/bugs/1681421>
<icey> yeah Chipaca
<icey> as far as I can tell
<icey> Chipaca: only thing that changes is the timestamp and PID
<morphis> Son_Goku: no, didn't looked into that yet
<morphis> Son_Goku: https://github.com/cheggaaa/pb you mean, right?
<Son_Goku> yeah
<morphis> Son_Goku: that is interesting, its not yet in your BuildRequires: list
<Son_Goku> it is, though
<morphis> ah no
<morphis> there it is
<morphis> Son_Goku: yeah looks a bit outdated, so there is a bodhi request already to get it updated or what did you mean with your second comment?
<Son_Goku> morphis: like we did with the other one
<Son_Goku> file a bug to request it to be updated
<morphis> sure, but for what do we need an update?
<morphis> Son_Goku: I don't see any direct commetn from zyga on this
<Son_Goku> https://bodhi.fedoraproject.org/updates/snapd-2.23.6-4.fc25%20snapd-glib-1.10-1.fc25#comment-587757
<morphis> ok, lets give a newer version a try and see if that fixes the problem
<Son_Goku> the progress bar package (https://apps.fedoraproject.org/packages/golang-github-cheggaaa-pb) ships code from 2015
<Chipaca> Son_Goku, zyga, dunno if you knew but the socket is no longer needed
<Son_Goku> Chipaca: wut
<Son_Goku> why?
<morphis> Chipaca: /run/snapd.socket is dropped?
<Chipaca> no
<zyga> re
<Chipaca> the .socket is no longer needed
<Son_Goku> then how is it socket activated?
<zyga> mvo: looking
<Chipaca> snapd listens to /run/snapd.socket and /run/snapd-snap.socket automatically if it hasn't been activated on startup
<zyga> Chipaca: I know
<Chipaca> ah ok
<Son_Goku> geez, you scared me for a sec
<Chipaca> it's still useful, because the .socket can start up earlier than the .service
<Chipaca> and queue stuff for us
<Chipaca> Son_Gokuâ i'd love to be able to say i did it on purpose, but not this time
<zyga> mvo: aha, I will have some silly test fixups to do
<zyga> mvo: thank you!
<Son_Goku> the socket and timer units are enabled by default in Fedora
<zyga> mvo: this is just a list of grep patterns to correct
<Chipaca> Son_Gokuâ enabled but not started?
<Son_Goku> well, the snapd package will start them if distro policy says they are enabled on install
<zyga> Son_Goku: right, I think the socket is relevant as before but what Chipaca meant is that we no longer require it strictly speaking
<Son_Goku> so for Fedora 25 and newer, that will be the case
<Son_Goku> Fedora 24 and EL7, it won't be
<morphis> Chipaca, zyga: so you guys basically don't require systemd to pass you a socket fd anymore, correct?
<mvo> zyga: thanks for looking into it
<mvo> zyga: silly question, is there anything in 3145 that can be observed from the outside? i.e. I will not see anything in snap interfaces or similar?
<Chipaca> morphisâ dude, you can run snapd directly, for testing and stuff. Hence https://github.com/chipaca/bin/blob/master/run-snapd-srv
<Chipaca> morphisâ (when testing stuff i usuall âgo build -o /tmp/srv ./cmd/sanpd && sudo ~/bin/run-snapd-srvâ
<Chipaca> )
<morphis> sure but there was a time when we had to do something like https://github.com/teknoraver/snap-openwrt/blob/master/snapd/src/snapd-wrapper.c explicitly to get snapd running
<Chipaca> morphisâ yes; no more
<morphis> good
<Chipaca> morphisâ if you look at the history of run-snapd-srv, before it used to call systemd-activate
<Chipaca> same thing really, but easier
<mvo> niemeyer: your input on https://github.com/snapcore/snapd/pulls?q=is%3Aopen+is%3Apr+milestone%3A2.24 would be great,  3145 needs a re-review
<mvo> niemeyer: and the other two need to land for 2.24 as well
<Chipaca> morphisâ you'll see lines like â2017/04/10 13:44:33.800749 daemon.go:211: DEBUG: socket "/run/snapd.socket" was not activated; listeningâ, which means it's doing this that we're discussing
<morphis> very good
<zyga> mvo: thinking
<zyga> mvo: yes, it wil be seen in snap interfaces
<zyga> mvo: this is why those tests fail
<jdstrand> Chipaca: hey
<Chipaca> jdstrandâ snappy-debug is yours, yes?
<zyga> jdstrand: when would snap confine need /dev/tty ?
<mvo> zyga: hm, sorry, I'm still not seeing the full picture - 3145 in isolation will not work because it needs a core snap with core-support-plug. either by renaming the meta-data or by landing the followup branch 3154. is that correct? so the order would be 3154, 3145, 3153?
<zyga> mvo: correct
<jdstrand> zyga: typically if it is trying to write debug output
<zyga> jdstrand: aha, interesting
<jdstrand> zyga: https://bugs.launchpad.net/snap-confine/+bug/1681421/comments/1
<mup> Bug #1681421: snap-confine dmesg error and snap hangs <Snappy Launcher:New> <https://launchpad.net/bugs/1681421>
<jdstrand> zyga: well, or error, info, etc
<zyga> jdstrand: right
<jdstrand> Chipaca: well, I guess, yes
<Chipaca> jdstrandâ :)
<zyga> jdstrand: should we add that to the profile then, I didn't see it today
<jdstrand> zyga: did you read my comment? :)
<zyga> jdstrand: yes
<zyga> jdstrand: you said you'd add it
<jdstrand> "I'll add this to the snap-confine profile"
<zyga> jdstrand: since 2.24 is being pushed out we could add this today still
<Chipaca> jdstrandâ i ask because running 'strings' on the .swp file you ship in there is interesting
<jdstrand> zyga: if you want to do that this second, feel free
<jdstrand> meh
<jdstrand> Chipaca: :\
<Chipaca> jdstrandâ :-D
<Chipaca> jdstrandâ not *that* interesting, otherwise I would've reached out in private
<jdstrand> Chipaca: yep, thanks for letting me know. I'll also be adding a test to the review tools (I thought I had this already tbh)
<morphis> Son_Goku: https://bugzilla.redhat.com/show_bug.cgi?id=1440773
<Chipaca> jdstrandâ I'd poke sergiusens to add .swp files to the ignore list, but he's not around
<Chipaca> jdstrandâ if only we had a place to write down issues we had so we could keep track of them asynchronously
<jdstrand> Chipaca: haha
<jdstrand> zyga: so I can get to the /dev/tty thing in a few minutes if that would help. if you are going to do it, let me know
<icey> jdstrand: your change to the apparmor profile removed the dmesg warning, unfortunately the snap's behaviour hasn't otherwise changed
<Son_Goku> morphis: was the progress bar thing the one that caused the build to fail on ppc64?
<jdstrand> icey: are you using snappy-debug?
<morphis> Son_Goku: no
<jdstrand> icey: or just dmesg?
<icey> I have, it gave no output earlier
<jdstrand> icey: I mean just now
<morphis> Son_Goku: we didn't found out what the problem is with ppc64
<Son_Goku> ah
<icey> jdstrand: running `$ sudo snappy-debug.security scanlog alacritty` just now gives no output when I run `alacritty` in another tab
<jdstrand> icey: ok. in another window, do 'grep DEN /var/log/syslog'
<zyga> jdstrand: I'm in the standup now, if you can do it I'll merge that for 2.24
<jdstrand> icey: snappy-debug doesn't yet understand dbus denials (it will, just doesn't yet)
<zyga> jdstrand: thank you!
<icey> just multiple lines of the rw on /dev/tty
<zyga> jdstrand: (I'm still working on the plug rename thing)
<icey> nothing new
<jdstrand> icey: ok, then yeah, it is something else. I'll fix the the /dev/tty denial
<jdstrand> zyga:
<jdstrand> zyga: ok
<icey> jdstrand: I'm going to see if a simple rust snap still works :)
<icey> jdstrand: looks ike a no go on a super simple rust program as well
<jdstrand> weird
<jdstrand> icey: is this classic, devmode or strict confinement?
<icey> jdstrand: classic, I can try devmode / strict with this minimal one too
<icey> the thing I'm actually trying to snap will require classic though, it's a terminal :)
<icey> well jdstrand , building it in classic works perfectly
<icey> (the test one)
<morphis> Son_Goku: is there an easy way to use a source dir instead of a tarball for an rpm build?
<jdstrand> sergiusens: hey, can you take a look at backscroll when you're around to help icey with a rust program that isn't running in classic?
<icey> jdstrand: I've got 2 rust programs not running in classic now
<jdstrand> icey: in addition to that irc ping, you might bring this topic up in the forum
<sergiusens> jdstrand, sure, icey and I have been looking at this here and there
<Son_Goku> morphis: I think you can use rpmbuild -bb --in-place
<jdstrand> ah
<Son_Goku> it skips %prep stage
<jdstrand> ok, I'll step back then
<morphis> Son_Goku: let me try
<sergiusens> forum or rocket, irc is sort of dead to me :-P
<Son_Goku> and ignores source and patch
<icey> sergiusens: it's the same snap too :)
<icey> sergiusens: alacritty will /try/ to start with strict  mode on, but with classic mode, it hangs
<sergiusens> icey, yeah, I figured, GL drama and I still need to pass in those flags that were mentioned in the rust plugin
<icey> as does my super simple, no dependency rust program
<icey> sergiusens: it's not just gl...
<sergiusens> icey, is this xenial build, xenial run
<sergiusens> ?
<icey> sergiusens: yakkety
<icey> and sergiusens, this program has the same problem: https://is.gd/wDGfHt
<icey> super tiny and exhibits the same symptoms
<sergiusens> icey, mind reminding me in which issue we got the recommendation on flags to pass to rust?
<sergiusens> icey, most likely a program loader issue
<icey> sergiusens: https://github.com/rust-lang/cargo/issues/3694
<icey> sergiusens: I'm working on a tweak to the rust plugin to set RUSTFLAGS to LDFLAGS
<icey> sergiusens: this classic mode + rust thing is killing me though
<icey> strict + rust works fine
<icey> (if the program can do strict)
<sergiusens> icey, yeah, so most certainly program loader related
<sergiusens> icey, so RUSTFLAGS format isn't really documented, is it 1:1 with LDFLAGS?
<icey> no clue sergiusens  :)I was literally just trying shoving ldflags into rustflags
<icey> but I can't even test since it can't run
<sergiusens> right, let me ask on the Issue
<icey> sergiusens: I'm also updating the snap-confine bug with a bit more info
<icey> sergiusens: looks like we may want something like : RUSTFLAGS = -C link-args="$(LDFLAGS)"
<sergiusens> icey, oh, "Note that the exact linker that the compiler invokes isn't guaranteed to not change over time, so there's not always a valid interpretation of LDFLAGS even if it exists."
<sergiusens> icey, can you figure out what linker it is using?
<tvoss> pedronis: trying to figure out what your comment about the lib version means :)
<icey> sergiusens: I suspect that on linux it's using ld, but cargo (and rust) can also compile on all sorts of other systems (windows) so that may be what he's referring to
<icey> sergiusens: https://www.reddit.com/r/rust/comments/58z5xx/does_rust_use_gnu_or_llvm_linker_on_linux/
<mup> PR snapd#3161 opened: snap-confine,browser-support: /dev/tty for snap-confine, misc browser-support for gnome-shell <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3161>
<morphis> Son_Goku, zyga: we still have "/usr/bin/ld: cannot find -lcap" for rpm builds in latest master
<Son_Goku> :S
<cachio> sergiusens, getting "GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature"
<pedronis> tvoss: it's the command that doesn't like -b < 1024, or it's the library?
<jdstrand> zyga: fyi, https://github.com/snapcore/snapd/pull/3161
<mup> PR snapd#3161: snap-confine,browser-support: /dev/tty for snap-confine, misc browser-support for gnome-shell <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3161>
<morphis> Son_Goku: let me try to fix this
<sergiusens> cachio, on what?
<cachio> sergiusens, when I make apt-get update on classic in my dragonboard
<sergiusens> cachio, oh, ask ogra_
<cachio> sergiusens, ok, tx
<tvoss> pedronis: it's the library ultimately
<ogra_> jdstrand, is https://forum.snapcraft.io/t/would-someone-create-an-electron-snap-for-this-forum/78/16 related
<tvoss> pedronis: libssl refuses b < 1024
<pedronis> tvoss: ok, that was my wondering
<ogra_> jdstrand, i noticed that i see the mmap denial only on systems with newer kernels
<cachio> ogra_, hey, getting "GPG error: http://ports.ubuntu.com/ubuntu-ports xenial InRelease: Could not execute 'apt-key' to verify signature"  when I make apt-get update on classic in my dragonboard
<pedronis> tvoss: you need a 2nd snapd review and input again from tyler IÂ suppose
<ogra_> jdstrand, same app works fine on a bare 16.04 with the original 4.4
<tvoss> pedronis: I was thinking about erroring out, but just raising to working level seems to be more reasonable
<cachio> ogra_, any idea why?
<ogra_> cachio, yeah, rthere is a bug open for that ...
<ogra_> not yet
<tvoss> pedronis: yup, will give Tyler a ping now
<cachio> ogra_, ok, thanks
<ogra_> cachio, bug 1670475
<mup> Bug #1670475: apt-secure complaints with classic snap on arm64 (dragonboard) <Snappy:New> <https://launchpad.net/bugs/1670475>
<cachio> ogra_, great, tx
<ogra_> (this isnt actually dragonvboard only, i see it on pi2/3 too now)
<ogra_> i'll try to make up some time for it this week
<ogra_> it is old enough that it starts to smell :)
<cachio> ogra_, good
<icey> sergiusens: is there anything I can do to help with diagnosing / fixing this classic rust snap issue?
<icey> I've got a nive 25mb strace output of trying to run it
<sergiusens> icey, let me wrap up working on yarn support and then look into this. We have a rust integration test demo which I will turn into a classic confined snap for testing out
<icey> sergiusens: we have to ensure that it runs too, it builds just fine but will never run
<sergiusens> icey, bottom line is that, `readelf -a <elf>`'s output under program loader needs to have the core snaps ld instead of the one on the system or you are in for trouble
<sergiusens> icey, yeah, in our demos suite we test that they run ;-)
<morphis> Son_Goku: ok, this seems to be more my fault but wondering what I am doing wrong with my in-tree build
<icey> sergiusens: looks like the ld is: [Requesting program interpreter: /lib64/ld-linux-x86-64.so.2] ?
<zyga> jdstrand: thank you
<icey> sergiusens: it looks like, when snapcraft is calling build, that env['LDFLAGS'] is _not_ set
<sergiusens> icey, it is, you just don't see it... under snapcraft.internal.common.run (or run_output) there's this wrapper script that gets created
<sergiusens> this was in snapcraft 0.2, before my time (I took over on 0.3) and never managed to improve this logic
<icey> sergiusens: I'm trying to do something like: https://gist.github.com/ChrisMacNaughton/475882f81acab077e5e693e7df5e433e to get the RUSTFLAGS setup but LDFLAGS isn't present :-/
<Chipaca> niemeyerâ I think I left a dangling Spread-19
<niemeyer> Chipaca: Not a great problem these days.. it should get cleaned up automatically without any ill side effects
<Chipaca> k
<Chipaca> niemeyerâ i mean, started spread with -reuse, and then deleted the .spread file :-)
<niemeyer> Chipaca: Aha, yeah, that might make it hard to reuse it ;)
<zyga> jdstrand: looked again
<Chipaca> niemeyerâ so flaky
<Chipaca> niemeyerâ hopping subjects, from mwhudson on https://bugs.launchpad.net/snappy/+bug/1638537:
<mup> Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537>
<Chipaca> AIUI, generating an RSA key ends up benchmarking montgomery multiplication, and I know there are SIMD tricks you can use for that. Go doesn't seem to be using anything in this area but it looks like ssh-keygen is using openssh's routines for this and I bet they are optimized nearly as much as is possible.
 * zyga looks at failing tests on various "rename" branches
<tvoss> tyhicks: hey there, would be great if you could have another pass on https://github.com/snapcore/snapd/pull/3130
<mup> PR snapd#3130: overlord/devicestate: switch to lib(open)ssl for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<Chipaca> tvossâ question for you about that
<Chipaca> tvossâ are you using locking_function and threadid_func? (how/where?) is that even needed?
<tvoss> Chipaca: shoot, btw: ssh-keygen uses openssl ultimately
<Chipaca> tvossâ yeah i know, the above was to give gustavo some context about this
<tvoss> Chipaca: I haven't looked into threaded behavior, yet, as I was just looking at device key generation.
<tvoss> Chipaca: making generateRSAKey available within all of snapd (and investigating into thread-safety) is on my list next
<niemeyer> Chipaca, tvoss: Heya, reusing ssh-keygen really looks like the best alternative there
<Chipaca> niemeyerâ that's one to talk with tyhicks, as he's the driver of the move to libssl
<cachio> jdstrand, did you find any workaround for this bug https://bugs.launchpad.net/snappy/+bug/1670475 ?
<mup> Bug #1670475: apt-secure complaints with classic snap on arm64 (dragonboard) <Snappy:New> <https://launchpad.net/bugs/1670475>
<Chipaca> at least afaik
<morphis> Son_Goku: was my fault
<tvoss> niemeyer: based on tyhicks feedback, I adjusted the PR to use rsa_generate_key_ex from openssl directly. ssh-keygen uses the same call
<morphis> tvoss: your PR builds fine on fedora
<tvoss> morphis: ack
<morphis> zyga, Son_Goku: https://paste.ubuntu.com/24354626/ that is what fails currently on fedora with latest master
<Son_Goku> yeah, something is being linked statically
<zyga> mvo: based on the discussion in the call I'd like to add https://github.com/snapcore/snapd/pull/3160 to the 2.24 milstone if that is okay
<mup> PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160>
<Son_Goku> morphis: I had this problem before and fixed it
<zyga> morphis: static linking + fortify = incompatible
<zyga> morphis: do a patch that allows us not to build it (it's useless on classic systems)
<zyga> Son_Goku: curious to know what you did
<Son_Goku> it builds fine in 2.23.6 with all the current patches
<zyga> aha
<Son_Goku> but in 2.23.5, I had to do some sed magic to make it build
<morphis> zyga: I know this isn't supposed to work but we landed all changes in 2.24 and that one fails
<Son_Goku> to get rid of it requesting static library preferences
<zyga> Son_Goku: aha
<zyga> Son_Goku: hmmm
<zyga> Son_Goku: I think we need that still
<zyga> Son_Goku: I'd like to find a solution where it can stay and we can link
<Son_Goku> yes
<zyga> Son_Goku: (and on fedora the build is entirely dynamic)
<Son_Goku> yep
<zyga> anyway, I'm sure we can
<zyga> just wanted to say this
<morphis> zyga: did the build for the shutdown helper change between 2.23.6 and 2.24?
<zyga> morphis: perhaps, the point is that hardedned static builds just don't exist yet AFAIK
<zyga> morphis: maybe we now apply hardening... well, harder
<morphis> zyga: we do on fedora
<jdstrand> cachio: only the crappy one in comment #1
<cachio> jdstrand, ok, thanks
<zyga> morphis: I know but this was disabled so that it could link
<zyga> morphis: same was true in debian/ubuntu BTW
<morphis> zyga: were was this disable?
<morphis> s/disable/disabled/?
<zyga> morphis: with cflags overrides
<morphis> zyga: we don't do this for 2.23.6
<zyga> morphis: not sure if this is there now, the point is that just static hardened linking doens't exist AFAIK
<zyga> morphis: I'm lost in which-version-had-what
<morphis> zyga: that is fine, however something change in the build of the shutdown helper between 2.23.6+patch and 2.24 so that it now doesn't work anymore
<zyga> morphis: git diff on the makefile to check :)
<morphis> yeah, checking that already
<morphis> zyga: didn't you integrate https://github.com/snapcore/snapd/pull/3108 in yours as said on that PR?
<mup> PR snapd#3108: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3108>
<icey> sergiusens: just posted some fun in #rust that you may enjoy: https://gist.github.com/ChrisMacNaughton/a81233e05995013ebb9a0c333c157b76
<mvo> zyga: sure, its ok - sorry for the delay, I was in the releae meeting
<zyga> mvo: that's okay
<zyga> mvo: any changes/
<mvo> zyga: just that we need validation from the CE team when we do 2.24 to stable
<zyga> ok, that's good
<zyga> niemeyer: hey, we're seeing some mgo.v2 errors related to git
<zyga> niemeyer: e.g. http://pastebin.ubuntu.com/24354760/ in https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-snappy-dev-image/yakkety/amd64/s/snapd/20170410_141305_8a2e6@/log.gz
<zyga> niemeyer: do you have any ideas if that could be related to gopkg.in? (any spike in load)
<niemeyer> zyga: No idea.. let me see
<niemeyer> zyga: Doesn't seem extraordinary.. it's doing ~10mbps in and ~10 out, which is even below what it has been sustaining recently
<zyga> niemeyer: anything odd in logs? this particular repo failed numerous times today; maybe it's just coincidence
<niemeyer> zyga: Nothing special I can see.. this is requested about ~10 times every minute
<niemeyer> zyga: I just fetched it locally as well from my crappy network without issues
<niemeyer> zyga: Process is up since Feb 21.. RSS at 22MB.. load at 0.2.. can't see much to be worried about yet
<niemeyer> zyga: The fact this is also an EOF makes me worried that perhaps the networking of those machines is not as healthy as it should be
<zyga> niemeyer: thanks for checking, I'll keep monitoring
<zyga> niemeyer: yeah
<zyga> niemeyer: the only possiblity is linode itself now
<niemeyer> zyga: Well.. :)
<niemeyer> zyga: I'm far less optimistic about my abilities to guess problems like that :)
<ogra_> tvoss, niemeyer asked me to carry the keygen issue over to the forum, i opened https://forum.snapcraft.io/t/ubuntu-core-key-generation-slowness/229/1
<ogra_> please take a look
<tvoss> ogra_: ack
<tvoss> niemeyer: did you have a chance to walk through the PR?
<ogra_> tyhicks, jdstrand ^^^ same for you two :)
<niemeyer> tvoss: No, sorry, I should have done that.  That said, I have a reasonable idea of where things stand. The reason I asked ogra_ for some details on that particular piece is just that it feels like ssh-keygen is the best way forward, and there's some disagreement about that which isn't entirely clear, so would like to have a thread for us to talk
<morphis> zyga: you saw my message about https://github.com/snapcore/snapd/pull/3108 ?
<mup> PR snapd#3108: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3108>
<zyga> morphis: yes, I won't have time to touch this before 2.24 though
<morphis> zyga: ok, let me see if I get this quickly up
<tyhicks> jdstrand: you can ignore the ssh-keygen topic - it was being discussed by mdeslaur, sarnold, and myself
<tyhicks> I've responded in the forum
<ogra_> tyhicks, thanks
<tyhicks> np
<niemeyer> tyhicks: Thanks! Will follow up there
<jdstrand> tyhicks: ack, thanks
<mup> PR snapcraft#1241 closed: help: replace dashes with underscores when printing plugins help <Created by EduardoVega> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1241>
<mvo> Chipaca: re https://forum.snapcraft.io/t/declaratively-defining-environment-variables/175> what am I missing? I thought we have all the bits needed in master now?
<Chipaca> mvoâ we do?
<Chipaca> mvoâ let me look :-/
<mvo> Chipaca: I replied to that forum thread
<mikeb_> I'm having problems with snapcraft daemons.  It looks like if I have a 'notify' daemon defined in my snapcraft.yaml, snapd is waiting for the notification before starting other daemons.  Is this known behavior?
<mvo> Chipaca: unless I miss something of course :)
<mvo> Chipaca: but I think the example from sergio works, at least we have a very similar spread test and I remember fixing things there
<jdstrand> niemeyer: hi! I found an issue in the mailing list functionality of the forum. where is the best place to report that, the forum?
<niemeyer> jdstrand: Yes, there's a "forum" category
<Chipaca> mvoâ which is the test that tests this?
<mvo> Chipaca: https://github.com/snapcore/snapd/blob/master/tests/main/snap-env/task.yaml
<mvo> Chipaca: https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/test-snapd-tools/meta/snap.yaml
<zyga> Cloning into '/tmp/go/.cache/govendor/gopkg.in/check.v1'...
<zyga> error: RPC failed; curl 56 GnuTLS recv error (-9): A TLS packet with unexpected length was received.
<zyga> niemeyer: ^ now on check.v1
<mvo> Chipaca: check the EXTRA_CACHE_DIR: $SNAP_USER_DATA/ there
<mvo> Chipaca: thats the case that we want, right?
<Chipaca> mvoâ note that what I'm saying we should support is
<niemeyer> zyga: Network seems pretty busted
<Chipaca> mvoâ command: foo $BAR
<niemeyer> zyga: Let me try restarting the process just in case
<Chipaca> mvoâ which we don't
<Chipaca> afaik
<mvo> Chipaca: aha, yes, this one is indeed missing
<mvo> Chipaca: good point, sorry that I misunerstood this
<Chipaca> mvoâ in you can't even have âcommand: foo --bar=bazâ
<niemeyer> zyga: Done
<mvo> Chipaca: yeah, command is super restrictive currently
<Chipaca> yep
<mvo> Chipaca: +1 for fixing that
<Chipaca> mvoâ tweaking https://forum.snapcraft.io/t/papercuts-mouth-sized-bugs/228 to explain this
<mvo> Chipaca: thank you!
<jdstrand> niemeyer: ok, thanks
<jdstrand> ah, ``` works in the forum too (thank goodness)
<niemeyer> jdstrand: Thanks for reporting.. I'm interested as we're planning to migrate the list there pretty soon
<Chipaca> also in the forum, hitting '?' gives you a list of keyboard shortcuts \o/
<zyga> niemeyer: thank you, I restarted tests
<mvo> zyga: thanks! 3154 looks good now, looks like it needs a second review
<zyga> yes!
<mvo> Chipaca: woah, this is cool
<zyga> I'd review it but that would be self-serving
<Chipaca> mvoâ ikr
<jdstrand> niemeyer: fyi, https://forum.snapcraft.io/t/mailing-list-urls-have-appended-breaking-the-url-for-text-only-emails/231
<zyga> jdstrand: so meta that the key character is not in the actual URL
 * zyga is starving
<mikeb_> I'll ask my question in a different way...  Given a snapcraft.yaml file with several daemons of different types (notify, simple, oneshot, forking) in the apps: section, is there an implicit ordering that is used to start up those daemons at install/boot time?
<zyga> ogra_: can you review https://github.com/snapcore/core/pull/32
<mup> PR core#32: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <https://github.com/snapcore/core/pull/32>
<zyga> niemeyer: FYI ^ that's the rename on core snap itself
<ogra_> zyga, approved, want me to click the merge button ?
 * ogra_ clicks 
<Chipaca> mikeb_â there is no ordering
<mup> PR core#32 closed: Rename core-support,network-bind plugs to make them unique <Created by mvo5> <Merged by ogra1> <https://github.com/snapcore/core/pull/32>
<niemeyer> zyga: Thanks, quick lunch first
<Chipaca> mikeb_â I'll add this to the papercuts thread
<zyga> ogra_: no, let's wait for gustavo's review please
<ogra_> zyga, bah, crap
<ogra_> well, i'll care for the rollback in case gustavo is unhappy with it
<zyga> ogra_: OK
<zyga> ogra_: no worries, I think it is okay
<ogra_> yeah, trivial enough
<Chipaca> mikeb_â done
<zyga> + first practical attempt at renaming plugs
<kyrofa> mikeb_, do your daemon's save pid files?
<mvo> ogra_: do you mind if I run a core build now that the plug rename has landed?
<ogra_> mvo, go ahead
<mvo> ta
 * zyga lunch
<zyga> (late)
<mikeb_> kyrofa: My daemons don't explictly save pid files - that should be handled by snapd or systemd I would think.
<mikeb_> Chpaca: I'm not familiar with the "papercuts" thread.
<Chipaca> mikeb_â I mean, I made a note of this so we don't forget and get around to it eventually
<Chipaca> mikeb_â is this blocking your work right now?
<Chipaca> or can you live without it for a while?
<mikeb_> Chipaca: There does seem to be some ordering as several daemons were not started because one of my notify daemons didn't notify.
<Chipaca> oh
<Chipaca> After={{.MountUnit}} {{.PrerequisiteTarget}}
<Chipaca> hah, i'm a muppet
<Chipaca> davmor2â shut up
<mikeb_> Chipaca: semi-blocking.  I have a nasty hack workaround that does an "end-around" around snappy.  I'm trying to leverage as much of snappy's daemon functionality.
<Chipaca> mikeb_â sorry, give me a bit to actually read the code instead of answering from memory
<davmor2> Chipaca: I didn't say a word but now you mention is that are similarities between you and animal
<mikeb_> Chipaca: I'm away for a couple hours.  I'll check back then.  Thanks.  I'll also try to put together a demo snap to illustrate further.
<Chipaca> mikeb_â ah, no, the After= is just for things like networking
<Chipaca> mikeb_â that would be very useful
<Chipaca> thanks!
<morphis> zyga: ok, pushed https://github.com/snapcore/snapd/pull/3162
<mup> PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162>
<morphis> zyga: can you comment on what still needs to be changed?
<mup> PR snapd#3162 opened: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162>
<zyga> morphis: thanks at lot! looking
<zyga> morphis: let's see if the tests pass
 * Pharaoh_Atem sighs
<zyga> morphis: at some point I'd like to rm -rf libtool autoconf and automake personally
<Pharaoh_Atem> meson :)
<zyga> I love them the same way 70 year old people love going to the doctor's
<morphis> zyga: me too
<Pharaoh_Atem> I feel the same way about golang :)
<Pharaoh_Atem> I'm no fan of autotools either, though
<zyga> Pharaoh_Atem: I honestly disagree though :)
 * zyga looks at 
<zyga> error: cannot install "test-snapd-python-webserver": Get
<zyga> https://search.apps.ubuntu.com/api/v1/snaps/details/test-snapd-python-webserver?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%2Ccontact%2Ctitle%2Ccontent%2Cversion%2C
<zyga> origin%2Cdeveloper_id%2Cprivate%2Cconfinement: net/http: request canceled (Client.Timeout exceeded while awaiting headers)
<zyga> whaaat just happened here
<Pharaoh_Atem> zyga: go code is fine, but everything else about go sucks
<zyga> pstolowski: around?
<pstolowski> zyga, yes
<zyga> pstolowski: can you look at https://travis-ci.org/snapcore/snapd/builds/220592064
<zyga> pstolowski: save the logs if needed
<zyga> pstolowski: I'd like to re-start it
<zyga> pstolowski: not sure if that's something we should add to retry list
<zyga> it seems linode has a bad hair day with networking
<mup> PR snapcraft#1246 opened: Preparation work for collaboration support. Includes refactor of get/push_vâ¦ <Created by psivaa> <https://github.com/snapcore/snapcraft/pull/1246>
<zyga> pstolowski: tell me when ready
<pstolowski> zyga, ok, saved a copy
<zyga> pstolowski: thanks!
<pstolowski> zyga, yes I think it makes sense to retry on those. in fact, we would retry on net.Timeout(), but apparently this doesn't fall into that error category
<zyga> it would be nice to run qemu with special network that drops packets
<zyga> to see how we faire
<pstolowski> zyga, so perhaps again, some unwrapping is needed, or different error type check
<zyga> pstolowski: seems like the most whack-a-mole bug ever BTW
<zyga> pstolowski: whack-a-hydra
<pstolowski> zyga, uhm
<pstolowski> zyga, perhaps the shouldRetry() check should be totally reversed... e.g. don't retry only on well-known errors that shouldn't be retried. otherwise always retry
<zyga> pstolowski: what would be the well-known errors?
<zyga> Chipaca, pstolowski, pedronis: we need more reviews for 2.24 branches
<Chipaca> yes! looking
<Chipaca> zygaâ 2.24 branches have grown!
<zyga> can you please start with https://github.com/snapcore/snapd/pull/3154
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<zyga> other branches will depend on it
<Chipaca> snapd#3145 needs niemeyer's eyes
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<Chipaca> (as he marked it as needs-changing)
<morphis> zyga: at least that patch gets us building on fedora again
<zyga> yes
<zyga> morphis: nice!
<Chipaca> i already had reviewed 3154!
 * Chipaca actually clicks the button now
<morphis> zyga: snap-update-ns was removed?
<Chipaca> zygaâ just needs to be green now
<zyga> morphis: it wasn't finished, the C parts were removed, we're implementing it in go now
<morphis> zyga: ah right, I remember looking at that PR from you
<niemeyer> zyga: About #3145, a question:
<zyga> niemeyer: yes
<niemeyer> zyga: How do we get to that state given that we don't have plugs and slots with the same name anymore?
<morphis> Pharaoh_Atem: Finish: rpmbuild snapd-2.24-4.fc25.src.rpm
<pstolowski> zyga, i don't know. was just a crazy idea.
<morphis> Pharaoh_Atem: so the last thing we need is https://github.com/snapcore/snapd/pull/3162
<mup> PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162>
<pstolowski> zyga, but perhaps not a bad one
<zyga> niemeyer: we get to that state because on core -> ubuntu-core transition the `network-bind` plug ends up disconnected as it has two suppliers (during the time core is installed) ubuntu-core and core
<zyga> niemeyer: I added core-support there just in case I missed something, as it makes sense to ensure those two plugs are just always connected
<zyga> niemeyer: does that answer your question? (not sure I inferred the "that state" part correctly)
<niemeyer> zyga: At least I still don't get how we end up there
<pstolowski> zyga, looking at 3160
<niemeyer> zyga: I thought we could only end up there as a consequence of having plug/slot with same name
<niemeyer> zyga: We agreed to fix that so that never happens
<zyga> niemeyer: no, that is not a factor in this case
<zyga> niemeyer: it happens because the migration process installs core before removing ubuntu-core
<zyga> niemeyer: ah, sorry,
<zyga> niemeyer: let me think
<zyga> niemeyer: I either swapped network-bind and core-support
<zyga> niemeyer: or something else is at play
<niemeyer> zyga: Yep, smells fishy
<niemeyer> zyga: That method is handling a single snap and plug/slot name
<zyga> niemeyer: thanks for the dilligence!
<zyga> s/ll/l
<zyga> niemeyer: what is interesting is that branch alone, without internal rename logic from other branches affects the spread test
<zyga> niemeyer: let me review the code around that
<niemeyer> zyga: Right, exactly.. because we have a plug and slot with the same name
<niemeyer> zyga: So it's indeed duplicated
<niemeyer> zyga: But when we fix that, which is the better approach, we shouldn't need it anymore
<Pharaoh_Atem> morphis: snapd 2.24 hasn't been released yet, has it?
<niemeyer> zyga: Exactly the sort of issue we discussed today in the standup.. fixing the invariant will unbreak this and potentially other things we're not even aware about yet
<morphis> Pharaoh_Atem: it hasn't
<morphis> Pharaoh_Atem: was just lazy in constructing the source archive name
<Pharaoh_Atem> ah
<pedronis> zyga: well auto connection is by interface,  so core can auto-connect to core-support in both core and ubuntu-core
<pedronis> if both snaps are installed (which indeed happens during transition)
<zyga> pedronis: and then we do ... nothing, because we bail out if there's more than one candidate
<pedronis> yes
<pedronis> anyway either we don't have the connections, or we have misnamed connections, cannot have both
<pedronis> for the same system
<zyga> ogra_: did new core snap build already in edge?
<ogra_> zyga, yup
<zyga> ogra_: we need to fix master snapd to let tests pass
<zyga> one sec
<ogra_> zyga, ah, so you need a rebuild afterwards ?
<ogra_> NP, just ping me then
<mup> PR snapd#3163 opened: tests: adjust to look for network-bind-plug <Created by zyga> <https://github.com/snapcore/snapd/pull/3163>
<zyga> ogra_: https://github.com/snapcore/snapd/pull/3163
<mup> PR snapd#3163: tests: adjust to look for network-bind-plug <Created by zyga> <https://github.com/snapcore/snapd/pull/3163>
<zyga> ogra_: we need this to land when the core snap with PR 32 is in ede
<zyga> edge*
<ogra_> ok
<ogra_> well, the core snap is there
<zyga> right
<niemeyer> zyga: After you're done with your investigation, please let me know how you want to move forward
<zyga> niemeyer: sure, now I need to take a break but we need to land https://github.com/snapcore/snapd/pull/3163 to unbreak master
<mup> PR snapd#3163: tests: adjust to look for network-bind-plug <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3163>
<zyga> niemeyer: I looked at transitionConnectionsCoreMigration for how the clash is affecting it
<jdstrand> jjohansen: hey, could you look at my comment in https://forum.snapcraft.io/t/would-someone-create-an-electron-snap-for-this-forum/78/18 and let me know if this is the updated mmap mediation (ie, I need to adjust the policy for these denials to add 'm')
<zyga> niemeyer: but TBH I don't see any impact
<pedronis> well autoconnection doesn't look at names of plugs
<niemeyer> zyga: Reviewed snapd#3153.. LGTM plus a suggestion on the wording
<mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
<zyga> niemeyer: thanks looking
<niemeyer> zyga: #3163 LGTM
<pedronis> anyway 3145 is not related to the name duplication, it just intersects with it, still nor sure IÂ like the special casing there though :/
 * zyga -> break and coffee
<jjohansen> jdstrand: likely bug 1658219
<mup> Bug #1658219: flock not mediated by 'k' <verification-done-xenial> <verification-done-yakkety> <AppArmor:In Progress by jjohansen> <linux (Ubuntu):Fix Released> <linux (Ubuntu Xenial):Triaged> <linux (Ubuntu Yakkety):Triaged> <https://launchpad.net/bugs/1658219>
<zyga> once 3163 is green I'll merge it and merge master into open 2.24 branches to see what's wrong
<zyga> and get back to the question niemeyer asked above, but so far back to puzzle mode
<jdstrand> jjohansen: that was what I was thinking, but I wasn't sure of the status of the patches wrt 4.10.0-15.17-generic in zesty
<zyga> (or maybe just tired / stressful day and didn't see something obvious)
<jdstrand> jjohansen: I guess based on that bot response, zesty has the patches. it seems like the bug status was moving quite a bit so wanted to ask
<jjohansen> jdstrand: it was not reverted in zesty
<jdstrand> jjohansen: ah, ok, thanks. that makes it easier
 * zyga afk
<ondra> roadmr can you please help NicolinoCuralli, he seems to have snap stacked in manual review stage.
<ondra> roadmr can you please check what's the reason and if what steps are needed to unblock it
<mup> PR snapcraft#1235 closed: store: API interactions for developer collaboration.  <Created by psivaa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1235>
<mvo> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial-snappy-dev-image/xenial/ppc64el/s/snapd/20170410_171526_28765@/log.gz has a test failure where even 40s worth of retries (search for "4 retries") we get no response - is linode in bad shape or our network?
<zyga> hrm, loooots of network.Timeout errors
<zyga> mvo: hey
<zyga> mvo: I just opened my laptop (on the walk, yes, nuts people here)
<zyga> mvo: I'm seeing the same thing
<mvo> zyga: ha! I have a question in the forum for you soon
<zyga> mvo: sure
<mvo> zyga: so do you think its linode? or store?
<zyga> mvo: that's interesting, I think linode
<zyga> mvo: my reason is that I saw numerous SSL handshake errors while git clone on linode test setup
<zyga> mvo: so there are two consistent places where networking is observed as flaky
<zyga> mvo: but no measurements really
<zyga> mvo: I'm in a fast-food restaurant as my kids dragged us here, I may use my spread key to run some silly network tests and see what works
<zyga> mvo: but not sure how to do it
<zyga> mvo: I was thinking about a hourly "health check" that git clones all the repos we care about
<zyga> mvo: and asks the store for stuff
<zyga> mvo: contains grep for retry counts
<zyga> mvo: and git clone errors
<zyga> mvo: and reports this somewhere
<zyga> mvo: but again one of those things I probably never get to finish as I have no recent web konwledge to plot this anywhere
<zyga> mvo: what was your question?
<mvo> zyga: what was the remaining issue in the plug renaming ? you mentioned there was something new that came up?
<zyga> mvo: aha
<zyga> mvo: sorry, I was meaning to paste but then didn't
<zyga> mvo: it was here on irc
<zyga> mvo: do you have logs?
<mvo> zyga: yeah, but some context is missing for some reason, is there a short summary?
<zyga> mvo: starts with `18:04 < niemeyer> zyga: About #3145, a question:
<zyga> mvo: I can pastebin that part of the log if you don't have a IRC logs
<zyga> mvo: but
<zyga> mvo: gustavo asked one fundamental question
<ogra_> https://irclogs.ubuntu.com/2017/04/10/%23snappy.html
<zyga> mvo: network-bind was on old and new core (ubuntu core and core)
<ogra_> ;)
<zyga> mvo: or wans't it?
<mvo> zyga: correct
<zyga> mvo: ok, so it should have been migrated
<zyga> mvo: unless there old core didn't have the plug
<zyga> then no connection and no migration (of connections)
<ogra_> old core didnt have a config hook
<zyga> mvo: the question is this: is the transition bug affected by the clashing plugs we found later
<ogra_> that is ubuntu-core didnt
<zyga> aaaah
<zyga> ogra_: thanks!
<ogra_> :)
<zyga> mvo: to finish that thought: so are we missing something
<mvo> zyga: no plugs in ubuntu-core
<zyga> mvo: (i.e. was there something else at play)
<zyga> but if the network-bind *plug* (called just network-bind) was first on the new core snap (not ubuntu-core)
<zyga> then everything broken is accounted for IMO
<zyga> as it is just a new plug that has two auto-connect options
<zyga> mvo: does that make sense?
<zyga> darn so many network issues in linode now
<zyga> does linode have a status page?
<zyga> https://status.linode.com/
<zyga> all stuff operational
<zyga> but I see red on PRs all around
<mvo> zyga: hm, why do we have the bug in network-bind but not in core-support ? that transient correctly, no?
<zyga> mvo: core-support is a new thing, old core did not provide it
<zyga> mvo: and also, maybe, no tests for that
 * zyga checks
<mvo> zyga: its something added via snap/implicit.go
<zyga> mvo: no tests for core-support
<zyga> mvo: I mean, no spread test
<mvo> zyga: to see if the transition for that works?
<zyga> mvo: checks for anything related to core-support
<zyga> mvo: anything, just grep is empty
<zyga> mvo: so if it is connected or not, we don't know
<zyga> mvo: but since it's not in old ubuntu-core I suspect it's not affected
<zyga> mvo: and this whole rabbit hole started because federico pointed out a failing test in some other repo
<mvo> zyga: what does "its not in old ubuntu-core" mean?
<zyga> mvo: and we started pulling
<zyga> mvo: the "core-support" slot is not provided by "ubuntu-core"
<zyga> mvo: so when "core" is installed it is connected normally as there's one provider, the new core itself
<zyga> mvo: if anything I'm saying is fishy please shout, I really want to make sure we've got tihs
<mvo> zyga: core-support is only added via implict.go and those are added to both ubuntu-core and core, no?
<zyga> and this release is uneventful
<zyga> mvo: was it added by snapd that is present in ubuntu-core?
<zyga> mvo: aaha
<zyga> mvo: classic
<mvo> zyga: yeah :) I'm just trying to understand it better
 * zyga wonders
<zyga> mvo: so my theory is that
<zyga> mvo: because ubuntu-core is old
<zyga> mvo: there'd be no core-support interface there
<zyga> mvo: and even if, no test is measuring that
<ogra_> it was also never added to the snapcraft.yaml in ubuntu-core ...
<mvo> zyga: I add the test now :)
<zyga> mvo: so we only noticed because network-bind was measured via spread
<zyga> ogra_: yes, because it's implicit
<ogra_> ah, right
<zyga> ogra_: implicit is very tricky, some only get added depending on os-release
<zyga> mvo: thank you!
<ogra_> yeah
<mvo> zyga: whats strange is that the code that can do the transition also knows about the implicit core-support so when that code runs ubuntu-core should have core-support
<zyga> mvo: https://github.com/snapcore/snapd/pull/3159 is green in travis and 2/4 adt passed
<mup> PR snapd#3159: store: retry once on hashsum mismatches in a Download() <Created by mvo5> <https://github.com/snapcore/snapd/pull/3159>
<mvo> zyga: but yeah, let me add core support
<zyga> mvo: rest are timeouts
<zyga> mvo: ack/nack?
<ogra_> mvo, but that would only be true if someone actually released an ubuntu-core after the ocde was added ... did we release new ubuntu-core since ?
<mvo> zyga: it needs review, we need to decide if we want to do one retry unconditionally (thats what the branch is doing) or doing it *only* if we had partial content in a previous retry
<zyga> mvo: ohhh, sorry,
<mvo> ogra_: yes, we have to. otherwise we don't transition
 * zyga was watching wrong PR
<ogra_> (i mean, unless someone uses ubuntu-core from edge )
<zyga> mvo: I meant >https://github.com/snapcore/snapd/pull/3163
<mup> PR snapd#3163: tests: adjust to look for network-bind-plug <Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/3163>
<zyga> 3 failures, travis green
<mup> PR snapd#3163 closed: tests: adjust to look for network-bind-plug <Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3163>
<mvo> ogra_: if you use ubuntu-core ages old then things don't transition. or only if you updated the deb but never did a successful snap refresh that pulls in a new ubuntu-core which is possible but would be strange
<zyga> mvo: all network related
<zyga> as in timeout
<mvo> zyga: +1
<zyga> not network-bind :)
<zyga> thanks!
<zyga> I'll merge this into other PRs now
<mvo> ta
<mvo> zyga: test is running now (about connected core)
<mvo> zyga: eh connected core-support
<mvo> zyga: I still wonder if we should merge network-bind into core-support but I don't think it buys anything and also we need to understand why network-bind acts like it acts and core-support (maybe) dosn't - or maybe it does
<ogra_> we really need to become more creative with our naming
<ogra_> core and classic are both so overused everywhere now
<zyga> mvo: we can next time
<zyga> mvo: I think we need to re-think core plugs
<mvo> zyga: yes, after the fire. sorry for pushing out the distraction
<ogra_> i dont see why we need confinement at all for it
<ogra_> given we are in full control of the hook it could well be unconfined
<zyga> mvo: no worries, I think it's a valid way out of the problem
<zyga> mvo: kill all those plugs
<zyga> mvo: and make the connection implicit
<zyga> well
<zyga> not connection, permissions
<zyga> *maybe*
<zyga> it's something to discuss
<mvo> zyga: test for core-support works, trying network-bind now
<zyga> mvo: all 2.24 PRs restarted
<mvo> ta
<zyga> mvo: I didn't reply to comments on https://github.com/snapcore/snapd/pull/3145 yet
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> mvo: I need to reply to niemeyer about his questoin
<zyga> but I need to move now (family)
<zyga> can you take that please?
<zyga> niemeyer: I think, based on my understanding and discussion with ogra and mvo, that the name clashes are not a factor in core transition
<zyga> I wish I had irssi on screen now
<mvo> zyga: I don't see open comments in there
<mvo> zyga: happy to reply of course
<mvo> zyga: once I know where to :)
<mvo> zyga: but go if your family needs you
<mikeb_> Chipaca: Snappy daemonization issues part 1.  https://github.com/mabnhdev/snappy-daemon-demo - See the README file.
<zyga> mvo: refreshing
<zyga> maybe stale page
<cachio> sergiusens, I am creating a dashboard with some kpi for ubuntu core, I  thought perhaps we can do the same for snapcraft
<cachio> sergiusens, the idea would be to detect any regression just looking at the dashboard
<cachio> sergiusens, it is the current one for snap core https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-ubuntu-core-dashboard?editorTab=Metrics
<zyga> mvo: walking with open laptop, I see questions from pedronis that I have to answer
<cachio> sergiusens, any suggestion? what do you thing about that?
<mvo> zyga: yeah, I can look at those
<cachio> sergiusens, it is being executed in real hardware
<pedronis> mvo: zyga: yes, agreed the name clash is not the factor there, I think having just a forum topic for both issues (named after only one)Â has probably confused things
<zyga> pedronis: yes, it was started with this, but I do think those are separate two problems
<zyga> pedronis: thank you for your input!
<Erix> hi
<Erix> is this the right place to ask a question about ubuntu nextcloud snap help?
<pedronis> mvo: I had no blocker question, the issue is mostly understand what those branches do all together, one of my question is that it seems at least two of the fixes will never need to be done together which is good, but part of that understanding
<mvo> pedronis: I think we don't understand the issue yet tbh
<pedronis> mvo: which one? :)
<mvo> zyga: so I added a test that ensures that things are connected - core-support is connected, network-bind is not. this is with the new network-bind-plug
<mvo> pedronis: the transition issue
<pedronis> well we install core while ubuntu-core is present
<pedronis> no?
<mvo> pedronis: yes
<zyga> mvo: this matches an existing test that has the same expectation and outcome
<pedronis> at least autoconnect will not work in that case
<zyga> mvo: just runs nightly
<mvo> pedronis: why does it work for core-support ?
<zyga> feerico has it someqhere
<pedronis> mvo: does the old ubuntu-core has a core-support plug?
<pedronis> sorry
<pedronis> slot?
<mvo> pedronis: its added via snap/implicit.go for anything that is an OS
<mvo> pedronis: so I would say yes
<mvo> pedronis: this is the part that confuses me
<pedronis> mvo: well, added when?
<zyga> pedronis: in ifacestate
<pedronis> mvo: if you have something where you can run this through IÂ would recommend adding logging in the autoconnect bits
<mvo> pedronis: its added in 6 places or so
<pedronis> mvo: yea
<mvo> pedronis: yeah, I add logging
<pedronis> mvo: notice that sometimes it depends if info comes from repo
<pedronis> or from snapmanager
<mvo> pedronis: but still strange, one would assume that when both core-support and network-bind are added via implicit.go either both get connected or none, but not one and and not the other
<pedronis> snapmanager is not so good at adding implicit slots
<pedronis> mvo: well, no
<pedronis> mvo: there's another factor the snap declaration
<pedronis> possibly
<mvo> pedronis: ohhhhh
<zyga> mvo: that is how auto connect works
<pedronis> network-bind is autoconnect for everything, no?
<pedronis> core-support I need to recheck what we did exactly
<sergiusens> cachio: you will want to talk to elopio, we have something similar going on
<mup> PR snapd#3158 closed: store: add download test with EOF in the middle <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/3158>
<sergiusens> bring it up on the forums or rocket
<zyga> pedronis: no, same behavior but we only tested it and noticed
<mvo> sergiusens: yeah, I think thats exactly it, core-support has only a single candidate
<pedronis> zyga: ?
<zyga> 20:14 < pedronis> network-bind is autoconnect for everything, no?
<pedronis> zyga: I mean the declarations doesn't block autoconnect for network-bind
<mvo> pedronis: hm, maybe not - basedeclartion allows plug-snap-type: core so both core and ubuntu-core should be allowed(?=
<zyga> right
 * mvo needs to step out for a little bit
<pedronis> mvo: I'm looking, that stuff is confusing
 * zyga didnt think about assertions
<mvo> pedronis: indeed
<pedronis> mvo: it says deny-auto-connection: true
<mup> PR snapd#3164 opened: tests: ensure network-bind and core-support are connected <Created by mvo5> <https://github.com/snapcore/snapd/pull/3164>
<pedronis> so it's back to the snap-declarations
<pedronis> let me look at those
<mvo> zyga, pedronis: the above PR should be good to test that our fix actually works
<mvo> (and it looks like it does not, i.e. we need to figure the root cause still and not just fixup on the next run :/)
<sergiusens> mvo: not for me I guess
<zyga> hmmm
<zyga> mvo: what makes you say so?
<pedronis> mvo: zyga: so the sna-declaration of both core and ubuntu-core will not let core-support connect
<pedronis> well auto-connect
<pedronis> bit wondering how it works at all
<zyga> store assertion?
<zyga> on core
<pedronis> yes, store assertion
<pedronis> on both
<pedronis> the base declaration just says   deny-auto-connection: true
<pedronis> so they cannot auto-connect, not sure how the configure hook works now
<pedronis> but the fact is not interfaces is kind of expected
<zyga> mvo: sorry to nag but I want to make sure I'm not missing anything, what makes you say that we've still haven't gotten to the bottom of it and tests confirm that
<pedronis> given that, transition or not
<pedronis> ah, no
<pedronis> confusing
<zyga> pedronis: I'm trying to parse two previous lines
<zyga> pedronis: cna you re-phrase that
<pedronis> zyga: sorry
<zyga> sorry, just tired and really want to understand what's going on here precisely
<pedronis> zyga: so network-bind doesn't autoconnect? but core-support does?Â or is that the reverse?
<zyga> pedronis: network-bind does auto-connect AFAIR, let me check
<zyga> core-support doesn't autoconnect
<zyga> ah, super confusing
<zyga> sorry
<zyga> we don't know if core-support connects in practice
<zyga> my two statements were "obvious" intents but not facts
<zyga> network-bind did not connect according to a test that fgimenez ran
<pedronis> at least the declarations now that I read them carefully should let them both autoconnect
<zyga> pedronis: yes, that is certainly the intent
<zyga> pedronis: that both plugs connect to core and perhaps to ubuntu-core as well (not sure)
<pedronis> though only os snaps can have core-support plugs or slots
<zyga> pedronis: what was measured is that ubuntu-core -> core transition started failing in nightly tests where the network-bind *plug* was not connected
<zyga> pedronis: and at the time we didn't check core-support *plug*
<pedronis> well, unless the slots are added differently they should behave similarly afaict (at least for the os snap)
<mvo> zyga: sorry for being confusing. so https://github.com/snapcore/snapd/pull/3164/files#diff-23e6c1e2bbf5a1a24798303971f19b99R83 works
<mup> PR snapd#3164: tests: ensure network-bind and core-support are connected <Created by mvo5> <https://github.com/snapcore/snapd/pull/3164>
<mvo> zyga: however the line below does not
<mvo> zyga: so core-support appears to be fine and connected but network-bind is not
<zyga> mvo: so line 83 works and line 84 doesn't work?
<mvo> zyga: correct
<pedronis> there is no difference between them though
<zyga> mvo: can you show me the debug output, do you have snap interfaces there?
<mvo> zyga: sure, one sec
<zyga> pedronis: maybe, do we auto-add "core-support" to ubuntu-core too?
<zyga> pedronis: if so, yes, I agree
<mvo> zyga: http://paste.ubuntu.com/24356000/
<zyga> also not sure how this test works
<zyga> which snapd is used while ubuntu-core is installed?
<zyga> some ancient one
<zyga> or master?
<pedronis> the question is about the slots
<zyga> `:core-support             core:core-support-plug`
<mvo> zyga: this is pretty recent master
<zyga> so it's connected
<pedronis> so yes, they should be added the same way
<zyga> pedronis: interesting
<zyga> walking home
<zyga> 10 min
<mvo> zyga: the full log, sorry its huge http://paste.ubuntu.com/24356011/
<zyga> thnx
<mvo> zyga, pedronis: sorry, really need to step out for some minutes now
<mvo> zyga, pedronis: but please keep me updated, bbiab
<pedronis> zyga: ah, but now we check both sides, plug to slots and slots to plugs
<pedronis> for autoconnect
<zyga> yes
<zyga> for some time
<pedronis> so slots we know they both have both, because we add them
<pedronis> but plugs, IÂ don't know
<pedronis> I mean slots are added implicitly
<zyga> pedronis: ubuntu-core snap has neither plugs
<zyga> pedronis: we don't add implicit plugs
<pedronis> does the ubuntu-core we use has   a core-support plug?
<zyga> re, sorry, wifi connected and n-m bugs galore
<zyga> 20:39 < zyga> pedronis: ubuntu-core snap has neither plugs
<zyga> 20:39 < zyga> pedronis: we don't add implicit plugs
<zyga> pedronis: that's what I said / saw last
<pedronis> no plug ?
<pedronis> that would provoke the reverse problem
<pedronis> IÂ mean if it has no plug then we are back that the two should be symmetric
<zyga> pedronis: ubuntu-core does not have network-bind plug or core-support plug
<zyga> pedronis: only core has those
<zyga> pedronis: yes, I think something is fishy still
<pedronis> then when we try to connect from slots they should both work?
<zyga> pedronis: I just got home, setting up to dig
<zyga> pedronis: no, because the plug on core has two candidates again, core and ubuntu-core
<zyga> pedronis: because slots are added, even to ubuntu core
<pedronis> zyga: we try from both sides
<zyga> pedronis: yes
<zyga> pedronis: maybe I misunderstand your point
<pedronis> zyga: so when we try on core from slots
<pedronis> it doesn't matter how many slots there
<pedronis> are
<pedronis> only plugs
<zyga> pedronis: aha, let me see
<pedronis> but then as I said
<pedronis> IÂ still don't understand why those two don't work the same
<zyga> pedronis: in both auto-connect "sides" (plug/slots) we don't connect if more than one viable candidate; so yes, fishy
<pedronis> yes, so the from plug side is expected to fail
<zyga> pedronis: but looking at it I also found: // Suggested connection already exist so don't clobber it.
<pedronis> because two slots
<zyga> pedronis: so maybe the clashing names have some impact
<pedronis> but the from slots, don't understand why one works and the other not
<zyga> we check if a conn state exists
<zyga> and
<zyga> if by that time we migrate ubuntu-core to core
<zyga> maybe something weird happens
<zyga> like core:network-bind core:network-bind
<zyga> so we don't connect it from that side now
<zyga> plausible?
<zyga> (that would explain why rename of plug might fix it)
<zyga> or would it, mmmmmm
<zyga> well, tired
 * zyga looks for errors in that code
<zyga> maybe something swapped
<pedronis> anyway indeed ubuntu-core has neither plug
<pedronis> at least at stable
<zyga> pedronis: yes but remember our tests do magic repacking so maybe we're missing something non-obvious there
<zyga> pedronis: I'd like to see a old-snapd update to new-snapd without any magic
<pedronis> we have a different bug it seems snap download now defaults to edge ???
<zyga> pedronis: what is in the snap declaration for ubuntu-core
<zyga> pedronis: or how can I see that with snap known
<pedronis> there is nothing interesting in the snap declarations
<pedronis> for both core or ubuntu-core
<zyga> pedronis: no? what about assertions?
<pedronis> ?
<zyga> pedronis: newAutoConnectChecker
<pedronis> I mean they don't have any plugs or slots bits
<zyga> aha
<pedronis> all it matters is the base declaration
<pedronis> afaict
<zyga> pedronis: so how do we let core-support connect, via base?
 * zyga looks
<pedronis> it's confusing
<pedronis> but the only control we do is really that core-support plugs and slots can only be on os
<pedronis> nothing else
<zyga>       plug-snap-type:
<zyga>         - core
<zyga> we have no "core" type, we have "os"
<zyga> is that just a discrepancy?
<pedronis> yes core==os
<zyga> ok
<pedronis> TypeOS is still the internal name
<pedronis> but core is what is used in the decls
<ogra_> to make it less confusing ? :)
<zyga> ogra_: decls are public
<zyga> ogra_: we can fix the core code without anyone noticing
<ogra_> well, the snapcraft.yaml uses type: os :)
<zyga> ogra_: I think we wanted to wait with that as it is old stuff
<ogra_> so in other code i'd also expect to find "os" when something is called "type"
<zyga> ogra_: old == existing
<zyga> ogra_: and declarations were new
<ogra_> heh
<zyga> ogra_: so we added the right language
<zyga> ogra_: we'll correct core's snap.yaml in due time
<ogra_> k
<zyga> ok, with https://github.com/snapcore/snapd/pull/3164 I can test a few theories
<mup> PR snapd#3164: tests: ensure network-bind and core-support are connected <Created by mvo5> <https://github.com/snapcore/snapd/pull/3164>
<zyga> give me 15 minutes, let's see
<zyga> ok, test in progress
<zyga> I will have some useful data in 15 minutes
<zyga> when spread finishes
<zyga> hmm
<zyga> dh_install: snapd missing files: usr/bin/snap-update-ns
<zyga> what happened there?
<ogra_> missed a git add ?
<zyga> no
<zyga> it was removed
<zyga> something resurrected that line
 * zyga looks
<zyga> I see
<zyga> `-usr/lib/snapd/snap-update-ns
<zyga> ok, I must be missing something
<zyga> aha
<zyga> -resend
<ogra_> debian/snapd.install
<zyga> sorry
<ogra_> i see it in there
<zyga> ogra_: what do you see?
<ogra_> look in debian/snapd.install
<zyga> ogra_: can you paste the line
<zyga> ogra_: running out of ram...
<ogra_> there is a line for it
<zyga> gah
<ogra_> usr/bin/snap-update-ns /usr/lib/snapd/
<zyga> ogra_: there is one but is is different than mine?
<zyga> that's the *correct* line
<zyga> it's installed from usr/bin because it's a go binary now
<zyga> I just restarted spread
<ogra_> oh, i missed the "lib"
<zyga> the lib is ok too, not changed
<zyga> anyway, checking again
<zyga> I think it was missing -resend
<niemeyer> zyga, mvo: I think I reviewed the critical things.. am I missing something still?  What's the outcome of the prior conversation on the de-dup of adding plugs/slots?
 * zyga has logs and reviews them now
<zyga> niemeyer: we are pursuing one thread that we still don't understand wrt why network-bind is affected but core-support is not
<zyga> niemeyer: I added something that may help us to understand to logs, reading them now
<zyga> niemeyer: mvo posted a PR 3164 that shows the failure on vanilla master
<zyga> niemeyer: no other updates yet
<tvoss> niemeyer: how do you propose to revert the state of the current branch? just start over and cherry pick commits?
<mvo> zyga: here is an interessting though - network-bind is used in the tests in both test-snapd-python-webserver and also in core, if I remove test-snapd-python-webserver things seem to work
<mvo> zyga: I'm double checking that now
<niemeyer> zyga: Ok
<niemeyer> tvoss: Need some more context
<tvoss> niemeyer: for the changes to device key creation
<mvo> niemeyer: we want to get to the bottom of this just to be sure we don't overlook another problem, its a bit thorny right now
<cachio> niemeyer, I have created this dashboard with tome kpis for ubuntu core, https://platform-qa-dashboard.canonical.com/dashboard/db/kpi-ubuntu-core-dashboard
<mvo> zyga: yes, so with test-snapd-python-webserver -> core gets no network-bind. without anything in network-bind: things work
<cachio> niemeyer, just tell me if you are insterested to see other metrics on there
<niemeyer> cachio: Oh, nice, let me check it out
<cachio> niemeyer, all those metrics are obtained from executions on real hardware
<mup> Bug #1681547 opened: Gnome3 on Ubuntu 17.04 doesn't find snap desktop files <Snappy:New> <https://launchpad.net/bugs/1681547>
<cachio> niemeyer, any sugestion is welcome
<zyga> mvo: interesting
<zyga> mvo: I tweaked logs to be shorter and am trying again
<cachio> niemeyer, the idea is to detect any performance regression, but we could any other metric
<niemeyer> cachio: It would be nice to hook that up with our existing test suite
<niemeyer> cachio: The spread tests specifically
<cachio> niemeyer, we are working on that
<niemeyer> cachio: Ah, that's great then
<niemeyer> In theory that should cover most of the interactions
<cachio> niemeyer, I have created a change request in spread to export xunit format
<cachio> niemeyer, once we have that, then we can show test results and a lot metrics on grafana too
<zyga> mvo: interesting, any theory why?
<niemeyer> cachio: That's probably not coming, but you can use the format used to display timings in Travis to easily pick up the running time
<mvo> zyga: no idea right now, just a piece in the puzzle
<niemeyer> cachio: Ah, wait.. you mean you already did it, let me chcek
<cachio> niemeyer, https://github.com/snapcore/spread/pull/25/files
<mup> PR spread#25: Adding capability to write xunit report with the task suites and results <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/25>
<cachio> niemeyer, well the original idea was to run spread tests in real hardware and report results and performance times to grafana
<cachio> niemeyer, we are close to that
<mup> PR snapcraft#1247 opened: Fixing Store integration tests <Created by cprov> <https://github.com/snapcore/snapcraft/pull/1247>
<pedronis> zyga: because then the slots side doesn't work either, because there are two plugs in the system now
<pedronis> zyga: working from the plug side is more natural for autoconnect
<zyga> pedronis: !
<zyga> pedronis: aha, yes
<pedronis> here the slots side almost saves us
<zyga> pedronis: it also means our slot auto-connect is a bit wonky
<pedronis> but not if something else needs network-bind
<zyga> pedronis: it should connect all candidates if that's possible (all plugs)
<pedronis> yes, it doesn't make a lot of sense IÂ suppose
<pedronis> but not sure
<pedronis> anyway
<pedronis> now things make a bit of sense
<zyga> pedronis: thank you, this is a very good input,
<zyga> mvo: ^ I think it makes sense, and it matches what we observe
<zyga> mvo: I added logs for this, will know ... now
 * zyga reads
<pedronis> zyga: auto-connecting looking from the plugs on core doesn't work because we have core and ubuntu-core we the same implicit slots
<pedronis> zyga: auto-connection from core core-support slot work because there's only core plug (ubuntu-core doesn't have the plug)
<pedronis> zyga: network-bind isn't so lucky because from the slot side we observe both the core plug but also any other snap using network-bind plug
<pedronis> this also indeed shows that the new auto-connect logic we added from the slot side doesn't make complete sense
<pedronis> bit too tired to think how exactly it should work though
 * zyga hugs pedronis brilliance! thanks for solving it
 * mvo hugs pedronis as well
<zyga> ok, restarted tests to just capture the smoking gun log
<zyga> niemeyer: if that holds, what do you want us to do?
<zyga> niemeyer: it seems there's another bug where slot-side auto-connection is just silly and needs re-thinking
<zyga> niemeyer: and we now noticed
<pedronis> zyga: when we connect from the slot side IÂ suppose the question is not whether there just on matching plug, but whether there are no other snaps with a slot that would connect witht the same plugs as us
<zyga> pedronis: I think we may want to limit that to content if there's no connection
<zyga> pedronis: and nothing else maybe
<zyga> pedronis: (except core perhaps)
<zyga> pedronis: then re-think
<pedronis> so just find candidate plugs
<pedronis> and then reapply the logic from the other side
<pedronis> and see if we are the winner
<zyga> mmm
<pedronis> anyway not a quick fix for 2.24
<zyga> yes, I think so too
<zyga> mvo: tell me what you want to do now
<pedronis> it just seems that only network-bind plug has the problem we thought both had on core
<zyga> mvo: yes
<zyga> er
<zyga> pedronis: yes
<niemeyer> Folks, these conversations are much better held in the forum.
<niemeyer> The scroll will soon be over everybody's screens and those conversations will be lost.
<zyga> niemeyer: agreed
<pedronis> niemeyer: IÂ understand but IÂ don't see other solution that copying the result, thinking on the spot through the forum doesn't work for me
<niemeyer> zyga: I don't know what "that holding" means, for related reasons
<mvo> zyga: what I want to do :) ? fold network-bind into core support, release 2.24 and fix all the other stuff in 2.25 - but I'm not sure that is feasible
<niemeyer> pedronis: It's just a different window where you can type the same message. :)
<pedronis> I suspect that is not so simple (there are empires built on that :) )
<pedronis> anyway we don't even have a topic yet aboutÂ *this* problem
<pedronis> not the other one
<niemeyer> pedronis: Yeah, to be clear I'm mainly pointing out I see important conversations scrolling over
<niemeyer> pedronis: We sort of do.. https://forum.snapcraft.io/t/duplicate-plug-slot-names-inside-the-core-snap/184/22
<pedronis> that's not this problem
<niemeyer> pedronis: This is where we're discussing the problems related to network-bind and core-support
<pedronis> is not about names of plug at alls this one
<ogra_> thats rather a new topic ... about auto connection
<pedronis> yes
<zyga> pedronis: 2017-04-10T21:57:11+02:00 INFO cannot auto connect {core network-bind-plug} (plug auto-connection), candidates found: "core:network-bind,ubuntu-core:network-bind"
<niemeyer> mvo: Do we understand the issue of why one works and the other doesn't by now?
<zyga> pedronis: 2017-04-10T21:57:11+02:00 INFO cannot auto connect {core network-bind} (slot auto-connection), candidates found: "core:network-bind-plug,test-snapd-python-webserver:network-bind"
<zyga> pedronis: so you were totally right
<pedronis> niemeyer: yes
<zyga> mvo: ^
<zyga> niemeyer: yes, I think we do
<stokachu> did the ability to install from --edge disappear?
<ogra_> nope
<pedronis> no
 * ogra_ does it ever day
<stokachu> snap info conjure-up doesn't show the edge channel
<ogra_> does the store UI show it in the edge channel ?
<stokachu> yes
<ogra_> thats weird
<pedronis> zyga: do you want me to write something in the forum? or do you?
<zyga> pedronis: I'm writing
<pedronis> ok
<pedronis> IÂ think a different topic would be better
<pedronis> fwiw
<stokachu> i released this morning https://gist.github.com/battlemidget/f5670fe7450258c884eccdd309bdcdf3
<pedronis> especially the general autoconnect from slots issue
<tvoss> pedronis: https://github.com/snapcore/snapd/pull/3130 is back to the ssh-keygen state
<mup> PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<tvoss> tyhicks: ^
<mvo> niemeyer: the problem is understood now (thanks to pedronis!). the question is what we do. if we want to fix this all for 2.24 it will be at least tomorow, maybe even a day later
<mvo> niemeyer: I guess thats ok, unless we have some obligations to release soon (jamiebennett may know)
<stokachu> ogra_: do you see my snap in the edge channel?
<zyga> pedronis: done
<ogra_> stokachu, nope ...
<stokachu> that makes me sad
<niemeyer> mvo: Can we strive for tomorrow?  Today seems way too late given your timezones, and Wednesday feels too close to holidays
<zyga> pedronis: yes, I'll start a new topic for this but perhaps tomorrow
<mvo> niemeyer: we can strieve for tomorrow, zyga, pedronis ?
<ogra_> ogra@styx:~/Devel/branches/snapd$ snap info conjure-up|grep edge
<ogra_> ogra@styx:~/Devel/branches/snapd$ snap info core|grep edge:
<ogra_>   edge:      16-2 (1665) 83MB -
<ogra_> stokachu, definitely not there
<stokachu> so what's happening?
<mvo> niemeyer: alternatively we can paper over it via just having core-support
<zyga> mvo: I think we can, even current solutions are sufficient
<ogra_> stokachu, i guess you need a store person
<stokachu> the snap store shows revision 185
<ogra_> with a green box ?
<stokachu> yes
<mvo> niemeyer: i.e. we could remove the network-bind plug from core, fold that into ore-support and we have a working transition agian and fix things for 2.25
<zyga> mvo: we can do the core-support trick but I don't think even that is mandatory now
<ogra_> or just a thumbs up icon ?
<pedronis> mvo: as I said, I think the proper fix for slot autoconnect is more 2.25 material
<stokachu> nope it's published
<stokachu> ive been doing this awhile
<stokachu> :D
<pedronis> mvo: the issue here is really mostly that core and ubuntu-core coexist for a bit
<zyga> mvo: but I'd love to discuss that tomorrow morning :)
<ogra_> and if you go into the details of this revision it is also released to edge ?
<zyga> I wonder if we can EOD now
<stokachu> ogra_: yep
<pedronis> mvo: auto-connect from slot is just an escape hatch that works for one but not the other (because core-support is only on core)
 * ogra_ heard others complaining that their channels didnt end up being set (never seen that myself)
<mup> PR snapd#3165 opened: interfaces: adjust shm accesses to use 'm' for updated mmap kernel mediation <Created by jdstrand> <https://github.com/snapcore/snapd/pull/3165>
<niemeyer> pedronis, mvo: That sounds like it could be a problem even for core-support alon
<niemeyer> e
<ogra_> stokachu, well, then probably try nessita
<stokachu> nessita: hi
<pedronis> niemeyer: well ubuntu-core doesn't have the plug (but could have)
<pedronis> IÂ mean the plug for core-support
<pedronis> atm
<mvo> niemeyer: core-support alone is fine because nothing else uses core-support currently except core. ubuntu-core does not use any plugs
<mvo> pedronis: -^
<pedronis> mvo: won't that change? or we build ubuntu-core differently? without hooks?
<mvo> pedronis: we build ubuntu-core without hooks and there is no plan (AIUI) to change that
<niemeyer> mvo: Okay.. for some reason gut feeling says we should understand and fix the issue with both network-bind and ubuntu-core, as we're close to it
<niemeyer> Sorry
<niemeyer> network-bind and core-support..
<niemeyer> It feels like we're really close now
<zyga> niemeyer: I think the issue that needs more coding now is the behavior of auto-connect for slots
<pedronis> niemeyer: there are two issues
<pedronis> is not one issue
<zyga> niemeyer: (or both plgus and slots, but slots are more obviously wrong)
<pedronis> the 2nd issue make it so that we don't have lucky escape from the first
<stokachu> who else handles the snap store
<stokachu> i can't get edge to show up anymore
<mvo> stokachu: maybe noise][ can help you
<zyga> mvo: shall we regroup in the morning?
<stokachu> who can i email about this?
<pedronis> niemeyer: this is the 2nd issue: https://forum.snapcraft.io/t/auto-connect-logic-starting-from-slots-of-an-installed-refresh-snap-is-naive/236
<enoch85> hey guys
<enoch85> how do I import a snap from a .snap file?
<enoch85> do I need to install snap first, and then put that file in a certain dir or something?
<niemeyer> pedronis: Thanks, very clear
<mvo> zyga: yeah, I will follwoup in the forum
<niemeyer> enoch85: snap install filename.snap
<niemeyer> --dengarous
<niemeyer> --dangerous
<niemeyer> enoch85: The flag means you acknowledge the fact it's unsigned, unreviewed, and may do Bad Things
<zyga> mvo: ok
<zyga> I replied to pedronis' post already
<zyga> let's talk tomorrow, have a great evening everyone
<mvo> zyga: sleep well
<enoch85> niemeyer: aah ok nice
<enoch85> snap install /path-to/filename.snap ?
<stokachu> niemeyer: will the discourse forum have ubuntusso or other authentication mechanisms?
<stokachu> like github
<stokachu> rather use that then create another account
<ogra_> enoch85, --dangerous ... else it will not install
<ogra_> enoch85, but yeah, the rest is ccorrect
<enoch85> ogra_: ok thanks
<ogra_> stokachu, long term it will ... but not there yet
<enoch85> ogra_: I get this: ZOE ERROR (from /usr/lib/snap/snap): zoeParseOptions: unknown option (--dangerou)
<enoch85> ZOE library version 2013-02-16
<enoch85> what's up?
<ogra_> you missed an s ?
<enoch85> root@daniel-pc:~# snap install /home/daniel/Desktop/nextcloud-client_continuous.gitb02dab3_amd64.snap --dangerous
<enoch85> ZOE ERROR (from /usr/lib/snap/snap): zoeParseOptions: unknown option (--dangerous)
<enoch85> ZOE library version 2013-02-16
<enoch85> no?
<ogra_> snap version ?
<ogra_> (whats the output of that ?)
<enoch85> tbh I'm on Debian
<enoch85> did apt install snap
<enoch85> snap version just gives me what I should wrote to get an output
<enoch85> like a help sort of
<enoch85> SNAP - Semi-HMM-based Nucleic Acid Parser (version 2006-07-28)
<enoch85> might be helpful?
<ogra_> err
<ogra_> apt purge snap ...
<ogra_> apt install snapd
<ogra_> snap is a media player ...
<enoch85> ok sec
<ogra_> you want snapd
<enoch85> aah better
<enoch85> yup
<enoch85> that solved it
<enoch85> thanks
<ogra_> :)
<enoch85> now where is the snap?
<enoch85> hmm
<enoch85> can't find it in my launcher
<enoch85> (on Desktop)
<ogra_> you might need to log out and back in again ... snapd puts an XDG_DATA_DIR entry in the Xorg start scripts to find the .desktop files ...
<enoch85> ogra_: got it from here: https://github.com/nextcloud/client_theming/releases
<enoch85> okok
<enoch85> will try
<enoch85> sec
<enoch85> ogra_: yaay it worked
<ogra_> :)
<ogra_> enjoy
<enoch85> now, if I want to update the snap, do I just download the new snap and type snap install again?
<enoch85> or do I have to remove old stuff also?
<ogra_> just snap install should be fine
<ogra_> or better ask oparoz to upload it to the store ... then it would auto-update
<zyga> niemeyer: just before I EOD, I updated https://github.com/snapcore/snapd/pull/3153 and https://github.com/snapcore/snapd/pull/3154 as suggested
<mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <https://github.com/snapcore/snapd/pull/3154>
<pedronis> niemeyer: I think now the forums capture what we found here
<zyga> niemeyer: if you +1 both we can have an easier morning
<pedronis> s/forums/forum/
<enoch85> ogra_: thanks :D
<ogra_> np :)
<Pharaoh_Atem> zyga, morphis: looks like all the tests failed https://github.com/snapcore/snapd/pull/3162 :(
<mup> PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162>
<morphis> Pharaoh_Atem: infrastructure issues ..
<morphis> Pharaoh_Atem: will retrigger tomorrow
<Pharaoh_Atem> bully :/
<zyga> morphis: merge master and retry
 * zyga is off now
<enoch85> wow snaps are great!
<enoch85> like .exe for windows (sorry for the comparison ;) )
<enoch85> or .msi maybe
<niemeyer> enoch85: Haha, thanks, I guess! ;)
<Pharaoh_Atem> enoch85: it's basically like self-contained zip thingies for Windows
<Pharaoh_Atem> or the way apps are handled on MacOS
<enoch85> great stuff
<enoch85> once you go snap you never go back
 * Pharaoh_Atem sighs
<niemeyer> zyga: They're both approved
<niemeyer> enoch85: You can actually go back.. see "snap revert --help"
 * niemeyer ducks
 * Pharaoh_Atem knew that was coming
 * zyga hugs niemeyer
<zyga> just returned to the office to feed the fish and turn lights off
<Pharaoh_Atem> you have an office?
<enoch85> niemeyer: haha
<zyga> niemeyer: given all the data now can you update your stance on https://github.com/snapcore/snapd/pull/3145
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<zyga> niemeyer: the needs fixing is 4 days old
<ogra_> Pharaoh_Atem, i find more interesting that he has fish TBH
<ogra_> **in* his office
<Pharaoh_Atem> well, I mean, yeah, that too :)
<zyga> Pharaoh_Atem: yes, it's a separate room upstaris
<zyga> Pharaoh_Atem: duplex appartment (is that the right term?)
<mvo> niemeyer: I feel slightly uneasy if we go out with the current set of 2.24 fixes but not the fix for the autoconnect, then core interfaces will only connect because we fixup things in 3145 after the fact. i put an alterative fact^Widea into the forum. but its just my gut feeling, so happy to be overriden
<zyga> Pharaoh_Atem: essetially small part of attic
<ogra_> maisonette :)
<Pharaoh_Atem> ah
<mvo> niemeyer: (hope there is enough context in the above)
<Pharaoh_Atem> zyga: it's a duplex place if it has its own AC, bathroom, and kitchen area
<Pharaoh_Atem> if it lacks that, then it's just a multi-level apartment
<zyga> Pharaoh_Atem: no, just window :)
<zyga> Pharaoh_Atem: and the door is downstairs
<zyga> Pharaoh_Atem: just 2nd level with attic and roofless terrace
<nessita> stokachu, hi
<nessita> stokachu, how can I help you?
<niemeyer> zyga: isn't the statement there still true?
<niemeyer> zyga: Actually, the conversation today
<niemeyer> zyga: We discussed it here rather than in the PR.. I'll update the PR as I should have done originally, sorry
<niemeyer> mvo: Looking
<zyga> niemeyer: thank you! that's all I need
 * pedronis should call it a day
 * tvoss calls it a day
<niemeyer> zyga: Updated #3145 with a summary of what we discussed about it here
<niemeyer> mvo: Replied in the forum
<niemeyer> tvoss: Have a good night
<tvoss> niemeyer: would be great if you could follow up on tyhick's question here: https://github.com/snapcore/snapd/pull/3130
<mup> PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<tvoss> niemeyer: would like to pick up tomorrow my morning
<mvo> niemeyer: thanks a lot ! I will catchup with zyga and pedronis in the european morning and prepare something. thanks again! and a huge HUG to zyga and pedronis for getting to the bottom of this
<pedronis> mvo: zyga: I just noticed that if we fix slot-driven autoconnect correctly the bug is there, we have a plug and two slots we cannot autoconnect
<pedronis> so we really need to special case this (core and ubuntu-core both around) somehow, at some point
<pedronis> slot-driven autoconnect is quite buggy, and core-support works out because of the bug
<pedronis> atm
<zyga> pedronis: yes, I saw; is that fixed with the special hack that ignores the "ubuntu-core" candidate or should I EOD, am tired, and don't understand that correctly?
<mup> PR snapd#3166 opened: interfaces/builtin: fold network-bind into core-support <Created by zyga> <https://github.com/snapcore/snapd/pull/3166>
<pedronis> zyga: we need something like that, exactly how and where not sure, I fear we get things double connected for a bit that way?
<pedronis> is that a problem?
<zyga> pedronis: same plug to same slot?
<zyga> pedronis: no, that's a no-op
<zyga> pedronis: (and also not an error)
<zyga> mvo: fold idea in PR above, no tests, let's discuss this tomorrow :)
 * zyga really tries to get away now
<mup> PR snapcraft#1229 closed: sources: add VCS asset tracking <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1229>
<mvo> zyga: \o/ I can work on this further in my morning and we catch up
<pedronis> mvo: the fold will help us only until we fix autoconnect :/
<mvo> zyga: *go away*
<pedronis> so not sure it's a winner
<mvo> pedronis: yes, but I think thats ok
<mvo> pedronis: well, maybe
<mvo> pedronis: I am bit concerned that 2.24 slips even further if we try to fix all the bugs and we are also in a bit of a rush because the 2.24 is sitting on our shoulders which is also not great. I'm trying to find something minimal we can do to move us forward
<mvo> pedronis: *but* having said that, if the minimal fix/workaround is no good, we need to bite the bullet I think :/
<pedronis> my worry is that we do a strange things and then things are broken again
<mvo> pedronis: your input is very important here, if you think its not the right approach I think we need to reconsider
<pedronis> as IÂ said IÂ don't think we need to fix autoconnect now fully
<pedronis> but we should not also do something that is broken again
<pedronis> once we do that IÂ think :/
<mvo> pedronis: well, we will have a test that ensures we don't break things accidently
<mvo> pedronis: the ubuntu-core -> core transition one will have the new check that core-support is connected
<mvo> pedronis: but if we go down the other route and not fold things, we still need to do something with auto-connect, no?
<pedronis> what I'm saying is that we will need some form of #3145 at some point anyway
<mvo> pedronis: or do you think the 3145 workaorund is good enough? it
<mvo> pedronis: aha, ok
<mvo> pedronis: we would probably only need this part https://github.com/snapcore/snapd/pull/3145/files#diff-b88a3954d898e0a8ab681d98f1407a0fR332 though?
<mup> PR snapd#3145: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3145>
<pedronis> mvo: because as I said during the transition we have two slots
<pedronis> so autoconnect wouldn't work unless we break the tie somehow
<mvo> pedronis: what I dislike about 3145 is that we go into a buggy state and then fixup things
<pedronis> mvo: first of all I'm not sure we need the fixup bit
<mvo> pedronis: this fixup we will need to keep forever but if we fold network-bind into core-support I think we can get away without a fixup
<mvo> pedronis: hm, thats interessting
<pedronis> mvo: we do setup profile with the new core no
<pedronis> before running the hook
<pedronis> mvo: so autoconnect itself at that point should fix things if we convince to do the right thing
<mvo> pedronis: aha, but not with 3145 as it is now, right?
<mvo> pedronis: some more code is needed for that
<pedronis> mvo: probably less code
<mvo> pedronis: less code is good :)
<pedronis> as I said we don't need the fixup
<mvo> pedronis: won't we  need it for systems who are already in this state(?)
<pedronis> mvo: I think the question is really what do in autoConnect
<pedronis> mvo: well, they can be fixed only with a new core, no?
<pedronis> and the new core will run setup-profiles for itself?
<pedronis> no?
<mvo> pedronis: oh, indeed
<mvo> pedronis: yes, that should work!
<niemeyer> School run
<pedronis> mvo: IÂ put some comments about what we discussed in #3145 itself, we should see what to do with it in morning, maybe it can be just cut down to the barebones
<mvo> pedronis: thanks a lot! yeah, lets catchup in the morning
<mvo> pedronis: I have to say https://github.com/snapcore/core/pull/33 and https://github.com/snapcore/snapd/pull/3166#pullrequestreview-31963086 look really compelling to me as a way outâ¦
<mup> PR core#33: the core snap only needs core-support  (not network-bind) <Created by mvo5> <https://github.com/snapcore/core/pull/33>
<mup> PR snapd#3166: interfaces/builtin: fold network-bind into core-support <Created by zyga> <https://github.com/snapcore/snapd/pull/3166>
<mup> PR core#33 opened: the core snap only needs core-support  (not network-bind) <Created by mvo5> <https://github.com/snapcore/core/pull/33>
<mvo> pedronis: for now at least. but I am sleepy now so I guess I tend to gravitate to the simple solution even more so than usually :)
<mvo> pedronis: but indeed, we need to fix the auto-connect code in any case at some point
<pedronis> mvo: well, as I said it will broken again once we fix stuff
<mvo> pedronis: indeed
<pedronis> so unless we think is the right thing in some sense, it's not a super win
<mvo> pedronis: lets talk in the morning, thanks again for all these insights :)
<mvo> pedronis: fair point
<pedronis> mvo: I can see argument that would make it make sense, but anyway tomorrow
<mvo> pedronis: that would make sense to use the "cheap" workaround you mean?
<mup> PR snapd#3161 closed: snap-confine,browser-support: /dev/tty for snap-confine, misc browser-support for gnome-shell <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/3161>
<jdstrand> mvo: hey, not sure if you want to pull that ^ into 2.24
<mvo> jdstrand: absolutely
<jdstrand> mvo: cool, thanks
<mvo> pedronis: I'm off now, more tomorrow. /me waves
<mup> PR snapd#3154 closed: many: rename two core plugs that clash with slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3154>
#snappy 2017-04-11
<mbenz> Did you see Tino is gone as of today?
<morphis> morning!
<tvoss> good morning :)
<mup> PR snapd#3167 opened: interfaces: fold network bind into core support with tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/3167>
<tvoss> pedronis: so tyhicks is proposing /run/snapd as the place to put the temporary key files
<tvoss> pedronis: is that reasonable for you?
<zyga> good morning
<zyga> tvoss: what's up? :-)
<tvoss> zyga: aiming to finalize the key generation PR
<zyga> tvoss: mhm
<zyga> mvo: hey
<tvoss> zyga: tyhicks is proposing /run/snapd to place the temporary key files, I'm fine with that. Do you have any objections?
<zyga> mvo: I merged one of the approved PRs last night
<zyga> tvoss: who will place them there?
<tvoss> zyga: snapd itself, when generating the device key. cleaning them up once the operation finishes
<zyga> tvoss: /run/snapd/lock and /run/snapd/ns are touched by snap-confine but I think this is fine
<zyga> tvoss: maybe you can use a sub-directory, not sure what your plan is fully
<tvoss> zyga: I just need a place to put the key files temporarily
<zyga> tvoss: and /tmp is not good?
<tvoss> zyga: so readable/writable by snapd only is pretty much the only requirement
<zyga> aha
<morphis> zyga: so this static/non-static build of snap-confine is really tricky now, why did you drop the the --enable-partially-static thing and switched to individual --enable-static-* switches?
<tvoss> zyga: with that, /run/snapd seems like a good choice
<zyga> morphis: because --enable-partially-static is a no-op in the new scheme, it's always like that
<zyga> morphis: you can pick any partially static part of snap-confine
<zyga> morphis: and it is not possible to build a fully static snap-confine anyway, because of udev
<zyga> tvoss: and /tmp?
<tvoss> zyga: does snapd get its own /tmp? If not, I would rather put it in a more specific directory
<zyga> tvoss: no, snapd doesn't get any magic treatment, /tmp is shared
<tvoss> zyga: so I would rather go for /run/snapd then
 * zyga is still somehow confused, why /run vs /tmp for temp file
<zyga> it's not that /run is bad, I just want to understand why it was picked over /tmp
<tvoss> zyga: following securities advice. /tmp is world readable, right?
<zyga> tvoss: as is run
<zyga> tvoss: it's just a matter of giving the right mode to the file
<tvoss> zyga: it get's the right mode from ssh-keygen already
<zyga> tvoss: so there's no difference
<tvoss> zyga: feel free to comment on the PR, too.
<zyga> tvoss: yep, thanks
<zyga> tvoss: is that 2.24 material?
<zyga> tvoss: or 2.25?
<tvoss> zyga: well, ideally, we would have it in 2.24
 * zyga nods
<zyga> pedronis: hey
<zyga> pedronis: so I'd like to understand how we are going to proceed
<zyga> pedronis: (fold and fix later vs fix now)
<zyga> pedronis: do I understand correctly that the root issue is how auto-connect works?
<mvo> https://forum.snapcraft.io/t/unblocking-2-24/238 is my proposal to get 2.24 out and then fix the deeper issues
<pstolowski> morning
<zyga> pstolowski: hello :)
<morphis> zyga: so for whatever libtool/autotools reason https://github.com/snapcore/snapd/pull/3162 disables linking libcap statically, it ends up in _STATIC but is linked against the .so
<mup> PR snapd#3162: cmd: use libtool for the internal library <Created by morphis> <https://github.com/snapcore/snapd/pull/3162>
<morphis> pstolowski: morning!
<zyga> morphis: because the .la files now dictate everything
<zyga> morphis: kind of suspected this would happen though, did we merge that already by any chance?
<morphis> sure, but shouldn't we be able to override that?
<morphis> zyga: we didn't
<morphis> tests are detecting that libcap is dynamically linked
<zyga> morphis: yes but the way is not the same, I suspect
<pedronis> mvo: zyga: IÂ answered there
<zyga> morphis: look at the resulting makefile
<zyga> pedronis: thanks!
<morphis> zyga: I do
<morphis> zyga: .._STATIC = -lcap is what we have there
<mvo> pedronis: so just picking selected bits from 3145 ? let me see
<zyga> pedronis: "this part" is fixDisconnectedCorePlugs or the hack further down in autoConnect?
<zyga> morphis: those are just variables, look at rules
<pedronis> zyga: the hack in autoconnect, after thinking it seems we don't need fixDisconnectedCorePlugs ... when we intall the new core we run autoconnect logic again
<zyga> pedronis: aha, interesting
 * zyga thinks 
<pedronis> zyga: remember that for core we run setup-profiles twice, once in the old snapd and once in the new one
<zyga> yes, that's right
<zyga> and the 2nd try will already have the hack and will connect things
<zyga> (the plugs that is)
<zyga> mvo: I think it will work too
<zyga> I worry about folding (a little) that it's a slippery slope we will have to climb out of for some reason we cannot forsee yet
<pedronis> this is not true for very old snapds but then those have other bugs around running configure too
<zyga> (that we will end up needing the privilege separation in core0
<zyga> mvo: I think this is your call ultimately, while we discuss more and more there will be more and more branches proposed/merged
<zyga> mvo: so if you want to limit the extent of the changes we put into 2.24, I think the way is to release now
<mup> PR snapd#3168 opened: .travis.yml: add option make raw log less noisy <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3168>
<mvo> zyga, pedronis: I am fine with adding a special case for core/core-support in auto-connect, if its small and targeted, but I really want to get on with 2.24, that is my overriding priority right now (of course while still making sane decisions)
<mvo> zyga: release now with 3167? or release now now :) ?
<zyga> mvo: "now" as in quickly
<mvo> +100
<mvo> pedronis: so your second suggestion is to use folding + special case, a special case like http://paste.ubuntu.com/24359539/ ?
<pedronis> mvo: well if we also fold the special case could be just about core-support but yes
<mvo> pedronis: do you have something simpler in mind already, if so, would you mind sketching it out? I'm fine with fold+special-case as it feels like we at least have everything ready when autoconnect is fully fixed this way. as long as its straightfoward :)
 * zyga would like to know what the fully fixed autoconnect is like
<mvo> zyga: thats for later, lets not get distracted ;)
<pedronis> that's a bigger thing
 * mvo puts on his tunnel vision glasses
<pedronis> not doing to think about that now (though IÂ have ideas)
<pedronis> mvo: IÂ think just taking that bit and   plug.Interface == "core-support"Â  first would be enough for now , if we fold ... we can improve/change it later
<zyga> do you want me to prepare that branch?
<mvo> zyga: if you don't mind, as small as possible please :)
<zyga> mvo: OK
<morphis> zyga: ok, problem is that libtool needs the full-path to the .a we want to statically link
<mup> PR snapd#3164 closed: tests: ensure network-bind and core-support are connected <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/3164>
<mup> PR snapd#3165 closed: interfaces: adjust shm accesses to use 'm' for updated mmap kernel mediation <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3165>
<mvo> I need reviews for 3167 - at leat one, the underlying branch (without the spread test) got a +1 from gustavo already
<zyga> mvo: running tests locally
<mvo> zyga: great, looking forward for this branch
<mvo> to this branch
<zyga> mvo: I included the small yaml cleanup as I didn't want to tear that out and it is harmless (just variable rename for correctness)
<zyga> mvo: (same that was there originally)
<mvo> zyga: sounds good, push it
 * mvo is being pushy
<mup> PR snapd#3168 closed: .travis.yml: add option to make raw log less noisy <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3168>
<pstolowski> we don't seem to have any spread tests which exercises gadget config defaults, do we?
<pedronis> pstolowski: no, also that functionality is broken in other ways
<pstolowski> pedronis, how do you mean?
<pedronis> pstolowski: that at first boot it will not always be applied because of order issues
<pedronis> of things
<pstolowski> pedronis, oh i see. ty
<pedronis> something to fix for 2.25 (I think)
<mup> PR snapd#3169 opened: many: fix plug auto-connect during core transition <Created by zyga> <https://github.com/snapcore/snapd/pull/3169>
<zyga> pedronis, mvo: ^
<mvo> zyga: could you have a look at 3167 please?
<Chipaca> morning eurofriends
<Chipaca> anything particularly lit today?
<zyga> mvo: certainly, looking now
<mvo> ta
<zyga> Chipaca: morning separatistic islander, nothing particularly on fire
<mvo> hey Chipaca! good morning
<mvo> Chipaca: I'm having slight tunnel vision to get 2.24 out but otherwise things are fine
<mvo> s/slight/huge/
<Chipaca> mvoâ as well you should
<Chipaca> mvoâ as long as it's not from getting up too quickly or something :-)
<zyga> mvo: the regexpes there feel too generic, if we grow core-support-apparatus they will still match
<zyga> mvo: but since tests are passing ignore me for now :)
<mvo> zyga: :) happy to do a followup
<zyga> mvo: in 2.25 :)
<zyga> mvo: I just approved it
 * zyga is getting hungry
<zyga> I'll talk to you after some 1-2-1s
<mvo> Chipaca: if you don't mind a review of 3167 would be great, should be very simple
<mvo> zyga: sure, thanks for your help!
<Chipaca> zygaâ my whole house is going to be smelling of slow-cooking beans, onions, peppers and bay leaves today. I think I'm having another breakfast.
<Chipaca> mvoâ +1; there's a typo in a comment, but you can fix later
<mvo> Chipaca: hahahaa - thats such a freudian slip - cure-support!
<Chipaca> :-)
<Chipaca> mvoâ maybe you're just missing '80s rock
<mvo> Chipaca, ogra_: and now - https://github.com/snapcore/core/pull/33/files
<mup> PR core#33: the core snap only needs core-support  (not network-bind) <Created by mvo5> <https://github.com/snapcore/core/pull/33>
<mup> PR snapd#3166 closed: interfaces/builtin: fold network-bind into core-support <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3166>
<mup> PR snapd#3167 closed: interfaces: fold network bind into core support with tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3167>
<mvo> Chipaca: lol
<mvo> pretty please
 * mvo is still pushy
<ogra_> approved
<mvo> ta!
<Chipaca> yeah, +1. Bring on the two-line merges.
<ogra_> heh
<mup> PR core#33 closed: the core snap only needs core-support  (not network-bind) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/33>
<pedronis> zyga: does #3169 work from your tests?
<mup> PR snapd#3162 closed: cmd: use libtool for the internal library <Created by morphis> <Closed by morphis> <https://github.com/snapcore/snapd/pull/3162>
<mvo> ogra_: and one more for core (sorry for that)
<mup> PR core#34 opened: really remove network-bind-plug <Created by mvo5> <https://github.com/snapcore/core/pull/34>
<pedronis> zyga: mvo: core-support is interesting because is probably the only? one of the only interfaces where plug and slot that connect are on the same snap?
<mvo> pedronis: yeah, I think so
<zyga> pedronis: network-manager and modem-manager have some smilar properties
<zyga> or maybe something related to location support, I recall really wacky archtecture
<zyga> but core-support is certainly most common
<fgimenez> mm i'm getting a lot of "2017-04-11 04:37:02 Discarding linode:ubuntu-core-16-64 (Spread-06), cannot connect: cannot connect to linode:ubuntu-core-16-64 (Spread-06): ssh: handshake failed: ssh: unable to authenticate, attempted methods [password none], no supported methods remain" this morning https://travis-ci.org/snapcore/spread-cron/builds/220818086#L382
<zyga> aha
<zyga> maybe some other spread collected that machine since it was started?
<pedronis> zyga: if we have more maybe (IÂ say maybe) it would be interesting to consider the concept of self-plugging , instead of abusing autoconnect for this
<zyga> pedronis: implicit or somehow explicitly declared in yaml?
<pedronis> well somehow/somewhere we would need to say that core-support plug on core is supposed to plug into the same snap slot
<DonAlex> Does anyone know what barriers there are to getting tincd running as a snap?
<pedronis> anyway if it's just core-support if might be easier to just special case (also because the issue is mostly transition)
<zyga> DonAlex: we don't know what tincd is so probably you need to tell us more
<zyga> pedronis: I agree we should explore how connecting should work
<zyga> pedronis: including a way to say "this snap requires connection before it is functional"
<zyga> pedronis: something that is currently not possible
<mvo> Chipaca: one more trivial review please https://github.com/snapcore/core/pull/34 - silly me for overlooking this earlier
<mup> PR core#34: really remove network-bind-plug <Created by mvo5> <https://github.com/snapcore/core/pull/34>
<Chipaca> mvoâ hah
<Chipaca> +1'ed
<DonAlex> zyga: https://tinc-vpn.org/
<DonAlex> If I am using a snap on a server I want to be able to put it on my VPN
<mup> PR core#34 closed: really remove network-bind-plug <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/34>
<mup> PR snapd#3170 opened: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170>
<zyga> DonAlex: we don't have support for user services
<zyga> DonAlex: not sure if that is required
<zyga> DonAlex: I'd recommend building it as a snap and checking what is missing
<zyga> DonAlex: we will gladly take feedback
<zyga> DonAlex: as for permissions, you may need to run in devmode initially (not sure)
<zyga> DonAlex: devmode means that confinement is advisory, not mandatory
<zyga> DonAlex: but we can add new interfaces quickly
<zyga> DonAlex: (or extend existing interfaces where appropriate)
<zyga> DonAlex: stay in the loop, post on forum.snapcraft.io, try things out
<mvo> we are close to user services, there is a PR, let me try to find it
<mvo> https://github.com/snapcore/snapd/pull/2752
<mup> PR snapd#2752: snap: add support user-sessions from snaps <Blocked> <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2752>
<pedronis> mvo: so 2.25 is probably more likely to be around the 25th, after yesterday discussion?
 * zyga is done with breakfast
<mvo> pedronis: correct
<zyga> and heads to 1-2-1
<pedronis> mvo: changing the date on github
<mvo> pedronis: \o/
<DonAlex> zyga: I guess the biggest problem will be with creating the device or loading the tun module.
<DonAlex> zyga: That is normally a system action. Though if you use user permission on some system it works.
<zyga> DonAlex: tun module can be loaded with the kmod interface
<zyga> DonAlex: essentially snapd will load the module for you
<zyga> DonAlex: does it take any parameters that need to be tweaked / set
<zyga> DonAlex: what devices do you need to create?
<DonAlex> zyga: hmm no i don't think so .. just needs the device to be created
<zyga> DonAlex: does the module do that or is that done from userspace?
<DonAlex> zyga: it creates and iterative interface names per network so tun1 tun2 etc.
<ogra_> mvo, hmmm
<ogra_> unknown plugs interface name reference 'network-bind-plug' lint-snap-v2_hook_plugs_plug_reference (configure, network-bind-plug)
<mvo> ogra_: yeah, see above
<ogra_> mvo, thats what the store mailed me for the last round of core buillds
<ogra_> ah, k
<mvo> ogra_: the fix is in, Chipaca was kind enough to review. silly me for overlooking a plug reference
<mvo> too much tunnel vision :(
<mup> PR snapd#3171 opened: snapstate: normalize gadget defaults <Created by stolowski> <https://github.com/snapcore/snapd/pull/3171>
<ogra_> mvo, well, i'D appreciate a tunnel vision that distracts me from that awful spreadsheet
<mvo> ogra_: :(
<zyga> oh
<zyga> darn, I forgot
<Chipaca> mvo, ogra_, zyga, all the unknowns there are killing me (and there's 2+ weeks to go for those)
<ogra_> Choh, i thought it was supposed to be done by friday
<ogra_> Chipaca,
<Chipaca> nope, 2-3 weeks
<ogra_> sigh
<Chipaca> yep
<ogra_> mvo, this build got through !
<mvo> ogra_: yeah, I'm running a local test now and fire spread
<mvo> up
<mikeb_> Chipaca: In case you didn't see my note yesterday, I've put up that promised demo at https://github.com/mabnhdev/snappy-daemon-demo.
<Chipaca> mikeb_â I didn't, no
<Chipaca> network's been iffy and irc doesn't cope well with that
<Chipaca> mikeb_â why is 'devmode' needed?
<woodrowshen> mvo: hi
<Chipaca> mikeb_â anyway, thanks, I'll look into this
<mvo> hey woodrowshen
<DonAlex> Ok .. gonna have a go at building it myself. Will let you know what happens via the forums.
<mikeb_> Chipaca: devmode is force of habit - I mostly play with code that violates containment.
<Chipaca> mikeb_â cheeky :-)
<Chipaca> mikeb_â but seriously, thank you, and I'll be playing with this
<Chipaca> might get something into 2.25 if it's concise enough
<mikeb_> Chipaca: I appreciate your time.  Thanks.
<Chipaca> (and if we all agree on it)
<woodrowshen> mvo: i built snappy image with armhf, and just found core snap rev. is 1580, is it current rev. in stable ?
<mvo> woodrowshen: that sounds correct
<mvo> woodrowshen: 1580 is the stable core on armhf with snapd 2.23.6
<woodrowshen> mvo: ok, thanks. i met the weird case of failure to exec `snap list`
<zyga> re
<zyga> how can I help?
<mvo> woodrowshen: what is the failure? can you please pastebin it
<mvo> zyga: mostly waiting for tests now, the new core breaks the interfaces-network-bind spread test testing a fix locally and then we should be good again
<woodrowshen> mvo: http://paste.ubuntu.com/24359921/
<woodrowshen> mvo: just output "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: EOF"
<zyga> woodrowshen: let me help you
<zyga> mvo: focus on the fix :)
<mvo> woodrowshen: Apr 11 08:46:07 localhost snapd[1994]: runtime: out of memory: cannot allocate 258801664-byte block (510001152 in use)
<mvo> woodrowshen: what system is that? how much ram?
<mvo> zyga: ha! thank you
<zyga> woodrowshen: how about "snap version"
<mvo> zyga: even better
<zyga> woodrowshen: and systemctl status snapd.service
<woodrowshen> zyga: mvo: thanks a lot
<woodrowshen> zyga: ooo...
<mup> PR snapd#3172 opened: tests: fix interfaces-network-bind to match the new core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3172>
<woodrowshen> zyga: all snap commands can't work
<zyga> woodrowshen: how much memory do you have there?
<woodrowshen> zyga: 1G
<zyga> woodrowshen: what is that system, is it a VM?
<zyga> woodrowshen: what dis
<zyga> distribution?
<woodrowshen> zyga: roseapple-pi, a devel board
<zyga> woodrowshen: aha
<zyga> woodrowshen: which kernel are you running
<woodrowshen> zyga: 3.10.37
<zyga> woodrowshen: and how did you install the system; did you build an all-snap (aka core) image or is this a distro running on your board and you just installed/compiled snapd there
<zyga> woodrowshen: with 1GB of ram, are you running anything like a graphical UI there?
<woodrowshen> zyga: https://github.com/xapp-le/SnappyUbuntuCore/blob/master/builder/build-snappy.sh
<woodrowshen> zyga: i used this script to build it
<zyga> woodrowshen: let me see
<woodrowshen> zyga: no any graphics satck
<woodrowshen> zyga: s/satck/stack/
<zyga> woodrowshen: aha, so it's an all-snap/core image
<woodrowshen> zyga: yes, and previous images i had built didn't happen that.
<zyga> woodrowshen: can you pastebin "top -b -n 1"
<woodrowshen> zyga: i wonder if we have pastebin snap XDDD
<zyga> woodrowshen: you can ssh in
<zyga> woodrowshen: run that command
<zyga> woodrowshen: and copy-paste
<zyga> woodrowshen: (into something like pastebin.ubuntu.com
<woodrowshen> zyga: http://paste.ubuntu.com/24359952/
<zyga> woodrowshen: does snap version run?
<zyga> woodrowshen: or is that crashing too?
<woodrowshen> zyga: no, the system still works normally. just snap commands will get stuck
<tvoss> pedronis: mind having another look here: https://github.com/snapcore/snapd/pull/3130
<mup> PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<woodrowshen> zyga: even snap version
<tvoss> pedronis: switched back ssh-keygen :)
<woodrowshen> zyga: sorry fix the description, snap commands will get stuck for a while, and output "error: cannot list snaps: cannot communicate with server: Get http://localhost/v2/snaps: EOF"
<zyga> right
<Chipaca> woodrowshenâ journalctl -u snapd.service
<Chipaca> please
<mvo> hm, unreleated -  I think we need spread tests for the core options, I just got  a failure trying to snap set  core ystem.power-key-action - looks like we have no /etc/systemd/logind.conf.d directiory
<zyga> woodrowshen: and after you get that log, can you systemctl restart snapd.service
<zyga> woodrowshen: and see if memory usage drops
<zyga> woodrowshen: and if you can run snap changes or what not
<woodrowshen> Chipaca: http://paste.ubuntu.com/24359985/
<mvo> zyga: do you know if there is a way to allow only a single "mkdir" on a directory via apparmor. i.e. not full write but just mkdir?
<Chipaca> woodrowshenâ there you go then
<Chipaca> woodrowshenâ this is probably bug #1674778
<mup> Bug #1674778: snapd hangs with 100% CPU usage when image has a custom gadget snap <gadget> <snapd> <Snappy:Confirmed> <https://launchpad.net/bugs/1674778>
<Chipaca> woodrowshenâ IOW you probably have a bug in your gadget snap, and we have a bug in snapd where it OOMs on gadget snap weirdness
<Chipaca> to be clear: âruntime: memory allocated by OS (0x7286e000) not in usable range [0x965c2000,0xffffffff)â
<Chipaca> on a 32-bit system
<Chipaca> means OOM
<zyga> mvo: yes, directoy and stuff inside are separate
<zyga> mvo: e.g. /path/to/dir w,
<zyga> er
<mvo> zyga: thanks, excellent
<zyga> mvo: e.g. /path/to/dir/ w,
<zyga> the trailing slash matters
<zyga> try that as I suspect you need more than w in practice
<Chipaca> mikeb_â you around?
<woodrowshen> zyga: http://paste.ubuntu.com/24359994/
<zyga> right
<woodrowshen> zyga: snapd cna't free the memory
<woodrowshen> zyga: ok, i see.
<mvo> zyga: thanks, running it locally now. I'm adding a test to ensure that snap set core after the transition *actually* really works and hit a bug :)
<zyga> mvo: good call, outch, what bug?
<zyga> Chipaca: what's the reason for the extra memory use, do you know?
<Chipaca> zygaâ no
<Chipaca> somebody should look into that bug at some point :-)
<zyga> Chipaca: maybe the hook hangs and we buffer something it says into memory?
<Chipaca> mikeb_â I'm trying to reproduce the issues you're seeing, and I'm not being able to
<Chipaca> zygaâ we've seen the OOM also because the gadget asks for an interface it hasn't been granted
<mvo> zyga: I push a PR once my local test finishes, but its not super critical, just adding it to really ensure all angles are tested
<Chipaca> zygaâ and because its assertion is signed with the wrong key
<Chipaca> zygaâ these things happen before the hook afaik
<Chipaca> zygaâ also afaict it's not spamming changes; there was a relatively low amount of changes at the time
<zyga> aha
<Chipaca> as i say, somebody needs to dig
<zyga> yes, for sure
<Chipaca> mikeb_â ah, i might be understanding one of the issues you mention now
 * Chipaca looks further
<pedronis> Chipaca: do we know if it's reproducible on amd64? undoing a first boot install and OOM ?
<mup> PR snapd#3173 opened: tests: add extra test after the core transition for snap get/set core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3173>
<mvo> zyga: ^- thats the one I talked about
<zyga> aha
<woodrowshen> Chipaca: the last comment on bug said removing the interface on hook can fix the issue, but my gadget didn't use that like him
<Mirv> bye bye
<Mirv> I'll rejoin if I'll create snappy products
<Chipaca> woodrowshenâ that comment comes from a different thread and was posted to that bug in error
<Chipaca> woodrowshenâ while it is related, in that on second pass the gadget's yaml was wrong because it asked for that interface, it's not the only cause of the bug
<Chipaca> woodrowshenâ when the bug was first created, the OOM was because of bad signing
<Chipaca> woodrowshenâ at this point I believe any issues with the gadget snap will cause this
<Chipaca> pedronisâ I don't know
<Chipaca> pedronisâ should be easy to test with a core amd64
<woodrowshen> Chipaca: oh, indeed.
<woodrowshen> Chipaca: how to define the "bad signing"
<fgimenez> mvo: tests/main/interfaces-network-bind is failing with the latest edge i386 core (rev 1682), not sure if that's expected https://travis-ci.org/snapcore/spread-cron/builds/220883610#L731
<Chipaca> woodrowshenâ model under one account, gadget under another
<mvo> fgimenez: https://github.com/snapcore/snapd/pull/3172 will fix that
<mup> PR snapd#3172: tests: fix interfaces-network-bind to match the new core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3172>
<fgimenez> mvo: great thank you!
<Chipaca> hmm, why is 'snap try' setting snapsup.Flags.RemoveSnapPath
<zyga> mm
<woodrowshen> Chipaca: hmmmm, got it.
<zyga> Chipaca: feels wrong, right?
<Chipaca> woodrowshenâ there's an exception there where i think they don't have to match if canonical is the signer of one of those things
<Chipaca> zygaâ well, it doesn't break stuff, but prints an ugly warning
<Chipaca> 2017/04/11 11:11:00.366879 handlers.go:299: Failed to cleanup /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: remove /home/john/canonical/snappy/src/github.com/snapcore/snapd/tests/lib/snaps/test-snapd-service: directory not empty
<zyga> Chipaca: worse, it feels like with a simple slip it could rm -rf your code
<Chipaca> zygaâ it's not a -r :-)
<zyga> right
<zyga> yet
<Chipaca> found the issue, i think
<mvo> zyga: looks like 3169 is failing, maybe a fluke? could you please have a look (spread still runnig but the failure is in the log)
<zyga> checking
<zyga> mvo: I have one thing I'd like to add, from last evening
<Chipaca> mikeb_â looking into this is pointing out several little warts even before getting at the issues you're seeing (yay!)
<pedronis> zyga: mvo: Error executing linode:ubuntu-14.04-64:tests/main/refresh-delta-from-core
<Chipaca> mikeb_â wrt ordering though, there is no implicit ordering other than with the service that flags "the network is up"
<Chipaca> and the mount unit that mounts the snap into place
<zyga> pedronis: right, I'm looking it at it
<mup> PR snapd#3172 closed: tests: fix interfaces-network-bind to match the new core <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3172>
<zyga> Apr 11 10:06:39 ubuntu snapd[4401]: 2017/04/11 10:06:39.614845 helpers.go:173: cannot connect plug "core-support" from snap "core", no such plug
<zyga> this will never go away, we don't have a system where plugs change and we forget past connections
<mvo> zyga: what do you want to add?
<mvo> fwiw, from my POV 2.24 is now ready, 3169 is mostly a bonus for me
<zyga> mvo: fine, not for 2.24
<zyga> mvo: debugging
<mvo> zyga: feel free to add, the tests need to re-run anyway
<zyga> mvo: something like this http://paste.ubuntu.com/24360222/
<zyga> mvo: + for slots, symmetrically
<mvo> zyga: sounds good
<mvo> zyga: and if things are ready after lunch it lands
<mvo> otherwiseâ¦
<zyga> mvo: surE :)
<zyga> pedronis: that failed because: Apr 11 10:06:35 ubuntu /usr/lib/snapd/snapd[4213]: store.go:1264: DEBUG: Available deltas returned by store: []
<zyga> I'm checking what the test is doing now to see if that's expected
<woodrowshen> Chipaca: so how can i help to track the issue ?
<zyga> mvo: hrm hrm hrm, I think we need something for that dangling slot connectiong
<zyga> *connection
<zyga> not super critical but we should do somehing about it or it will stay forever
<mvo> zyga: please add it to the 2.25 page
<zyga> ok
<zyga> mvo: so the failure you mentioned
<zyga> mvo: if edge<->beta on core snap had no delta in the store then the failure is a fluke
<zyga> https://github.com/snapcore/snapd/pull/3174 <- debugging
<mup> PR snapd#3174: interfaces,overlord: log interface auto-connection failures <Created by zyga> <https://github.com/snapcore/snapd/pull/3174>
<mup> PR snapd#3174 opened: interfaces,overlord: log interface auto-connection failures <Created by zyga> <https://github.com/snapcore/snapd/pull/3174>
<zyga> mvo: this is failing now https://github.com/snapcore/snapd/pull/3173
<mup> PR snapd#3173: tests: add extra test after the core transition for snap get/set core <Created by mvo5> <https://github.com/snapcore/snapd/pull/3173>
<zyga> mvo: I think it needs one of the other branches after network-bind was reomved from core
<zyga> re
<mvo> zyga: ta, I add it now
<mup> PR snapd#3169 closed: many: fix plug auto-connect during core transition <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3169>
<zyga> thanks!
<zyga> mvo: can you also merge https://github.com/snapcore/snapd/pull/3129
<mup> PR snapd#3129: interfaces/mount: add InfoEntry type <Created by zyga> <https://github.com/snapcore/snapd/pull/3129>
<zyga> mvo: it's harmless but I want that extra debug output there
<mup> PR snapd#3129 closed: interfaces/mount: add InfoEntry type <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3129>
<mvo> zyga: mixing the debug and the entry in a single PR is a bit unfortunate, lets try to have two next time. but its in, its harmless indeed
<zyga> yeah, it's an old PR
<zyga> I just wanted to merge that deubg output
<zyga> mvo: I can move it to a separate PR if youwant
<mvo> zyga: too much hassle and tests will take too long :/
<mvo> zyga: its ine
<mvo> in
<zyga> thanks!
<zyga> ok, what's left for 2.24
<mvo> I prepare 2.24 now, so the window is almost closed if someone has some last minute things
 * zyga looks
<mvo> its all in
<zyga> woot!
<zyga> great
<mvo> I'm running 3173 locally just to feel good but in parallel prepare changelog tag etc
<zyga> mvo: did you branch off master?
<mvo> zyga: it was probably not current
<zyga> I mean, for the release
<zyga> I'd like to land approved thins with 2+1s
<zyga> (for 2.25)
<mvo> zyga: lets wait a tiny bit, I branched locally so I guess its ok
<zyga> OK
<mvo> zyga: what branches do you have in mind? I think we need to go over the previous 2.24 now that network-bind is no longer used and fix those
<zyga> https://github.com/snapcore/snapd/pull/3153
<mup> PR snapd#3153: interfaces: validate plug/slot uniqueness <Created by zyga> <https://github.com/snapcore/snapd/pull/3153>
<zyga> I'll just enjoy the sun and get back to update-ns code
<mvo> zyga: sounds good, I will merge master into 3153 in the meantime to ensure we have no surprises (but I think we won't)
<pedronis> mvo: yea, tomorrow IÂ would like to start merging some of the aliases stuff that will need the move completed before we can release again
<pedronis> zyga: 3145 can be closed now?
<pedronis> mvo:Â so we didn't rename the plug in the end for 2.24? I see all the rename PRs in 2.25
<zyga> pedronis: checking
<zyga> pedronis: yes, I believe so
<mup> PR snapd#3145 closed: overlord/ifacestate: fix auto-connect during core snap transition <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/3145>
<mup> PR snapd#3175 opened: daemon: do not set RemoveSnapPath flag when doing a try <Created by chipaca> <https://github.com/snapcore/snapd/pull/3175>
<mvo> pedronis, zyga: https://github.com/snapcore/snapd/pull/3154 this one got in
<mup> PR snapd#3154: many: rename two core plugs that clash with slot names <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3154>
<pedronis> mvo: so only 3160 left ?
<mvo> pedronis: it looks like it yes, but it also still has network-bind in there which needs updating. but I think we can go out with 2.24 without it, or am I missing something?
<mvo> pedronis, zyga: also in 3154 we also rename network-bind, this can now be removed I think
<pedronis> mvo: I don't know :) too many moving parts, maybe zyga has a better idea there
<zyga> mvo: yes, I will follow up and remove it
<zyga> pedronis: haha, you think too highly of me,
<zyga> pedronis: let me see
<zyga> aha
<mvo> pedronis: I'm pretty sure things are fine (within the limits we set) and the migration works and no surprises, I think we can do the remaining bits for 2.25
<mvo> but I will let zyga double check :)
<zyga> that one, I think it's not really needed anymore because we auto-connect the plug correctly now
<mvo> thats my understanding as well
<zyga> I'd tweak it to remove the core network-bind connection as it's just garbage now (and it will stay annoying forever)
<mup> PR snapd#3176 opened: snapcraft.yaml can come in many guises now <Created by chipaca> <https://github.com/snapcore/snapd/pull/3176>
<Chipaca> mikeb_â ping
<icey> so, the issue I was having with Rust binaries isn't because of linking to the wrong thing: https://pastebin.ubuntu.com/24360512/
<icey> if sergio were here, I'd ping him...
<pedronis> mvo: yes IÂ see more clearly what landed, yes seems it's a consistent set
<ogra_> icey, try rocket.ubuntu.com instead
<icey> yeah but that means authing to _one more thing_ :-/
<icey> and he doesn't seem to be in there either :_/
<icey> fail
<Chipaca> zygaâ   run-snapd-ns-snappy\x2ddaemon\x2ddemo.mnt.mount                                           loaded    active mounted   /run/snapd/ns/snappy-daemon-demo.mnt
<Chipaca> zygaâ why is that left behind when the snap failed to install?
<zyga> Chipaca: interesting, is anything else left behind?
<zyga> Chipaca: e.g. apparmor profile?
<zyga> Chipaca: this should go away the same way as apparmor profiles
<zyga> Chipaca: but maybe there's a bug
 * zyga looks
<mvo> pedronis: thanks a lot for double checking
<zyga> Chipaca: ohhh
<zyga> Chipaca: we don't write .mount files
<zyga> ah
<zyga> sorry
 * zyga is so dumb
<zyga> I confused this entirely
<zyga> Chipaca: that file is harmless
<zyga> Chipaca: we don't remove them because there's no need
<zyga> Chipaca: we discard the namespace but we don't unlink
<Chipaca> a bunch of /var/lib/lxcfs stuff :-) but that's probably not our fault
<zyga> Chipaca: that file should be empty
<zyga> Chipaca: and should be (if you stat -f it) not nsfs or proc
<Chipaca> and a lockfile and some apparmor stuff
<zyga> Chipaca: apparmor stuff?
<Chipaca> type: nsfs
<zyga> Chipaca: interesting
<Chipaca> that's for /run/snapd/ns/snappy-daemon-demo.mnt
<zyga> Chipaca: so it's a namespace that lives on
<zyga> Chipaca: did we remove the snap?
<Chipaca> zyga, yes, the snap failed to install
<zyga> Chipaca: looks like an omission then
 * zyga looks
<Chipaca> and a bunch of /sys/kernel/security/apparmor/policy/profiles/snap.snappy-daemon-demo.* things
<Chipaca> but those might be because apparmor is append-only or something
<Chipaca> dunno
<zyga> doDiscardSnap should remove that
<zyga> Chipaca: those should be removed as well
<zyga> feels like a bug mr Chipaca :)
<Chipaca> zygaâ well it doesn't, at least when a 'snap try' fails
<zyga> Chipaca: can you show me snap change for this number?
<Chipaca> which number?
<zyga> of the change that installed it
<Chipaca> zygaâ http://pastebin.ubuntu.com/24360558/
<zyga> Chipaca: so we only discard in doDiscardSnap (discard-snap)
<zyga> pedronis: if the initial install of a snap fails we should clean up after it
<zyga> pedronis: trying to figure out which task should do it
<zyga> Chipaca: what is odd is that we undone setup security profiles
<zyga> Chipaca: but the profile is still there
<Chipaca> niemeyerâ any objection to allowing use of "last" as a change id that gets the last change?
<zyga> Chipaca: is /var/lib/apparmor/profiles/ also full of leftovers?
<Chipaca> zygaâ sounds like the undo doesn't
<zyga> Chipaca: well, I bet it does but I bet something is missing :)
<Chipaca> zygaâ that directory is empty
<Chipaca> (i've got 3 snaps installed)
<Chipaca> zygaâ i think you meant /var/lib/snapd/apparmor/profiles
<Chipaca> zygaâ and i've got some garbage there, but nothing related to this
<Chipaca> (it seems when i was trying out the bcc snap we weren't cleaning this up after ourselves or something)
<zyga> Chipaca: yes, sorry
<pedronis> zyga: the undo of each tasks in the install
<zyga> pedronis: here it is tricky, what needs to (maybe) be undone is a result of the configure hook
<zyga> pedronis: but only if this is the only revision
<zyga> pedronis: (discarding the namespace)
<pedronis> of the hook?
<pedronis> you mean sideeffects or running the hook?
<zyga> of the snap (it's global to the snap)
<mup> Bug #1681833 opened: Devmode Edge Snap not automatically updating <Snappy:New> <https://launchpad.net/bugs/1681833>
<zyga> here it looks like configure hook failed
<zyga> so installation stopped there
<pedronis> you we undid everything before that
<zyga> but the bug is that at this time we're essentially erasing the snap existence
<pedronis> yea
<zyga> we don't discard the namespace/connections though, apparently
<pedronis> connections?
<zyga> we only do that in discard-snap
<zyga> pedronis: "conns" in state
<pedronis> ah
<zyga> right
<zyga> which is only done if we're removing a snap
<pedronis> well something is wrong then
<zyga> so there's assymetry
<pedronis> zyga: there's  a discard-conns task actually
<zyga> pedronis: we do that when removeAll is set
<pedronis> yes
<pedronis> but that's not relevant
<pedronis> it needs to be done in some relevant undo
<pedronis> we don't do more tasks when something fails
<zyga> pedronis: I yes, I think som
<pedronis> we just undo things
<Chipaca> https://forum.snapcraft.io/t/rfc-easy-way-to-get-last-change/246?u=chipaca <- RFC thing
<zyga> pedronis: right
<Chipaca> mupâ you could preview forum links, couldn't you
<zyga> pedronis: I think we should graph what tasks are added in install/remove see if something is missing
<zyga> pedronis: I don't fully grok the extra cases that are there
<pedronis> zyga: well what we do in other places would be do something in remove-profiles if we are the last revision standing
<pedronis> instead of an extra task
<pedronis> I'm not sure why we have the extra task
<zyga> pedronis: I agree it should be something like that
<pedronis> I don't think I worked on that afair
<zyga> pedronis: I'll spend some time graphing this on paper and post in the forum
<pedronis> zyga: fwiw clear-aliases is going away in the new world
<zyga> FYI I simplified https://github.com/snapcore/snapd/pull/3160/files
<mup> PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160>
<dragly> What is the current status of snap dependencies? Is or will it be possible to have a snap depend on a specific version of a different snap as a library?
<zyga> dragly: no, can you tell me why you would like to have that?
<zyga> dragly: the content interface can be used to do that to some extent but I bet some edge cases are still very rough
<dragly> To reduce the size of snap packages.
<zyga> dragly: note that the content interface is something only snaps from one publisher can use
<zyga> dragly: with the exception of snaps that are blessed in the store, where anyone can share them
<dragly> Just curious about how far snaps are thought to go in terms of replacing apt in the long run.
<zyga> dragly: so if you upload a snap
<zyga> dragly: and then a 2nd one
<zyga> dragly: and you want to share some libraries between the two
<zyga> dragly: you can make a third snap with those libraries
<jdstrand> mvo: allowing write on a dir> the best you can do is '/path/to/dir/ w,' (the trailing '/' is important). that does allow changing the inode data too though (eg, perms, ownership)
<zyga> dragly: and update either or both of the first two snaps to useit
<mvo> jdstrand: thanks, that is what I used now
<zyga> dragly: but, the key is that youare in control of the three snaps still
<dragly> zyga: I see. That sounds like a reasonable middle way.
<zyga> dragly: the exception is for "blessed" snaps (not a strict term)
<zyga> dragly: where e.g. the qt project publishes a polished snap that they say they will responsibly update
<zyga> dragly: and that the ABIs are stable and what not
<zyga> dragly: and that snap can have an assertion that says anyone can now use it for content sharing
<zyga> dragly: we don't have any better mechansims yet but remember that there was never any plan to do dpkg/apt granularity packages
<zyga> dragly: I think as the content interface matures we'll have more option
<dragly> Qt was exactly the project I was thinking of. We have a couple of large snaps because we include a bit too much of Qt.
<zyga> dragly: but for now what's what we offer
<zyga> dragly: I would encourage you to make your own shared qt snap for now
<zyga> dragly: and experiment with this
<zyga> dragly: it's not perfect
<zyga> dragly: I'm hoping to make big improvement in 2.25
<zyga> dragly: (there are cases now where it will not work well)
<zyga> dragly: but this is the "taste" of the idea
<zyga> dragly: once qt project publishes a snap you could evaluate and switch to it
<dragly> Sounds good. What is your take on the issues of bundling say crypto libraries in a snap that might need security updates?
<zyga> dragly: same as everything else
<zyga> dragly: it's just something someone needs to update
<zyga> dragly: if it's not updated it doesn't matter (it's broken)
<zyga> dragly: if it gets updated that's good
<zyga> dragly: it's never perfect
<zyga> dragly: note that some libraries are available in the core snap
<zyga> dragly: if the ssl project starts publishing a ssl runtime snap
<zyga> dragly: and commit to maintaining it
<zyga> dragly: people can use it
<zyga> dragly: otherwise snapcraft can offer some features
<zyga> dragly: where you can just rebuild it
<zyga> dragly: (the snap you are building)
<zyga> dragly: and include updated ssl (again, just an exapmle)
<dragly> Sounds like that would solve most issues. I understand that this is a really hard balance to keep between containerized packages and shared packages for reduced size and security updates.
<zyga> dragly: also the impact of an update
<zyga> dragly: maybe the update actually breaks your snap
<dragly> Yes, I guess that has been the biggest issue with shared packages like dpkg or conda.
<mup> PR snapd#3177 opened: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<dragly> One wants the security updates, but not the breaking API changes.
<zyga> dragly: sometimes it's not possible
<morphis> mvo: can you mark https://github.com/snapcore/snapd/pull/3177 for 2.25?
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<dragly> zyga: Do you have some thoughts on NixOS and similar "everything-is-a-package-version" distros?
<zyga> dragly: they advance a lot of the theory and some of the tooling, I'm happy to see them
<zyga> dragly: e.g. reproducible builds initiative in general is very valuable for trust
<zyga> dragly: otherwise I think we are putting a different idea forward
<dragly> do you think much of that will be merged into Ubuntu's snap+dpkg ecosystem?
<zyga> dragly: not really, not at a whole distro level
<zyga> dragly: I think reproducible builds will spread across all binary distributions though
<zyga> dragly: that part is really generic, important and in progress across the landscape
<dragly> that's good
<morphis> Son_Goku: I don't have a good fix yet for the libtool/static linking problem
<morphis> Son_Goku: the best we can do for now is to drop all other patches and just keep the one for libtool support once we update to 2.24
<zyga> dragly: snaps aim to be practical
<zyga> dragly: ship software now, iterate, improve, learn
<dragly> As an application developer, I find the idea of NixOS intriguing, but the target audience is of course way bigger for snap packages.
<zyga> I think it's like with all research and business
<zyga> dragly: forget snaps, look at all the linux packaging formats and the play store
<zyga> dragly: it's clear that you can ship a zip file and win ;)
<zyga> dragly: and the rest is irrelevant at large
<dragly> excactly
<dragly> zyga: and in terms of security, I guess containerization is of greater importance than many other issues
<zyga> dragly: yes, the old trust model is not realistic, I think
<dragly> zyga: no. I'm looking forward to be able to download more binaries with less worry about their origin.
<zyga> (old trust model == manually reviewed software from trustworthy developers)
 * zyga -> call
<dragly> ah, I see. I was thinking more along the lines of trusting some random site which gives you a binary to download.
<mup> PR snapd#3178 opened: Release 2.24 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3178>
<zyga> dragly: that is even worse :) I was referring to the change from trusted source / binary to untrusted binary and sandboxing
<mup> PR snapcraft#1248 opened: snap: include asset tracking details in snap/snapcraft.yaml <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1248>
<mup> PR snapcraft#1249 opened: Add Linux Mint support <Created by nefelim> <https://github.com/snapcore/snapcraft/pull/1249>
<mvo> fgimenez: sorry to push more work towards you but do you think you could put the verification for https://bugs.launchpad.net/snapd/+bug/1673568 on your todo please?
<mup> Bug #1673568: snapd 2.23.6 SRU tracking bug <verification-needed> <snapd:New> <snapd (Ubuntu):New> <snapd (Ubuntu Xenial):Fix Committed> <snapd (Ubuntu Yakkety):Fix Committed> <https://launchpad.net/bugs/1673568>
<fgimenez> mvo: sure np, will let you know how it goes
<mvo> fgimenez: thanks!
<mup> PR snapd#3176 closed: snapcraft.yaml can come in many guises now <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3176>
<mup> PR snapd#3153 closed: interfaces: validate plug/slot uniqueness <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3153>
<Chipaca> Apr 11 15:26:17 fogey snap[29722]: cannot snap-exec: cannot read info for "snappy-daemon-demo": stat /var/lib/snapd/snaps/snappy-daemon-demo_x1.snap: no such file or directory
<mup> PR snapd#3179 opened: packaging: add `built-using` header for 16.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3179>
<Chipaca> I hope that's not what I think that is :-(
<mpt> Hi, in âtrack/risk/branchâ for channel names, what does âbranchâ refer to? <https://forum.snapcraft.io/t/channels-2-0-implementation/156> facubatista mvo
<davidcalle> facubatista: ^
<davidcalle> (oh sorry, didn't noticed you were pinged already)
<mvo> mpt: hey, nice to see you! facubatista is probably the better person to answer, but my understanding is that this is a new store feature that allows to open "branches" with arbitrary names (like latest/stable/hotfix-for-lp1334)
<facubatista> mpt, the branch is a kind of "sub channel" for the "stable" channel, that will allow people to release temporary fixes
<mvo> mpt: AIUI those will not be surfaced in snap info, someone need to tell you about the branch. but I was not in this paricular design meeting so take it with a slight grain of salt :)
<facubatista> mpt, the names are arbitrary, you can just release into them, but after 30 days they will be removed (or you can remove them before, when the fix is integrated into stable)
<facubatista> mpt, there's a bigger doc explaining better, we're just holding off the formal announcement until all tools properly support them
<facubatista> mpt, in any case, I can answer any question you have
<mpt> mvo, nice to see you too :-)
<Chipaca> jdstrand, daemons of type "notify" need to talk to /run/systemd/notify. Is that added anywhere? Is this anywhere on your radar?
<mpt> facubatista, thank you. So as I understand it at the moment, snaps are (about to be) four-dimensional: each combination of {channel Ã track Ã branch Ã architecture} can have a different binary in it. Is that correct?
<mpt> Or maybe more accurately, the store is four-dimensional
<jdstrand> Chipaca: it isn't and no
<Chipaca> jdstrandâ noted and noted
<Chipaca> niemeyerâ i'm struggling a little bit with when to file bugs in launchpad and when to opne a new topic in the forum
<Chipaca> niemeyerâ so if you see i'm doing it wrong, shout :-)
<morphis> zyga: I am going to play around with the unshared /etc tomorrow or did you already started that work?
<facubatista> mpt, it's tricky, you don't have a whole "product" on branch, as branches only exist for the stable channel
<niemeyer> Chipaca: If you need coordination across teams, Launchpad.. if you want awareness and a nice conversation about it, forum.. if you want both, both :)
<zyga> morphis: I have a trivial branch but nothing useful, just comment out /etc and see what happens
<zyga> er
<zyga> well, roughly so
<mpt> facubatista, so you canât have a branch for a custom channel, then
<facubatista> mpt, we consider it four-dimensional, yes, but channel x track x architecture x series (series == release), being branches a special case of stable channel
<facubatista> mpt, what do you mean with "custom channel"?
<facubatista> mpt, we have pre-fixed channels (edge, beta, candidate, stable) and you can only create branches for "stable" (in any track, though)
<mpt> Oh, right, so branches *are* the custom channels
<mpt> Ok, I misunderstood
<facubatista> mpt, mmm... I don't know if call it like that... "custom channel" sounds like you could add a fifth or sixth channel to the well defined risk sequence (edge, beta, candidate, stable)
<mpt> facubatista, I was just copying mvoâs phrase in my link above, âThis allow publishers to go beyond the current 4 channels we offer and provide custom channelsâ
<facubatista> mpt, yes, they're custom in the sense that you can arbitrarily name them, but are more "sub channels from stable"
<mpt> understood
<facubatista> mpt, :)
<mpt> facubatista, but this is the first time Iâve heard of series for the store. What is that?
<facubatista> mpt, the "release": 16, 18, etc
<facubatista> mpt, it's a name mess, because originally you didn't "publish an upload", you "released it", so name colision was high :/
 * zyga has mild food poisoning, ttyl :/
<mpt> facubatista, thank you. One more question for now: Is there an existing UI design doc on how (any of) these should be presented to uploaders?
<jdstrand> zyga: :( feel better
<zyga> fresh juice, sometimes not healthy
<facubatista> mpt, presented in the web ui or in the command line tools? so far, we're all using the slash-separated names, and everybody seems to understand it perfectly... so, for example, you could "snapcraft release" to 2.2/candidate, or stable/hotfix3, etc
<mpt> facubatista, Web UI
<morphis> zyga: ok, will play a bit with that
<facubatista> mpt, for the web ui we're using the slash separated names to present the channels... I don't think the web ui is ready to actually release into tracks or branches, it's holding a little back and not given priority... in any case, there's no design that I'm aware of
<mpt> ok, thanks again
<facubatista> mpt, no problem
<morphis> mvo: was there anything which was blocking https://github.com/snapcore/snapd/pull/2592 other than missing time from your side?
<mup> PR snapd#2592: many: add support for session dbus services via snaps <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2592>
<mvo> morphis: a little bit of extra work, we need to generate the host /etc/dbus.d configuration automatically for the re-exec case
<mvo> morphis: otherwise I think its good
<mvo> morphis: why? is that something you want to see?
<qengho> fg
<qengho> bah
<morphis> mvo: would be nice to have, I can have a look if you want
<zyga> morphis: I think that it would be nice to get to a point where we can run unit tests and spread tests on debian and fedora equally; we still have a lot of catch-up to do
<morphis> zyga: yeah, I finalizing the first round for a debian setup
<morphis> fedora is next on my list
<morphis> just need some lines of real code in between instead of writing shell scripts all the day .. :-)
<morphis> niemeyer: by that chance, from what I've heard you are the one who can help me to get a debian-9 image on our linode farm, right?
<niemeyer> morphis: Yes! Thanks for working on that
<morphis> niemeyer: np, its time for that :-)
<niemeyer> morphis: Please open a topic on the forum and I'll follow up with instructions
<morphis> niemeyer: aye
<mvo> morphis: I would not say no, I think the way to model this is similar to the appamor host file writing, let me look for the code
<mvo> morphis: lets talk tomorrow morning, I think there is little left to do for this feature
<morphis> mvo: sounds good
<morphis> niemeyer: https://forum.snapcraft.io/t/extending-ci-for-snapd-to-debian-fedora/250
<niemeyer> morphis: Thanks! Will reply after lunch.. biab
<morphis> niemeyer: thanks!
<zyga> morphis: some comments on https://github.com/snapcore/snapd/pull/3177/
<mup> PR snapd#3177: cmd/snap: make users Xauthority file available in snap environment <Created by morphis> <https://github.com/snapcore/snapd/pull/3177>
<morphis> zyga: thanks
<zyga> morphis: very rough feedback so far, let's iterate and I'll help you out
<morphis> zyga: let me rework those tomorrow
<zyga> morphis: thanks!
<zyga> morphis: can you please merge master into https://github.com/snapcore/snapd/pull/3170
<mup> PR snapd#3170: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170>
<ogra_> hey suhamera
<suhamera> hi
<suhamera> i'm trying to run Ubuntu Core on my DragonBoard 410c
<zyga> suhamera: hey
 * zyga feels mildly sick but better
<ogra_> we dont really have any way to install the core image to the MMC.... and the dragonboard is a bit tricky in that regard
<suhamera> :)
<suhamera> but is any way to do it?
<zyga> niemeyer: hey, can you re-review https://github.com/snapcore/snapd/pull/3095 please
<mup> PR snapd#3095: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <https://github.com/snapcore/snapd/pull/3095>
<ogra_> specifically because the little-kernel hardcodes the boot device, so you cant just dd an img to the MMC device
<ogra_> you would have to dd partition for partition and leave out the lk one
<zyga> niemeyer: I think that if this lands today I could do a full cycle, for subset of problems, tomorrow
<niemeyer> zyga: Responding to Simon and have a call in 10 mins, happy to do right after that
<suhamera> yes, i've tried it with no success
<zyga> niemeyer: thank you!
<zyga> suhamera: you'd need an installer that copies a core image to nand
<zyga> suhamera: otherwise sure, why not
<ogra_> s/nand/MMC/
<suhamera> ogra_ so what will the difference with dd?
<suhamera> the image will be the same?
<ogra_> suhamera, you would need to dd each partiton from the SD to the equivalent partition on the MMC, leaving out aboot (which holds the lk)  ... and indeed that only works if the partition sizes match (which they probably do not)
<ogra_> well ...
<mpt> Someone should make an app that installs a random snap, launches it, and takes a screenshot
<mpt> They could call it â¦ Snapshot
<mpt> Iâm so sorry
<morphis> davidcalle: thanks for writing https://insights.ubuntu.com/2017/04/11/snap-support-lands-in-fedora-24-25-26 ?
<morphis> s/?/!/
<morphis> niemeyer: didn't read through your reply in detail yet, but do I need access to linode for that?
<Croepha> Hello
<Croepha> for Core, is there a bank of debug symbol files? specifically /lib/x86_64-linux-gnu/libm.so.6 with build id: 9247f19167971267b6fadf4ba633290188a5483b core_394.snap doesn't seem to match any version of that file in ubuntu...  (apt-file search b6fadf4ba633290188a5483b yielded no results...)
<ogra_> 394 ?
<ogra_> thats pretty ancient
<Croepha> I only update everyone once and a while, its too much of a moving target
<ogra_> erm ... it auto-updates itself usually
<Croepha> if you are saying that newer version would have debug symbols then that would be another thing
<ogra_> no
<Chipaca> Croephaâ how have you disabled updates?
<ogra_> if we'd ship debug symbols the package would be huge ... :)
<Croepha> I agree that i should update, but Ive already been burned by an update once before, making me rework some things, so, I haven't made updating a priority, until I get closer to being finished with all of my parts
<Croepha> Chipaca, no DNS entry
<Chipaca> ogra_â how're they handled in ubuntu anyway? i thought they were 'automatic'
<Chipaca> ogra_â but i don't really know what that means
<Chipaca> other than there not being a -dbg package
<ogra_> Croepha, well, given that ubuntu core is rolling not upgrading is not really wise
<Chipaca> ogra_â he's not disabled it! just extreme revision vetting
<ogra_> Croepha, but anyway ... https://launchpadlibrarian.net/291962392/core_16.04.1_amd64.manifest is the manifest file of 402 (we dont have one for 94, but this should have the same libm)
<ogra_> Chipaca, i thought via DNS hacking ?
<niemeyer> morphis: You need to have a Linode key.. the same you use for running your spread tests
<niemeyer> morphis: Do you have one?
<ogra_> s/94/394/
<Croepha> im not saying I won't update, or am advocating not updating as a good thing, its just like when you are working on a car, its best if its not rolling down the highway whilst your under it
<Chipaca> Croephaâ aw, where's the fun in that?
<ogra_> Croepha, what you can do is to bind-mount the libm binary with dbg symbols on top of the actual libm in the readonly core
<ogra_> Croepha, well, the system is designed in a way that each single part should be upgradeable on its own without breaking
<ogra_> Croepha, if anything breaks, that is definitely a bug we need to know about
<Croepha> ogra_, I agree completely, but what im saying is that when you are working with custom stuff, sometimes it helps freeze everything that you aren't working on.... its so frustrating when you are working on stuff, and the system is changing beneath you without you knowing... even little things like the default location of a file or the size of something in memory...
<Chipaca> I agree
<Chipaca> when you're building stuff, if something you don't control changes, it sucks
<Chipaca> because then you don't know if failures are yours, or some random change in the thing that changed
<Chipaca> so you separate those: change your stuff until it works, then upgrade the system, repeat
<Chipaca> right?
<ogra_> well, but 394 is really ancient ...  updating and noticing that you can throw away half your work because the system changed in large amounts is equally bad
<Croepha> I am 100% for updates, and I think that Snappy Core is awesome in the way it does updates, and agree that it helps solve a lot of compatibility changes
<Chipaca> yeah, 394 sounds like an iteration takes 6+ months :-)
<Croepha> ogra_, well, I guess, I could update more often :)
<ogra_> 394 was around november ...
<Croepha> Chipaca, yeah, its been a slow ride working on this stuff
<Croepha> or im really slow...
<ogra_> http://people.canonical.com/~ogra/core-builds/ ... (doesnt have manual builds, seems 394 was one)
<Chipaca> 394 is probably ubuntu-core, not core
<pedronis> 394, sounds very ancient, wonder what snapd version is inside that
<ogra_> oh, yeah, even that
<Croepha> core             16.04.1      394  canonical  -
<ogra_> ah, phew
<Chipaca> ah! cool :-)
<Chipaca> still, so many bugs fixed :-D
<ogra_> but still, what pedronis said applies ...
<ogra_> snapd might be rather feature-less
<Chipaca> Croephaâ what does "snap version" say?
<ogra_> or have features that have long changed
<Croepha> snap    2.17  snapd   2.17  series  16
<ogra_> woah
<Chipaca> :-)
<pedronis> well, newer than 2.0.10
<ogra_> heh
<Chipaca> yep
<pedronis> so middle ages instead of antiquity :)
<ogra_> pre-re-exec ...
<Chipaca> ogra_â 2.0.10 had re-exec
<Croepha> lol, ok you have convinced me to update at earliest connivence
<Chipaca> ogra_â 2.17 is post-un-re-exec
<ogra_> Chipaca, and then dropped it
<pedronis> there's no pre and after rexecec
<pedronis> because we turned it off and then on again
<niemeyer> zyga: reviewed
<ogra_> yeah, only on-off-re-exec
<Chipaca> 5 months, 1 wee ago
<Chipaca> week*
<Chipaca> Submission date
<Chipaca> 2016-11-02 11:55 - 5 months, 1 week ago
<Chipaca> ogra_â https://myapps.developer.ubuntu.com/dev/click-apps/6021/rev/394/
<ogra_> yeah
<Croepha> just to give you guys a peek into why i don't want to update all the time, is that in the past there has been issues with versioning of the core, and the ubuntu-image tool and snapcraft, and right now I know that all of those tools work together with the current versions of things, and when I update, then I will basically have to update all the other things...  Also, I have sort of cobbled together a really odd build iteration routine... instead
<Croepha>  of using snapcraft, I just use a prime directory, and build straight to it, and I rsync over the prime dir to the ubuntu core system.... this is much faster than running snapcraft every iteration
<Chipaca> Croephaâ sergiusens and/or kyrofa might be interested in that
<Chipaca> Croephaâ (otoh i think snapcraft has done some work around making things quicker)
<Chipaca> Croephaâ always interested in pain points around the build process
<Chipaca> well, I say always. Not *always* always: right now i'm more interested in going AFK for a while
<Chipaca> :-)
<Croepha> later
<Chipaca> ttfn :-)
<morphis> Pharaoh_Atem, zyga: https://phoronix.com/scan.php?page=news_item&px=Snap-In-Fedora
<Pharaoh_Atem> morphis: well, I guess that's what prompted mattdm to email me
<Croepha> thanks for the help Orga! i think I found what I need
<ogra_> cool
<Croepha> btw, instead of mounting the symbol files over, you can just use "set solib-search-path"
<ogra_> ah
<ogra_> but doesnt that change the path for all libs ?
<Croepha> you can add a path
<Croepha> just add a new path
<Croepha> like, you aren't changing which lib is actually loaded... thats what LD_PRELOAD... does
<Croepha> you are just helping gdb find the debug symbol files
<Croepha> so, what I am doing, is I am running some binaries on a core machine and connecitng to it over via gdbserver
<Croepha> on my local machine, I have a copy of the core snap and the prime dir, and can manually mount the snap and set sysroot in gdb
<ogra_> ah
<ogra_> clever
<Croepha> imho, this is the best debug workflow
<Pharaoh_Atem> morphis, zyga: testing scratch build of 2.24
<morphis> Pharaoh_Atem: nice
<Pharaoh_Atem> https://koji.fedoraproject.org/koji/taskinfo?taskID=18934608
<Pharaoh_Atem> also a test to see if ppc64 is fixed: https://koji.fedoraproject.org/koji/taskinfo?taskID=18934608
<nacc> is there a way in a snapcraft.yaml to specify that not only do i want a set of packages to be in stage-packages, but any packages they depend on?
<nacc> or do i need to explicitly specify them/
<ogra_> no
<ogra_> deps are processed b default
<ogra_> *by
<nacc> ogra_: hrm, i just built a snap that has ptyhon-pygit2 but not libgit2
<nacc> oh wait
<ogra_> but maintainer scripts are not run ...
<nacc> i bet LD_LIBRARY_PATH didn't get set!
<Pharaoh_Atem> ~_~
<Pharaoh_Atem> isn't pygit2 by default linked statically to libgit2?
<nacc> it does a 'from _pygit2 import *'
<nacc> and that spits a backtrace in the interpreter about not finding libgit2.so.24
<nacc> let me try with LD_LIBRARY_PATH set
<Mutter> Hi, i already ask question about boot Core on Dragonboard and get the reply to make some changes in kernel
<nacc> yeah it worked by specifing LD_LIBRARY_PATH=$SNAP/usr/lib64
<nacc> err LD_LIBRARY_PATH=$SNAP/usr/lib/x86_64-linux-gnu
<nacc> is this possibly due to using 'classic' confinement? would snapcraft normally have wrapped this?
<Mutter> But I have to rebuild the kernel from source - right?
<Mutter> So where I can get the core kernel source?
<nacc> ogra_: iirc, the wrapper script generator set it before. Does the /usr/bin/snap method not do that?
<ogra_> nacc, i dont think there are any wrappers in use when classic confinement is on
<nacc> ogra_: ah, so in classic, i need to explicitly specify values in my yaml to use the snapped libs?
<ogra_> i dont really know ... never did a classic snap ... afaik it functions exactly like a deb
<nacc> ah ok
<nacc> yeah maybe i should switch back to devmode confinement :)
<ogra_> probably a good forum question ;)
<nacc> ogra_: yep, i'll try and ask there
<nacc> it's almost certainly just me not having messed with my snap in some time (just been fixing bugs) and trying to refresh it with lots of changes to snapcraft since
<Pharaoh_Atem> morphis: pushing snapd-2.24 builds for F24+
<morphis> Pharaoh_Atem: that is wonderful!
<morphis> will give it a try tomorrow
<suhamera> ogra_: could you please show the direction to fix issues with .img on eMMC?
<ogra_> suhamera, well, i doubt it will work with the existing partitioning of the MMC
<ogra_> http://paste.ubuntu.com/24362438/ ... the aboot partition size seems to be smaller on the MMC
<ogra_> suhamera, so this will be non trivial ... first of all make a backup of the eMMC aboot partition with dd ...
<suhamera> Ok
<ogra_> then dd the whole sd image to /dev/mmcblk0
<ogra_> that should force the SD card partition table onto the eMMC
<suhamera> But
<ogra_> then dd the backed up aboot partition content to the aboot partition on the eMMC
<ogra_> and then ... good luck
<suhamera> :)
<suhamera> But on my eMMC I have the android or Debian partition table
<suhamera> And it could be different
<ogra_> (by "dd the whole sd image ..." i mean you should use a virgin img, not the Sd you are using indeed)
<ogra_> suhamera, well, check the size of the aboot partition
<suhamera> Ok, thanx
<ogra_> that is the only important bit ... the one on the SD has booting from the external port hardcoded ... so you cant use that on the eMMC
<Croepha> ogra_: you may be interested to know, that updating /was/ the answer in the final analysis, its easier to get debug symbols for the newer versions
<Croepha> but im glad I know about the build logs/manifests so I can find the versions in the future
<ogra_> :)
<Croepha> btw, for my debug/dev workflow, this is what I am doing for an rsync server: sudo classic sudo rsync --daemon --no-detach -v --log-file=/dev/stdout --config=./rsyncd.conf
<ogra_> neat
<ogra_> (to bad we dont support services inside classic else you could have it auto-start)
<Croepha> ehh, its not a big deal, I just have a text file of stuff to run on a restart
<kyrofa> zyga, https://stackoverflow.com/questions/43354435/snapd-dead-after-installing-a-snap-with-requested-plugs is that the core/ubuntu-core plug/slot issue?
<nacc> if `snap info usd-nacc` shows a snap (with classic confinement), why would `sudo snap install usd-nacc --classic` say 'snap not found'?
<kyrofa> nacc, because usd-nacc is only available on edge
<kyrofa> nacc, snap install by default uses stable
<nacc> kyrofa: ah so i need --classic --edge ?
<kyrofa> Bingo
<nacc> kyrofa: thanks! wonder if that could be a bit more user-friendly :)
<nacc> but yeah, pebkac :)
<kyrofa> nacc, yeah I've hit the same issue
<tvoss> niemeyer: hey, thanks for the review. Looking into your remark about using a dynamic name for the key file. would you be okay with a dynamic directory under /run/snapd instead. Easier to just use ioutil.TempDir as opposed to ioutil.TempFile (which returns an open File).
<niemeyer> tvoss: What's the win compared to using the real temporary dir?
<tvoss> niemeyer: assuming that you mean real temporary file: I would have to close the file and figure out its name. code looks nice with ioutil.TempDir: http://pastebin.ubuntu.com/24362847/
<Pharaoh_Atem> morphis: updates proposed for snapd to F24, F25, and F26
<Pharaoh_Atem> morphis: Wut
<Pharaoh_Atem> my name was mentioned in the Ubuntu Insights blog post
<Pharaoh_Atem> O.o
<morphis> Pharaoh_Atem: congratulations!
 * Pharaoh_Atem feels very odd about all this
<ogra_> a celebrety!
<niemeyer> tvoss: Why do we need to use /run for a temporary file?
<tvoss> niemeyer: I'm following guidance from security here
<niemeyer> tvoss: Okay... can we find that out? :)
<tvoss> tyhicks: ^
<niemeyer> tvoss: There's a directory in the system which is meant to be used for temporary content like this..
<niemeyer> tvoss: It's not about dir vs. file.. it's about /tmp vs. /run
<tvoss> niemeyer: ah, I misread your comment then
<tyhicks> niemeyer: the code was writing the device key temporarily to $PWD where it wasn't clear what $PWD was
<niemeyer> tyhicks: Yeah, definitely a good improvement to not do that.. the point above is unrelated
<tvoss> niemeyer: I'm fine with putting it into /tmp
<tyhicks> I'm not
<tyhicks> it needs to be somewhere where the world can't read the key file, doesn't it?
<tyhicks> this is private key material, not public
<tyhicks> well, public is included
<tyhicks> we're not wrapping the key with a passphrase so I don't think it should be stored, even temporarily, in a world readable location
<tyhicks> creating a subdir inside of /tmp/ is fine as long as the perms are sufficient
<niemeyer> tyhicks: Yes, I completely agree it shoudn't be world readable
<niemeyer> Somewhat obviously :)
<niemeyer> That's still unrelated to /tmp vs. /run
<tyhicks> ok
<tyhicks> I didn't want to dictate where it should go
<tyhicks> other than the directory permissions part
<tyhicks> thanks niemeyer :)
<niemeyer> Yeah, I think we're all sort of in agreement, but were talking slightly across purposes
<tyhicks> I think so, as well
<tvoss> let's be explicit, because it's late here :) /tmp/snapd{RANDOM} with 0700 would do the trick, correct?
<tyhicks> tvoss: if using /tmp, please use whatever equivalent golang has for securely creating a temp directory (such as what the mktemp utility provides)
<tyhicks> tvoss: that meets my requirements
<tvoss> niemeyer: ^ are you fine with the approach, too?
<niemeyer> tvoss: Yeah, I was assuming simply ioutil.TempDIr
<tvoss> niemeyer: cool, thx
<niemeyer> tvoss: If that's not offering the right mode, then something equivalent that does
<tvoss> niemeyer: mode is not documented for ioutil.TempDir, but I can easily os.Chmod() the tempdir prior to calling ssh-keygen. Or am I missing a potential attack vector here?
<niemeyer> tvoss: Seems better to have a osutil.PrivateTempDir
<niemeyer> tvoss: In snapd itself..
<tvoss> niemeyer: okay, will add it
<niemeyer> ahtvoss: Note we already have a handy strutil.MakeRandomString (which should really be called RandomString simply)
<niemeyer> tvoss: Thank you!
<niemeyer> I'm going to step out for some exercising.. o/
<tvoss> ah, reading code helps, ioutil.TempDir creates with 0700
<tvoss> https://golang.org/src/io/ioutil/tempfile.go?s=2138:2195#L66 ff
<tvoss> tyhicks: ^
<tyhicks> looks good to me
<tyhicks> wish it were documented
<tyhicks> that's not your problem though
<tyhicks> thanks tvoss
<stokachu> facubatista: just ran into that issue again, emailed you a copy of what i see
<cholcombe> this is prob a silly question but do you have to be logged into the store to install private snaps?
<cholcombe> i ask because i want a juju charm to install a private snap
<cholcombe> i also don't want to put my credentials in the charm haha
<mup> PR snapd#3095 closed: cmd/snap-update-ns: add C preamble for setns <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3095>
#snappy 2017-04-12
<lutostag> on my rpi3 after I snap install pulseaudio I don't see any cards/sinks, anything I need to do to set that up?
<Son_Goku> morphis: I think I'll crash and burn if someone suggests double LSM again as a solution
<ngaio> Is anyone interested in helping me create a snap for Rapid Photo Downloader?
<Croepha> perhaps if you ask a specific question :)
<Croepha> but im actually about to go for the day
<ngaio> Croepha, I'm a bit confused about the relationship between getting something from pip via the requirements.txt and that thing requiring dependencies to be present beforehand
<ngaio> outside of a snap environment, one has to apt install all the build requirements first, naturally
<Croepha> are you using the python plugin in snapcraft?
<ngaio> I don't know if I should be or not
<ngaio> it's a python program, but it's dependencies are not trivial
<Croepha> if you want to do the equivalent of an apt-install for a snap, you can do something called "stage-packages"
<Croepha> but, that usually isn't the best for python requirements
<Croepha> im not very familiar with the python plugin, but I think it expects a properly structured python package source, and it will bundle requirements that are specified in the setup.py
<gregl> One thing i can't get a handle on is how do you make changes to a snap app? I i'll use Hexchat as an example,I usually change the colors in it by changing some config files. Snap is a read only file system,so i am a bit lost here..
<Croepha> gregl: everything that needs to be variable, should be located in one of the writable directories
<ngaio> ok thanks Croepha I'll look into it some more
<Croepha> gregl: use https://snapcraft.io/docs/reference/env
<Croepha> gregl: you could also look at the users home directory for settings files, but that isn't a snap supported thing to do
<Croepha> but it works
<gregl> Croepha, Ok thanks,I did find the writeable folders..
<gregl> Cool .I will look a bit more..
<nacc> ok, i must be doing something obviously wrong. given the following yaml: http://paste.ubuntu.com/24364688/ i want the run.sh in snap/run.sh in the same git repository as the main part to be included in the built snap as the application. Basically, add a custom wrapper that is in the same repository
<mup> PR snapcraft#1250 opened: Fixed links to doc <Created by andyli> <https://github.com/snapcore/snapcraft/pull/1250>
<nacc> but when i use the builders on launchpad, i just get errors consistently about being unable to find run.sh
<nacc> ah, i might be being bit by LP: #1663534 ... i wonder why `snapcraft cleanbuild` on my 17.04 machine at home doesn't complain, though?
<mup> Bug #1663534: Dump plugin can't copy files from snap/ <Snapcraft:Confirmed> <https://launchpad.net/bugs/1663534>
<mup> PR snapcraft#1251 opened: internal: remove empty lines in the unclean parts message <Created by EduardoVega> <https://github.com/snapcore/snapcraft/pull/1251>
<stub> I've got revision 9 of a snap published in the stable channel in the store that I can install with 'sudo snap install wal-e --classic'. However, doing that in an lxd container on the same box is getting revision 6.
<stub> I suspect it is a permissions issue, and the difference is the lxd container is not logged on at all. But I can't see where it is screwed up.
<stub> oh, got it. The scripted install in the container was using the wrong channel.
 * stub wonders if 'snap list' and 'snap refresh' should mention channels
<mup> PR snapd#3178 closed: Release 2.24 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3178>
<morphis_> Son_Goku: you mean AppArmor and SELinux in parallel?
<mup> PR snapd#3180 opened: many: fixes for `go vet` in go 1.7 <Created by mvo5> <https://github.com/snapcore/snapd/pull/3180>
<mvo> jdstrand: hey, I heard rumors that there is an issue with the renamed snap-confine apparmor profile in 2.24/2.23.6 - if you have more details I would love to hear them
<sbeattie> mvo: it looked like the ADT tests for the kernel would uninstall the 2.22.6 snapd (without purging and without uninstalling snap-confine) and then later install snapd 2.23.6. Because of that, I think the postrm bit to remove the old snap-confine profile wouldn't get triggered.
<sbeattie> So both versions of the profile would exist after the "upgrade".
<mvo> sbeattie: aha, thank you. let me try that
<mvo> sbeattie: do you happen to know if there is a log or a bug available for this?
<sbeattie> mvo, jdstrand: I'm not sure a bug got filed for it
<sbeattie> mvo: log is at https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/l/linux-hwe-edge/20170410_201241_f4dfd@/log.gz
<mvo> sbeattie: ta!
<sbeattie> mvo: I'm not honestly sure if it's a snapd bug or an ADT bug.
<sbeattie> but I can file one in case you decide to upload something on the snapd side to fix/work around it.
<mvo> sbeattie: definitely worth persuing, I suspect that we left a file behind (/etc/apparmor.d/usr.lib.snapd.snap-confine) in some upgrade screnario
<zyga> good morning
<pstolowski> hey zyga, morning!
<zyga> hey hey
<zyga> sorry, overslept
<zyga> how's everything?
<sbeattie> mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023
<mup> Bug #1682023: snapd/snapd-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade <snapd (Ubuntu):New> <https://launchpad.net/bugs/1682023>
<mvo> thanks sbeattie
<mvo> hey zyga and pstolowski
<mvo> and good morning fgimenez_ :)
<mvo> fgimenez_: I added a forum topic and invited for you, not sure if that works
<fgimenez_> mvo: zyga pstolowski good morning
<fgimenez_> mvo: sure, already ack'ed with a hearth :)
<mvo> sbeattie: apw figured out that on purge the apparmor profile is removed from disk but not unloaded from the kernel. not sure if that is expected behaviour ? maybe a precaution to ensure that running binaries that are removed from disk but still in memory are still protected? in any case it explains the error but its a bit unclear what we can do about it
<fgimenez_> mvo: i'm currently involved in core validation at candidate too, as soon as that is sorted i'll put hands on the sru
<mvo> fgimenez_: thank you, no problem, I just got asked about it via irc and with a forum topic its much easier for me, I can just point people to that :)
<zyga> sbeattie: if you purge snap-confine does that go away?
<fgimenez_> mvo: totally, the forum is a huge improvement for that
<zyga> aha
<zyga> it didn't purge
<pstolowski> o/
<mvo> zyga: yeah, I suspect we need a dpkg-mainthelper to remove the conffile on the snap-confine package as well
<zyga> mvo: the package gets removed on purge
<zyga> mvo: I tested this when we were working on the .real workaround
<apw> i think the suggestion is you have old snapd + fat snap-confine installed
<apw> you now purge snapd only
<apw> and then install the -updates snapd
<apw> i am trying to get into that situation here
<mvo> zyga, apw: http://paste.ubuntu.com/24365745/ might be all we need -  but first we need to reproduce :)
 * zyga looks
<zyga> mvo: thank you
 * zyga is still sleepy
 * mvo hugs zyga
<apw> mvo, ok reproduced
<mvo> apw: I think I did so as well and the mainthelper did help me, could you pastebin your steps so that I can double check?
<apw> mvo, just doing it again with a transcript to be sure i did it sane
<mup> PR snapd#3181 opened: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3181>
<apw> mvo, ok reproduced and documented: http://paste.ubuntu.com/24365841/
<apw> mvo, shall i add that to the bug as well
<mup> PR snapd#3182 opened: store: tests for unexpected EOF <Created by stolowski> <https://github.com/snapcore/snapd/pull/3182>
<mvo> apw: \o/ #3181 should help, I wonder what the easiest way for you to double check might be (if you are still interessted). I could do a PPA build for you? or I just reproduce all your steps once its in master and it gets into our daily edge ppa.
<mbriza> when trying to run the anbox snap in fedora, i get "execv failed: No such file or directory" - is that a problem of snapd or the snap?
<apw> mvo, if you have a .deb set i thnk i can legitimatly test those by hand to confirm
<apw> all this because people are not doing upgrades right, sigh
<mvo> apw: http://people.canonical.com/~mvo/tmp/for-andy/
<mvo> apw: this one is hopefully good
<zyga> mbriza: hey, perhaps snapd, can you please tell me which release are you on?
<apw> Removing obsolete conffile /etc/apparmor.d/usr.lib.snapd.snap-confine ...
<apw> mvo, ^ i assume that is a good sign
<apw> and i have only the .real
<apw> so i call that fixed in your packages
<morphis_> zyga: looks like today is happy we-update-all-distros-with-2.24-day :-)
<zyga> morphis_: indeed
<zyga> morphis_: congratulations on android box :)
<zyga> morphis_: did you try it on fedora, mbriza above said there is something fishy
<morphis_> zyga: thanks, that was a long overdue thing
<morphis_> zyga: no, not yet but I know people tried
<morphis_> zyga: it will be a bit harder as we don't have dkms packages for the binder/ashmem kernel drivers there yet
<zyga> morphis_: aha
<zyga> morphis_: how does the snap work?
<morphis_> zyga: devmode-only :-D
<morphis_> zyga: and https://github.com/anbox/anbox/blob/master/scripts/container-manager.sh#L31
<zyga> aha
<zyga> morphis_: I think you could detect if you have apparmor around you and skip aa-exec
<zyga> morphis_: but I bet this will come with time
<zyga> mbriza: ^^
<morphis_> zyga: yes, for non-apparmor enabled systems we have
<morphis_> zyga: https://bugs.launchpad.net/ubuntu/+source/snap-confine/+bug/1647168
<mup> Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168>
<morphis_> that was the initial reason for the aa-exec call
<morphis_> didn't investigated that further yet
<mvo> apw: \o/
<mvo> apw: if you could comment in https://github.com/snapcore/snapd/pull/3181 that would be great
<mup> PR snapd#3181: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <https://github.com/snapcore/snapd/pull/3181>
<apw> mvo, am just making sure i did the test right (i am sure i did) and scipting it
<apw> mup, ok that worked and i am happy i am sure it did :)
<mup> apw: I apologize, but I'm pretty strict about only responding to known commands.
<apw> mvo, ok that worked and i am happy i am sure it did :)
<mvo> \o/ again!
<apw> mvo, is that sufficient (as a comment)
<mvo> apw: absolutely, thank you
<abeato> ogra_, I have flashed latest rpi3 image, but I am not able to connect to the store from console-conf, is that a known issue? It hangs in "Contacting store..."
<ogra_> abeato, Bug #1638537
<mup> Bug #1638537: snapd eats 100% CPU for about 5 minutes on first boot causing a load of >2.0 <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1638537>
<abeato> ogra_, not sure if it is the same, I can enter console-conf, it fails when trying to contact the store
<ogra_> like ... with an error ?
<ogra_> or does it just sit there ?
<ogra_> if the latter ... give it time ... if not, thats something different then
<abeato> ogra_, sits there, although it has just entered in the end... took really long :/
<ogra_> yep, there is a fix ... but not landed yet
<abeato> weird...
<abeato> ok, good to know
<ogra_> it generates the device gpg key
<abeato> ogra_, another thing, which is the recommended way to get wifi working on rpi3?
<ogra_> and go's routine for that is extremely resource consuming ...
<ogra_> configure with wired ... ssh in, run: sudo console-conf ... disable wired, enabled wlan, reboot
<ogra_> the wlan only has issues on the very first boot
<abeato> ogra_, hm, is disabling wired needed?
<ogra_> not really ... just the german in me that wants it cleaned up :P
<abeato> lol
<abeato> thanks!
<pstolowski> zyga, hey, do you have a moment to review #3182? it's just a test and I need 2nd review
<zyga> pstolowski: yes, looking
<zyga> pstolowski: stopped mid-way, brb
<zyga> re
<zyga> pstolowski: so, not sure I understand what's going on there, I'll ask a few questions if that's okay
<nottrobin> how do I get the ownership of a snap transferred to a different user/namespace?
<zyga> nottrobin: I think you can file a bug in the store
<zyga> http://launchpad.net/snapstore
<nottrobin> ta
<zyga> fun fact: scaleway offers ubuntu without 'updates' repository enabled
<zyga> so just security
<zyga> and main
<zyga> I just installed snapd 2.0.2 /o\
<nottrobin> bug filed: https://bugs.launchpad.net/snapstore/+bug/1682063
<mup> Bug #1682063: Transfer documentation-builder from nottrobin to canonicalwebteam <Snap Store:New> <https://launchpad.net/bugs/1682063>
<ogra_> zyga, hmm, we should probably make a deal with the security team to push it to -security in parallel (like kernels) ... that setup is surely not uncommon
<zyga> pstolowski: commented
<zyga> ogra_: yes, I agree
<zyga> ogra_: but I also wonder if ubuntu is certified there
<pstolowski> zyga, thanks!
<ogra_> zyga, well, disabling updates and leaving security on is not uncommon on servers i think
<sbeattie> ogra_: we only push kernels to security when we know of security issues fixed in them; alas, that happens 90% of the time. But we do push non-security toolchain things to security (to fix security builds or boot issue breakages), I suspect snapd would fall under this area.
<ogra_> sbeattie, yeah
<ogra_> given the amount of apparmor and seccomp changes each release has :)
<zyga> ogra_: aha, I didn't know that
<zyga> ara: hey, certification question, do we (as canonical) give any guarantee what it means to run "ubuntu" wrt updates? are you expected to have updates disabled when you install ubuntu?
<ara> zyga, not sure I understand the question
<zyga> ara: the case is that scaleway offers xenial images but the sources.list file only lists xenial-security and custom scaleway repo
<zyga> ara: you boot an ubuntu xenial instance from some cloud provider
<ogra_> zyga, by default they are always on ... but you can indeed preseed installs
<zyga> ara: is it still ubuntu if they disabled updates by default?
<ara> zyga, well, I think you are able to just keep xenial-security (kernel udpates go to the security pocket)
<ara> zyga, that's why those are different pockets
<ara> zyga, in case you just want security-updates but not bug fixes
<ara> zyga, so I guess the answer might be "yes, that's still 'ubuntu'"
<zyga> ara: aha, I see, thanks for clarifying that
<zyga> ara: do you know if we certify scaleway images?
<ara> zyga, no idea, you can ask that question to patricia, she may know
<ara> zyga, (Gaughen)
<zyga> thank you! :)
<zyga> gaughen: do you know if we certify scaleway xenial images?
<Chipaca> this multiple-services-in-one-snap demo thing is proving to be a trove of fails
<Chipaca> e.g., install it, installation fails because one of the services doesn't start, installation undoes, random services left running
<zyga> Chipaca: smells like 2.25 bugfix
<Chipaca> if i can get to the bottom of it all in time, sure
<Chipaca> :-)
<Chipaca> those two random branches yesterday were a part of it
<Chipaca> (and there's more weirdness in 'snap try', but i'm leaving that for later)
<zyga> Chipaca: I kind of like EnsureDir approach
<zyga> Chipaca: so we "ensure" service files are in place
<zyga> Chipaca: or that they are fully gone
<zyga> Chipaca: problem with stranded services is also interesting but separate
<zyga> Chipaca: did we forget to kill them
<zyga> Chipaca: or did they just refuse to die for some reason?
<Chipaca> the service files go away as is appropriate
<Chipaca> the services themselves don't
<Chipaca> if i had answers to your questions i'd be a day ahead of where i am :-)
<zyga> Chipaca: :-)
<pedronis> Chipaca: we have a few things that have an undo, but not a undo what we did if we fail in the middle
<pedronis> Chipaca: you can look at doLinkSnap for something that tries to do that properly
<zyga> pedronis: idea
<zyga> pedronis: not sure if good but still
<zyga> pedronis: let's add a "cleanup stack" to a change
<zyga> pedronis: any task can register cleanup actions that only get ran if we fail
<pedronis> ?
<zyga> pedronis: then if we fail we run the undo handlers and the cleanup list
<pedronis> well we have cleanup
<pedronis> nowadays for some stuff
<zyga> pedronis: the reason is that this way each task can have fine-grained elements that get added as the task progresses
<zyga> oh?
<Chipaca> there's a cleanup task
<zyga> so something like this exists?
<pedronis> not like this
<zyga> aha
<zyga> I was thinking along the lines of:
<pedronis> I'm mostly worried about the multiplication of concepts
<zyga> (inside one task)
<zyga> doA()
<pedronis> we have undos
<zyga> if not error, cleanupOnFailure(undoA)
<zyga> doB()
<zyga> if not error, cleanupOnFailure(undoB)
<zyga> ...
<pedronis> what we are not good at is dealing with the task that errored itself
<zyga> aha
<pedronis> but there's defer and stuff for that in theory
<zyga> well
<zyga> I worry that some of those concepts span one task
<zyga> so a chain of tasks in one change assumes some structure
<zyga> well
<zyga> anyway, just an idea
<zyga> I'm looking forward to see what Chipaca comes up with
<pedronis> well if undoing one error span tasks
<pedronis> then those tasks are not quite right
<zyga> pedronis: I think we are in this situation now still
<pedronis> that's a different kind of bug
<pedronis> not a reason to add complexity
<mup> PR snapd#3174 closed: interfaces,overlord: log interface auto-connection failures <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3174>
<zyga> right, I agree
<zyga> thank you mvo!
 * zyga considers upgrading to 17.04 to run polaris as IRC client
<zyga> anyone doing that
<zyga> it has nice UI and nice notification
<pstolowski> zyga, refactored 3182 test per your commnet
<pedronis> Chipaca: that's that don't manipulate state too much can usually be fixed by calling their undo manually on their failure path
<pedronis> s/that's/tasks/
<mvo> zyga: 17.04 ftw!
<zyga> mvo: are you on it?
<pedronis> assuming they are correctly idempotent
<pedronis> Chipaca: we basically need quite a few integration undo tests
<pedronis> mmh, not undo
<pedronis> error and undo to be precise
<mvo> zyga: my workstation, works very well
<Son_Goku> morphis_: yes
<zyga> pstolowski: thank you!
<zyga> pstolowski: checking
<zyga> pstolowski: commented
<pstolowski> zyga, looking, thanks
<Chipaca> mvoâ on unity 8? :-)
<mvo> Chipaca: *cough*
<pstolowski> zyga, ok, updated
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/3183 :)
<mup> PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
<zyga> pstolowski: (replied to your PR, just add a comment there and +1)
<zyga> pstolowski: have a look, you reviewed -1 in this series already
<mup> PR snapd#3104 closed: tests: fix unity test <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3104>
<mup> PR snapd#3183 opened: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
<zyga> pstolowski: not sure if I should parse mount and super-block options or optional fields deeply
<zyga> Chipaca: go-ness review appreciated ^^
<Son_Goku> mvo: you have a typo in your release notes
<Son_Goku> I think you mean "joystick" instead of "joystrick"
<mvo> Son_Goku: autsch, thank you! I will fix it
<Son_Goku> mvo: The 2.24 packages should synchronize out to updates-testing in Fedora in a few hours, so you can probably simultaneously mention Fedora and Ubuntu in the 2.24 release announcement
<mvo> Son_Goku: awesome! you rock!
<zyga> Son_Goku: awesome work! :)
 * zyga might consider switching to Fedora 25 for daily work 
<Son_Goku> mvo: I don't know if you make the release announcement usually before or after it is approved to go into ubuntu updates, so if you usually do it after, then I think we should probably push for people to test the Fedora package updates first
<Son_Goku> zyga: :D
<Son_Goku> Fedora master race :D
<mvo> Son_Goku: I draft the release annoucement (its in the forum) and JamieBen_ is now handling the announcing, but usually we announce when its in -proposed
<Son_Goku> speak of the devil :P
<JamieBennett> :)
<Son_Goku> but yeah, I submitted the updates to be released to updates-testing yesterday
<zyga> (especially if someone asks me to work on selinux)
<zyga> I need to spend some time at the forum today
<Son_Goku> so they should go out in a couple hours or so
<Son_Goku> people are also now asking about being able to craft Fedora-based snaps too
<zyga> Son_Goku: this is a compound question, we can craft a snap that uses fedora bits on top of the current ubuntu-based core snap or a fully fedora based "base" snap that we don't support yet
<Son_Goku> yeah, I know
<zyga> Son_Goku: I think we should get base snaps first
<sborovkov> Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior?
<morphis_> Son_Goku: btw. you want to push 2.24 to stable already now?
<Son_Goku> zyga: well we can't do either right now, because snapcraft needs work
<zyga> Son_Goku: then we will be able to do what people are really asking for: snapd not tied to ubuntu "base"
<Son_Goku> zyga: yes
<zyga> Son_Goku: note that snapcraft is not the only way to make snaps
<Son_Goku> I know, but it's what we're pushing
<zyga> Son_Goku: I think initially it is fine to just hand-craft snaps :)
<zyga> (I love that hame)
<zyga> name*
<morphis_> Son_Goku: one thing I talked with zyga about earlier today was that we wait for the official release date as everyone is having it just as candidate right now
<zyga> Son_Goku: I think snapcraft can only really be done when we have base snaps
<Son_Goku> yes
<Son_Goku> morphis_: what *is* the official release date?
<morphis_> 4/24
<Son_Goku> April 24?!
<Son_Goku> for 2.24?
<morphis_> yes
<morphis> yes
<Son_Goku> wow, that's two weeks from now
<zyga> Son_Goku: that's confusing
<morphis> Son_Goku: that is the regular candence time period for a snapd release
<zyga> the reality is this:
<zyga> 2.24 is in candidate/beta channel now
<morphis> through those two weeks it goes through all kinds of QA
<zyga> it's not a stable release
<zyga> it's a source tarball release
<zyga> + invitation to test the binary
<zyga> since we have channels and are actively using them
<zyga> the term "release" is not the same
<zyga> as we traditionally are used to
<zyga> I think we need to write this down
<zyga> and use clear terminology all the time
<morphis> zyga: but if you take the original "release" term, the release date is April 24 and what we have today is more of a 2.24-rc1
<zyga> and attach a short summary to each announcement
<Son_Goku> wow, there was literally no point in me pushing 2.24 at all, then
<morphis> Son_Goku: there is!
<zyga> morphis: exactly so
<morphis> Son_Goku: we need to send calls out for testing in the community
<Son_Goku> morphis: the problem is that if I'm ahead of Ubuntu, things are going to be broken
<Son_Goku> VERY broken
<morphis> a bodhi request is fine but it should land until th real 2.24 is out
<Son_Goku> Ubuntu moves too slowly in almost every regard when it comes to this
<Son_Goku> but if we're going to hold back the final release, I better turn off the autopush
<zyga> Son_Goku: why would they be broken?
<zyga> Son_Goku: yes, please turn off autopush for this
<Son_Goku> because the core snap is always broken on classic distros when it has an older snapd than what I run
<zyga> Son_Goku: are you sure/
<zyga> Son_Goku: why would it be broken?
 * Son_Goku shrugs
 * zyga tries to understand
<zyga> Chipaca: thanks for the feedback
<zyga> Chipaca: I think I'll leave the int parsing asis
<Son_Goku> it's not worth debugging because it's a spaghetti of interface things and weird errors
<zyga> Chipaca: but I was wondering about OptinalFlds
<zyga> Chipaca: and mount and super-block option
<zyga> Son_Goku: I mean, what error did you see
<Son_Goku> mainly non-existent interface errors
<zyga> Chipaca: should I call it OptionalFields and make it []string that I really parse?
<Son_Goku> they have no practical effect on Fedora now, since interfaces mean nothing
<zyga> Son_Goku: which interface specifically?
<zyga> Son_Goku: this may be an unrealted bug that I need to fix
<zyga> (same happens on ubuntu now)
<Son_Goku> well, I don't remember, since this was a week ago
<zyga> is it about network-bind or core-support?
<Chipaca> zygaâ ah, i might be the wrong person to talk with about names. OptionalFields is probably better than OptionalFlds though
<Son_Goku> core-support, I think
<zyga> if so this is a harmless note and I do need to correct that
<zyga> there's a branch that's pending merge and it will be in 2.25
<Chipaca> zygaâ about whether to leave it as an array, depends what you use it for
<Son_Goku> though it might have also been network stuff *shrugs*
<Son_Goku> in any case, it has no appreciable affect in Fedora
<zyga> Son_Goku: both are expected
<Son_Goku> since confinement is broken
<zyga> Son_Goku: it's not really related to confinement this time :)
<zyga> Son_Goku: it is the thing where we renamed plugs and there's no nice method to forget old connection
<Son_Goku> well, the interface/plug stuff is enforced through AppArmor
<zyga> Chipaca: ok, let's review/land this and I'll follow up with better names and perhaps deeper parsing
<zyga> mvo: can you review/land https://github.com/snapcore/snapd/pull/3183 for further iteration?
<mup> PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
<Son_Goku> zyga, mvo, morphis: Bodhi's auto push on +3 stable karma is disabled
<morphis> Son_Goku: good!
<zyga> Son_Goku: thank you!
<Son_Goku> now it's basically up to me to push if no one tests after 7 days
<zyga> mvo: maybe we can edit the forum post here to indicate when we expect to release it in binary form and when was the source tarball released
<pedronis> zyga: Chipaca: yes, Opts is kind of common, Flds not as much
<zyga> https://github.com/snapcore/snapd/pull/3183
<mup> PR snapd#3183: interfaces/mount: add parser for mountinfo entries <Created by zyga> <https://github.com/snapcore/snapd/pull/3183>
<zyga> pedronis: +1
<Son_Goku> morphis, zyga: https://lists.fedoraproject.org/archives/list/devel-announce@lists.fedoraproject.org/message/LT2Y5JKCT2FIM2Q6HMZHNTEXEPGW4JZI/
<zyga> pedronis: I'm inclined to spell it Options as that matches mount.Entry for fstab
<morphis> Son_Goku: nice!
<mvo> zyga: sure, go ahead, its a wiki (I think)
<Son_Goku> zyga, since we're going to have Fedora in parallel to Ubuntu, might as well make the announcement reflect that
<zyga> mvo: can you push the 2.24 tag to master?
<zyga> mvo: ah, I see it now
<zyga> sorry
<mvo> zyga: :)
<zyga> mvo: edited
<mvo> ta
<sborovkov> Hello. I am building gadget snap myself. One of the things I modify is few options of config.txt (gpu_mem and couple of other options). But when I run the resulting image all my options are commented out in config.txt. What does that and how do I prevent that behavior? Is that done by configure hook or what?
<morphis> sborovkov: sounds more like the wrong config.txt gets copied into place
<mvo> sborovkov: I think its done by the configure hook, it will unset things that it has not in the internal snapd config iirc
 * zyga switches gears for a moment
<morphis> mvo: isn't that coming with 2.24 or is already part of 2.23?
<mvo> morphis: 2.23.6 has a bug so yeah, only in 2.24
<sborovkov> mvo: any idea how to change that? I mean I could set those config options myself but that would require additional restart
<morphis> sborovkov: so from which channel is your core snap coming?
<sborovkov> edge
<morphis> ah
<sborovkov> morphis: can't be wrong config.txt - otherwise all my options would not be in there even commented out
<morphis> sborovkov: any specific reason to use edge?
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/3184
<mup> PR snapd#3184: store: misc cleanups in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3184>
<zyga> sborovkov: maybe bug in ubuntu-image
<zyga> sborovkov: wrt channels
<sborovkov> morphis: yes. because it has a bunch of resloved bugs that are blockers
<zyga> I think it handles that poorly now
<mup> PR snapd#3184 opened: store: misc cleanups in tests <Created by zyga> <https://github.com/snapcore/snapd/pull/3184>
<morphis> sborovkov: ah I see
<sborovkov> also a bit annoying that you can't make ubuntu-image to use your snap for instance from edge channel but core snap from the beta
<morphis> sborovkov: you can manually add snaps to your resulting image
<mvo> sborovkov: we could change the configure hook code to simply ignore anything that is not set. the downside is of course that if you snap core set pi-config.something="" that would go directly into config.txt, i.e. there is no way anymore to uncomment things. but maybe thats ok
 * mvo is away for lunch
<sborovkov> mvo: I am ok with everything. Though just for my case since I build gadget snap myself can't I set those options manually somewhere? So it does not unset them.
<morphis> sborovkov: https://gist.github.com/morphis/abdc1e83ba0578e756073bd89fa128ed
<morphis> sborovkov: especially https://gist.github.com/morphis/abdc1e83ba0578e756073bd89fa128ed#file-create-image-sh-L225
<morphis> sborovkov: if you download the snap before together with its assertion via snap download you can drop the unasserted: true
<zyga> morphis: scaleway arm servers use patched non ubuntu kernel
<zyga> morphis: no chance for apparmor
<zyga> morphis: I don't think it's worth pursuing yet
<morphis> zyga: ah
<morphis> zyga: the better go with what plars is building
<zyga> morphis: yes
<zyga> morphis: I'll check their x86 VMs out of curiosity
<morphis> :-)
<renat> Hi, guys=) It's Renat from Screenly=)
<renat> Hi, sborovkov=)
<morphis> renat: hey!
<renat> I have just a small question - snappy core doesn't ship with udisks2 installed, and I should install udisks2 into my snap, is it correct?
<morphis> renat: we have a udisks2 snap in the store you can
<morphis> renat: you wont be able to get udisks2 into your own snap
<pstolowski> Chipaca, hey, are you working on any of this https://forum.snapcraft.io/t/easy-way-to-get-last-change/246 ?
<renat> morphis, thanks! That's exactly what I need!
<Chipaca> pstolowskiâ negatory
<morphis> renat: there is upcoming documentation for that snap which is currently available here: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/udisks2/tree/docs
<morphis> renat: but the same will be soon on docs.ubuntu.com
<pstolowski> Chipaca, ok. bonus question then
<renat> Thanks, morphis!
<Chipaca> I should charge for these
<morphis> davidcalle: you know when a new deployment of the docs will happen?
<morphis> davidcalle: especially for https://github.com/CanonicalLtd/ubuntu-core-docs/pull/29 ?
<mup> PR CanonicalLtd/ubuntu-core-docs#29: Enable udisks2 documentation and fix up broken links <Created by jhodapp> <Merged by caldav> <https://github.com/CanonicalLtd/ubuntu-core-docs/pull/29>
<pstolowski> Chipaca, yesterday on the standup we discussed making "task" alias for "change" command (and make the latter hidden but still supported), but reading that forum topic makes me think that perhaps I missed something
<Chipaca> the other way around, making change alias for task
<Chipaca> i did not update the forum after the meeting
<Chipaca> also, tasks, not task
<davidcalle> morphism: later today
<pstolowski> Chipaca, ah!
<Chipaca> 1 change -> multiple tasks
<davidcalle> morphis
<sborovkov> mvo: I am still a bit confused. On the first boot pi-config is not actually set. But it's not like it removes kernel, dtparam and so on and so on from config.txt? Or is it not touching them because they can't be changed via configure hook?
<pstolowski> chihchun, "tasks" yes. suddenly it all makes more sense and you will not get any more bonus questions, i'm sorry
<Chipaca> pstolowskiâ and it wouldn't be an alias in the sense that go-flags supports aliases; it'd be a separate hidden command that just calls the other one
<pstolowski> uh, Chipaca ^
<pstolowski> Chipaca, yes yes sure
<Chipaca> woah, you need four chars to get my name
<__chip__> there
<__chip__> now i'm special
<zyga> morphis: can we relase 2.24 jointly to suse too?
 * __chip__ looks at _28Kb 
<pstolowski> in fact I did this change already in cmd, it just felt strange.. "tasks" it's then
<__chip__> pstolowskiâ how does it feel strange?
<Son_Goku> davidcalle: can we have snappy-docs move to the snapcore org?
<pstolowski> __chip__, only in that's mutiple tasks realy, plural
<morphis> zyga: yes, working on that
<__chip__> pstolowskiâ ah :-)
<ogra_> ooh .... Chipaca has wings!
<jdstrand> mvo: not sure if you saw, but fyi https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1682023
<mup> Bug #1682023: snapd/snap-confine leaves behind /etc/apparmor.d/usr.lib.snapd.snap-confine on upgrade <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1682023>
<zyga> morphis: sounds good
<jdstrand> mvo: at, it looks like you probably did see it now that I am reading backscroll
<mup> PR snapcraft#1247 closed: Fixing Store integration tests <Created by cprov> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1247>
<jdstrand> mvo: responded in 3181
<zyga> jdstrand: hey
<zyga> jdstrand: can you have a look at https://github.com/snapcore/snapd/pull/3138 -- it is a tiny RFC branch about mounting
<mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<pstolowski> http://www.omgubuntu.co.uk/2017/04/use-snap-fedora
<zyga> mvo: can you have a 2nd look to ensure that we want to land https://github.com/snapcore/snapd/pull/3160/files
<mup> PR snapd#3160: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <https://github.com/snapcore/snapd/pull/3160>
<mup> PR snapd#3182 closed: store: tests for unexpected EOF <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3182>
<pstolowski> zyga, ^ you will probably need to merge master into 3184
<zyga> pstolowski: looking
<zyga> aha
<zyga> thanks!
 * zyga is a bit hungry and parched, sounds like a time for a break
<zyga> done
<zyga> see you at the stand-up
<zyga> niemeyer: please have a look at https://github.com/snapcore/snapd/pull/3138 -- it is on the critical path for update-ns now
<mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<morphis> zyga, mvo: looks like spread tests are a bit flawky today, is that known?
<zyga> morphis: URL please
<zyga> morphis: I didn't see any failures
<morphis> https://s3.amazonaws.com/archive.travis-ci.org/jobs/221306064/log.txt
<morphis> linode:ubuntu-14.04-64:tests/main/refresh-delta-from-core is failing here
<morphis> zyga: that is for https://github.com/snapcore/snapd/pull/3170
<mup> PR snapd#3170: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <https://github.com/snapcore/snapd/pull/3170>
<mup> PR snapd#3185 opened: snap: added tasks subcommand <Created by stolowski> <https://github.com/snapcore/snapd/pull/3185>
<mvo> morphis: https://forum.snapcraft.io/t/autopkgtest-failues-with-master/260 - I think its because of the interfaces change but I did not look deeper
<morphis> mvo: hm ok
<morphis> then let me don't count on this and I will wait until the dust settles :-)
<zyga> morphis: just merge master
<zyga> aha
<zyga> the failure is in delta-from-core
<zyga> morphis: you just joined and disconnected
<mup> PR snapcraft#1252 opened: ci: split plugin integration tests out <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1252>
<Son_Goku> zyga, morphis: https://lists.fedoraproject.org/admin/lists/ci.lists.fedoraproject.org/
<zyga> Son_Goku: I got 503
<Son_Goku> hmm, Postorius seems to be down
<zyga> aha
<zyga> what was the thing behind the URL?
<zyga> ah, it's up now
<Son_Goku> the mailing list for Fedora CI
<morphis> ah :-)
<morphis> 403 forbidden for me
<morphis> zyga: btw. did you manage to file all bugs for the SELinux denials on Fedora?
<zyga> morphis: I filed two
<zyga> morphis: I didn't file more as we need to check if it makes sense
<morphis> zyga: have those two on my list
<morphis> good
<zyga> morphis: and I think we need to see if the format is right
<zyga> morphis: I can file the rest
<morphis> zyga: lets wait with that
<morphis> I will look first and then we can decide
<Chipaca> niemeyerâ want me to open a topic about snap service?
<niemeyer> Chipaca: Almost done with it already
<Chipaca> niemeyerâ :-D
 * zyga goes to eat that lunch he was meant to earlier 
<zyga> I'll focus on focum / email after that
<zyga> enjoy easter holidays o/
<niemeyer> Chipaca: https://forum.snapcraft.io/t/command-line-interface-to-manipulate-services/262
<Pharaoh_Atem> zyga, morphis, sergiusens: don't forget to respond to mattdm's email :)
<sergiusens> Pharaoh_Atem: yeah, I'll reply with what I know, but leave the other paragraphs we discussed to zyga or morphis
<Pharaoh_Atem> sergiusens: that's fine
<ogra_> hah ... the right keyboard for core developers ... finally ... https://www.massdrop.com/buy/vortex-core-47
<Chipaca> ogra_â what, no GOTO key?
<ogra_> probably at the bottom :)
<Chipaca> ogra_â http://4.bp.blogspot.com/-lUibvtAqm2E/UYVrSpG_4MI/AAAAAAAAAxE/oov7bXRCLw4/s1600/keyboard.jpg
<ogra_> !
<Chipaca> ogra_â or, rather, http://images.eurogamer.net/2013/articles/1/6/5/1/7/8/3/139143204009.jpg/EG11/resize/600x-1/quality/80/format/jpg
<ogra_> yeah, i think popey raved about that one before on G+
<Chipaca> heh
<Chipaca> massdrop is so expensive from uk though
<Chipaca> also, i can't really justify another keyboard
<Chipaca> it is a beaut tho
<ogra_> heh, yeah, i ddint mean to push you towards buying it ...
<jdstrand> niemeyer: fyi, I plan to start an 'ownership' topic today. I can layout the various use case that have been accumulating as well as what we discussed yesterday
<jdstrand> cases*
<ogra_> i'm typing on the pok3er ... next bigger model with 67 keys
<jdstrand> niemeyer: and hi!
<jdstrand> niemeyer: I figured it might be easier this way since I've thought about this for a while (ie, if I lay it out rather than responding with other use cases)
<niemeyer> jdstrand: Sounds great, thank you!
<jdstrand> np
<Chipaca> cuppa tea anyone?
 * Chipaca goes
 * tvoss tea, earl grey, hot
 * genii hugs his pot of coffee instead
 * ogra_ joins genii in huggung coffee pots 
<morphis> zyga: the export_test.go trick is good, but how can I share the best way a Mock* method across modules?
<morphis> adding it to testsutils?
<tvoss> niemeyer: hey, https://github.com/snapcore/snapd/pull/3130 just went green :) would be great if you could have a look
<mup> PR snapd#3130: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <https://github.com/snapcore/snapd/pull/3130>
<niemeyer> tvoss: WIll do.. a bit busy this morning, but will do in the afternoon
<tvoss> niemeyer: great, thank you
 * tvoss goes to build docker snaps with configurable cert directory
<ogra_> would be awesome if that finally landed
<ogra_> so much back and forth ...
<Chipaca> tvossâ now rewrite it using libressl
 * Chipaca hides
<tvoss> Chipaca: I would rather look at golang's BigInt and optimize that a little ;)
<ogra_> make it EvenBiggerInt
<bspock> Which folder should be added in my $PATH in order to run the installed snaps?
<ogra_> bspock, the snapd package adds that autiomatically ...
<ogra_> (you need to log out and back in if you only just installed snapd though)
<bspock> ogra_: Ah, that's probably my problem. Will try that, thanks
<ogra_> your path should then have /snap/bin at the end
<Chipaca> tvossâ just math/big.divWVW
<Chipaca> tvossâ although math/big.bitLen probably also
<tvoss> yup, gcd might be candidate as well, haven't look further, though
<tvoss> looked
<sborovkov> mvo: btw why does rpi-config has _ converted to '-'. But not everywhere? :) Like here - framebuffer-ignore_alpha
<kyrofa> sborovkov, OCD sniping?
<kyrofa> I'm unhappy you even typed it here :P
<kyrofa> ogra_ might have an idea
<Chipaca> sborovkov, kyrofa, different things
<Chipaca> _ is within a name
<Chipaca> - is between scopes
<Chipaca> levels
<Chipaca> whatever you want to call them :-)
<kyrofa> Ah, thanks Chipaca :)
<Chipaca> there's a hierarchy in there
<stub> -_-
<Chipaca> totally (-_-)
<Chipaca> (i wasn't saying it was a *good* reason :) )
<sborovkov> Hmm, alright. It's just not very convenient when you have a list of config.txt options you want to actually set
<sborovkov> Because they all need converted according to different rules then
<Chipaca> sborovkovâ do you think you could raise the issue on the forum?
<Chipaca> sounds like something that needs to be spelled out in more detail
<sborovkov> Chipaca: sure, what forum are you talking about
<Chipaca> sborovkovâ forum.snapcraft.io
<ogra_> sborovkov, see topic :)
<Chipaca> :-)
<sborovkov> Damn, did not think of that
<sborovkov> Like that's just a bit inconvenient. Can't even replace dashes with underscores. Because there gpu-mem-256. Need to have 2 maps to convert it.
<mup> PR snapd#3186 opened: tests: allow installing snapd from -proposed for SRU validation <Created by fgimenez> <https://github.com/snapcore/snapd/pull/3186>
<t-mon> Hi everyone! I'wanted to ask how I can access gpio's from my snap since the gpio interface is missing on my system. I'm using snapd on a debian. Is there any other way how I can workaround this for development?
<t-mon> Should I move this question to the forum?
<Nicolino_> hi all : i don't find a command for producing a list of all avalaible revision of a snap on the store
<Chipaca> Nicolino_â snapcraft history, i think?
<Nicolino_> thanks
<Nicolino_> also fot the core?
<sborovkov> Chipaca: according to this hierarchy how are those options called? config_hdmi_boost, hdmi_force_hotplug (I am not sure how to query all supported names...)
<Chipaca> Nicolino_â "for the core"? you mean for the core snap?
<Chipaca> Nicolino_â you can only get the list of revisions of the snaps you have dev rights to
<Chipaca> i mean upload privs
<Nicolino_> yes  i mean core snap
<ogra_> well ... there is "snap info core"
<ogra_> but that only shopws current versions
<Chipaca> Nicolino_â you can't get a list of all revisions
<Chipaca> Nicolino_â you can get a list of published revisions, via 'snap info'
<Nicolino_> i would test my uboot setting with a core upgrade
<Nicolino_> i create an device image right now Chipaca
<ogra_> Nicolino_, just switch channels then
<Chipaca> Nicolino_â you could `snap refresh --beta core`, starting from stable
<Chipaca> yeah
<ogra_> snap refresh core --edge
<Nicolino_> thanks a lot to all :D
<ogra_> (and to switch back later just replace --edge with --stable)
<Chipaca> ogra_â http://i.imgur.com/XbjbHlM.jpg
<ogra_> :D
<mup> PR snapd#3183 closed: interfaces/mount: add parser for mountinfo entries <Created by zyga> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3183>
<Croepha> anyone know off hand an easy way to get usb keyboard in the initramfs shell?
<pstolowski> it would be great to get 2nd review for 3184 and land it quickly, a trivial MP
<Chipaca> Croephaâ ogra_, if anyone
<mup> PR snapd#3184 closed: store: misc cleanups in tests <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3184>
<mup> PR snapcraft#1252 closed: ci: split plugin integration tests out <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1252>
<mvo> sborovkov: autsch, if it does not do it everywhere that is a bug
<sborovkov> mvo:  IS there a way to query all  supported keys? I was checking the names from your post actually https://forum.snapcraft.io/t/configuration-options-for-core-snap/87 - specifically framebuffer-ignore_alpha
<ogra_> Croepha, no easy way i fear ... you would have to re-pack it and add the respective modules (or simply use a serial console)
<Croepha> ogra_, ok thanks, this is a custom kernel I made 6 months ago, I just finished downloading the Intel NUC image for 16, hopefully that will work, if not I'll rebuild
<sborovkov> mvo: or was that typo in the post and I can just replace underscores with dashes? :-)
<ogra_> well, that wont have hid modules either in the initrd
<Croepha> for the record, im actually using the intel compute stick, and several months ago, the kernel that shipped with didn't have good support for the hardware
<ogra_> we are very explicit to only include drivers that are needed to find the rootfs
<Croepha> ogra_: ok good to know, im hoping that maybe the new kernel might fix another problem and make the initramfs KB driver unessasary
<Croepha> but if it doesn't, then I might pop open the device physically and look for serial headers
<ogra_> that could well be, i remember adding some modules on request of the team that was working with the NUC
<Croepha> that might be easier then using a custom kernel
<ogra_> afaik the normal pc-kernel snap should now work
<Croepha> btw, is the NUC image the same as the regular amd64 image?
<Croepha> like, is it a generic kernel?
<ogra_> not sure ... there might be additional snaps in it by defult
<ogra_> the kernel is definitely the same though
<Croepha> ok good to know
<Croepha> thanks
<ogra_> that got fixed between 15.04 and 16 snappy images
<Croepha> I just got a USB 3 thumb-drive, eager to see the perf differences first hand
<Croepha> I wanted to try the new image, but didn't want to overwrite the image that kinda works on my other thumbdrive
<Croepha> ehh, a bit underwhelming
<niemeyer> tvoss: reviewed, thanks for all the work there!
<sborovkov> mvo: yeah, it was typo in your post. Nice. Cause I was already doing 2 maps to convert back and forth :-)
<Croepha> ogra_ im assuming that the serial interface for the initramfs requires a real BIOS serial port, i.e. a USB to serial wont work?
<ogra_> USB to serial would be exactly the opposite
<ogra_> so no, i dont think it would
<Croepha> right, thanks, figured Id ask
<jdstrand> morphis: I want to think about your bug #1647168 more but will ask here, quickly, snap-confine 1.0.43? shouldn't you be on at least 2.22.6 if not 2.23.6 (proposed)?
<mup> Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168>
<morphis> jdstrand: that bug is quite old but thanks for looking into that!
<morphis> jdstrand: need to see if I can still reproduce this with the latest snapd/snap-confine
<morphis> jdstrand: http://anbox.io/ is the application I was experiencing this with
<pompomJuice> hi
<kyrofa> Hey there pompomJuice, welcome
<Croepha> it appears that the pc-kernel rev 60 doesn't support HDMI audio on the intel compute stick
<pompomJuice> How do I get snappy install to install my locally made snapcraft packages? the unauthorized setting does not work?
<pompomJuice> Installing my-open-vm-tools_0.1_amd64.snap Signature verification failed with exit status 14
<kyrofa> pompomJuice, what do you mean mine "unauthorized setting?"
<kyrofa> s/mine/by/
<kyrofa> pompomJuice, ah, installing local snaps requires you to use the --dangerous flag
<pompomJuice> kyrofa: snappy install --allow-unauthenticated my-open-vm-tools_0.1_amd64.snap
<pompomJuice> none of those things work with snappy
<pompomJuice> just snap
<kyrofa> pompomJuice, ah, that's snappy 15 speak
<kyrofa> pompomJuice, it's changed a bit since then
<pompomJuice> So are these snappy cloud images usable?
<Croepha> so, what is the appropriate bug tracker for getting patches into the core kernel?
<pompomJuice> I cannot change the channel and I cannot install dangerous modes
<kyrofa> pompomJuice, https://askubuntu.com/questions/822765/snap-install-failure-error-cannot-find-signatures-with-metadata-for-snap
<kyrofa> pompomJuice, is that what you're seeing?
<pompomJuice> kyrofa: Yes know about those options. The problem I have is I am trying to use the ubuntu core cloud image. It does not comes with snapd. Rather with "snappy"... a front end of sorts for snap
<kyrofa> pompomJuice, that sounds wrong
<pompomJuice> it has different options
<kyrofa> ogra_, do you know anything about that ^^ ?
<pompomJuice> it does sound wrong!
<pompomJuice> I want snapd
<pompomJuice> it has what I need
<kyrofa> pompomJuice, yeah, the command called "snappy" is very old. It sounds like you're using a distro based on 15.04
<pompomJuice> but this cloud image comes with a noob mode snappy so I was wondering what is going on
<kyrofa> pompomJuice, what cloud image are we talking about? Do you have a link?
<pompomJuice> kyrofa: http://cloud-images.ubuntu.com/snappy/devel/core/current/
<kyrofa> pompomJuice, whoa, super old
<kyrofa> That is indeed 15.04
<pompomJuice> ok lol
<pompomJuice> no wonder I am getting nowhere with this
<pompomJuice> thanksman
<jdstrand> morphis: oh weird that it is quite old, I only just saw it recently
<zyga> hey guys
<morphis> jdstrand: you think it could have been a bug in snap-confine?
<morphis> zyga: hey! :-)
<jdstrand> morphis: there is a lot going in with bind mounts. I'm not prepared to say what the problem is
<zyga> what are you chatting about?
<jdstrand> though I have a lot of concerns regarding /dev/binder
<morphis> jdstrand: ok, then let me try that again and see if is still a problem
<jdstrand> going on*
<morphis> zyga: https://launchpad.net/bugs/1647168
<mup> Bug #1647168: /dev/ashmem and /dev/binder not usable inside confinement <snap-confine (Ubuntu):New> <https://launchpad.net/bugs/1647168>
<zyga> aha
<zyga> This is with snap-confine 1.0.43 on Ubuntu 16.04
<jdstrand> hey zyga
<zyga> snap-confine 1.0.43
<jdstrand> yeah, that was what I mentioned
<jdstrand> too old
 * zyga reads the bug 
<jdstrand> zyga: fyi, I'm not actively looking at it atm. it is on my list to circle back to cause I have some pretty strong opinions about /dev/binder
<zyga> morphis: do you have the apparmor denials at hand?
<zyga> jdstrand: binder is the android RPC-like IPC right?
<jdstrand> yes
<zyga> you syscall and start executing in the same time slice, in another process
<jdstrand> it is a window to a whole new, glorious attack sruface... err... world
<morphis> zyga: it is, not I don't that is quite a long time ago
<morphis> jdstrand: :-)
<zyga> aha
<zyga> jdstrand: is binder now in the kernel? I didn't know this
<zyga> and ashmem
<zyga> wow
<morphis> jdstrand: guess what, we need a binder interface :-)
<morphis> zyga: its in staging but disable by default in the std. Ubuntu kernel
<zyga> morphis: aha
<morphis> I have dkms packages for both
<zyga> well, I'd say, letem have it for android-support interface
<zyga> and just grant it to this snap
<zyga> it's all software
<zyga> and you know
<morphis> or something like this
<zyga> windows xp wasn't exactly safe
<zyga> ;-)
<morphis> far from :-)
<jdstrand> zyga: no, this would have to be on an android kernel
<jdstrand> morphis: I know you said that, but that is a *lot* more complicated than just saying 'yes, you can use /dev/binder'
<morphis> jdstrand: yeah :-)
<morphis> jdstrand: that is one of the cases why anbox will be devmode-only for quite some time
<jdstrand> zyga: I'm going to pretend your argument was a joke :)
<zyga> jdstrand: well, it was a joke but I was actually serious about it as well, if we don't provide it as an interface everyone will just use devmode; is that better?
<jdstrand> I don't want to have this conversation :)
<jdstrand> really, it depends on what is running on the other side
<jdstrand> if it is like on Touch, then the services are pruned and hardened
<jdstrand> it we are exposing the whole android service set, then, no, it probably isn't terribly better than devmode
<morphis> jdstrand: in this case it would be more granting a single which isn't used outside of the snap
<morphis> jdstrand: actually I have patches to make binder namespace aware
<jdstrand> well, let's not distract ourselves atm :)
<morphis> absolutely not :-)
<morphis> just thinking out loud
<jdstrand> I just wanted to put forth that devmode may work better with a newer snapd/snap-confine
 * jdstrand nods
<jdstrand> zyga: "Once Linux 4.13 is released any distribution can choose to enable apparmor and get complete confinement without rebuilding most of snapd" - where did you get 4.13?
<Erix> hi
<Erix> i installed nextcloud snap on ubuntu server 16.10
<Erix> cannot find a2ensite for apache2
<nacc> kyrofa: --^ redirected them from #ubuntu-server
<kyrofa> nacc, ah, thank you
<Erix> thanks nacc
<kyrofa> Erix, nextcloud embeds upstream apache within it. There is no a2ensite
<nacc> np, figured you'd be able to answer quicker than I :)
<kyrofa> Erix, it ships pre-configured and ready to go, but it's not a general purpose apache
<kyrofa> Its sole purpose is to serve Nextcloud
<Erix> kyrofa, I'm kind of newbie about this
<redpill> are snaps supposed to mount on /snap/bin  ?
<kyrofa> Erix, oh that's okay, let's back up a little :)
<kyrofa> Erix, is this the first time you've setup Nextcloud?
<Erix> I'm trying to edit a virtualhost config file
<kyrofa> Erix, what is your end goal?
<Erix> Actually I edited but guides tell me to run a2ensite
<Erix> direct http to https
<Erix> I'm following nextcloud guide about https
<nacc> redpill: i think they are mounted on /snap/<snapname>/<rev>
<nacc> redpill: based upon what i see in my test VM :)
<kyrofa> Erix, there's a huge difference between setting Nextcloud up by installing apache, choosing a database, etc. and just installing the snap
<kyrofa> Erix, the snap takes care of all that stuff for you (but limits your power a bit as a result), whereas if you want to setup it all up yourself you can't use the snap
<redpill> odd my are not
<Erix> kyrofa, I get that
<kyrofa> Erix, if you want to set it up yourself you need to use the Nextcloud release tarball
<Erix> it was just too easy
<Erix> :)
<Erix> I'm running nextcloud with my little linux knowledge
<kyrofa> Erix, enabling HTTPS using the snap is easy, and you don't need to play with Apache configs to get there
<nacc> redpill: iiuc, /snap/bin is now just a place for symlinks to /usr/bin/snap to live (for each snapped application) -- based upon the one snap i have installed :)
<kyrofa> Erix, assuming you still want to use the snap, what documentation are you following so I can know what you've done?
<nacc> redpill: since /snap/bin is on PATH
<Erix> kyrofa, https://docs.nextcloud.com/server/11/admin_manual/configuration_server/harden_server.html#use-https-label
<redpill> ty that helps
<redpill> nacc: ^
<nacc> redpill: i'm not an expert, but that's what i see in my 16.04 vm
<kyrofa> Erix, and what vhost are you editing?
<Erix> kyrofa, nextcloud.enable-https: section on your snap site is about this also?
<nacc> redpill: you should be able to see what's mounted where with `mount | grep squashfs`
<kyrofa> Erix, indeed
<nacc> kyrofa: is there a general "I installed this snap, how do I use it" functionality? (or even just for nextcloud)?
<Erix> kyrofa, BTW thanks for the great work
<nacc> kyrofa: i'm thinking similar to regular manpages, but specific to the snap's quirks
<Erix> it was not poosible for me to install nextcloud without your snap
<kyrofa> nacc, this pretty much: https://github.com/nextcloud/nextcloud-snap#how-to-use
<nacc> kyrofa: ack, just wondering how a user should go from `snap install nextcloud` to that URL without coming here :)
<nacc> kyrofa: i guess `snap info nextcloud` has the url
<kyrofa> nacc, yeah, that's the idea
<kyrofa> nacc, still not super friendly, but I'm not sure how to make it better
<nacc> kyrofa: duly noted for when i see that kind of question in the future, thanks
<nacc> kyrofa: yeah, i was just thinking -- given that you know which commands you are exposing in the yaml, it'd be nice for there to be  blurb for each
<kyrofa> Erix, so: is the snap actually working for you, then? You just want to enable HTTPS?
<nacc> kyrofa: in they yaml, then you could in theory do `snap man nextcloud` and it'd just spit out those fields, if there
<kyrofa> nacc, in the `snap info` output?
<nacc> kyrofa: not "great", but it'd be a bit more user-friendly then "go to this URL"
<nacc> kyrofa: i think it'd be a separate command, or maybe a flag?
<kyrofa> nacc, yeah, best I can do as a snap author is add `-h` options to my commands :P
<nacc> kyrofa: yeah -- i guess we also have to get used to doing <snap_name>[tab] to see the commands
<kyrofa> nacc, indeed. At least for now, yeah
<Erix> kyrofa, yes
<Erix> kyrofa, everything works as I like
<kyrofa> Erix, oh, did you figure out how to use `enable-https`?
<Erix> I just want to force every connection to https
<kyrofa> Ah, okay, sorry. Happy to walk you through if you like
<kyrofa> Erix, `nextcloud.enable-https -h` might be helpful
<Erix> kyrofa, just reading the -h output
<kyrofa> Great minds
<mcphail> A solution for man pages and bash compketion is needed
<kyrofa> Erix, it really comes down to "how do you want to get your cert/do you already have a cert"
<kyrofa> mcphail, yeah I think both are in the works
<mcphail> great
<Erix> kyrofa, self-signed seems easier option for me
<Erix> going with that
<kyrofa> Erix, yeah that's pretty easy. Easy to change to something like let's encrypt later if you want
<Erix> kyrofa, restarted apache
<Erix> is it done?
<kyrofa> Erix, yep
<kyrofa> Erix, just visit it again and you'll see http redirect to https
<Erix> kyrofa, I see https but its red and labeled not secure by chrome
<kyrofa> Erix, yeah, because it's self-signed
<Erix> ok. I guessthat
<Erix> but it is secure connection
<kyrofa> Erix, you'll need to use Let's Encrypt (or another CA) if you want web browsers to be happy
<kyrofa> Indeed, it's encrypted
<zyga> re
<zyga> jdstrand: from jjohansen
<Erix> kyrofa, it was so easy also
<Erix> thanks again
<Erix> very much
<kyrofa> Erix, my pleasure, any time
<kyrofa> Erix, FYI, I also idle in #nextcloud if you ever run into issues
<Erix> ok. I'm there also
<Erix> Although I read as much as needed but
<Erix> is this right;
<Erix> snaps are combinations of pre configured software for a specific target in mind
<Erix> thats is what I understood
<jjohansen> zyga: that is the goal, it is possible I want get everything landed by then, especially if some of it gets stuck for testing in the -next tree
<jdstrand> zyga: hmm, I thought that was an estimation, not a hard date, but I don't know
<jdstrand> it's super important to be sure
<jjohansen> jdstrand: yeah, that is the goal
<jjohansen> I do have some concerns around the extended network mediation, which unix sockets are the first of
<zyga_> re
<zyga_> sorry, network
<tvoss> niemeyer: thanks for the review :) let me get to your final remarks
<jdstrand> zyga_: in case you missed it:
<jdstrand> 15:09 < jjohansen> zyga: that is the goal, it is possible I want get everything
<jdstrand>                    landed by then, especially if some of it gets stuck for testing
<jdstrand>                    in the -next tree
<zyga_> aha
<jdstrand> 15:10 < jdstrand> zyga: hmm, I thought that was an estimation, not a hard date, but
<jdstrand>                   I don't know
<zyga_> thank you jdstrand
<jdstrand> 15:10 < jdstrand> it's super important to be sure
<jdstrand> 15:10 < jjohansen> jdstrand: yeah, that is the goal
<jdstrand> 15:11 < jjohansen> I do have some concerns around the extended network mediation,
<jdstrand>                    which unix sockets are the first of
<jdstrand> np
<zyga_> jjohansen: do you think there will be any pushback?
<jjohansen> ugh, now you have sent /me into panic mode, my deadline is only 7-8 weeks out
 * jjohansen so prefers to ignore reality
<zyga_> hard time to
<jjohansen> yeah
<zyga_> in case we get hit, I really enjoy working with you
<kyrofa> Erix, sorry I missed your question. Yeah, that seems like a reasonable way to think of them
<Croepha> does there exist a snap for the 4.11 kernel?
<tvoss> niemeyer: done and pushed
<stokachu> facubatista: around?
<stokachu> getting a proxy error trying to upload to the store
<facubatista> stokachu, here
<facubatista> stokachu, "proxy error"?
<stokachu> yea
<facubatista> stokachu, using snapcraft?
<stokachu> yep
<Erix> kyrofa, thanks
<stokachu> facubatista: http://paste.ubuntu.com/24369710/
<stokachu> facubatista: http://paste.ubuntu.com/24369715/ in its entirety
<facubatista> stokachu, looks like a generic server error, will take a look
<stokachu> thanks, a kubernetes release for juju is blocked on us
<facubatista> stokachu, did you retry?
<stokachu> just twice
<stokachu> you want me to try again?
<stokachu> facubatista: ^
<facubatista> stokachu, 1'
<facubatista> stokachu, mind to try once again? thanks
<stokachu> ok
<stokachu> facubatista: looks like it went through
<facubatista> stokachu, oh, ok
<stokachu> facubatista: what was the issue?
 * facubatista has mixed feelings in this situations.. glad it worked, but sad the original problem couldn't be debugged further
<facubatista> stokachu, we were experiencing some storage issues, I just tried to confirm if it was the case here... but now it worked :/
<stokachu> facubatista: ah ok
<stokachu> facubatista: ill let you know on the next issue :D
<facubatista> stokachu, thanks :)
<facubatista> stokachu, how big is your snap file?
<stokachu> facubatista: 92.5MB
<facubatista> stokachu, thanks! (collecting info for people that also studied these transient errors)
<stokachu> anytime
<mup> PR snapcraft#1245 closed: nodejs plugin: add support for yarn <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1245>
<gregl> If I install a snap of a running program (plexmediaserver),will it mess up my running version??
<mcphail> Can anyone point me to a Rails application which has been snapped? Wondering if I should try to tackle snappificating Mastodon
<mwhudson> so something in snapd is filtering out the TMPDIR environment var
<mwhudson> any ideas where? grepping isn't finding anything
<oky> mwhudson: do you need to set it?
<mwhudson> a user of my classic snap wants to set it, yes
#snappy 2017-04-13
<oky> mwhudson: set it in the wrapper, right?
<oky> or are you saying the it is set in the wrapper and its being unset
<mwhudson> it's set in the environment that invokes snap but is unset inside the snap
<mwhudson> http://paste.ubuntu.com/24371015/
<mwhudson> i guess i should just file a bug
<qengho> Hah ha ha. https://medium.com/@nusenu/is-this-a-ubuntu-based-botnet-deploying-tor-relays-and-bridges-b4ce1a612039
<pstolowski> morning
<mup> PR snapd#3173 closed: tests: add extra test after the core transition for snap get/set core <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/3173>
<zyga> pstolowski: hello
<mup> PR snapd#3187 opened: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <https://github.com/snapcore/snapd/pull/3187>
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/3187
<mup> PR snapd#3187: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <https://github.com/snapcore/snapd/pull/3187>
<zyga> pstolowski: follow-up from yesterday
<pstolowski> zyga, ok
<zyga> pstolowski: if you look at individual commits then the changes are easier to parse
<zyga> morphis: hey, are you working today?
<mup> PR snapd#3170 closed: interfaces/builting: allow read-only access to /sys/module <Created by morphis> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3170>
<mwhudson> zyga: two things
<mwhudson> zyga: (1) https://forum.snapcraft.io/t/something-filters-out-tmpdir-even-for-classic-snaps/277
<mwhudson> zyga: (2) for env var stuff, did you consider looking at main's 3rd argument and using execve rather than getenv/setenv etc?
<zyga> hey
<zyga> mwhudson: haha, I was just reading that :)
<mwhudson> heh
<zyga> mwhudson: yes, I want to use execve everywhere, I don't think we can use os.setenv safely
<mwhudson> i don't know why i even posted anything about that to a list or bug, i should have just poked you :-)
<zyga> mwhudson: as for the TMP thing, I was just about to grep
<zyga> :D
<mwhudson> zyga: i didn't realize until fairly recently how much of a hack glibc's environment functions are
<zyga> mwhudson: I think you just reminded me of a very old bug
<zyga> mwhudson: pre-shared namespaces
<zyga> mwhudson: hehe, yes, it's all just ... er... creative
<zyga> mwhudson: so, look at (sic) mount-support.c and grep for TMPDIR
<zyga> mwhudson: we set TMPDIR *when setting the namespace initially*
<zyga> not each time
<zyga> I'll fix that ASAP
<zyga> so it's all bonkers
<mwhudson> zyga: that doesn't get called for classic snaps though does it?
<mwhudson> unless this classic_confinement bool is very obscurely named :-)
<zyga> mwhudson: another good remark, I'll disambiguate that
<zyga> mwhudson: correct, it doesn't get called for classic confinement
<zyga> hmm hmm
<zyga> so we have also snap-exec
<zyga> but I grepped and found nothing TMP*
<zyga> one more ideas is that the new environment handling code is messing up stuff
<zyga> (where snapcraft.yaml can define environment)
<zyga> let me fix the first bug and iterate
<mwhudson> i did have something of a poke and found nothing
<mwhudson> if it turns out to be something glibc does when you execute a setuid binary i might be very angry
<mwhudson> oh god
<zyga> oh
<zyga> that's a good hunch
<zyga> probably another AT_SECURE magic
<zyga> does the kernel meddle with environment?
<mwhudson> http://lists.gnu.org/archive/html/bug-glibc/2003-08/msg00076.html
<mwhudson> it seems less likely
<mwhudson> syscall(SYS_execve, ...)?
<zyga> aha :)
<zyga> let's confirm this is really in the code still (but I bet it is)
<mwhudson> although i can't find it in my glibc checkout
<mwhudson> reading glibc code makes me appreciate go in a few ways
<zyga> about to look, just pushed a PR
<zyga> yes, glibc has this special kind of mix of being C, having insane indents and having ugly identifiers in one place
<zyga> I love C, I really do, but ... not glibc
<zyga> https://github.com/snapcore/snapd/pull/3188
<mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
<zyga> without spread yet, I'll do spread next when we confirm what's going on in glibc
<mwhudson> zyga: also preprocessor abuse
<mup> PR snapd#3188 opened: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
<mwhudson> i think i have found the glibc evil
<zyga> mwhudson: look at sysdeps/generic/unsecvars.h
<zyga> mwhudson: :)
<zyga> it's still there
<mwhudson> ah right, i'd found the other end, where that is used
<mwhudson> it's AT_SECURE, as you said
<zyga> why in the world is this unsetting TMPDIR though
<zyga> or TZDIR for that matter
<mwhudson> so my syscall idea was not going to help
<mwhudson> zyga: i guess so you can't do TMPDIR=/etc <some setuid program> and have it scribble randomly
<zyga> aha, yes :/
<zyga> indeed
<mwhudson> snap run translates TMPDIR to TMPDIR_, snap-confine copies TMDIR_ back to TMPDIR? >:)
<zyga> hahaha
<zyga> well
<zyga> not sure if it is worth all the effort
<mwhudson> it's my day for working late in the evening, you're not going to get sense
<pedronis> zyga: what does snap-confine do for a classic snap?
<mwhudson> one day it will mount /var/lib/snap at /snap on some distros...
<mwhudson> (did i guess that right?)
<zyga> pedronis: pretty much nothing AFAIR
<pedronis> ok
<zyga> mwhudson: no, we cannot do that sadly, classic confinement doesn't use any namespaces
<zyga> well, let me check
<zyga> maybe we do something
<zyga> yeah, we mkdir user data directories
<zyga> but that's all
<zyga> mwhudson: I commented on the forum
<zyga> mwhudson: https://github.com/snapcore/snapd/pull/3189
<mup> PR snapd#3189: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
<mup> PR snapd#3189 opened: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
 * zyga -> coffee
<zyga> re
<mup> PR snapd#3082 closed: many: break the /aliases mutation API with a clean 400 (aliases v2) <Blocked> <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3082>
<pedronis> Chipaca: hi, IÂ would appreciate a 2nd review for snapd#3087
<mup> PR snapd#3087: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<Chipaca> hadn't i done this one already?
<pedronis> Chipaca: no, you did the helpers one, this one builds tasks on top of them
<mup> PR snapd#3160 closed: overlord/ifacestate: automatically rename connections on core snap <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3160>
<pedronis> Chipaca: yea, that was #3044
<pedronis> Chipaca: it's a long adventure
<Chipaca> :-)
<Chipaca> pedronisâ your super-wide screen is leaking again
<pedronis> Chipaca: I don't think it's my screen, it's how emacs wraps things for me
<Chipaca> pedronisâ i meant the comments
<pedronis> I know
<Chipaca> ah
<pedronis> just saying is not the screen
<Chipaca> strange, mine leaves those mostly alone
<Chipaca> anyway, no biggie
<pedronis> Chipaca: anyway just comment and will rewrap
<Chipaca> will do
<Chipaca> but i'm reviewing based on the diff to master, which doesn't let me comment directly
<pedronis> Chipaca: sorry, I need to remove the comment, now all deps are merged
<pedronis> it can be reviewed normally
<pedronis> Chipaca: it's just biggish, mostly tests
<ogra_> zyga, looking at https://github.com/snapcore/snapd/pull/3188, i i'm wondering, is there really any practical case where a setenv would not work ? (why the check?)
<mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
<Chipaca> ogra_â ENOMEM
<Chipaca> setenv can fail with ENOMEM
<ogra_> ah, well ... but then you will die anyway
<Chipaca> ogra_â yes but ignoring an ENOMEM because it will die anyway is how you get Bad Things done to you
<ogra_> heh, k
<Chipaca> there's practical, and then there's under attack
<ogra_> yup, understood
<zyga> ogra_: snap-confine is written in paranoia mode, we try to check all errors
<ogra_> i noticed ;)
<Chipaca> man, i wish we were in 1.8 already
<Chipaca> sort.Slice is where it's at
<zyga> Chipaca: when designing a language, make sure that sorting doesn't suck in 1.0 release
<zyga> ;-)
<Chipaca> well, it is slightly nasty, in that it uses reflect
<Chipaca> so the old way is probably faster and cleaner
<Chipaca> but ... convenience
<morphis> Son_Goku: did you try to enable test execution for snapd recently?
<Son_Goku> I don't know what to do for test execution
<zyga> Son_Goku: go test ./...
<zyga> (probably)
<Son_Goku> right now, I don't think it does anything for golang testing...
<morphis> ./run-checks would be nice
<zyga> wrapped with $distro.magic.incantation --mandatory-swtich=magic-value
<zyga> ^^ typo is part of the API
<zyga> :D
<Chipaca> zygaâ you forgot --moar-magic
<morphis> Son_Goku: enabling that for use right now
 * zyga fetches the coffee from downstairs :)
<Son_Goku> I did flip the check switch during 2.23.6 builds, but I didn't see anything happening...
<Son_Goku> so I just switched it back off
<morphis> ah
<morphis> I can look into that later today
<zyga> Son_Goku: the "more magic" position
<Son_Goku> haha
<mcphail> Does anyone have an example of a snapped Rails application?
<zyga> mcphail: I think we do but it's a biggie
<zyga> mcphail: forum.snapcraft.io runs as a snap
<zyga> mcphail: and that's a big discourse thing
<mcphail> zyga: cool. Is there a snapcarft.yaml I can look at?
<mcphail> (or snapcraft.yaml would be better!)
<zyga> I suspect so but the person snapping it is off this week, back next tue
<mcphail> zyga: ta. I'll poke again next week
<morphis> zyga: isn't the forum just a docker container?
<Chipaca> nope, snap
<Son_Goku> sadness and despair, according to niemeyer
<Son_Goku> :)
<ogra_> i think he was quite happy in the end
<Son_Goku> well, he was unhappy with the complexity of discourse setup
<ogra_> yeah
<Chipaca> but we also got services control back from that little experiment, so \o/
<Chipaca> :-)
<Son_Goku> haha
<ogra_> :D
<Son_Goku> that's always nice
<Chipaca> dogfooding ftw
<ogra_> woof
<morphis> Chipaca: nice
<Son_Goku> most of this is sadness and despair for me, for now
<Son_Goku> as all dogfooding just crushes my soul as I use Ubuntu-y things on my nice Fedora system :P
<ogra_> Chipaca, .... hmmm ... i wonder ...
<Chipaca> Son_Gokuâ eww
<ogra_> Chipaca, how about we'd hook all services inside the core snap on an Ubuntu Core install up to that interface
<Chipaca> Son_Gokuâ i feel your pain
<Son_Goku> Chipaca: things get... weird
<Chipaca> ogra_â you're preaching to the choir
<ogra_> snap stop core.timesyncd && snap install ntpd
<Son_Goku> and because some of the redirection stuff doesn't actually work, I get to see really strange stuff from time to time
<ogra_> ;)
<Chipaca> ogra_â i want the core snap to be fully described in the snap.yaml :-)
<Son_Goku> like random GUI application crashes when it launches
<morphis> zyga: do you introduced the check-syntax-c rules for snap-confine with 2.24?
<mcphail> Son_Goku: you get that on Ubuntu too ;)
<zyga> no, that was there for eons
<Son_Goku> and my resolution of my computer resetting when I launch a program that uses OpenGL
<morphis> zyga: hm, https://paste.ubuntu.com/24373248/
<Son_Goku> going from 1080p to 800x600 is unpleasant
<zyga> morphis: oh, interesting, maybe difference in indent?
<zyga> morphis: but that's fine
<morphis> zyga: either there is a difference in how intent works on suse in constrast to Ubuntu
<zyga> morphis: I plan to kill indent
<zyga> maybe today
<morphis> zyga: however, requires me to patch 2.24 now :_)
<ogra_> Son_Goku, where are all the bugs for that ? :)
<Son_Goku> ogra_: I'd love to file bugs, but I have this thing about not filing bugs when I don't have any idea what is happening :)
<Son_Goku> it's not useful or helpful, imo
<Chipaca> right, but
<ogra_> but then nobody else will know it happened to you when he looks for info if it happens to him
<Son_Goku> and in my experience, those kinds of bugs just get ignored anyway
<Chipaca> Son_Gokuâ is this really random? no STR?
<Son_Goku> the most repeatable case is in my VMware Fusion VMs
<Son_Goku> but it's really random on KVM VMs or on real systems
<Chipaca> rats
<Son_Goku> applications *do* reliably crash on Fedora GNOME though
<Chipaca> Son_Gokuâ and do you get to see the window before it crashes? or does it straight up never start?
<Son_Goku> never starts
<Son_Goku> it just dies
<Chipaca> Son_Gokuâ does the error message say something about permission denied, when it dies?
<Son_Goku> nope
<Chipaca> aw
<Son_Goku> if it did, I'd have something to file :D
<Chipaca> thought maybe it was merely a bad case of bug #1672819
<mup> Bug #1672819: exec'ing a setuid binary from a threaded program sometimes fails to setuid <amd64> <apport-bug> <kernel-key> <xenial> <linux (Ubuntu):Triaged> <linux (Ubuntu Xenial):In Progress by colin-king> <https://launchpad.net/bugs/1672819>
<Son_Goku> actually, it might be
<Chipaca> that's going to take a while to get better on fedora, i reckon, unless you pick up the patch when cking has it
<Son_Goku> Chipaca: I'll have to try to repro again
<Son_Goku> on a clean system
<Son_Goku> my current VMs are dirty, dirty beasts
<Chipaca> Son_Gokuâ even if you don't know what's going on, steps-to-reproduce are super useful
<Chipaca> Son_Gokuâ also, see if adding/removing virtual cpus changes whether things crash or not (per that bug)
<Son_Goku> I know for a fact that everyone with nvidia cards can't use snappy at all for graphical things
<Son_Goku> it straight up crashes
<Chipaca> that should not happen
<Chipaca> does zyga know?
<Chipaca> we've got work in there specifically for nvidia
<Son_Goku> I think zyga knows
<Son_Goku> well, if he didn't before, he does now
<zyga> so easy to learn here
<Son_Goku> but I think I mentioned it during the 2.23.6 testing
<zyga> nvidia support is not perfect, we need a different approach really
<Chipaca> zyga is supposed to be off today i think
<zyga> me?
<Chipaca> which is why i'm pretending he's not here
<zyga> really?
<zyga> actually
<Chipaca> zygaâ aren't you?
<zyga> my wife is out
<Chipaca> zygaâ isn't it jueves santo in spain?
<zyga> my kids are out
<Son_Goku> I thought that ws mvo?
<zyga> hmmmhmm
<zyga> and I'm here because work
<Chipaca> i thought spain did thu+fri, as opposed to other places doing thu+mon
<zyga> (my family has a fantastic hike to a castle on a hill next by)
<zyga> Chipaca: one thing I miss is people reminding me about holidays in spain
<Chipaca> zygaâ the one with the wineyards?
 * zyga checks wikipedia
<Son_Goku> wouldn't that be sergiusens, not zyga?
<Chipaca> wineyard?
<zyga> Chipaca: no, not that one
<ogra_> friday and monday should be off in spain
<Chipaca> vineyard!
<Chipaca> heh
<Son_Goku> oh, you're talking about Spanish vineyards
 * Chipaca 's bain is lossy
<Son_Goku> anyway, decathorpe privately mentioned to me that he can't run anything on his host system as he uses an nvidia card
<Son_Goku> all applications just crash
<ogra_> all
<Chipaca> sergiusens does not have vineyards close by
<ogra_> ?
<Son_Goku> ogra_: all GUI ones, anyway
<Son_Goku> CLI ones are fine
<zyga> https://www.google.es/maps/@42.051898,3.1313432,339m/data=!3m1!1e3!5m1!1e4?hl=pl
<zyga> here
<ogra_> well, i run gui apps just fine on my desktop that has an nvidia
<Chipaca> there are some two mountains chain to the west, which is about 200km as the crow flies (if you ignore it flying up and down again)
<Chipaca> but those are not too good :-)
<Son_Goku> ogra_: you also use Ubuntu, and not Fedora :)
<Son_Goku> currently, I think snappy requires custom implementations for nvidia handling for each distro
<ogra_> Son_Goku, right, but thats definitely something we need to fix urgently
<zyga> yes
<ogra_> and first of all we need a bug for itf from someone who has it happening ;)
<Son_Goku> I'm going to poke decathorpe to file a bug
<Son_Goku> he doesn't want to... saying it's an edge case
<Son_Goku> but it's not... :/
<pedronis> Chipaca: thx
<Son_Goku> also, Fedora's nvidia implementation is the first to use libglvnd natively
<Son_Goku> so I don't know how that affects what we do here in snapd and snap-confine
<ogra_> it needs to be supported
<zyga> well
<zyga> I know what to do
<zyga> it's just 1) hardware 2) coordination 3) time
<ogra_> well, 1) ... expense it ...
<ogra_> :)
<Son_Goku> ehh
<Son_Goku> this new Canonical may not want to accept it :/
<ogra_> if i need to enable a new board for Core i can expense it too ... cross-distro support is still equally important even in the new canonisl i think
<Chipaca> you can get an nvidia card for less than the price of an rpi3
<ogra_> right
<Chipaca> so i doubt it'll be a problem
<Son_Goku> ogra_: I hope so
<Son_Goku> I'm really worried about it
<ogra_> dont be
<zyga> Chipaca: interesting, today is a public holiday in almost all of Spain but not in Catalonia
<zyga> ogra_: once we start working on nvidia support I'll definitely buy and expense a card
<Son_Goku> wow, you got screwed :/
<ogra_> because catalonia isnt spain ;)
<Chipaca> zygaâ Catalunya lliure or something
<zyga> Chipaca: exactly ;)
<sergiusens> I am here today
<sergiusens> not a holiday
<zyga> it's interesting to observe how people react when my wife speaks catalan
<sergiusens> just Friday
<zyga> if she starts they are surprised and use catalan
<sergiusens> and yes, it is 7:20 AM and I've been up since 4AM
<ogra_> crazy
<Chipaca> sergiusensâ how's the kid?
<zyga> if they start and overhear us they use broken english or spanish
<Son_Goku> sergiusens: it's 6:20AM here and I've been up since 3:30AM
<sergiusens> Chipaca: read my toot? :-P
<Chipaca> on twitter? didn't see it
<zyga> but if she switches to catalan again (just to practice) they often ask "wow you speak catalan, how is that possible" :)
<sergiusens> my kid is sleeping, I am not anymore
<Chipaca> on mastodon i don't have you
<Chipaca> (mastodon calls them toots)
<zyga> Chipaca: ah, more mastodon?
<zyga> is there a snap for it
<zyga> last time I looked it was ugly to deploy
<Chipaca> zygaâ oooh
<mcphail> Ha! it was mastodon I was wanting to snappify (hence the question about Rails)
<sergiusens> Chipaca: @sergiusens@mastodon.cloud but I managed to get an account on @sergiusens@mastodon.social so I might be switching there soon
 * zyga doesn't get the new fashion
<Chipaca> sergiusensâ in mastodon, what's the difference between @sergiusens and @sergiusens@mastodon.social?
<Chipaca> and why can't you just move?
<Chipaca> anyway
<Chipaca> this is not helping me get work done
<sergiusens> Chipaca: different accounts
 * Chipaca cracks his whip at himself
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/3189 trivial
<mup> PR snapd#3189: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
 * zyga waits unil we get back to uucp for social news
<zyga> that will be something ;-)
<zyga> I'm ahead of the wave ;-)
<ogra_> well, uucp still exists
<ogra_> just use it ;)
<zyga> Thanks for the review Pharaoh_Atem :)
<sergiusens> apparently if you still have identica you could just get federated into mastodon
<zyga> ogra_: ha, but if just I use it, nobody will know
 * sergiusens goes back to ignoring irc
<zyga> Chipaca: and https://github.com/snapcore/snapd/pull/3188 (more important) while you're at it ;)
<mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
<Chipaca> uhh
<Chipaca> zygaâ there's a bug about us overriding TEMPDIR on classic
<Son_Goku> oh dear
<Son_Goku> please don't break me more :(
<zyga> Chipaca: it's not that, it's a ld.so thing
<zyga> Chipaca: we looked at it in the morning with mwhudson
<zyga> Chipaca: AT_SECURE == unset TMPDIR (but not TEMPDIR)
<Chipaca> Son_Gokuâ the bug is about us doing it when we shouldn't, not viceversa
<Chipaca> zygaâ so to get TMPDIR past snap-confine we'd need to sneak it in?
<Chipaca> heh
<zyga> Chipaca: hmm, is this still about TMPDIR?
<zyga> Chipaca: well
<zyga> Chipaca: look at this thread on the forum:
<zyga> https://github.com/snapcore/snapd/pull/3188
<mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
<zyga> https://forum.snapcraft.io/t/something-filters-out-tmpdir-even-for-classic-snaps/277/2
<zyga> (sorry, ^C sometimes fails)
<Chipaca> 'snap run' -> sets _TMPDIR from TMPDIR; snap-exec -> sets TMPDIR from _TMPDIR, or something like that
 * Chipaca reads
<zyga> Chipaca: yeah, I proposed something like that
<zyga> Chipaca: not sure if we should do it though, feels very very edge case
<zyga> it can be done for sure
<Chipaca> ah there we go
<Chipaca> we probably need to do that to make it work, probably for all other env vars that are cleared for AT_SECURE
<zyga> Chipaca: those are listed in...
<zyga> UNSECURE_ENVVARS in glibc tree
<zyga> http://paste.ubuntu.com/24373481/
<Chipaca> NIS_PATH
<Chipaca> hue hue hue
<zyga> yes, some arcane stuff in there
<Chipaca> ANYWAY!
<Chipaca> i've got code to code
<zyga> me too :)
<Chipaca> otherwise #3150 will never see the light of day
<mup> PR snapd#3027 closed: snap: run snap-confine from core if snap is also running from core <Created by mvo5> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/3027>
<mwhudson> Chipaca: you can just do the env resetting in snap-confine, i think
<mwhudson> although hm, maybe snap-exec would be easier, would be easier to re-use the same code that way i guess
<Chipaca> mwhudsonâ I'll let zyga have his fun with that
<mwhudson> heh heh
<zyga> mwhudson: note that we don't run snap-exec if we use `snap run --shell`
<zyga> so I think it has to be snap-confine + snap-run that play
<zyga> Chipaca: I'm going through PRs and I got to https://github.com/snapcore/snapd/pull/3150
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<zyga> Chipaca: is there any way to split this, can anything land before?
<Chipaca> zygaâ on the one hand, no
<zyga> (thanks for de-conflicting)
<Chipaca> zygaâ on the other hand, no
<Chipaca> :-D
<Chipaca> zygaâ that's what i'm working on right now
<zyga> fine :)
<zyga> hmm?
<zyga> so yes or no? :)
<zyga> if you want I will review it as-is
<Chipaca> zygaâ it can't be split. But it's not really that big?
<Chipaca> i mean, etelpmoc.sh is long, but narrow :-)
<zyga> Chipaca: like a good bridge should be :)
<Chipaca> mostly the silly 'case' thing
<Chipaca> the spread test that failed in travis passes when running spread locally. I've rebased to master and repushed, to see if it works in travis or not
<Chipaca> but it might be travis messing up the encoding somehow?
<mup> PR snapd#3105 closed: tests: download previous snapd package from published versions instead of specific PPA <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3105>
<Chipaca> dunno
<zyga> Chipaca: maybe some locale stuff is odd there
<zyga> btw we seem to run out of machines frequently now
<Chipaca> pr'aps
<zyga> Chipaca: ping me when you want me to review it
<Chipaca> zygaâ one thing that could be done to make this shorter is to take lib.exp0 and merge it with the other lib.exp0 and DRY it
<Chipaca> but not sure it's worth it
<zyga> nah, that's fine
<zyga> I was mostly scared about 58 files changed :)
<zyga> that's only fun to read when we change to GPL-4
<zyga> pedronis: can you have a 2nd look at https://github.com/snapcore/snapd/pull/3010/files
<mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <https://github.com/snapcore/snapd/pull/3010>
<Chipaca> zygaâ ah! 58 files is mostly test data
<Chipaca> test config? test ... stuff
<Chipaca> zygaâ for each completion test there's a .vars, a .sh and a .complete
<zyga> right, that's fine
<zyga> I'll review it when you ping me
<Chipaca> $ find tests/completion/ -type f \! -name \*~ | wc -l
<Chipaca> 44
<Chipaca> ^ i was curious :-)
<mup> PR snapd#3010 closed: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3010>
<mup> PR snapd#3016 closed: interfaces: add kubernetes-support interface and adjust related interfaces (LP: #1664638) <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3016>
<zyga> I could use a review for https://github.com/snapcore/snapd/pull/3149
<mup> PR snapd#3149: cmd: make locking around namespaces explicit <Created by zyga> <https://github.com/snapcore/snapd/pull/3149>
<zyga> we will then use it for fixing snap-confine and /snap sharing in containers
 * ogra_ hugs a bunch of people for https://github.com/snapcore/snapd/pull/3010
<mup> PR snapd#3010: snap: skip /dev/ram from auto-import assertions to make it less noisy <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3010>
<ogra_> that will quieten the image boots a lot
<zyga> ogra_: yes, totally
<zyga> tvoss, ogra_: just merged the rsa changes
<tvoss> zyga: great, thank you :)
<mup> PR snapd#3130 closed: overlord/devicestate: switch to ssh-keygen for device key generation <Created by vosst> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3130>
<zyga> Pharaoh_Atem, morphis: we need to depend on whatever provides ssh-keygen for snapd >= 2.25
<zyga> ditto fir suse
<morphis> zyga: I know :-)
<morphis> watching the forth and back on this discussion for some
<zyga> I'd like to land https://github.com/snapcore/snapd/pull/3138
<mup> PR snapd#3138: interfaces/mount: add Change.Perform <Created by zyga> <https://github.com/snapcore/snapd/pull/3138>
<morphis> zyga: looks like you need to dicuss that with jdstrand further
<zyga> morphis: I think this is a misunderstanding there but I will discuss
<zyga> jdstrand: if you are around :)
 * zyga is getting hungry, brb
<Son_Goku> zyga: easy enough to add for me "Requires: /usr/bin/ssh-keygen" :)
<NicolinoCuralli> hi guy : is it a awaited behavoiur the manual review for a snap with classic confinement?
<Chipaca> NicolinoCuralliâ say again please?
<zyga> Son_Goku: yes, that's pretty nice :-)
<zyga> NicolinoCuralli: yes
<zyga> NicolinoCuralli: all snaps that use classic confinement run ... unconfined, so we need to do the classic debian-like review of the software
<Chipaca> ah, zyga if you parsed that you're better at it than I am
<NicolinoCuralli> chipaca: i upload a snap with classic confinement on the pubblic store and  I hit a manual review ? is it ok?
<Chipaca> NicolinoCuralliâ yep! as zyga explained.
<ogra_> NicolinoCuralli, yes, that is expected ...
<zyga> NicolinoCuralli: I think the rules are that the snapcraft yaml is merged in the upstream repository
<ogra_> NicolinoCuralli, classic means "unsafe" so it needs review
<zyga> NicolinoCuralli: there's a reason to disable confined
<zyga> NicolinoCuralli: and the developers are recognized in the community
<zyga> NicolinoCuralli: I think that's the rough list but I could be wrong, it's a case-by-case review really
<NicolinoCuralli> ok: i need to understand about use of strict mode or classic mode then i need to test the same package in classic or strict confinement
<zyga> NicolinoCuralli: if you can do strict - go strict
<zyga> NicolinoCuralli: that's better in many ways
<icey> zyga: so I should get my PR accepted upstream before getting my classic snap accepted?
<zyga> NicolinoCuralli: and is compatible with more distribution
<zyga> icey: most likely yes
<zyga> icey: what is the software you're thinking about?
<icey> zyga: alacritty, a shell written in Rust with GPU acceleration
<NicolinoCuralli> how can i help us to make the review more fast for the my snap?
<zyga> *shell* ???
<zyga> as in /bin/sh
<zyga> with GPU accel?
<NicolinoCuralli> us -> you
<zyga> NicolinoCuralli: I don't know honestly, it's not a well exercised process
<icey> zyga: https://github.com/jwilm/alacritty
<zyga> NicolinoCuralli: maybe file a bug on the snapstore to track it?
<zyga> http://launchpad.net/snapstore
<zyga> aha
<zyga> interesting :)
<zyga> we use GPUs to make teletype emulators nicer
<Chipaca> NicolinoCuralliâ why do you need it to be classic?
<Chipaca> that's where the review starts :-)
<NicolinoCuralli> the snap must achieved in a more straight manner the network layer
 * zyga fails to parse that
<Chipaca> NicolinoCuralliâ to do what with it?
<Chipaca> NicolinoCuralliâ we have interfaces for most things you'd want to do with the network
<NicolinoCuralli> Chipaca: advanced network monitoring
<Chipaca> NicolinoCuralliâ so make it a strict snap, using the network-monitor interface
<Chipaca> was it network-monitor?
 * Chipaca looks
<ogra_> observe :)
<NicolinoCuralli> Chipaca; this a one of two project that i want to deploy with snap : https://www.indiegogo.com/projects/fingbox-network-security-wi-fi-troubleshooting#/
<Chipaca> network-observe perhaps
<Chipaca> NicolinoCuralliâ that does sound like something you should be able to do with the network-observe interaface
<Bizon> icey: are the current terminal emulators so slow we need a new one written with performance in mind?
<NicolinoCuralli> Chicapa : network-control ( it achieve the raw network interface ) , network-* interface, gpio
<icey> Bizon: that's not my question to answer :-P I'm just snapping something that somebody else made ;-)
<zyga> NicolinoCuralli: what does "achive the raw network interface" mean?
<NicolinoCuralli> Zyga: we use libpcap
<zyga> NicolinoCuralli: so a raw socket in promiscuous mode?
<Son_Goku> zyga, morphis: https://bugzilla.redhat.com/show_bug.cgi?id=1442051
<Chipaca> wait, gpio?
<NicolinoCuralli> zyga: for ethernet interface  and monitor mode for the wireless interface
<morphis> Son_Goku: yeah, nvidia is broken
<Chipaca> NicolinoCuralliâ is this a core system?
<zyga> Son_Goku: thanks, I'm replying in the bug
<NicolinoCuralli> Gpio for viualization of state od the network of the sysytem by leds
<zyga> ha, nice
<Chipaca> NicolinoCuralliâ I mean: is the device this is running on an all-snaps system? i.e. 'ubuntu core'?
<NicolinoCuralli> Chicapa: could you explain better your question?
 * zyga -> food (for real this time)
<ogra_> Chipaca, then classic wouldnt work at all
<Chipaca> NicolinoCuralliâ the snap you are writing, it's for running on a device?
<NicolinoCuralli> Chicapa: we want to use snap system for distribution of updates
<NicolinoCuralli> Chicapa: the snap is for running a dedicated hardware
<zyga> NicolinoCuralli: what Chipaca is asking about is what distribution is running on that device
<zyga> NicolinoCuralli: if it's say, debian or ubuntu + snapd + your snap
<zyga> NicolinoCuralli: then you can use classic confinement
<NicolinoCuralli> ubuntu 16.04 for classic confinement
<zyga> NicolinoCuralli: if it is the ubuntu-core distribution
<zyga> NicolinoCuralli: then you cannot use classic confinement at all
<NicolinoCuralli> zyga, Chiacapa: ubuntu-core for the strict confinement
<Chipaca> right
<Chipaca> so a classic snap is out of the picture
<Chipaca> NicolinoCuralliâ but, you should be fine using a strict snap with the appropriate interfaces
<Chipaca> NicolinoCuralliâ some of them don't auto-connect, but if it's dedicated hardware you can make them autoconnect from the gadget snap
<NicolinoCuralli> Classic snap is in the picture : i need to evaluate a feasibility for the classic mode on a standard ubuntu 16.04
<NicolinoCuralli> autoconnect from gadget don't work : i try it days ago and report on mailing the problem
<morphis> zyga: https://build.opensuse.org/request/show/487821
<Chipaca> NicolinoCuralliâ OK. That takes us back to the same question: why do you need classic? (it sounds like you don't)
<morphis> zyga: but please don't merge yet
<Chipaca> NicolinoCuralliâ what was the email subject?
<NicolinoCuralli> Chicapa: workaround for connect no autoconnect interfaces without login on system
<Chipaca> NicolinoCuralliâ ah!
<Chipaca> I don't know who *knows* this. zyga, or ogra_, either of you know how the autoconnect-from-gadget works?
<NicolinoCuralli> Chicapa: I think that some chance that a snap core update can broke some functionality  with my custom kernel the i want to try classic confinement
<ogra_> Chipaca, nope
<mup> PR snapcraft#1253 opened: Cross-compilation support for the Go plugin <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1253>
<ogra_> Chipaca, sounds more like a pedronis question ... i guess it happens during firstboot setup
<ogra_> (well, pedronis or mvo)
<Chipaca> pr'aps
<Chipaca> pedronisâ poke poke
<NicolinoCuralli> Chicapa: I think that some chance that a snap core update can broke some functionality  with my custom kernel then I want to try classic confinement
<pedronis> Chipaca: autoconnect from snap is something we haven't implemented yet
<pedronis> afaik
<Chipaca> pedronisâ oh drat
<pedronis> sorry, I mean from gadget
<Chipaca> yeah i read you
<NicolinoCuralli> Chicapa: my answer is clear for you? sorry for the bad english :D
<Chipaca> NicolinoCuralliâ so, we have some work to do to autoconnect from the gadget; it's not there yet
<Chipaca> NicolinoCuralliâ your answer is clear :-) your reasoning isn't :-/
<NicolinoCuralli> Chicapa: yes, i know this
<NicolinoCuralli> Chicapa: i try to explain better
<Chipaca> NicolinoCuralliâ I mean, if core breaks your kernel, it'll break whether classic or not
<NicolinoCuralli> Chicapa : this because ubuntu-core snap and core snap are the same things
<NicolinoCuralli> Chicapa : this because ubuntu-core snap and core snap are the same things?
<Chipaca> NicolinoCuralliâ yep
<Chipaca> (there is no ubuntu-core snap, now)
<NicolinoCuralli> what is the best practice for remain aligned with your work on core?
<Chipaca> I'm not the right person to answer that
<Chipaca> I'm too deep in the trenches
<Chipaca> even my two-levels-up view does not cover the whole thing
<Chipaca> NicolinoCuralliâ maybe JamieBennett
<NicolinoCuralli> Chicapa: i mean thins as monitoring the core code use on the edge channel or thing as it
 * JamieBennett reads the back scroll
<Chipaca> zyga, niemeyer, have you guys ever seen travis insert spurious \u0008's into tests?
<JamieBennett> NicolinoCuralli: can you summarise your question again?
<NicolinoCuralli> Hi Jamie: we want to try classic confinement on ubuntu 16.04 ( not ubuntu core ) for preserve us from possible problem from misalignement between kernel functionality ( apparmor etc ) and snapd
<NicolinoCuralli> but with Chicapa and Zyga answert i understood that it don't preseve us from a possibile problem of misaligment
<NicolinoCuralli> JamieBennet: is it correct?
<mup> PR snapd#3087 closed: overlord/snapstate: introduce tasks for aliases v2 semantics with temporary names for now (aliases v2) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/3087>
<JamieBennett> NicolinoCuralli: are you using a custom kernel on ubuntu classic?
<NicolinoCuralli> yes
<NicolinoCuralli> the board is custom
<JamieBennett> NicolinoCuralli: So your custom kernel will have to closely match anything we do with our kernel as we only guarantee our kernel/snapd combo for reference devices
<JamieBennett> You would have to look at our kernel development tree and keep up to date
<NicolinoCuralli> the same for uboot used and snapd?
<NicolinoCuralli> JamieBennet : the same for uboot used and snapd?
<JamieBennett> well, snapd would (zyga correct me if I am wrong) be refreshed as normal, just like if one of our kernels were used but if there is something missing from your kernel then potentially snapd would behave badly / not work
<JamieBennett> we don't tend to mess too much with uboot once it is working
<morphis> Son_Goku: looks like the vendorized build of snapd is broken on fedora with the name change of the upstream tarball
<morphis> Son_Goku: seeing: error: File /builddir/build/SOURCES/snapd-2.24.tar.gz: No such file or directory
<Son_Goku> yeah, I fixed it in my spec
<morphis> when building with $ rpmbuild --with vendorized -bs snapd.spec
<Son_Goku> http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/tree/snapd.spec#n49
<morphis> tought I've fetch your latest already
<morphis> Son_Goku: yeah I have that change
<NicolinoCuralli> JamieBennett: how can we integrate our board with yours for make it a reference device ?
<morphis> Son_Goku: with http://pkgs.fedoraproject.org/cgit/rpms/snapd.git/commit/?id=868fcee99a09259d0707fbc7544725a03204656f as latest change and not local changes I get that build error
<JamieBennett> NicolinoCuralli: for it to be a Canonical reference device it needs a kernel and gadget from Canonical, this means that we commit to ensuring it works throughout the dev cycle. It is heavily tested and if problems arise we fix them. For your board there isn't the same level of commitment as you are doing the work, not Canonical.
<JamieBennett> NicolinoCuralli: So it is down to you to ensure your image works, so tracking our kernels, applying any needed patches, and testing
<JamieBennett> NicolinoCuralli: If you wanted Canonical to do that work then we would need to have a conversation around that
<mup> PR snapcraft#1254 opened: ci: fix travis ordering for locales generation <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1254>
<Son_Goku> morphis:
<Son_Goku> [makerpm@yu-ohki SPECS]$ rpmbuild -bs --with vendorized snapd.spec
<Son_Goku> error: File /home/makerpm/rpmbuild-snp2/SOURCES/snapd_2.24.vendor.orig.tar.xz: No such file or directory
<Son_Goku> [makerpm@yu-ohki SPECS]$ rpmbuild --with vendorized -bs snapd.spec
<Son_Goku> error: File /home/makerpm/rpmbuild-snp2/SOURCES/snapd_2.24.vendor.orig.tar.xz: No such file or directory
<Son_Goku> works for me?
<Son_Goku> are you sure you're using your correct spec
<morphis> Son_Goku: the srpm build isn't what fails
<Son_Goku> oh, mock!
<morphis> https://paste.fedoraproject.org/paste/wb27V7lHa~SXRAObmJlgo15M1UNdIGYhyRLivL9gydE=
<Son_Goku> you need to pass --with vendorized to mock too
<morphis> Son_Goku: yes
<morphis> ah!
<morphis> Son_Goku: that works, thanks!
<NicolinoCuralli> JamieBennet: thanks for clarifications about the problem
<JamieBennett> NicolinoCuralli: np
<NicolinoCuralli> Thanks so much zyga and Chicapa
<Chipaca> are we doing the standup today?
<Chipaca> it's going to be sparse :-)
<pedronis> Chipaca: we are there
<ogra_> well, some of us are in there
<ogra_> but we could skip
<zyga> Chipaca: nope
<zyga> what is that character?
<morphis> zyga, Son_Goku: this is interesting: https://paste.fedoraproject.org/paste/gs6MGVrtlqxoaQIPFM5YOl5M1UNdIGYhyRLivL9gydE=
<Chipaca> zygaâ backspace
<morphis> I think the "missing function body" errors come from the build tag !gccgo in those .go files
<morphis> Son_Goku, zyga: wondering why the %gotest macro has -compiler gc hardcoded
<zyga> morphis: huh
<zyga> morphis: maybe go packaging magic and .[ch] files doesn't play ball?
<morphis> zyga: it's gccgo
<morphis> at least looks like that is the problem from a first quick look
<pstolowski> zyga, let me know if there is any low hanging fruit that you want landed.. would be good to clean the queue a bit
<zyga> pstolowski: I'm just checking
<zyga> https://github.com/snapcore/snapd/pull/3189
<mup> PR snapd#3189: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <https://github.com/snapcore/snapd/pull/3189>
<zyga> https://github.com/snapcore/snapd/pull/3188
<mup> PR snapd#3188: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <https://github.com/snapcore/snapd/pull/3188>
<zyga> those need to wait for tests
<zyga> same here https://github.com/snapcore/snapd/pull/3187
<mup> PR snapd#3187: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <https://github.com/snapcore/snapd/pull/3187>
<mup> PR snapd#2981 closed: tests: add kernel-module-control interface test <Created by fgimenez> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2981>
<morphis> zyga, Son_Goku: that is interesting, our vendor .tar.gz doesn't include salsa2020_amd64.s
<morphis> which salsa20_amd64.go refers to for the real implementation
<zyga> morphis: oh
<zyga> morphis: maybe the export code doesn't expect assembly?
<morphis> https://github.com/golang/crypto/tree/master/salsa20/salsa
<morphis> that is the thing I am not sure
<morphis> zyga: copying https://raw.githubusercontent.com/golang/crypto/master/salsa20/salsa/salsa2020_amd64.s manually in place works
<zyga> morphis: look at the vendor code
<zyga> morphis: govendor bug?
<morphis> maybe
<morphis> but wondering why the tests build and run with the same tarball on suse
<morphis> zyga: https://build.opensuse.org/build/home:mrmorph:branches:system:snappy/openSUSE_Leap_42.2/x86_64/snapd/_log shows it could compile those bits
<taaem> So I installed Ubuntu Core 16 on a Raspberry Pi but I noticed that there are only very minimal packages preinstalled, its missing for example lvm2 for lvm hard drives and since apt is not supported and snap doesn't find anything and afaiu it isn't supposed to find stuff like that. So now I have the problem that I can't use my old harddrives with Ubuntu Core because of this missing lvm2
<ogra_> taaem, well, ubuntu core forcuses on embedded ...
<ogra_> lvm is a rather rare use case
<ogra_> (which doesnt mean there wont be a lvm2 snap eventually for external disks or some such, but it is surely not a high prio)
<mup> PR snapcraft#1254 closed: ci: fix travis ordering for locales generation <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1254>
<taaem> ogra_: okay so I'll have to use another distro then but thanks
<ogra_> taaem, what do you try to do ?
<taaem> ogra_: I want to use Nextcloud on my rpi3 and I used rasbian and OpenSUSE before and they both failed on me so I thought I'd try Ubuntu Core
<ogra_> well, that works fine without lvm at least ...
<taaem> and the hdd was lvm from the begginning mostly so i could easily expand the space available without having to mess with nextcloud but only with the underlying fs
<ogra_> just with "snap install nextcloud" (and the rest ios done in your browser then)
<taaem> yeah but I have already 100GB of data on the lvm partition of my external hdd
<taaem> and I certainly don't want to migrate that
<ogra_> right, that might not be very pracical then
<ogra_> you could file a whishlist bug for getting an lvm snap though :)
<ogra_> https://bugs.launchpad.net/snappy/+filebug
<zyga> taaem: 100GB will copy in what? 5 minutes?
<ogra_> zyga, not on a USB disk i suspect
<ogra_> (given that it is attached to a pi i assume it is USB)
<taaem> a good ol' hdd
<taaem> attached over usb
<ogra_> yeah, that gets you 400MB/s max
<ogra_> err
<ogra_> 400Mbit/s
<zyga> ogra_: I just put a very old 160GB disk into a usb 3.0 case
<zyga> ogra_: copying at 80MB/s
<ogra_> 3.0
<ogra_> ...
<zyga> so?
<zyga> anyway moot point
<ogra_> the max for 2.0 is 24MB/s
<ogra_> that takes quite a while
<zyga> (not really true)
<zyga> anyway
<zyga> what's wrong with adt
<taaem> its usb 2
<zyga> tests are very sow today
<taaem> btw
<zyga> (usb 2.0 has different modes, some are much more efficient)
<ogra_> zyga, release day ?
<zyga> depends on usb/sata controller
<zyga> ogra_: do we rebuild the world on release day
<taaem> and I would need 100GB free on another disk to make that migration
<ogra_> zyga, plain USB 2.0 controllers cant shovel more than 24MB/s over the bus, no matter how well the scsi->USB part is
<ogra_> that only gets you fast  disk IO between the bus and the disk
<ogra_> zyga, no, but the main cvonnection to the datacenter gets hammered
<zyga> ogra_: https://en.wikipedia.org/wiki/USB_Attached_SCSI
<taaem> ogra_: https://bugs.launchpad.net/ubuntu/+bug/1682446
<mup> Bug #1682446: lvm is not available on Ubuntu Core <wishlist> <Snappy:New> <Ubuntu:New> <https://launchpad.net/bugs/1682446>
<mup> Bug #1682446 opened: lvm is not available on Ubuntu Core <wishlist> <Snappy:New> <Ubuntu:New> <https://launchpad.net/bugs/1682446>
<ogra_> The USB 2.0 specification was released in April 2000 and was ratified by the USB Implementers Forum (USB-IF) at the end of 2001. Hewlett-Packard, Intel, Lucent Technologies (now Alcatel-Lucent), NEC, and Philips jointly led the initiative to develop a higher data transfer rate, with the resulting specification achieving 480 Mbit/s, a 40-times increase over the original USB 1.1 specification.
<ogra_> zyga, ^^^
<ogra_> from https://en.wikipedia.org/wiki/USB
<ogra_> The USB 3.0 specification was published on 12 November 2008. Its main goals were to increase the data transfer rate (up to 5 Gbit/s)
<zyga> ogra_: not sure what your point is
<ogra_> in reality you only get 400Mbit/s on 2.0 ... thanks to protocol overhead ... so it ends at 20-24MB/s
<ogra_> and there is no way to get any faster rates over 2.0
<zyga> ogra_: there are different protocols
<ogra_> but there is a physical limit
<zyga> yes but 24MB is not that limit
<taaem> so anyway thanks for the help i'll probably install ubuntu mate and that has snap support anyway
<ogra_> (and on a sidenote, on the pi you have the NIC on the same USB bus, so the rate is also shared)
<zyga> taaem: good luck
<zyga> taaem: mate on pi probably uses different kernel
<zyga> taaem: and snaps probably won't work (last time I checked)
<Threygoo> When is snappy going to be the default package manager for Ubuntu?
<ogra_> i think flexiondotorg worksed on getting snap support going in u-mate in 17.04
<ogra_> *worked
<ogra_> Threygoo, it is already the default for Ubuntu Core
<taaem> zyga: oh so then i'll proably wait for that to drop
<ogra_> Threygoo, and it will unlikely replace dpkg on classic installations
<Threygoo> Dismay at having 2 different package managers depending on Ubuntu variant.
<Threygoo> (Desktop or Touch)
<zyga> Threygoo: snapd and apt are different tools
<zyga> Threygoo: there will always be a deb based version of ubuntu
<zyga> Threygoo: but they serve diffeent goals
<zyga> Threygoo: expect to see more software devlivered as snaps
<zyga> Threygoo: but expect that the system software will be still managed as debs, perhaps as a step on their way to the core snap
<zyga> Threygoo: debs and snaps are not aiming to solve the same problem
<mcphail> Threygoo: hopefully snaps will replace PPAs
<ogra_> yeah
<nacc> *some* PPAs :)
<nacc> application ones, to be clear :)
<ogra_> nacc, are there any others ?
<nacc> well, i use ppas for snapshot development of packages
<ogra_> like ... the snap edge channel you mean ? :)
<nacc> i'm not going to develop the php package in a snap
<nacc> as it's a part
<nacc> (in snap parlance)
<mup> PR snapd#3180 closed: many: fixes for `go vet` in go 1.7 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3180>
<Threygoo> Perhaps I had a misunderstanding after reading this. http://www.omgubuntu.co.uk/2017/01/ubuntu-phone-ota-15-ditched
<nacc> ogra_: but yeah, that's an option, i suppose -- maybe even with classic confinement, i could do that
<zyga> Chipaca: can you have a look at https://github.com/snapcore/snapd/pull/3185
<mup> PR snapd#3185: snap: added tasks subcommand <Created by stolowski> <https://github.com/snapcore/snapd/pull/3185>
<mup> PR snapd#3188 closed: cmd/snap-confine: set TMPDIR and TEMPDIR each time <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3188>
<mup> PR snapd#3189 closed: cmd/snap-confine: don't use plain "classic" term <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3189>
<mup> PR snapcraft#1255 opened: Update rust plugin to set RUSTFLAGS <Created by ChrisMacNaughton> <https://github.com/snapcore/snapcraft/pull/1255>
<pstolowski> Chipaca, thanks for catching .hidden thingy!
<Chipaca> pstolowskiâ :-)
<mup> PR snapd#3175 closed: daemon: do not set RemoveSnapPath flag when doing a try <Created by chipaca> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3175>
<mup> PR snapd#3181 closed: debian: add maintscript helper to remove usr.lib.snapd.snap-confine in snap-confine <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3181>
 * zyga goes through PRs and merging stuff that's ready
<zyga> https://github.com/snapcore/snapd/pull/3179 needs a 2nd review
<mup> PR snapd#3179: packaging: add `built-using` header for 16.04 packaging <Created by mvo5> <https://github.com/snapcore/snapd/pull/3179>
<Chipaca> zygaâ snapd#3150 is ready for review fwiw
<mup> PR snapd#3150: In-snap bash tab completion <Created by chipaca> <https://github.com/snapcore/snapd/pull/3150>
<Chipaca> anyway, time for a break
<mcphail> Nice!
<zyga> Chipaca: thanks! Ill have a look now
<zyga> Chipaca: question
<zyga> Chipaca: why not include the completer helper in /etc/bash_completion.d
<zyga> specifically asking about this part "Furthermore, at this stage to enable snap completions you need to source /usr/lib/snapd/complete.sh after sourcing /etc/bash_completion (or /usr/share/bash-completion/bash_completion). It adds a default completion handler that overrides and falls back to the usual one."
<zyga> Chipaca: added a comment
<zyga> Chipaca: it'd be amazing if you could try this on Fedora
<Chipaca> zygaâ can you explain what you mean with your comment?
<Chipaca> zygaâ snap-exec is always "inside", isn't it?
<zyga> Chipaca: curious, yes
<zyga> Chipaca: but what does snap-exec see
<zyga> today it would see /etc/os-release is fedora
<zyga> so it would set SnapMountDir to /var/lib/snapd/snap
<zyga> and I suspect this would no longer work
<zyga> because snap-confine mounts /var/lib/snapd/snap in /snap
<zyga> Chipaca: do you have a fedora machine around?
<Chipaca> zygaâ your other comment, on data/info, it's on a change that was then reverted in a later commit or something, right?
<zyga> Chipaca: this was just a comment, the modification is indeed reverted
<Chipaca> zygaâ I do not have a fedora machine around
<zyga> Chipaca: fancy getting one :-D
<Chipaca> I've done worse things for king and country
<ogra_> did it pay off ?
<Chipaca> zygaâ any pre-built minimal image i can use?
<Chipaca> ogra_â i changed country
<ogra_> lol
<zyga> Chipaca: the server image is nice
<zyga> Chipaca: but I recommend workstation
<zyga> Chipaca: it's really nice to see
<zyga> Chipaca: if you have a 2nd machine or 2GB of extra RAM you can just spin up a VM
<Chipaca> zygaâ testing this on ubuntu was a bit of a pain, i must say
<Chipaca> I was going for a VM, yes
<Chipaca> I mean, testing completion
<Chipaca> involved bind-mounting snap-exec
<zyga> Chipaca: you can install snapd from the repo
<zyga> Chipaca: and copy snap-exec and what else might be needed
<zyga> Chipaca: there are fewer patches needed now (AFAIR just two)
<zyga> anyway, just an idea, it's nice to try IMO
<zyga> Chipaca: if you choose to do it I can help you out with any fedora questions
<Chipaca> zygaâ the workstation live iso is downloading
<Chipaca> 1 minute left
<zyga> Chipaca: excellent, thank you!
<mcphail> Chipaca: does this work like modern bash-completion (where the completions are available as soon as the package is installed) or old bash-completion (where you have to restart the shell or source /etc/bashcompletion)?
<Chipaca> mcphailâ for now, if you have bash completion working, you need to also source one file from your .bashrc
<mcphail> Chipaca: ok. Thanks
<Chipaca> mcphailâ once this has been kicked about some more we'll probably work with bash-completion upstream to get it working directly
<Chipaca> i.e. your .bashrc currently has (say) â. /etc/bash_completionâ
<mcphail> yep...
<Chipaca> after that you'd have to add a line e.g. â. /usr/lib/snapd/complete.shâ
<Chipaca> mcphailâ (just to be clear, this isn't even on master yet, so it's at least a month away from being âliveâ)
<mcphail> Chipaca: no, that's OK. I've been wrangling with bash-completions for a couple of packages, one of which I've snapped. Just curious to how I'm going to implement this, as it is much needed
<Chipaca> also i'm meaning to write a blog post (and a bit of code) around this, because it enables testing bash completers, which is apparently unheard of
<Chipaca> mcphailâ what this branch does is add a "completer" entry to snap.yaml
<Chipaca> mcphailâ and that needs to point to a file you ship that's like the snippets you shipped in /usr/share/bash-completion/completers
<Chipaca> or was it /completions
<Chipaca> and then stuff should just work
<Chipaca> (modulo aliases)
<mcphail> yep - I let pkg-config work that out for me ;)
<Chipaca> with the completer itself running confined
<mcphail> Look forward to testing this when it reaches us
<Chipaca> i half expect it to fall over on its face at the lightest prodding
<Chipaca> but so far it's holding up
<Chipaca> (by "it" there I actually mean the whole of bash programmable completion)
<Chipaca> eep
<Chipaca> i get no cursor in the fedora live thing
<zyga> Chipaca: what are you using for virtualization?
<Chipaca> kvm
<Chipaca> trying -vga qxl now
<zyga> Chipaca: you may need some extra options,
<zyga> Chipaca: one sec
<zyga> Chipaca: it should do fine in kvm but you need to enable ..
<Chipaca> one thing i miss from telegram is being able to annoy people by playing random muppets gifs when they're being muppetish
<Chipaca> i'm sure that's part of the reason for the change back to irc :-p
<mup> PR snapd#3190 opened: Change default options for Arch Linux <Created by Aimilius> <https://github.com/snapcore/snapd/pull/3190>
<Chipaca> zygaâ -vga qxl got me a cursor
<zyga> Chipaca: try https://fedoraproject.org/wiki/Features/Spice
<Chipaca> i can now see what i'm pointing at
<zyga> Chipaca: this should be better (didn't try it)
<Chipaca> yeah, no thank you
<zyga>  qemu <disk-image> -usbdevice tablet -soundhw ac97 -vga qxl -spice port=5930,disable-ticketing -enable-kvm
<Chipaca> ewwww
<Chipaca> the progress bar is wrong on fedora
<Chipaca> eww
<Chipaca> ick
<Chipaca> and ew
<zyga> yes
<Chipaca> guess what i'll be working on soonish
<zyga> morphis knows :)
<zyga> I suspect outdated deps
<Chipaca> i've had a nicer progress bar in the works for ages, but never got around to polish it enough for release
<Chipaca> mostly because i'm not happy with the terminfo thing it uses
<Chipaca> so i shall fix terminfo over this weekend
<Chipaca> \o/
<zyga> Chipaca: any luck getting it to tab-complete?
<Chipaca> zygaâ it's working on core still? dunno
<Chipaca> it seems to think it's a tablet, also
<Chipaca> giant swipey things to unlock the screen
<Chipaca> hah!
<Chipaca> pedronisâ you'll love this one
<Chipaca> pedronisâ panic: cannot checkpoint even after 5m0s of retries every 3s: open /var/lib/snapd/state.json.weprkog: read-only file system
<zyga> Chipaca: wat?
<zyga> why
<Chipaca> zygaâ i'm guessing the live iso has a readonly /var or something
<zyga> oh
<zyga> you are in the iso
<zyga> install it already :)
<Chipaca> it should work from the iso :-)
<zyga> Chipaca: snapd doesn't work from our installers
<zyga> aufs and stuff
<zyga> (e.g. maas)
<zyga> you do really need to install it
<Chipaca> hmm
<Chipaca> zygaâ i mean
<Chipaca> dnf install snapd worked
<Chipaca> how is it now readonly?
<Chipaca> the state.json even has stuff in it
<zyga> Chipaca: mmmmm
<zyga> no idea then
<zyga> what is in /proc/self/mountinfo
<zyga> I'm curious myself
<zyga> but my fedora's are all installed
<Chipaca> oh, looks like the kernel remounted everything readonly
<zyga> io issues?
<zyga> remount=ro?
<Chipaca> looks like it
<zyga> curiou
<zyga> curious
<Chipaca> maybe 2G was not enough
<pedronis> Chipaca: love might not be the right word
<Chipaca> pedronisâ :-D
<zyga> Chipaca: 2GB of ram and no disk?
<zyga> pedronis: infatuation ;-)
<Chipaca> there is a sausage on my screen telling me to join the fedora project
<Chipaca> zygaâ i blame you
<zyga> Chipaca: it's fun :)
<zyga> Chipaca: btw, sausage?!?
<Chipaca> zygaâ in a bun. With a squirt of mustard.
<ogra_> is that their equivalent of clippy ?
<ogra_> the talking sausage ...
<zyga> Chipaca: did you install the german sausage spin? ;-)
<zyga> Chipaca: I honestly don't know what is the sausage thing you're talking about
<zyga> :D
<Chipaca> zygaâ it's cycled away, but if it comes back up i'll screenshot it
 * qengho worries about Chipaca.
<Chipaca> qenghoâ that makes two of us
<Chipaca> zygaâ http://imgur.com/egQDBx9
<ogra_> clippy in a sausage dress ! i knew it
<zyga> woah
<zyga> I didn't see that
<zyga> I remember the "beefy miracle" release (was it?)
<zyga> but ... no :D
<zyga> Pharaoh_Atem: ^^ WTF is the sausage about?
<ogra_> yeah, the one wheer jono showed up in a sausage dress at the canonical haloween party
<Pharaoh_Atem> ooh the Beefy Miracle
<Chipaca> maybe it's a portrait of jono!
<Chipaca> telling us to join fedora!
<Chipaca> that makes sense
<Pharaoh_Atem> it's a hot dog
<Chipaca> s/portrait/caricature/
<Chipaca> s/caricature/uncannily accurate depiction/
<ogra_> http://www.phoronix.net/image.php?id=0x2011&image=ubuntu_beefy_jono1_med
<Pharaoh_Atem> dafuq
<Pharaoh_Atem> wow
<Pharaoh_Atem> wut
<zyga> hehehe
<zyga> see
<zyga> maybe new fedora branding
<zyga> gone with the blue
<Pharaoh_Atem> why is Jono the Beefy Miracle
<zyga> add the ketchu-red
<zyga> ketchup-red
 * zyga shakes fist at BT keyboard
<ogra_> Pharaoh_Atem, to praise fedora during a ubuntu helloween party
 * Pharaoh_Atem blinks
<ogra_> you guys released a few days before or so ...
<Pharaoh_Atem> ah yes
<ogra_> or a few later ...
<Pharaoh_Atem> Fedora 17 was a Halloween release
<Chipaca> also because jono
<ogra_> yeah
<Chipaca> :-)
<Pharaoh_Atem> hmm no it wasn't
<Pharaoh_Atem> it was a summer release
<zyga> Chipaca: do you have that mountinfo
<Pharaoh_Atem> anyway
<Chipaca> zygaâ which mountinfo?
<Pharaoh_Atem> Beefy Miracle is amazing
<zyga> Chipaca: /proc/self/mountinfo when you got read-only file system
<Pharaoh_Atem> zyga: the Beefy Miracle comes from the days of Red Hat Linux
<Chipaca> Pharaoh_Atemâ to me, hot dog sausages do *not* go with âamazingâ :-)
<Pharaoh_Atem> back in the old Red Hat Linux edition of Anaconda, it would show an image of a hot dag and a cup of soda at a fridge
<Pharaoh_Atem> with the shadowman badge on the fridge door
<Pharaoh_Atem> it advised to go take a break while it installs, and said go get a snack or something :)
<Chipaca> hah
<Pharaoh_Atem> anyway, since then, it hid in the recesses of the Red Hat/Fedora lore, because it disappeared mostly when the RHEL/FC split occurred
<Pharaoh_Atem> it was revived I think some time around Fedora 16 or so
<Pharaoh_Atem> 15 or 16
<Pharaoh_Atem> anyway, it was revived during the effort to centralize Fedora's branding and provide generic templates
<Pharaoh_Atem> the creation of the fedora-release and centralized fedora-logos packages also needed debranded counterparts
<Pharaoh_Atem> so William Woods, who was on the Anaconda team at the time, brought it back and created a generic Plymouth theme for it
<Pharaoh_Atem> and Bill Nottingham created a generic-logos package along with generic-release
<Pharaoh_Atem> ah, the generic-logos stuff existed since Fedora 8, but anyway the hot dog was used for the generic branding
<Pharaoh_Atem> today, generic-logos is maintained by me, while generic-release is regenerated during each Fedora release development
<zyga> Pharaoh_Atem: interesting :)
<Chipaca> Pharaoh_Atemâ to me, not knowing anything about that, suddenly to have a sausage telling me to do stuff is somewhat surprising
<Chipaca> Â¯\_(ã)_/Â¯
<Pharaoh_Atem> he was immensely popular for a time
<Erix> does snap packages get updated with a sudo apt-get upgrade command?
<zyga> Chipaca: let me explain the ubuntu logo for you ...
<zyga> ;-)
<ogra_> Erix, they upgrade themselves
<Chipaca> zygaâ I was there for that one, see :-)
<Pharaoh_Atem> most well-known release name for Fedora is the Beefy Miracle
<Pharaoh_Atem> it even has its own social media :)
<Pharaoh_Atem> and website
<Pharaoh_Atem> https://twitter.com/beefymiracle
<Pharaoh_Atem> https://beefymiracle.org/
<ogra_> Erix, if you want to force an update you can always run "snap refresh" though
<zyga> Chipaca: as was I but the point is that it's equally non-obviou
<Erix> ogra_, thanks. to be clear; with apt command or bot needed
<Pharaoh_Atem> damn, I need to poke wwoods to fix the website
<Pharaoh_Atem> the pictures aren't working
<nacc> Erix: apt doesn't control snaps
<Chipaca> Pharaoh_Atemâ so does El Pollod MagnÃ­fico! https://twitter.com/accountpolld
<Erix> ok. thanks
<Erix> nacc
<ogra_> Erix, snap has a systemd timer that checks for updates and applies them automatically, so you dont need to do anything
<nacc> Erix: iirc, snaps automatically refresh periodically, and you can force an immediate with `snap refresh` -- with appropriate confinement and channels if needed
<Chipaca> naccâ yup :-)
<Erix> ogra_, nacc thanks
<nacc> Chipaca: thanks :)
<Erix> Snaps makes things so easy that I'm looking for a downside
<Erix> :)
<ogra_> if you find it, file a bug and we might fix it ;)
<Erix> couldn't find any yet
<nacc> heh
<zyga> ogra_, Erix: snapd also has an internal timer
<zyga> the systemd timer is used as a safety net
<zyga> in case we get something very very wrong
<zyga> AFAIR the timer is pretty infrequent now
<Chipaca> 4 times a day
<zyga> systemctl cat snapd.refresh.timer
<zyga> 4 times a day?
 * zyga reads what OnCalendar does
<zyga> aha
<zyga> I thought we made it less frequent (like 2 weeks)
<Chipaca> zygaâ systemctl list-timers snapd.refresh.timer
<zyga> nice
<zyga> I didn't know about this sub-command
<Erix> it looks 3 times a day
<Erix> passed 2h 27 min
<ogra_> iirc the long term plan is to have the server actually send push notifications to snapd
<Erix> left 5 h 26 min
<ogra_> if there are snap upgrades available
<Erix> every 8 hours
<Chipaca> ogra_â the push story is complicated
<ogra_> i didnt say it is easy ;)
<Chipaca> ok, this is ot from me for today
<mup> PR snapcraft#1256 opened: ant plugin: honour proxy configuration <Created by cjwatson> <https://github.com/snapcore/snapcraft/pull/1256>
<Guest5550> Hi guys I've installed some apps from snaps it's throwing me the following error :
<Guest5550> Comp failed:  "file:///snap/dekko/124/usr/bin/plugins/ui/MainUI.qml:3 plugin cannot be loaded for module \"Ubuntu.Components\": Cannot load library /snap/dekko/124/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/libUbuntuComponents.so: (libmirclient.so.9: cannot open shared object file: No such file or directory)\n"
<Guest5550> any idea what's the reason for this ?
<nacc> Guest5550: might be a bug in the snap?
<Guest5550> It's works fine about a month but now it's started to breaking
<Guest5550> If i installed any app using snap it's giving me the same error
<great_man> Hello
<great_man> I'm facing a issue on snap apps Cannot load library /snap/dekko/124/ubuntu-app-platform/usr/lib/x86_64-linux-gnu/qt5/qml/Ubuntu/Components/libUbuntuComponents.so: (libmirclient.so.9: cannot open shared object file: No such file or directory)\n"
<great_man> Any idea what's wrong here ?
<mup> Bug #1682550 opened: Snap & ubuntu app platform not working <Snappy:New> <https://launchpad.net/bugs/1682550>
<mup> PR snapd#3191 opened: many: implement snap alias <snap.app> <alias> <Created by pedronis> <https://github.com/snapcore/snapd/pull/3191>
<mup> PR snapd#3192 opened: many: implement snap unalias <alias-or-snap> (aliases v2) <Created by pedronis> <https://github.com/snapcore/snapd/pull/3192>
<pedronis> Chipaca: I now have a couple more aliases v2 PRs that can be reviewed, at least a first pass, they likely all need a look from Gustavo
<lazyPower> I seem to recall having seen a go plugin that gives the snap builder an option to choose the go version, is that the case or are we relying on scriptlets pending bug 161985 being resolved?
<mup> Bug #161985: support i18n plural forms <zope.i18n:Won't Fix> <Zope 3:Won't Fix> <https://launchpad.net/bugs/161985>
<lutostag> anybody else hitting, https://bugs.launchpad.net/snappy/+bug/1611078/comments/29 I am too, can't seem to get snaps working in my lxcs, even though they did before...
<mup> Bug #1611078: Support snaps inside of lxd containers <landscape> <lxd> <nova-lxd> <verification-failed-xenial> <Snappy:Fix Released by stgraber> <apparmor (Ubuntu):Fix Released by tyhicks> <linux (Ubuntu):Fix Released by jjohansen> <lxd (Ubuntu):Fix Released by stgraber> <apparmor (Ubuntu
<mup> Xenial):Fix Released by tyhicks> <linux (Ubuntu Xenial):Fix Released by jjohansen> <lxd (Ubuntu Xenial):Fix Committed> <apparmor (Ubuntu Yakkety):Fix Released
<mup> by tyhicks> <linux (Ubuntu Yakkety):Fix Released by jjohansen> <lxd (Ubuntu Yakkety):Fix Released by stgraber> <https://launchpad.net/bugs/1611078>
<lazyPower> whoops i mean  bug 1616985
<mup> Bug #1616985: the go plugin doesn't support go 1.7 <isv> <plugin> <Snapcraft:Confirmed for sergiusens> <https://launchpad.net/bugs/1616985>
<tyhicks> lutostag: are you hitting the issue in an unprivileged container or in a privileged container?
<tyhicks> snaps aren't currently supported inside of privileged containers
<lutostag> tyhicks: well that would be a good reason, wouldnt it... ;) I'll retry
<tyhicks> lutostag: the good news is that it'll likely be supported soon thanks to https://github.com/lxc/lxd/pull/3155
<mup> PR lxc/lxd#3155: Enable stacking for privileged containers <Created by stgraber> <Merged by brauner> <https://github.com/lxc/lxd/pull/3155>
<lutostag> tyhicks: nope, doesnt work with a priviledged container...
<tyhicks> lutostag: that's expected
<lutostag> tyhicks: might it also be that I'm using snapped lxd rather than an apt install?
<tyhicks> lutostag: it will only work in an unprivileged container today
<lutostag> oh, I just did unpriviledged before that too
<lutostag> still did not work
<stgraber> lutostag: what kernel are you running exactly?
<lutostag> I'm on zesty too, which may be the thing
<lutostag> Linux doe 4.10.0-19-generic #21-Ubuntu SMP Thu Apr 6 17:04:57 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<stgraber> lutostag: what version of Ubuntu are you using for the container?
<lutostag> (and yes I installed squashfuse of course...)
<lutostag> I tried both xenial and zesty
<lutostag> I'll spin up a yakkety for good measure to
<stgraber> lutostag: zesty with a 4.10.0-19-generic kernel and a xenial container works fine here
<stgraber> lutostag: does /sys/module/fuse exist on your system?
<lutostag> stgraber: host or container?
<stgraber> same thing for that particular path
<lutostag> stgraber: it does
<lutostag> wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1577.snap (but that would be the somewhat-not-informative line from systemctl status snap-core-1577.mount)
<stgraber> lutostag: what do you get if you manually run: /bin/mount /var/lib/snapd/snaps/core_1577.snap /snap/core/1577 -t fuse.squashfuse -o ro,allow_other
<lutostag> stgraber: mount: wrong fs type, bad option, bad superblock on /var/lib/snapd/snaps/core_1577.snap
<lutostag> which seems like squashfuse isnt installed in the container, but dpkg -l says it is
<lutostag> (and reran for good measure)
<stgraber> lutostag: hmm, what container image did you use exactly?
<lutostag> lxc launch images:ubuntu/yakkety
<lutostag> and xenial and zesty
<stgraber> ok, then that's the problem
<stgraber> looks like squashfuse is missing a dependency on "fuse"
<stgraber> which is part of the official Ubuntu images but not in the community images
<stgraber> so if you use "lxc launch ubuntu:16.04" it'll work (after you install squashfuse)
<stgraber> but if you use "images:ubuntu/xenial" you'll need to install "fuse" and "squashfuse"
<lutostag> stgraber: yep, thats it indeed
<lutostag> apt install fuse worked like a charm
<lutostag> stgraber: sorry for the rigamarole, thanks ;)
<stgraber> I'll fix the squashfuse packaging whenever the next Ubuntu release is open for development
<lutostag> stgraber: appreciated... and if you're in for another separate riddle...
<lutostag> which I think falls more on the snap side than lxd...
<lutostag> on ubuntu core 16, if I run the default lxd daemon snap via /bin/snap run lxd falls over in certain situations, and I need to run it as root rather than via the included service file... https://gist.github.com/lutostag/a997f9189c1ae299a313853ecf4b14a7#file-rpi-setup-sh-L86 is what I cobbled together to prevent lxd daemon from spinning up and dieing repeatedly
<lutostag> only happens after giving it a /dev/net/tun forwarded to the container
<lutostag> anywho I'll have to file a full bug with a smaller repro for reals
<lutostag> thanks again
<mup> PR snapcraft#1230 closed: lxd: refactor Cleanbuilder into Containerbuild and add Project <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1230>
<mup> PR snapd#3187 closed: interfaces/mount: improve go identifier names of mountinfo, parse optional fields <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3187>
<mup> PR snapd#3193 opened: interfaces/mount: parse mount options to map[string]string <Created by zyga> <https://github.com/snapcore/snapd/pull/3193>
<mup> PR snapcraft#1257 opened: core: support running from other operating systems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1257>
<Croepha> just curious, but when would we be likely to see patches that are going into the ubuntu proper kernel, (Specifically the Intel HDMI auto patches that are in the 4.11 testing kernel) into the ubuntu core pc-linux kernel?
<Croepha> intel HDMI audio
<mup> PR snapd#3194 opened: tests: copy snap-confine apparmor profile into testbed <Created by zyga> <https://github.com/snapcore/snapd/pull/3194>
 * zyga wonders if anyone from the core team is around
<zyga> if so, please review the ^^ one liner
<zyga> jdstrand: thanks :)
<jdstrand> np
<zyga> jdstrand: btw, did you see http://klee.github.io/
<jdstrand> no, that's cool
<zyga> jdstrand: http://www.doc.ic.ac.uk/~cristic/papers/klee-osdi-08.pdf
<zyga> this is why I think this is interesting
<jdstrand> yeah, I skimmed it. it does seem interesting
<ogra_> zyga, approved
<zyga> ogra_: thanks
<zyga> I'm fixing 14.04 case
<zyga> where we dind't rename the aa profile to .real
<zyga> eh :)
<zyga> life
<mup> PR snapd#3194 closed: tests: copy snap-confine apparmor profile into testbed <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/3194>
#snappy 2017-04-14
<lutostag> I can't seem to see any sinks/sources besides dummy after I $ snap install pulseaudio # on the rpi3 according to https://developer.ubuntu.com/core/get-started/developer-setup#pulseaudio
<zyga> jdstrand: FYI, now that snap-confine can run from core we need to re-introduce all the extra security fixes and features we had ready
<AdamH> Hello, trying to teach myself to Qt, mir-kiosk running on Ubuntu Core. I have a basic hello world app using the mir-kiosk-apps as an example. But snapcraft fails unless I manually copy the executable from qt into the stage directory, which then allows the package to be created but when I install the snap I get the error message "cannot execute binary file: Exec format error" I get the feeling I am missing something basic. Any pointers ap
<AdamH> preciated as I have spend days trying to get this to work without success
<AdamH> https://github.com/AdamHeavens/falconhelloworld/
<qengho> AdamH: When you "install" the app, you get that error message?
<AdamH> qengho: No there are no errors I just see the error "/snap/falconhelloworld/x1/bin/falconhelloworld: cannot execute binary file: Exec format error" in syslog
<qengho> That's when you run it, or when systemd runs it on your behalf, then.
<qengho> ...a service/daemon.
<AdamH> Yes
<qengho> "file /snap/falconhelloworld/x1/bin/falconhelloworld"
<AdamH> I think I need to get the snapcraft process to build the app and place in /bin but not sure whats wrong with my yaml
<qengho> Run that. Tell me what it says.
<AdamH> I just get -bash: file: command not found
<qengho> Ugh. "ls -ld /snap/falconhelloworld/x1/bin/falconhelloworld"
<AdamH> -rwxr-xr-x 1 root root 14584 Apr 14 09:49 /snap/falconhelloworld/x1/bin/falconhelloworld
<qengho> AdamH: And where you create that snap, I want to know "file prime/bin/falconhelloworld"
<AdamH> I am creating the snap on an armhf lxc container, you want the results of the same command on prime/bin...
<qengho> AdamH: I want it on some rich system that has the "file" program. I don't have opinions about where you do that.
<mikeb_> Hi.  Can someone help me with a snapcraft cmake plugin problem?  In my cmake, I have 'find_package(libsystemd-dev REQUIRED)'. In my part, I have 'build-packages: [ libsystemd-dev]'.  When I try to build, CMake complains that it can't find the package.  What am I missing?
<AdamH> qengho: root@arm1:~/falconhelloworld/prime/bin# ls -ld falconhelloworld-rwxr-xr-x 2 root root 14584 Apr 14 09:49 falconhelloworld
<qengho> "file prime/bin/falconhelloworld"
<qengho> AdamH: is it a secret?
<AdamH> -rwxr-xr-x 2 root root 14584 Apr 14 09:49 falconhelloworld
<AdamH> root@arm1:~/falconhelloworld/prime/bin# file falconhelloworld
<AdamH> falconhelloworld: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.6.32, BuildID[sha1]=24061357469c24dda38ff15bc2b1af69a9ba470c, not stripped
<qengho> AdamH: Right, it looks to me like youre building a program for amd64 and trying to run it on armhf.
<AdamH> qengho: Yes useful command to know, thanks I will look at Qt settings, although I am copying this in manually as snapcraft will not build it dynamically. Thanks for your time
<qengho> AdamH: The first problem is the one to fix. "snapcraft fails".
<qengho> AdamH: Use "--debug" on snapcraft. Fix that problem first.
<AdamH> ok thanks
<jdstrand> zyga: oh! that's all landed?
<jdstrand> (snap-confine)
<jdstrand> zyga: and hi! :)
<wahbwahb1> Hi! I'm trying to build emacs using snapcraft and I'm running into this issue: https://bugs.launchpad.net/ubuntu/+source/snapcraft/+bug/1611505 - where 'loaders.cache' doesn't get copied into the snapcraft container. I was wondering if anyone can help. Here's my snapcraft.yaml: https://gist.github.com/benwah/7f027dbb50ec2279ba3d603145040546
<mup> Bug #1611505: gdk-pixbuf cache is missing from snap <bot-comment> <snap-desktop-issue> <snapcraft (Ubuntu):Confirmed> <https://launchpad.net/bugs/1611505>
<wahbwahb1> After I build the snap, I seem to find this `loaders.cache` file in the expected location, under ./prime ./stage ./parts/emacs/install
<stokachu> still hitting that 502 proxy error trying to upload my snap
<stokachu> basically takes 3 times before it accepts it
<kyrofa> jdstrand, got a minute to hop into rocket?
<jdstrand> kyrofa: yeah :)
<kyrofa> Thanks jdstrand. I pushed it as far as I could :P
<jdstrand> kyrofa: thanks for that and np
<kyrofa> pedronis, are you around?
#snappy 2017-04-15
<zyga> jdstrand: I we now do run snap-confine from core
<zyga> jdstrand: today is not the best moment (middle of the night, holidays) but I'll make sure to go through all the old PRs that got stuck
<zyga> jdstrand: and to see what we reverted
<zyga> jdstrand: and merge all those goodies for 2.25
<Pharaoh_Atem> wait, wut
<Pharaoh_Atem> snap-confine runs from the core snap now?!
<Pharaoh_Atem> that's only on Ubuntu, right?
<jrwren> does that mean better compatibility between trusty & xenial?
<Pharaoh_Atem> :(
<mup> Bug #1683061 opened: Support wayland <Snappy:New> <https://launchpad.net/bugs/1683061>
#snappy 2017-04-16
<nyceane> hey guys
<nyceane> https://developer.ubuntu.com/core/get-started/intel-joule
<nyceane> anybody here?
<nyceane> :(
<immu> hi anyone here
<immu> why do i need to sign into Ubuntu one to install a snap????
<immu> isnt Ubuntu one sign-in dead
<cjwatson> immu: login.ubuntu.com / SSO is the major part of what was Ubuntu One that survives, and it's the identity provider for most things that Canonical does
<cjwatson> (as well as some non-Canonical but Ubuntu-related things)
<immu> why i need to sign in to install snap apps
<cjwatson> I don't believe you do if you use sudo
<cjwatson> sudo snap install whatever
<immu> Ubuntu software is the app i use to install snap apps
<immu> for ex i insalled Hexchat IRC, the app isn't even listed as a snap packaged app?
<immu> why?
<cjwatson> Perhaps because it exists as both deb and snap
<cjwatson> I don't really know though, sorry
<immu> cjwatson, its ok
<immu> niemeyer, so no one here for snappy?
<immu> whos the boss?
<cjwatson> You won't find many people around at the weekend
<cjwatson> Especially not a holiday weekend in many parts of the world
<immu> cjwatson, ok
<ogra_> immu, Bug #1581713  and bug 1604016 might be interesting ...
<mup> Bug #1581713: Ubuntu Software always asks for an Ubuntu Single Sign-On account when installing or removing a snap package <xenial> <Ubuntu GNOME:Triaged> <gnome-software (Ubuntu):Confirmed> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1581713>
<mup> Bug #1604016: Snap requires sudo if not logged in <Snappy:Fix Released> <https://launchpad.net/bugs/1604016>
<immu> ogra_, mup thank will tag my self also.
#snappy 2018-04-09
<mup> PR snapd#5011 opened: data/selinux: Recognize more aspects that snapd needs access <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/5011>
<Son_Goku> zyga, ^
<eraserpencil> Hey guys, Im trying to build my own snap for a custom Arm kernel of Ubuntu. It's build well, but i cant install it. I have a "mount snap core" error
<eraserpencil> The hardware is a Jetson TX2, the kernel is Linux4Tegra 28.2
<eraserpencil> am i getting this "mount snap core" error because of my kernel? or because I did smtg wrong
<eraserpencil> it's running ubuntu
<mborzecki> morning
<zyga> good morning
<zyga> Pharaoh_Atem: ack, thank you
<zyga> Caelum: ack, trying
<zyga> eraserpencil: perhaps missing squashfs support in the boot loader or the kernel, not sure thoguh
<zyga> Caelum: ah, we need to adjust badness thing
<zyga> Caelum: we should submit our policykit files somewhere to SUSE central packages to get rid of the problem
<mborzecki> zyga: hey, morning
<zyga> hey
<eraserpencil> zyga: how is it that it can compress into squashfs it it didnt have squashfs
<zyga> eraserpencil: compress? the kernel never works on the compression side
<zyga> eraserpencil: also the boot loader and kernel have separate implementations
<zyga> eraserpencil: so perhaps it was the boot loader that got through the kernel but the kernel could not mount the root filesystem (squashfs) because it was not enabled in your kernel
<zyga> eraserpencil: I'm just saying it's possible, check your kernel configuration
<eraserpencil> how?
<eraserpencil> ahh custom kernel, ok nvm
<zyga> eraserpencil: you are using your own kernel, right?
<zyga> Caelum: fixed locally, will push when the package builds
<eraserpencil> it's LInux4Tegra by Nvidia
<eraserpencil> Asking the forum there now
<zyga> eraserpencil: you may want to look at forum.snapcraft.io too
<zyga> perhaps there's already a working kernel with snap support there
<eraserpencil> kk
<eraserpencil> thanks
<mvo> mborzecki: hey, good morning. have you seen the feedback in 4942?
<mborzecki> mvo: hey, yes, i'll be updating this shortly, got dug up in some rpm stuff
<zyga> Hey mvo, welcome back
<mvo> mborzecki: cool, thank you
<mvo> zyga: hey, thank you! nice to be back :) how are you (and the rest of the gang)? any fires ?
<zyga> I think we are good but we need 2.32.3 in stable  ASAP
<zyga> And we need .4
<mvo> zyga: sounds good
<zyga> .4 must bring hook fixes and the new store api
<mvo> zyga: we need .4 for the new api? or for moe?
<mvo> zyga: have the hook fixes landed in 2.32 already?
<zyga> Nope
<zyga> But there is an initial or
<zyga> PR
<mvo> zyga: cool, I have a look now
<mvo> zyga: do you think we should cherry-pick 5011?
<mup> PR snapd#5011 closed: data/selinux: Give snapd access to more aspects of the system  <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5011>
<hamo> mvo: hi mvo, we want to enable one custom board with ubuntu core, I followed the guide on the website
<hamo> mvo: but when I want to upload the kernel snap, it was rejected since kernel type is not allowed..
<hamo> mvo: so what should we do now to enable our device?
<mvo> hamo: custom enablement is probably good to discuss with e.g. ogra_ (he will be around in ~2h or so usually). you can sideload the kernel via ubuntu-image. you can also request a manual review for a rejected snap. kernels are not auto-accepted into the store because of all the security implications that this has
<mvo> hamo: and good morning :)
<mvo> zyga: 5006 looks like an easy win :)
<zyga> yeah, I'll do Jamie's interface PRs now
<hamo> mvo: haha.. It's afternoon here, good afternoon
<zyga> mvo: oh, about ubuntu-image, there's a broken snap that should probably be disabled now
<hamo> mvo: another question, I see I can directly upload to edge channel, but when I want to upload this kernel to edge channel, it failed as "A file with this exact same content has already been uploaded"
<hamo> mvo: how could I delete the bad one and re-upload it?
<zyga> hamo: exact same content?
<zyga> it's already there
<zyga> upload a different one
<hamo> zyga: yep, the same snap to another channel
<zyga> hamo: you don't need to upload it
<zyga> hamo: just publish it
<zyga> you can publish a revision into a channel
<mvo> hamo: yeah, it means the snap is already in the store, you can simply use "snapcraft release $your-snap $your-rev edge" (for example)
<hamo> zyga: mvo Good... let me try it
<mup> PR snapd#5006 closed: interfaces: misc updates for default, firewall-control, fuse-support and process-control <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5006>
<zyga> mvo: I asked jdstrand about back ports of the interface PRs
<zyga> ohhh
<zyga> I'm blind :)
<mup> PR snapd#5008 closed: interfaces: misc updates for default, firewall-control, fuse-support and process-control - 2.32 <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5008>
<mvo> zyga: thank you!
<mvo> zyga: what broken snap is there? a broken ubuntu-image snap?
<mvo> zyga: if so, anything we need to do about it?
<zyga> mvo: ubuntu-image is broken
<zyga> I think someone from foundations should take action
<hamo> zyga: mvo could I do release if the target package is in pending-review status?
<zyga> hamo: I don't know
<mvo> zyga: can you join #ubuntu-devel please ? not sure that sil2100 is aware of the issue
<mvo> hamo: I think you need to wait until this is reviewed, but please try I'm not 100% certain myself
<kalikiana> good morning
<mvo> kalikiana: good morning
<mvo> pedronis: \o/ for 5004 - you rock!
<pstolowski> morning
<zyga> hey kalikiana, pstolowski :)
<mup> PR snapd#4992 closed: tests/main/interfaces-opengl-nvidia: verify access to 32bit libraries <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4992>
<mvo> mborzecki: woah, 4989 (arch) succeeded on arch?!?
<mborzecki> mvo: yes :)
<mborzecki> mvo: even not that many tests had to be disabled :P
<mvo> mborzecki: nice job!
<mborzecki> mvo: even better, with all the gce support niemeyer it should have no impact on how long the tests take to run :P
<mvo> mborzecki: I really like this aspect of the PR :)
<mup> PR snapd#5005 closed: interfaces/hostname-control: allow setting the hostname via syscall and systemd <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5005>
<hamo> mvo: zyga another question, does snap/ubuntu core support boot from nand flash?
<iMadper> hamo: Yoooooooooo
<zyga> hamo: yes, it's just something that has to be handled by the gadget
<zyga> hamo: to be precise, snapd doesn't care where it's booted from
<hamo> zyga: really grea.....t,  any example of nand gadget?
<zyga> nope
<zyga> I only work on reference devices
<zyga> my point is that snapd doesn't constrain that
<zyga> if you can boot from NAND on your board that's fine
<zyga> mvo: about https://github.com/snapcore/snapd/pull/4987 -- I merged and then reverted your PR
<mup> PR #4987:  tests: add test to ensure `snap refresh --amend` works with different channels <Created by mvo5> <https://github.com/snapcore/snapd/pull/4987>
<zyga> as AFAIK it was conflicting with pedronis' big activity PR and it was contained therein
<iMadper> currently ubuntu core try to extend / modify the partition layout at the first boot. Which doesn't work for NAND... Hi, ondra, Have you tried it on Nand device?
<mup> PR snapd#4999 closed: advisor: use json for package database <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4999>
<mborzecki> do we have anything to manipulate/open file descriptors to journald?
<Chipaca> mborzecki: via journalctl, in systemd (search for jctl)
<Chipaca> mborzecki: all it does is use osutil.StreamCommand though
<Chipaca> not sure that's what you mean
<Chipaca> mborzecki: why?
<doko> mvo, zyga: any idea about the snapd autopkg test failure on i386? the history doesn't look well in any case
<zyga> hmm, no, could you please pass the link to the error?
<mborzecki> Chipaca: something bothering me about app autostart, so gnome-session does `sd_journal_stream_fd("foo.desktop",..)` and uses that fd as stdout/stderr
<mborzecki> Chipaca: in case of our autostart via `snap userd --autostart`, we end up with say `snap-userd-autostart.desktop: ...<logs from started app, eg. discord>` in the users journal, because the fd was open for snap-userd-autostart.desktop
<mborzecki> Chipaca: a way to fix it would be to open another set of fds just for the app and tag them
 * Chipaca reads sd_journal_stream_fd(3)
<mborzecki> mvo: ^^ intersting in the context of app autostart
<mvo> doko: last I looked at it we got random <kill-timeout reached> reached during the tests. for some reason it looks like the autopkgtest VMs are slow(er) than the other machines? maybe overcommited more?
<mvo> mborzecki: hm, interessting
<Chipaca> mborzecki: is userd still short-lived?
<mborzecki> Chipaca: yes, it just starts the apps and goes away
<Chipaca> 'cause if it is, i'd say just build against libsystemd
<Chipaca> and do the actual sd_journal_stream_fd call
<mborzecki> Chipaca: that would drag in cgo
<Chipaca> mborzecki: yes
<Chipaca> mborzecki: our reticence to use cgo is mostly around memory leaks, and applies to long-lived processes
<Chipaca> mborzecki: (that is outside of specific omg-needs-to-be-static cases =) )
<doko> mvo: the queue is empty now, so I wouldn't expect that. but please could you address this with Laney and/or make the tests more conservative then? or is this a real issue with git?
<Chipaca> mborzecki: OTOH it's quite likely the sd_journal_stream_fd call is really just calling dbus, so you could do it that way
 * Chipaca doesn't know though
<mborzecki> Chipaca: hm that might be a bit controversial, i'd rather land the PR as it is now and do a smaller iteration to address this incovenience
<Chipaca> mborzecki: or
<mvo> doko: I doubt its a real issue, this works fine in our GCE environment, we see close to 100% success there (sometimes network related failures). I will check with Laney.
<Chipaca> mborzecki: you could exec the command piped to systemd-cat
<mvo> doko, Laney an interessting observation is that they all (the recent ones) die in "+ journalctl --sync\n\n<kill-timeout reached>". makes me wonder if something is wrong with the systemd setup on these instance
<mborzecki> Chipaca: hm i could just reimplement this in Go: https://github.com/systemd/systemd/blob/97a33b126c845327a3a19d6e66f05684823868fb/src/journal/journal-send.c#L395 ;)
<pedronis> mvo: zyga:  hi,  do we support hooks and applications in bases?   IÂ don't think we prohibit them?  do we use themselves as the root filesystem or core if we run them?Â we should probably use themselves IÂ suppose, execpt to get snapctl etc
<zyga> we use themselves I believe but we hardly ever try
<zyga> core is almost like a base snap (almost) so we don't exercise that code
<pedronis> I'm not sure reading snap-confine code
<mborzecki> alloca(l + 1 + 1 + 2 + 2 + 2 + 2 + 2)
<mvo> pedronis: we do not prohibit them, but unless we have a use-case, maybe we should?
<zyga> pedronis: note that base is conveyed from snap run
<Chipaca> mborzecki: totally sane
<mborzecki> Chipaca: this one is intersting too:  header[l++] = '0' + !!level_prefix;
<mborzecki> Chipaca: int level_prefix
<Chipaca> mborzecki: I think rewriting that specific function in Go seems sane
<Chipaca> mborzecki: but, maybe do it in a separate PR
<mborzecki> Chipaca: agreed
<zyga> mborzecki: are you reading kernel sources?
<pedronis> mvo: zyga: we don't pass itself from snap run if the snap is a base, so IÂ suppose we use core as the filesystem which is not correct
<zyga> ah, systemd
<mborzecki> zyga: systemd, gnome-session and glib :P
<zyga> pedronis: that feels like a bug then
<mborzecki> because taking foo.desktop and starting an app cannot be trivial :)
<pedronis> mvo: yea, I think either we should prohibit them, or bases should not have a base (IÂ think that we might check already) and should be their own base
<mvo> pedronis: yeah, I think we do not allow a base to have a base but worth double checking, I make a note to look at this
<pedronis> mvo: for context  I was looking at this because of the question of what waits to setup in  UpdateMany
<pedronis> mvo: snaps should wait for their base,  and everything  should wait for core (in theory, and in the future the snapd snap) as the source of snapctl, snap-exec etc
<mvo> pedronis: I think that this setup makes sense
<Chipaca> snaps should wait for the things their default providers too
<Chipaca> no?
<pedronis> Chipaca: that's already done a bit differently
<pedronis> Chipaca: here is the question of things  for which snap-confine is unhappy if there's no current symlink
<Chipaca> mborzecki: OTOH systemd-cat is literally prepending "systemd-cat" to the exec line
<Chipaca> pedronis: ah
<pedronis> Chipaca: basically snap-confine reads the current of core and base,  and  if the inactive we cannot really do things with services or hooks of a snap
<Chipaca> yep yep
<pedronis> mvo: btw IÂ prepared the backport of new api for 2.32,  should wait until we are confident 2.32.3 is good before merging though
<mvo> pedronis: yes, I saw it and will eyeball it today (it was already reviewed so I will just do a quick sanity check)
<mvo> pedronis: and agreed that we need to hold it back a little
<mvo> pedronis: just double checked, we error if a base or an os snap has a base set
<pedronis> mvo: ok,  so either we fix  snap run to send the --base to be base for a base, or we need to prohibit
<pedronis> more
<mvo> pedronis: maybe we talk about it in the standup but my preference for now would be to disable hooks/apps on bases
<mvo> (unless we have a use-case)
<mup> PR snapd#5012 opened: snap: fix `snap advise-snap --command` output to match spec <Created by mvo5> <https://github.com/snapcore/snapd/pull/5012>
<pedronis> mvo: ok, it changes a bit the answer on what waiting needs to happen
<mvo> pedronis: changed in what way?
<pedronis> mvo: if bases  don't have apps, services or hooks, we don't need to wait on anything for them
<mvo> pedronis: indeed
<alexlarsson> zyga: Do you guys expose host fonts to apps?
<alexlarsson> zyga: i.e. https://github.com/flatpak/flatpak/issues/1563
<zyga> Yes, one of the interfaces does this
<zyga> But we expose the fonts, not all of the guts
<alexlarsson> same here
<alexlarsson> but, the guts is unfortunately needed for some things
<alexlarsson> thus that issue
<alexlarsson> Of course, the guts are a total horrorshow
<zyga> Yes, we
<zyga> Know this are not abi stable
<zyga> alexlarsson: re, so I think the fonts are the 1st best thing we can do
<zyga> the "guts" (caches, config files) are a no-no for now
<zyga> I'd be interested to understand more about when we need the config files
<alexlarsson> We do expose the caches
<alexlarsson> those are versioned
<alexlarsson> I believe for intance https://github.com/flatpak/flatpak/issues/1556 is due to the lack of the conf.d files
<alexlarsson> Hmm, interestingly that says snappy can display them :)
<alexlarsson> But, the conf.d snippets has per-language additions to some standard font names
<zyga> hmm, interesting
<zyga> alexlarsson: so snaps do get most of /etc from the host
<alexlarsson> so that you get glyphs picked from that font for e.g. sans-
<zyga> so perhaps we just didn't notice the issue because we share /etc/fonts/ automatically
<popey> The desktop helpers do some voodoo too.
<popey> https://github.com/ubuntu/snapcraft-desktop-helpers/blob/a3de48097a4d7e81ef309e1b2c4eaea970ef88cc/common/desktop-exports#L166
<zyga> yes, the helpers massage the world into compliance
<alexlarsson> Like, on fedora, 65-0-lohit-bengali.conf has:
<alexlarsson> https://paste.fedoraproject.org/paste/-gRyyRM~iFjfyMWMJFAgmA
<alexlarsson> Which i believe makes it pick that font for indic glyphs when showing sans-serif
 * zyga refrains from commenting about XML as a imperative programming language
<alexlarsson> Or something like that (who knows how this shit really works)
<zyga> but yeah
<zyga> it seems that this font config is what over time moved to /lib as "configuration" for systemd units and other non-config things that need to be there by default
<zyga> maybe fontconfig needs similar treatment, move most of that off to /lib and allow /etc for _optional_ overrides
<alexlarsson> In fedora the files in there are symlinked from /usr/share/fontconfig/conf.avail/
<zyga> same on Debian
<alexlarsson> But i think they need to be in one directory for the priority sort thing to work
<zyga> well, almost
<zyga> sorry, it's /etc/fonts/conf.avail
<zyga> there's a swarm of symlinks to that go from /etc/fonts/conf.d/ to ../conf.avail/
<alexlarsson> The main problem i have with it is that it just randomly includes these snippets that can do *anything*
<alexlarsson> like, set font directories, include other xml files, etc
<alexlarsson> They just randomly reused the system config language for per-font tweaks
<zyga> I think bringing those from the host is a mistak
<zyga> mistake*
<zyga> on our end it's just historic thing we want to undo
<zyga> we should ship working configuration in a read-only place
<zyga> and offer additional fonts from the host, but not their configuration
<zyga> *until* fonts can be shipped by flatpaks/snaps
<alexlarsson> But, if it is needed for e.g i18n, then we're kinda hosed
<zyga> and something sane is done about the "configuration" (some form of validation of what is allowed)
<alexlarsson> I'm lightly considering some kind of sanitizer thing to export the right things
<alexlarsson> Just wanted to sync with you as it seems you'll have similar issues
<zyga> so we are in the same boat, I think our setup works "more" but mostly by historic accident
<zyga> I wonder if anyone ever edits those
<zyga> and if we could really just make all of those configuration files immutable
<alexlarsson> I don't think anyone edits the files
<zyga> it might be a problem if the format changes (e.g. new syntax to do something new)
<alexlarsson> but, the directory will change as you install font packages
<zyga> and including the host's /etc causes problems
<alexlarsson> In fact the font *did* just change
<alexlarsson> eh, format
<zyga> font or the config system?
<zyga> oh
<zyga> can you explain what changed?
<alexlarsson> https://bugs.freedesktop.org/show_bug.cgi?id=105818
<alexlarsson> I think some translation thing changed
<alexlarsson> so, chrome with statically linked fontconfig cannot read the fontconfig 2.13 conf files
<alexlarsson> epic, eh?
<zyga> yes, year of the linux desktop is surely not this year
<alexlarsson> I think it is still backwards compat though
<alexlarsson> so, a sanitizer could just ignore "new" stuff
<zyga> yes the bug report comment says: "you could still use the older config files with newer library but the newer config files may not works with older library like that."
<zyga> so we could offer a frozen view of older configuration syntax, if one was available with each and every font package on all the distributions (read: probably not)
<alexlarsson> Yeah, the problem would be if the host font dropped a conf.d with some new config feature
<zyga> one idea is to offer a filter
<zyga> that takes an .xml config file
<zyga> some extra hint as to which output format to create
<zyga> and strip or translate some features into a compatible format for the given library
<alexlarsson> In an ideal world the config format should be split into two things
<zyga> that translator could run in a sandbox on export
<alexlarsson> one that does system config
<alexlarsson> and one that does per-font tweaks and that is minimal and stable
<alexlarsson> But, thats not what we got...
<alexlarsson> But yeah, we need some kind of xml-convertor/stripper like that
<alexlarsson> But, one has to actually understand all this crack to write it...
<zyga> alexlarsson: given the "track record" of xml I'd either sandbox the converter or write it in a safe language (preferably both)
<alexlarsson> Well, it is the host
<alexlarsson> like, the host is not going to be attacking the sandbox
<alexlarsson> its normally the other way around
<alexlarsson> So, i don't think that is the largest problem
<alexlarsson> But it has to be very flexible in handling new, unknown format extensions
<zyga> does flatpak allow flatpaks to ship fonts to the host?
<alexlarsson> no
<alexlarsson> runtimes can bundle fonts, and apps can bundle fonts
<alexlarsson> So you have *some* guarantees
<zyga> ok
<alexlarsson> but normally the idea is to use system fonts
<alexlarsson> For the apps
<zyga> alexlarsson: when did this issue surface?
<zyga> with the format chagne
<alexlarsson> the chrome thing?
<zyga> Antergos Linux, 4.15.15-1-ARCH
<alexlarsson> when 2.13 was released, so like a month or so ago
<zyga> ah, so probably some bleeding edge version of fontconfig
<zyga> sorry, I wasn't clear, I was thinking about fontconfig itself
<alexlarsson> fontconfig 2.13
<zyga> tumbleweed is at 2.12
<zyga> we will notice the issue soon then
<zyga> interestingly on opensuse /etc/fonts/conf.d is full of symlinks to /usr
<zyga> we can work around that to expose font configuration some other way but I worry that this is a ticking bomb
<zyga> mvo: 2.32.3 failed to build in xenial
<zyga> I see the build was restarted
<mvo> zyga: failed in the PPA?
<zyga> mvo: I noticed the build was restored and I removed the mail from my inbox, I don't recall
<mvo> zyga: aha, ok
<mvo> zyga: yeah, very rarely we get those
<popey> ogra_: i have a core system which doesn't seem to have resized the writable part. It's only 8GB on a 80GB disk. Is there some way to force it or do I need to bust out a live cd and gparted?
<ogra_> popey, well, it would be good to find out why it actually didnt resize (the resize code is pretty dumb, it should always work) ... can you re-flash and capture the log from /run/initramfs ?
<ogra_> (if the partition got resized but the filesystem has errors you wouldnt need gparted, just resize2fs)
<ogra_> s/has/had/
<popey> i think i know why it didn't
<popey> i dd'ed onto a usb stick, then once setup, i dd'ed *that* to the hard disk
<popey> so i guess it thinks it already ran once, so doesnt need to
<ogra_> well ... the script checks the partition size vs the device size and looks if there is free space after the writable partition
<popey> ok, used resize2fs and its okay now
<ogra_> ok
<popey> the partition was full size, but the filesystem wasnt
<popey> thanks!
<ogra_> so the parttition was actually at full size
<popey> (also is this the right place for core questions?)
<ogra_> *snap*
<popey> I mean, we don't have a category on the forum?
<ogra_> sure
<ogra_> "device" is the core cateogory
<ogra_> but i have admittedly not had much time the last week to look at the forum
<popey> ahh
<katnip> does an app installed with snap update itself?
<popey> if installed from the store, yes katnip
<ogra_> (got a big backlog i need to go through ... working for customers eats time :) )
<katnip> ok ty
<popey> katnip: any snap in particular you're interested in?
<katnip> it is hexchat
<cachio> zyga, after the change introduced to make snapd work better with selinux, should we be able to run tests on the google fedora again?
<cachio> zyga, I mean, without the change to make it permissive
<popey> katnip: ok, yes, when TingPing updates hexchat in the store, you'll get it
<zyga> cachio: I don't think so
<katnip> nice, thanks
<mvo> kalikiana: hey, do you happen to know if there is a plan to support "refresh-mode" in the snapcraft.yaml json schema?
<mvo> kalikiana: its a relatively new feature of snapd
<pedronis> mvo: did IÂ answer your question about test in 5004 ?
<mvo> pedronis: let me quickly double check
<mvo> pedronis: replied, it is indeed testing the thing I was looking for already
<pedronis> thx
<pedronis> looking into pawel comment atm
 * Son_Goku groans into existence
<Son_Goku> mvo, so it looks like my ability to compile snapd has been restored according to Koschei: https://apps.fedoraproject.org/koschei/package/snapd
<Son_Goku> (if you were wondering why I hadn't been packaging the last few releases, that gives you an indicator of why...)
<mup> PR snapd#5013 opened: cmd/snap-confine: ignore missing cgroups in snap-device-helper <Created by zyga> <https://github.com/snapcore/snapd/pull/5013>
<mvo> Son_Goku: \o/ great to hear. it was the go-yaml breakage?
<Son_Goku> yes
<zyga> mvo: ^ trivial review
<zyga> mvo: consider a .4 candidate PR
<Son_Goku> as evidenced by https://apps.fedoraproject.org/koschei/build/4577065, the dependency of  golang-gopkg-yaml-devel-v2 from 1-21 to 1-22 fixed it
<Son_Goku> that was picked up by Koschei on April 7
<ogra_> mvo, pedronis, hmm, is there some special trick to set a password to expired via system user assertion or is that simply not implemented (pretty typical usecase to have something like "admin/admin" and force the user to set a new PW on first login)
 * cachio afk
<Son_Goku> mvo, root cause was that yaml was mispackaged (v1 had v2 and v2 had v1)
<Son_Goku> * Fri Mar 30 2018 Robert-AndrÃ© Mauchin <zebob.m@gmail.com> - 1-22.gitcd8b52f
<Son_Goku> - Fix mixed-up directories
<mvo> Son_Goku: heh, ok
<Son_Goku> I'm pushing new go-yaml updates to stable _now_
<Son_Goku> https://bodhi.fedoraproject.org/updates/FEDORA-2018-e05b554cb4
<Son_Goku> it should sync out in the next 12 hours
<mvo> ogra_: not implemented afaict, what do you try to pass exactly? is the validation rejecting it?
<Son_Goku> mvo, so we can turn CI back on for Fedora either later today or tomorrow
<Son_Goku> we should also consider wiring up Fedora 28 CI
<ogra_> mvo, not trying to pass anything ... for a pre-release image a customer is asking for a default user/passwd in the image we give them ... would be nice to have that PW expired by default to force an updated PW ... i was just going through the documentation and didnt find anything on that topic
<mvo> ogra_: yeah, we don't support this right now
<ogra_> they want a dev image along with the production one and dont want to force the developers to make their own assertion ... but a known fixed PW is rather insecure as you know :)
<ogra_> i'll file a feature request on the forum ...
<mborzecki> standup is at 3pm?
<zyga> I think so, mvo?
<mvo> zyga, mborzecki yes
<mborzecki> ok
<zyga> ok, I need to take the dog out, also visit the vet nearby
<zyga> I may take the stand-up from my phone
<mr_lou> Who will make a Snap of a Java Runtime, so other Snaps can get Java support? :-)
<mr_lou> (Like VLC, to bring full Java menus to Blu-ray playback)
<mborzecki> off to pick up the kids, will be back for standup
<popey> ogra_: what do I have to do to get screen or tmux pre-installed on core?
<popey> (screen is 560K, tmux is 345K) or so...
<Chipaca> popey: bribery works
<Chipaca> screen is probably more useful on core because of the serial port support (unless tmux also has it and i just don't know how to use it)
<Chipaca> popey: OTOH, wouldn't a screen snap work?
<popey> I suggested tmux because AIUI screen is ye olde and tmux is newer shiny
<popey> would need classic which wouldn't work on core
<Chipaca> why would it need classic?
<Chipaca> hmm
 * ogra_ never used tmux ... (i'm probably to old for that new fangled stuff :P ) ... but i'm alos wondering why a snap wouldnt work
<popey> run arbitrary binaries
<popey> there is a tmux snap
<popey> its classic
<ogra_> classic though
<popey> hence why I'm asking
<ogra_> make a non-classic one ;)
<popey> it wont work non-classic
<popey> thats like saying have a bash non-classic, it would be moribund
<ogra_> screen definitely doesnt need to exec any arbitrary binaries
<ogra_> it just needs access to the tty's
<Chipaca> popey: i hear ogra_ volunteering to write a non-classic screen snap
<popey> screen also needs /var/run/screen to be 777
<ogra_> haha, ayeh, in 6 months or so ... (totally swamped with customer work nowadays .. )
<popey> hah! I just copied the screen binary out of the deb and it works!
<ogra_> :)
<Chipaca> popey: can it resume a session tho
<popey> (it should still be built in imo)
<ogra_> nah
<popey> yes
<ogra_> it should be snapped
<popey> ok on it
<Chipaca> popey: ogra_: probably with an ad-hoc interface
<Chipaca> popey: ogra_: especially if there's a common (or common core + special for each) between screen and tmux
<Chipaca> say screen uses /var/run/screen and tmux /var/run/tmux or sth
<popey> I'll try screen first
<Chipaca> I wonder what jdstrand thinks =)
<popey> because I need something, having to use ALT+F(n) and keep logging in is getting me down
<ogra_> just patch it to use a proper $SNAP_* dir ...
<ogra_> cant be that hard
<Chipaca> (tm)
<pedronis> mvo: pstolowski: IÂ updated 5004
<pstolowski> pedronis: thaks
<pstolowski> *thanks
<niemeyer> Hello all!
<popey> niemeyer: welcome back
<niemeyer> popey: Thanks!
<Chipaca> niemeyer: are you really here? i thought you were conferencing this week
<popeycore> \o/ offlineimap in one screen, mutt in another, cointop in another and irssi in the last \o/ Ubuntu Core "Workstation" done :D
<ogra_> yay !
<Chipaca> popeycore: sounds like you should snap bb
<ogra_> bb ?
<popeycore> hehe
<popeycore> or mplayer with aalib?
<ogra_> byobou ?
<Chipaca> ogra_: apt show bb
<pstolowski> niemeyer: hi!
<pstolowski> pedronis: +1 with one question/suggestion
<Chipaca> popeycore:Â¿por quÃ© no los dos?
<niemeyer> Chipaca: I'm really somewhat here today
<niemeyer> Chipaca: Departing tomorrow
<Chipaca> niemeyer: ah, ok =)
<popey> alan@hal:~$ snap run screen
<popey> Must be connected to a terminal.
<popey> :(
<Chipaca> popey: you probably got an apparmor denial there
<popey> yeah
<popey> one looking at /etc/shadow and one looking at /var/lib/extrausers/shadow
<Chipaca> huh, that was not what i expected
<ogra_> we might need a tty interface for that
<ogra_> or a console one or whatnot
<popey> jdstrand: good morning (when it's morning where you are). I am making a GNU Screen snap for core. Where should I request an interface/apparmor rules changes? :)
<pedronis> pstolowski: added the logging
<pstolowski> pedronis: awesome, ty!
<pedronis> mvo: we want a backport of 5004 once it has landed, right?
<jdstrand> popey: the forum is fine, but I would've thought you'd need classic
<jdstrand> zyga: as for 5006 and 2.32-- I already requested and milestoned 5008. seems you saw that
<zyga> yes, I saw that a moment after I asked
<jdstrand> cool
<mvo> pedronis: 5004> yes! but I can handle this as well if you want (ideally we squash the merge for easy cherry-pick)
<pedronis> yes, IÂ marked squash-merge
<pedronis> marked it
<mvo> ta
<zyga> jdstrand: I don't know if you remember this issue: https://github.com/snapcore/snapd/pull/5013
<mup> PR #5013: cmd/snap-confine: ignore missing cgroups in snap-device-helper <Created by zyga> <https://github.com/snapcore/snapd/pull/5013>
<zyga> jdstrand: we try to configure cgroups before we create them
<jdstrand> I do. thanks for the PR
<jdstrand> zyga: I approved. there is a comment suggestion to consider if you want
<zyga> jdstrand: thanks you
<jdstrand> zyga: fyi, for that comment: s/on start/after start/
<popey> jdstrand: there you go https://forum.snapcraft.io/t/screen-snap/4917 :)
<ogra_> popey, did you try adding and connecting account-control ?
<ogra_> might make the second denial go away
<popey> yeah, but i still get the error and it's not working
<BjornT_> i'm having problems building the maas snap on bionic. it worked on friday, but today i get this error: https://pastebin.ubuntu.com/p/tSW5RrZMBd/
<seb128> zyga, bug #1746710 is probably an issue in the desktop launcher and going to be fixed by the changes kenvandine is working on to handle real system & translated xdg dirs
<mup> Bug #1746710: Snap creates redundant duplicate directories in home folder <amd64> <apport-bug> <artful> <bionic> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1746710>
<jdstrand> pedronis: looking at asserts/* it seems that we do not yet support list alternations in the base declaration. Eg, this is not valid:
<jdstrand> deny-auto-connection:
<jdstrand>   - on-classic: false
<jdstrand>   - plug-attributes:
<jdstrand>       read: all
<jdstrand> pedronis: is that accurate?
<pedronis> IÂ need to look
<jdstrand> well, there is a parseList...
<pedronis> it seems strange, it should be supported
<jdstrand> I end up seeing:
<jdstrand> panic: cannot initialize the builtin base-declaration: invalid map entry key: "    plug-attributes"
<jdstrand> which has some weird whitespace issues..
<jdstrand> wait a sec
<jdstrand> this is what I see:
<jdstrand> panic: cannot initialize the builtin base-declaration: invalid map entry key: "      read"
<jdstrand> maybe it is just a missing left trim
<pedronis> IÂ never looked at the code that builds the base-decl from snippets
<pedronis> whitespace issues seem more likey though
<pedronis> because the code is the same for base-decl
<pedronis> and normal decl
<pedronis> and afaict they support alternation at that level
<jdstrand> pedronis: ok, I did:
<jdstrand> deny-auto-connection:
<jdstrand>   - on-classic: false
<jdstrand>   - plug-attributes:
<jdstrand>       read: all
<jdstrand> pedronis: if I adjust that to:
<jdstrand> deny-auto-connection:
<jdstrand>   -
<jdstrand>     on-classic: false
<jdstrand>   -
<jdstrand>     plug-attributes:
<jdstrand>       read: a;;
<jdstrand> s/a;;/all/
<jdstrand> I get farther
<pedronis> ah
<pedronis> yes
<pedronis> remember that syntanx is yaml (but not quite)
 * jdstrand nods
<jdstrand> this is the first alternation in a base declaration
<jdstrand> so I forgot about that point
<pedronis> well, I forgot too
<pedronis> and in the store it's JSON
<pedronis> so we don't see it
 * jdstrand nods
<jdstrand> pedronis: I think I'm good now. thanks!
<pedronis> that's the correct synax for map inside list elem
<pedronis> np
 * jdstrand nods
<popey> zyga: i note you registered links. Do you fancy transferring it to snapcrafters so we can keep it up to date (yours is 2.12, latest is 2.15)
<zyga> yes
<zyga> popey: just tell me what to do
<popey> zyga: email bret and ask to transfer the snap to snapcrafters please.
<noise][> zyga - better as a forum post, so my inbox isn't a bottleneck :)
<popey> The reason I said email is because whenever I post on the forum about transferring, we end up having to send a mail to confirm email addresses
<zyga> noise][: that's perfect
<zyga> I'll make a thread about this now
<popey> thank you!
<noise][> popey: true, but at least there are several people that can pick up the request vs emailing an individual
<noise][> at some point we'll need to make a web form on dashboard to initiate transfers
<popey> ok
<zyga> popey: https://forum.snapcraft.io/t/request-for-transfer-of-links-snap-to-snapcrafters/4919
<mup> PR snapd#5014 opened: overlord/snapstate: introduce envvars to control the channels for bases and prereqs <Created by pedronis> <https://github.com/snapcore/snapd/pull/5014>
<pedronis> mvo: ^
<mvo> pedronis: thank you
<mup> PR snapd#5015 opened: cmd/snap-confine: ignore missing cgroups in snap-device-helper (2.32) <Created by zyga> <https://github.com/snapcore/snapd/pull/5015>
<zyga> jdstrand: I see you noticed the thread where we discuss interface transactions
<zyga> jdstrand: how do you feel about that concept in general. I think we could defer some operations and only do the costly one on "commit"
<jdstrand> zyga: I gave it a heart :)
<jdstrand> zyga: so, I like it. for performance, we should definitely not be recompiling the profile on each connection
<jdstrand> zyga: this is going to be particularly noticeable on arm
<zyga> even on intel it's noticeable when we do things for each interface connection
<zyga> not once per snap
<zyga> or even once per transaction involving a set of snaps
<jdstrand> zyga: I know (I read the topic), but on arm it will be particularly painful
<zyga> yes
<Chipaca> that 'why are my fans spinning up? oh one of the cores has been at 100% for 2 minutes now running apport' moment
<zyga> Chipaca: apport helps to make UK weather better by making some more winds ;-)
<mup> PR snapd#5004 closed: daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5004>
<mr_lou> Can I install a 32bit version of VLC on my 64bit Ubuntu with Snap somehow?
<zyga> mr_lou: no, not easily
<zyga> mr_lou: is there a particular reason why you would like that?
<mr_lou> zyga, Well.... wanted to try the --classic in order to let VLC be in contact with the outside world, and thus be able to utilize Java, which is needed for full Blu-ray playback (menus on Blu-ray's use Java).
<mr_lou> Another option is for someone to make a Java Snap. Or at least I've heard so.
<zyga> classic is not a magic bullet, it won't make a snap that doesn't anticipate that work
<zyga> mr_lou: I'm afraid that that's now how things operate, there are plenty of java snaps around; what needs to happen is VLC upstream who control the VLC make that decision
<mr_lou> I mean a Java Runtime Snap...  a JVM.
<zyga> yes, I understand what you mean
<ogra_> theoretically 32bit snaps should work on a 64bit host ... the core snap currently ships the 32bit libc alongside
<zyga> mr_lou: you could make your own version of VLC that is compiled with java support, add java inside and try that
<mr_lou> Oh
<zyga> ogra_: yes but you cannot select a 32 bit snap if 64 bit snap is avaialable
<ogra_> (practically i'm not sure since vlc libs might call out to more than just libc)
<cjwatson> On 18.04 I get a constant stream of gnome-shell notifications about apparmor denials of bits of spotify (although spotify seems to work anyway).  Is this a snapd/apparmor/etc. bug or something that I should try to figure out how to report upstream?  Two sample denials:
<ogra_> ah
<cjwatson> type=AVC msg=audit(1523287531.978:16850): apparmor="DENIED" operation="mknod" profile="snap.spotify.spotify" name="/home/cjwatson/snap/spotify/6/.config/spotify/Users/colmmacuait-user/pending-messages.tmp" pid=21657 comm=436F726520546872656164 requested_mask="c" denied_mask="c" fsuid=1000 ouid=1000
<ogra_> snapd limitation, k
<cjwatson> type=AVC msg=audit(1523287596.759:16882): apparmor="DENIED" operation="truncate" profile="snap.spotify.spotify" name="/home/cjwatson/snap/spotify/6/.cache/spotify/Storage/index.dat" pid=21657 comm=4E6574776F726B20546872656164 requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
<zyga> truncate is interesting
<zyga> we should support taht
<zyga> jdstrand: ^
<cjwatson> I assume the mknod is for a pipe or something, not an actual device node
<zyga> cjwatson: the mknod one is less fun, it's probably a socket
<jdstrand> cjwatson: sounds like spotify got refreshed while it was running
<zyga> H
<zyga> ah, that's interesting
<jdstrand> this is the bug
<zyga> what's the revision you have now cjwatson?
<jdstrand> open fds, etc
<zyga> yes, it seems so
<cjwatson> Ah, so it was
<zyga> it's in my corner for sure
<cjwatson> 810  Done    2018-04-09T14:53:59Z  2018-04-09T15:15:51Z  Auto-refresh snap "spotify"
<zyga> after user mount namespaces
<cjwatson> rev 13 now
<jdstrand> cjwatson: stop spotify and restart and it will go away. zyga has this assigned to him so hopefully 2.33 will have a fix
<zyga> 2.34 more likely
<zyga> 2.33 is all but ready but we need to release 2.32 that works first
<jdstrand> or at least, have a way to handle this gracefully
<cjwatson> jdstrand: thanks - I would never have guessed that
<jdstrand> cjwatson: yeah, it is an annoying usability wart. it'll get addressed
<mup> PR snapd#5015 closed: cmd/snap-confine: ignore missing cgroups in snap-device-helper (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5015>
<mr_lou> zyga, Can't one Snap talk with other Snaps? If a JVM was a Snap of its own, it could be used by a lot of other Snaps? Like e.g. Android Studio too?
<zyga> mr_lou: yes it can but there are specific safeguards in place.
<zyga> mr_lou: the VLC snap would have to explicitly support this
<zyga> mr_lou: and unless the JVM snap was from a source that was approved as a publicly available JVM snap then VLC maintainers would have to ship their own JVM snap for this purpose (at that time they could just bundle java inside VLC)
<zyga> mr_lou: the goal is to avoid someone breaking lots of snaps that "depend" on the JVM
<zyga> Chipaca: can I ask you for a review of https://github.com/snapcore/snapd/pull/4868
<mup> PR #4868: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Squash-merge> <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4868>
<zyga> it's got two +1s but I one is from me and I made some changes there
<mup> PR snapd#5016 opened: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016>
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/5016/files#r180139800
<mup> PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016>
<mr_lou> zyga, I see. So the best approach is to get VideoLAN to embed a JVM.
<zyga> yes
<mr_lou> zyga, Ok. Thanks.
<Chipaca> zyga: sure
<zyga> thanks!
<Chipaca> uhhh
<zyga> ?
<Chipaca> in a bit though
<zyga> sure, no rush :)
<Chipaca> am in the middle of the refactor niemeyer asked for snapshot config to not be raw json
<zyga> sure
<zyga> no rush, it's not needed today
<Chipaca> ah, ok
<Chipaca> added to my TODO for tomorrow then
<zyga> this is 2.33 material
<zyga> thanks
<mup> PR snapd#4977 closed: debian: add gbp.conf script to build snapd via `gbp buildpackage` <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4977>
<pedronis> zyga: to be clear  I would really like #5014 in 2.32.4, because otherwise the first snapd deb in bionic will also not be testable
<mup> PR #5014: overlord/snapstate: introduce envvars to control the channels for bases and prereqs <Created by pedronis> <https://github.com/snapcore/snapd/pull/5014>
<zyga> pedronis: +1
<zyga> pedronis: my comments about documentation were really orthogonal to the change, I think this should land
<pedronis> zyga: but you didn't vote on the change
<zyga> ah, indeed, I'm following notifications from GitHub and I was just reacting to the change
<zyga> ok, more later
 * zyga -> school 
<popeycore> grrr. just had another occasion where doing "snap install" took out my entire x session
<zyga> popey: snap install bullseye
<mup> PR snapd#5017 opened:  daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5017>
<jdstrand> zyga: wrt pr 5016
<mup> PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016>
<jdstrand> zyga: I used the same methodology that the existing browser-support uses
<jdstrand> zyga: so, 'if r, ok := plug.Attrs["read"]; ok {' is supposed to see if it is there (ie, !ok returns nil, otherwise, go into the condition)
<jdstrand> zyga: then '_, ok = r.(string)' checks if sees if a string
<jdstrand> zyga: if it isn't or if it isn't and it isn't one of the allowed values, exit with error
<jdstrand> zyga: what am I missing?
<jdstrand> I don't see how 'r' is an interface{}... if it was, the testsuite would fail
<jdstrand> r, ok := plug.Attrs["read"]
<jdstrand> s/or if it isn't/or if it is/
<mup> PR snapcraft#2058 opened: Install python-distutils for the Python plugin on bionic <Created by bjornt> <https://github.com/snapcore/snapcraft/pull/2058>
<zyga> jdstrand: What is the type of plug.Attrs
<zyga> (Typing from my phone)
<jdstrand> zyga: map[string]interface{}
<zyga> So r must be interface{}
<jdstrand> based on snap/info.go, PlugInfo
<zyga> Perhaps go does the right thing
<jdstrand> zyga: I mean, I'm just using what browser-support has always done
<zyga> As I said I donât know how == and != is implemented in different types
<zyga> Yeah, registered that
<zyga> I will check what happens after school meeting
<zyga> Just wanted to point out that it may be subtly broken or cleverly correct :-)
<jdstrand> zyga: I'm not a go expert yet, but my understanding was that for go json, map[string]interface{} is used to 'hold a map of strings to arbitrary data types' (see https://gobyexample.com/json), therefore, based on how the json decoding works, if it isn't there, it is null
<Chipaca> jdstrand: nil is typed though, fwiw
 * Chipaca is probably missing context
<jdstrand> Chipaca: https://github.com/snapcore/snapd/pull/5016/files#r180139800
<mup> PR #5016: interfaces/home: add 'read' attribute to allow non-owner read to @{HOME} <Created by jdstrand> <https://github.com/snapcore/snapd/pull/5016>
<Chipaca> jdstrand: yeah, you need something like s, ok := r.(string)
<Chipaca> jdstrand: and then s will be the string
<jdstrand> Chipaca: it is the next line
<pedronis> jdstrand:  interface == string does the right thing though
<Chipaca> jdstrand: no, i mean
<Chipaca> jdstrand: you do: _, ok := r.(string)
<Chipaca> jdstrand: and then in the next line you do if r == "all"
<Chipaca> jdstrand: that r there is still an interface{}, not a string
<Chipaca> so you can't compare it to a string
<jdstrand> but it isn't
<Chipaca> ?
<jdstrand> it is only an interfacec{} if r, ok := plug.Attrs["read"]
<jdstrand> is !ok
<pedronis> Chipaca:  you can
<zyga> jdstrand: https://play.golang.org/p/ptO5oOH6daa
<zyga> it looks ok
<pedronis> A value x of non-interface type X and a value t of interface type T are comparable when values of type X are comparable and X implements T. They are equal if t's dynamic type is identical to X and t's dynamic value is equal to x.
<jdstrand> I mean, I can change this, but again, why was the browser-support not an issue and why does the testsuite pass if this is wrong
<zyga> yeah,
<Chipaca> pedronis: !!
<pedronis> basically comparing interfaces and non-interfaces does the reasonable thing
<Chipaca> jdstrand: heh, if it compiles, i was wrong :-)
<pedronis> (except nil  is hard)
<Chipaca> jdstrand: sorry for the noise then
<Chipaca> jdstrand: so, about you not being a go expert yet
<Chipaca> jdstrand: â¦ :-)
<pedronis> well, is a legitimate doubt
<jdstrand> well, just cause I got the testsuite to pass doesn't mean I am an expert by any means! :)
<pedronis> but indeed we use that in various places
<pedronis> it's generally ok
<pedronis> unless nil and pointers are involved
<pedronis> then it's fun(tm)
<pedronis> because nil of interface, and nil of pointer types are not the same
<jdstrand> right. we don't compare to nil here
<pedronis> and depending on return types of functions etc, is very easy to mix those up
<pedronis> and it's only not only interface{},  error is also an easy one to get a mess with nil
<pedronis> jdstrand: Chipaca: this illustrates the issue
<pedronis> it also shows that is the source of the interface value that needs to be careful though (unless source and use are really connected/close)
<cachio> niemeyer, if you could today create the secret for travis and spread should be great
<niemeyer> cachio: I'm talking to cprov about Travis right now
<cachio> niemeyer, great, thanks
<niemeyer> cachio: This is not about spread, though
<niemeyer> cachio: It's just the Travis token that for whatever reason stopped working
<cachio> niemeyer, ahh, ok
<niemeyer> (token for the travis API itself, that creates the request for building)
<mup> PR snapd#5018 opened: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5018>
<zyga> re!
 * zyga is back from school
<mup> PR snapd#5013 closed: cmd/snap-confine: ignore missing cgroups in snap-device-helper <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5013>
<Son_Goku> mvo, can we have https://github.com/snapcore/snapd/pull/5011 cherry-picked into 2.32?
<mup> PR #5011: data/selinux: Give snapd access to more aspects of the system  <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5011>
<mup> PR snapcraft#2035 closed: ci: cache core and lxd to avoid redownloading <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2035>
<zyga> mvo: looking
<zyga> Son_Goku: yes sure
<zyga> Son_Goku: do you want to make a backport or shall I quickly?
<Son_Goku> zyga, also, bodhi just pushed updated golang-gopkg-yaml to master mirror: https://bodhi.fedoraproject.org/updates/FEDORA-2018-e05b554cb4
<Son_Goku> zyga, you do it please
<zyga> Son_Goku: ack
<Son_Goku> I'm technically working still ;)
<zyga> I will re-trigger the fedora CI PR
<zyga> sure :) thank you for the fixes!
<Son_Goku> np
<mup> PR snapd#5019 opened: data/selinux: Give snapd access to more aspects of the system <Created by zyga> <https://github.com/snapcore/snapd/pull/5019>
<zyga> Son_Goku: done
<Son_Goku> awesome
<kyrofa> cprov, got an error case to make you aware of, but LP isn't working right now so I'm reaching out directly
<kyrofa> cprov, https://bugs.launchpad.net/snapcraft/+bug/1750177
<mup> Bug #1750177: When asking to release to a branch that's too long, a traceback is printed that gives no hints as to the source of the error. <stacktrace> <Snapcraft:New> <https://launchpad.net/bugs/1750177>
<kyrofa> cprov, the error response from the store is HTML instead of json
<kyrofa> (it's a 500)
<cprov> kyrofa: otp, will be with you in a few. Thanks for the bug
<kyrofa> cprov, sure thing. I'll add an "also effects" once LP lets me
<cprov> kyrofa: oh, timeout error, wow
<kyrofa> Yeah
<kyrofa> cprov, if I print the entire error response from the store, will that include anything particularly sensitive?
<kyrofa> Right now, when someone logs a bug, even if they run in debug mode we have no clue what the store handed them. I'd like to print the response in debug mode
<cprov> kyrofa: no, it's a internal server error page, I suppose, nothing sensitive or useful (tbh)
<kyrofa> cprov, I mean for ALL errors
<cprov> kyrofa: I don't think we should do that, we can land fixes to prevent non-API errors then snapcraft failing to interpret that should bail
<cprov> printing bad responses is as bad and printing traceback, isn't it ?
<kyrofa> cprov, we traceback in debug mode as well
<kyrofa> cprov, the primary experience (non debug mode) should be clean, of course
<kyrofa> cprov, bug when someone logs a bug, I want to see the response we barfed on
<kyrofa> Otherwise I have to try and duplicate it, and that's not always possible
<cprov> kyrofa: it's not that terrible if it's only printed in debug mode
<cprov> kyrofa: we have the error context logged server-side
<kyrofa> cprov, okay, so error responses shouldn't include anything overly sensitive?
<pedronis> jdstrand: Chipaca: seems IÂ wanted to link to an example (about nil and interfaces) but didn't: IÂ meant to share this: https://play.golang.org/p/0CGDjdMtcIS
<jdstrand> pedronis: heh, I was wondering :)
<jdstrand> roadmr: hi! fyi, https://bugs.launchpad.net/snapstore/+bug/1762544
<jdstrand> roadmr: I decided to enable the resquashfs sooner than later in the review tools in light of the upcoming sprint
<roadmr> jdstrand: oy! let's see
<jdstrand> ratliff: fyi, ^
<mup> PR snapcraft#2059 opened: storeapi: handle 500 error response when releasing snap <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2059>
<pedronis> zyga: cachio: 2.32 is still configured to use mainly linode for tests and things don't seem to b working great there
<j1mc> hi snappy people . . . is there a way to clear previous versions of an installed snap (other than uninstalling and re-installing the snap)? i've had three versions updates of the 'hugo' binary, and now have three loop mounted squashfs filesystems.
<roadmr> jdstrand: so what happens now if I set SNAP_ENFORCE_RESQUASHFS=0? no change in behavior?
<roadmr> (now == with the tools currently in the store, r1018 IIRC)
<j1mc> that particular setup messes with commands like "lsblk"
<jdstrand> roadmr: it will go back to how it acts today
<jdstrand> roadmr: well, wait. if you do that *today* without 1021, it will actually turn on enforcement since the previous envvar check was dumb (only checked if SNAP_ENFORCE_RESQUASHFS was set)
<jdstrand> roadmr: so, the feature flag should accompany r1021
<roadmr> jdstrand: OHH! yes, that's what I wanted to know
<roadmr> jdstrand: ok hm... this'll let me reason about the logic I need to implement. I'd love to have the feature flag ready *before* rolling out r1021 but if they go out together that could also work
<j1mc> i understand that the prior versions are in place to allow reverting to prior versions, but want to see if i can limit the number of prior versions / limit the number of prior loop-mounted snap / squashfs filesystems
<jdstrand> roadmr: if you want, I can revert 1021, fix the env var check, then you can pull that revision. then add back the flipped logic
<pedronis> j1mc: the limit is 3 (and at  the moment is not configurable), there's also been some discussion to really mount only the last (at least for normal snaps)
<Chipaca> j1mc: you can 'snap remove --revision=<an old one> yoursnap' to remove one of the old ones
<j1mc> pedronis: thank you
<Chipaca> j1mc: you can get the revision number from 'snap list --all yoursnap'
<jdstrand> j1mc: you can't today. you might want to add your thoughts to https://forum.snapcraft.io/t/all-revisions-of-snaps-are-mounted-when-they-dont-need-to-be/2294
<jdstrand> and you can workaround as Chipaca mentioned
<jdstrand> roadmr: shall I do that?
<j1mc> thank you both
<roadmr> jdstrand: was thinking... yes, that'd be great (i.e. if regardless of default behavior, they respond correctly to the env var being either =0 (off) or =1 (on), otherwise I don't have a way to preemptively add the feature flag
<jdstrand> ok. I'll update the bug when I do that. should just be a few minutes
<roadmr> jdstrand: the chances of a borked review-tools *and* a borked feature flag in the same rollout are slim but I'd prefer to be cautious
<roadmr> many thanks
<jdstrand> roadmr: ok, done. I updated the description to say r1022 has the default enforcement, and then added https://bugs.launchpad.net/snapstore/+bug/1762544/comments/1
<roadmr> jdstrand: gotcha!
<roadmr> jdstrand: so am I clear to add r1021 to the store queue? no behavioral change wrt resquashing vs. what I have now?
<jdstrand> roadmr: correct. please pull r1021
<roadmr> ok, incoming!
<jdstrand> roadmr: thanks!
<sergiusens> stgraber: hey, any reason why lxd on 2.0/stable is still 2.0.11?
<cachio> pedronis, yes, we should port all the google changes to 2.32.x
<cachio> I think we started moving to google after 2.32 was sent to beta
 * cachio afk
<JonelethIrenicus> any steam snaps
<stgraber> sergiusens: yes, because that's the latest 2.0.x stable release
<sergiusens> stgraber: am I stuck and out of luck to use 2.21?
<sergiusens> or is that an unsupported release?
<stgraber> sergiusens: 2.21 is unsupported
<stgraber> it's a feature release, we support those until the next one, which is out now (3.0)
<stgraber> if they're in an Ubuntu release, then we will do security updates as required for that Ubuntu release, but that's the extend of what we do on a non-LTS release of LXD
<kyrofa> stgraber, .0 are LTS releases?
<stgraber> kyrofa: major bumps are LTS releaes, yes. 1.0.x, 2.0.x, 3.0.x
<kyrofa> Gotcha
<sergiusens> stgraber: ok, so is it going into backports? Just wondering as autopkgtest use 2.21. Aside from that, is there a migration guide to move from 2.0 to 3.0? Or anything in particular to take into account?
<stgraber> sergiusens: it will, yes
<kyrofa> stgraber, quick sidebar: I can't seem to be able to run snaps within nested containers, is that a known issue?
<stgraber> kyrofa: snaps inside nested containers can't work because apparmor only allows for one level of nesting, so snapd in nested containers won't be able to load apparmor policies
<mcphail_> popey: o/
<kyrofa> Okay, that sounds familiar
<stgraber> sergiusens: 2.0 to 2.21 and 2.0 to 3.0 is pretty much the same thing, there's no manual upgrade stage, the upgrade is handled for you. API is backward compatible so no API breakage. The CLI has a few changes but it's not considered API for us (though we obviously try to limit potential breakages to major releases as was done here)
<sergiusens> stgraber: last time we talked you told me the REST API was more of internal thing and to stick to the CLI :-) I'll work out the quirks if it is not much
<kyrofa> stgraber, looks like Sergio had some network issues, but yeah-- we were under the impression the the REST API was unstable, so we used the CLI instead. Is that not true?
<stgraber> kyrofa: very much the other way around, API is only ever extended, things are never removed from it, same isn't guaranteed with CLI
<kyrofa> Seems we got our wires crossed somewhere, then-- we'll have to rethink that, thank you
<popey> mcphail: yay
<diddledan> why are the desktop parts taking forever to pull these days?!
<diddledan> s/pull/preparing to build/
<diddledan> i.e. what has changed recently that makes them take forever to do nothing?
<kyrofa> diddledan, "preparing to build" just unpacks stage-packages
<kyrofa> Perhaps more were added?
<diddledan> so why does it take forever?
<diddledan> https://usercontent.irccloud-cdn.com/file/8tUnpecv/image.png
<diddledan> it's been sat there for ages. other parts don't do that. it is specific to the desktop parts
<kyrofa> No idea
<kyrofa> Well, desktop parts do tend to have a large number of stage-packages
<kyrofa> But that's all I've got
<diddledan> it's new behaviour tho
<diddledan> something has changed
<kyrofa> Try running in debug mode, see if that gives you anything different
<diddledan> perhaps it's the extra checks for executable stacks et al??
<kyrofa> I don't believe that stuff happens until prime
#snappy 2018-04-10
<diddledan> yeah that's what I thought, too
<diddledan> you might be right that it's due to unpacking the stage packages but it takes an inordinately long time
<diddledan> something seems screwey because a single cpu core is pegged at 100% usage (not parallelised in any way)
<kyrofa> Well, it uses the apt python API, so yeah, that sounds right
<mwhudson> kyrofa: hey can i talk to you about patchelf? :)
<mup> PR snapcraft#2060 opened: package: ensure all relevant files are in for sdist <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2060>
<mborzecki> morning
<zyga> hey hey
<zyga> good morning
<zyga> there's going to be a thunderstorm this evening :)
<zyga> I cannot wait for that, I really missed them
<mborzecki> yeah, relaly can't wait for the first power outage this year
<zyga> ouch, do you think it will come to that?
<zyga> I was used to power outages in Spain when it was raining
<zyga> but not used to them here even when there's a very fierce storm
<mborzecki> right where i live there's an outage almost every time there's a thunderstorm
<mborzecki> otoh living in deep suburbs/almost country has some benefits too
<mborzecki> someone raised a really nice idea in the forum: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/102
<zyga> yes, that's a nice idea
<zyga> mobile data == restrict downloads
<mborzecki> need to look at the implementation, whether the setting is exposed over dbus and if so which bus it is
<mborzecki> mvo: morning
<zyga> mborzecki: it's dconf/gconf most likely
<zyga> good morning mvo
<mborzecki> zyga: looks like networkmanager https://bug792608.bugzilla-attachments.gnome.org/attachment.cgi?id=366968
<mborzecki> or libnm for that matter
 * zyga goes to make breakfast for the kids
<mborzecki> that's nice, if it's nm, then we could poke it through dbus
<mvo> hey mborzecki and zyga ! good morning
<mup> PR snapd#5017 closed:  daemon,overlord/hookstate: stop/wait for running hooks before closing the snapctl socket (2.32) <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5017>
 * zyga needs to pay some taxes but will be back to work shortly
<zyga> mvo: hey
<mup> PR snapd#5019 closed: data/selinux: Give snapd access to more aspects of the system (2.32) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/5019>
<zyga> mvo: about 2.32.4, it seems we have some number of PRs open
<zyga> is the goal to land that today?
<mvo> pedronis: you mentioned the snap roadmap page on the forum was a bit outdated/confusing, I updated it now, let me know if there is anything left that looks inconsistent or wrong
<mvo> zyga: not necessarily today but I think it would be good to prepare a 2.32.4 soon. we need to wait a little bit with the new api merge until we are sure that we don't need a .4 for .3
<mvo> zyga: (if that makes sense)
<zyga> hehe, Yes
<mborzecki> anyone wants to take a quick look at #5003, trivial change
<mup> PR #5003: cmd/snap-seccomp: graceful handling of non-multilib host <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5003>
<mborzecki> ?
<mvo> mborzecki: sure
<mborzecki> it'd be great if we could put it in .4 too, would allow me to drop a patch in the packacing
<mborzecki> mvo: thanks :)
<mborzecki> zyga: what is the version of fontconfig that breaks compatibility?
<mborzecki> hmm btrfs on 4.14.26-54.32.amzn2.x86_64, shutting down lxc container produces this: kernel https://paste.ubuntu.com/p/kp842QyGng/
<zyga> mborzecki: 2.13
<zyga> mborzecki: I'm going afk now (dog) but once back I can give you a reference to thebug report
<mborzecki> hm i have local/fontconfig 2.13.0+10+g58f5285-1 here
<mborzecki> zyga: heh, see what you mean, https://paste.ubuntu.com/p/cyxSH6cwVB/ saw that earlier and assumed that it's something with spotify snap
<mborzecki> zyga: it's not 'crashing' though
<pstolowski> morning
<mup> PR snapd#5020 opened: errtracker: check for whoopsie.service instead of reading /etc/whoopsie <Created by mvo5> <https://github.com/snapcore/snapd/pull/5020>
<kalikiana> good morning o/
<pstolowski> hey kalikiana
<zyga> Mborzecki: the reporter on one arch derivative saw crashes
<zyga> Hey kalikiana
<mborzecki> zyga: maybe it's some specific snap, spotify seems to work
<zyga> Perhaps
<zyga> Iâm still outside, Iâll sit in a coffee shop soon
<mup> PR snapd#5014 closed: overlord/snapstate: introduce envvars to control the channels for bases and prereqs <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5014>
<Chipaca> moin moin
<zyga> Hey hey John
<mup> PR snapd#5021 opened: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5021>
<pedronis> mvo: I created a backport of the envvars branch ^
<pedronis> #5018 needs a 2nd review
<mup> PR #5018: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5018>
<pedronis> mvo: about roadmap:  I see a formatting problem with USB hotplug status emoji ... also   in 2.32  feeding cloud-init and CDN aware are the same I think
<zyga> re
<zyga> pedronis: I'll review 5018 next
<mborzecki> zyga: checking for metered connection should be easy, just loooking at this prop on the main nm object https://developer.gnome.org/NetworkManager/unstable/gdbus-org.freedesktop.NetworkManager.html#gdbus-property-org-freedesktop-NetworkManager.Metered
<zyga> mborzecki: should snapd do that check directly?
<mborzecki> zyga: yeah, that's there it makes most sense probably
<zyga> what would happen on a core device that uses network-manager for networking
<zyga> snapd would have to understand that that endpoint is down when the n-m snap is inactive for instance
<mborzecki> zyga: the values of NMMeteres are somewhat funny https://developer.gnome.org/NetworkManager/unstable/nm-dbus-types.html#NMMetered,  NM_METERED_GUESS_NO, heh
<zyga> (or that a device may be only and always on metered connection)
<pedronis> we would need some gadget config or core config to ignore this
<pedronis> also there might be no NM as well
<mborzecki> no NM is easy to handle
<zyga> I wonder how it determines the guess
<pedronis> anyway it sounds like it needs a design forum post
<zyga> yes, definitely
<zyga> feels like a "snap set system refresh.metered = "always | priority | never" thing
<zyga> with gadget control as well
<mborzecki> `connection.metered: unknown`, that's for my wifi connection
<mborzecki> but i can explicitly mark it as metered
<mborzecki> zyga: are you on a modem now?
<Chipaca> mwhudson: yo
<zyga> yes
<mwhudson> Chipaca: hello
<Chipaca> mwhudson: my go snap auto-refreshed and now sigsegvs
<zyga> mborzecki: do you want me to check?
<mborzecki> zyga: can you do 'nmcli c show --active', the pick the uuid and `nmcli c show <uuid>`, look for connection.metered
<zyga> sure
<mwhudson> Chipaca: refresh again and it should break
<mwhudson> *unbreak
<Chipaca> mwhudson: ok :-) how so?
<mwhudson> Chipaca: patchelf is bad?
<mwhudson> Chipaca: https://forum.snapcraft.io/t/patchelf-broke-my-binary/4928
<Chipaca> mwhudson: sigh. ok.
<zyga> mborzecki: it's a bit dumb
<mwhudson> it'll unbreak just because i published the old version again
<zyga> nmcli being dumb about metered  https://www.irccloud.com/pastebin/UbF7cxGb/
<zyga> mborzecki: I wonder if it is in any way confused by the presence of the LXD bridge
<Chipaca> mwhudson: except now the store is timing out
<Chipaca> (â¯Â°â¡Â°ï¼â¯ï¸µ â»ââ»
<zyga> mborzecki: I don't see any way to mark the connection as metered from the gui
<mborzecki> zyga: hm, aren't you on gnome 3.28?
<zyga> mborzecki: and I don't see why it would not be marked as metered, pretty much all GSM/3G/4G/LTE is metered some way
<zyga> mborzecki: I'm on bionic now
<zyga> that's 3.28
<mborzecki> zyga: hm `nmcli c modify <uuid> connection.metered true` should mark it
<Chipaca> hmm, something's going on in the dc
<mvo> pedronis: ok, thanks, I will fix that
<mwhudson> yeah canonical irc is flapping
<zyga> hmm
<zyga> (process:14018): libnmc-CRITICAL **: 10:29:11.195: file clients/common/nm-meta-setting-desc.c: line 765 (<dropped>): should not be reached
<Chipaca> that + the assertions endpoint timing out
<zyga> mborzecki: ^ that's from "show"
<zyga> mborzecki: after the manual change
<zyga> metered connection (after manually tweaking the value) https://www.irccloud.com/pastebin/lBCN8dLI/
<mborzecki> zyga: woow ;)
<mborzecki> zyga: can you do `busctl --system introspect org.freedesktop.NetworkManager /org/freedesktop/NetworkManager` and look for .Metered ?
<zyga> sure
<mwhudson> so i have this binary in stage, it works, the one in prime breaks
<zyga> oh, busctl is a new thing to me
<pedronis> Chipaca: is connectivity, IÂ think they are making it worse to make it better,  but it got worse than unexpected
<pedronis> *than expected
<zyga> systemd :0
<mborzecki> or `busctl --system get-property org.freedesktop.NetworkManager /org/freedesktop/NetworkManager org.freedesktop.NetworkManager Metered`
<mwhudson> if i take the staged one and run strip --remove-section .note.go.buildid and patchelf --set-interpreter /snap/core/current/lib64/ld-linux-x86-64.so.2 it still works
<mwhudson> wtf is going on
<zyga> I wait for malware that is called something like ${crap}ctl to seem like another part of systemd
<mborzecki> zyga: yeah, but it's easier to use than dbus-send
<mwhudson> ah snapcraft does RPATH things as well
<zyga> zyga@t470:~$ busctl --system introspect org.freedesktop.NetworkManager /org/freedesktop/NetworkManager | grep Metered
<zyga> .Metered                            property  u           1                                        emits-change
<mborzecki> zyga: at least UX wise, just seems to do the right thing
<zyga> mborzecki: yeah, no doubt about that
<zyga> mborzecki: it's pretty nice
<zyga> mborzecki: we could subscribe to changes of that property
<zyga> mborzecki: read it
<zyga> mborzecki: and then carry on
<zyga> mborzecki: it feels like connectivty manager in overlord
<mborzecki> ok, so now it's showing metered = 1 -> NM_METERED_YES according to the NM dbus spec
<zyga> mborzecki: it could also monitor offline/online status
<mwhudson> ok can repro
<mborzecki> zyga: yes
<zyga> and eventually it could understand the set of snaps responsible for network being up
<mborzecki> zyga: i've actually used it in that camera boards i've shown you the photos of ;)
<zyga> and expose that to snapmgr
<zyga> yeah
<zyga> mborzecki: ok, let me know if you need any more testing
<zyga> mborzecki: as an intereseting use case
<zyga> mborzecki: all off office.zygoon.pl is on a metered connection
<zyga> mborzecki: from a router that has metered wifi
<mborzecki> ha, wonder how it figured that out
<zyga> well, the wifi/lan is metered as it is routerd through the LTE
<zyga> mborzecki: nothing figures that out yet
<zyga> but there's some part of the wifi spec that can convey this fact
<zyga> perhaps through DHCP but I really don't know
<zyga> but I read that gnome or maybe androind wants to support that
<zyga> mborzecki: if you want to play on my office LAN I can make an account for you
<mborzecki> (if it touches any of IEEE standards then it's better not to know)
<mborzecki> zyga: thanks but no need for now ;) just wanted to get the general picture
<zyga> sure :)
<mborzecki> zyga: btw. i've updated #4989
<mup> PR #4989: tests: add arch to CI <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4989>
<zyga> I'll finish review of 5018 and then start chopping my WIP user mounts branch
<zyga> mborzecki: thanks, I'll check soon
<zyga> http://omgfoss.com/install-spotify-linux-ubuntu-debian-fedora/
<zyga> this is cute :)
<zyga> https://www.irccloud.com/pastebin/kAgEqb8f/
<Chipaca> zyga: funny how they skipped the 'snap install spotify' step
<zyga> oh
<zyga> indeed
<zyga> hahaa
<zyga> that's even more silly
<popey> :)
<Chipaca> pedronis: was playing with the performance of unserialising an entry of a json object last night
<Chipaca> pedronis: I've got another reason to move to go 1.7+
<Chipaca> :-)
 * zyga found the "chronic" utility from moreutils
<zyga> Caelum: I added LEAP 15 to https://build.opensuse.org/project/show/system:snappy
<mborzecki> 	fmt.Println("baz == other type", foo["zed"] == "dez")
<mborzecki> w8, but spotify is not a classic snap, no need for the symlink
<mborzecki> aand copy pasted some random sample with comparing interfaces i was preparing for jdstrand's review  :)
<popey> no, but if you're installing snapd for the first time, you might want to do that for future classic snaps you may install
<mborzecki> zyga: can we land #4980?
<mup> PR #4980: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <https://github.com/snapcore/snapd/pull/4980>
<zyga> mborzecki: yes
<zyga> let's
<zyga> this unblocks cachio's work on fedora-on-google
<mup> PR snapd#4980 closed: Revert "spread.yaml: switch Fedora 27 tests to manual (#4962)" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4980>
<zyga> pedronis: reviewed 5018
<pedronis> thx, I expended the comments a bit
<pedronis> heh, expanded
<zyga> pedronis: thank you
<pstolowski> how can I interrupt/restart travis job that's stuck somewhere since yesterday? https://github.com/snapcore/snapd/pull/4940
<mup> PR #4940: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<mwhudson> Chipaca: well that was fun to chase down https://github.com/NixOS/patchelf/issues/146
<zyga> pstolowski: let me look
<zyga> ah
<zyga> that's more interesting, there's no link
<Chipaca> mwhudson: nice spelunking
<zyga> looks like travis broke there
<zyga> can you se that branch via travis itself?
<mwhudson> Chipaca: patchelf is .... interesting
<Chipaca> mwhudson: do I want to know
<Chipaca> :-)
<mwhudson>         /* !!! Why do we stop after a .dynstr section? I can't
<mwhudson>            remember! */
<mwhudson> for example
<pedronis> loose specs and faulty memory
<Chipaca> mwhudson:   /* yolo */
<mwhudson> Chipaca: pretty much
<mwhudson> pedronis: not so much "loose specs" as "it works on my machine" :/
<pedronis> mwhudson: well to be fair I expect elf and how it's used by compilers to be said, it worked with the binaries from baz
<pedronis> s/to be said/to be loose/
<mwhudson> i wonder what patchelf would do with burneye and things like that
<pedronis> maybe that's unfair though , and is not as bad as dwarf
<Chipaca> we should all go back to a.out
<Chipaca> :-)
<pstolowski> zyga: ah, right, i can get to the branch/build from travis directly. the missing link confused me. thanks
<mwhudson> pedronis: i've never had the courage to learn much about DWARF
<pedronis> mwhudson: well it's extensible,   as usual if  extensible format don't have way to convey this you can ignore or not, writing stable tooling is a nightmare
<pedronis> mvo: zyga:  we are getting handshake errors from linode, it means landing stuff to 2.32 is not easy,  IÂ wonder if we should back port the switch to gcloud
<pedronis> otoh it might be travis network issues
<zyga> I can try
<pedronis> anyway:   this is not fun:  https://travis-ci.org/snapcore/snapd/builds/364488153?utm_source=github_status&utm_medium=notification
<mup> PR snapd#5018 closed: overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps <Squash-merge> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5018>
<pedronis> so backporting 5018 requires  the new api stuff, or a rework of the backend_test changes
<mvo> pedronis: new api because of tests
<mvo> pedronis: ? or because of the functionality?
<mup> PR snapcraft#2061 opened: go: only use Go build package if not using the snap <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/2061>
<pedronis> mvo: because of tests
<pedronis> mvo: backend_test.go is very different
 * mvo nods
<pedronis> mvo: given that the plan is still to land the new api, IÂ will prepare a backport on top of 5002 , instead of a direct one
<pedronis> mvo: anyway we have troubles atm with tests on 2.32 because they still use linode and there seems to be travis->linode or linode problems
<mvo> pedronis: yeah, porting to google seems like a good idea
<mvo> zyga I got a report about snapd leaking threads, apparently for longer running snapd on bionic "ps -eTf|grep snapd" report very high numbers (in the 400s) for some people on bionic when it runs for ~2-3 days - you run bionic as well, is this something you see too?
<cachio> mvo, CE has approved 32.3 to stable
<zyga> Oh
<mvo> cachio: brilliant!
<zyga> No but i restart snapd for testing
<mvo> cachio: so once the store is ready lets push it out :)
<mup> PR snapd#5022 opened:  overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5022>
<mvo> cachio: and fingers crossed for tihs version
<cachio> mvo, sure
<mvo> zyga: yeah, same here
<mvo> pedronis: thanks for this PR!
<mvo> zyga: no worries, I try to gather more data
<pedronis> mvo: I'll try  to make a PR for 2.32 with just the systems stanza from master, not sure if we need other changes
<pedronis> I mean backends
<mvo> pedronis: +1
<thresh> is snapcraft.io down?
<mwhudson> thresh: looks like it
<thresh> hopefully nothing serious then
<mwhudson> thresh: i've pinged a sysadmin
 * mwhudson goes to bed
<thresh> many thanks!
<popey> https://status.snapcraft.io/ is handy fwiw
<thresh> (I firstly assumed it's the nation-wide firewall that blocks the way here, but oh well)
<mup> PR snapd#5023 opened: spread.yaml: try to switch to run tests on gcloud <Created by pedronis> <https://github.com/snapcore/snapd/pull/5023>
<pedronis> let's see ^
<zyga> pedronis: thank you
<zyga> sorry for not doing it before, I just got home now
<zyga> I need to file some time off for today
<zyga> the vet visit and other stuff was more walking than working
<pedronis> it might not work
<pedronis> IÂ don't know if it we have other changes that were needed
<pedronis> we'll see
<zyga> pedronis: hmm, perhaps something in run-tests.sh?
<pedronis> I don't know
<pedronis> ah true
<zyga> actually run-checks
<zyga>     spread google: linode:
<mborzecki> wrote a test to check if the logging through journal stream sockets works correctly, and it's failing radomly because the journal is not flushed yet :/
<zyga> that's closer to master now
<zyga> mvo: is there a report for the thread leak issue?
<zyga> mvo: on my artful desktop I see this:
<zyga> zyga@fyke:~/go/src/github.com/snapcore/snapd$ ps -eLf | grep '[s]napd' | wc -l => 23
<zyga> mvo: I am seeing this on my bionic laptop
<zyga> zyga@t470:~/go/src/github.com/snapcore/snapd/cmd$ ps -eLf | grep '[s]napd' | wc -l => 122
<zyga> over 100 more threads
<zyga> even though the deskop is a 8 core machine and the laptop is a 2 core machine
<mup> PR snapd#5024 opened: systemd: add helper for opening stream file descriptors to the journal <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5024>
<mborzecki> zyga: ps -eLf | grep '[s]napd' | wc -l => 36 on CPU(s): 16
<zyga> mborzecki: on arch or ubuntu?
<Chipaca> oh snap, lunch
<mborzecki> arch
<zyga> interesting, that's golang 1.10?
<mborzecki> 1.10.1
<mborzecki> package version is 2.32.2.r508.g629585a3f-1, let me rebuild the latest master
<pedronis> Chipaca: there's a meeting in 10 minutes
<zyga> same as in bionic (apart from probable patches)
<mborzecki> pedronis: standup @ 3pm right?
<Chipaca> pedronis: yeah. running.
<Chipaca> mborzecki: yeah, meeting is about epochs
<pedronis> mborzecki: yes, this is something else
<mborzecki> okok
<zyga> ah
<zyga> uff :)
 * Son_Goku groans to life
<Son_Goku> zyga, you should be able to re-enable fedora in CI now
<zyga> Son_Goku: we already enabled and merged it
<zyga> mborzecki: reviewed
<mborzecki> zyga: thanks
<mborzecki> heh, gofmt -s did not catch this
<zyga> mborzecki: 5003 reviewed
<mborzecki> zyga: ta :)
<mborzecki> off to pick up the kids, be back for standup
<zyga> cachio, mvo: 2.32.3 stable today?
 * zyga installed the new "communitheme" snap
<zyga> it's pretty neat, so the snap is a dumb data carrier
<zyga> and something in the desktop is picking up the snap's presence
<cachio> zyga, yes
<cachio> It should
<zyga> mvo: interestingly the number of threads is pretty stable, after reboot I see 114
<zyga> reading snapstore docs
<zyga> why is "sudo snapstore config store.domain="<domain>"" used over "snap set snapstore store.domain=...
<mvo> zyga: 114? I just have 12 here, let me try in a clean VM
<zyga> mvo: yes, this is vanilla beta
<zyga> er, sorry, that's vanilla edge
<mvo> zyga: I will try chocolate edge then
<zyga> I wish golang tweaked each thread cmdline buffer to indicate what is going on
<mup> PR snapd#5025 opened: interfaces/shutdown: allow calling SetWallMessage <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/5025>
<mup> PR snapd#5012 closed: snap: fix `snap advise-snap --command` output to match spec <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5012>
<ogra_> niemeyer, not sure if we have something like this on any snapd TODO yet ... (would be nice to have) https://forum.snapcraft.io/t/support-ask-for-reboot-via-sapcraft-yaml-and-snapd
<ogra_> niemeyer, heh, i guess we can merge that one with https://forum.snapcraft.io/t/allow-automatic-reboots-when-refreshing-a-snap/4935 (seems abeato and I had the same idea )
 * Chipaca will be a couple of minutes late to the standup (previous meeting overrun and I need a technical stop)
<zyga> Chipaca: ack
<zyga> jdstrand: are we going to use the stash directory approach
<zyga> jdstrand: or shall we go for the better option directly?
<jdstrand> zyga: I think that is based in part on release timing. that said, since this didn't make 2.32, why not just go for the non-stash approach since it is approved
<zyga> jdstrand: yeah, that sounds good to me, thank you
<zyga> jdstrand: and I can use this immediately then
<zyga> jdstrand: actually, can I merge both
<zyga> I think it's just worth preserving in history
<zyga> I'll merge the 1st approach
<zyga> resolve conflicts
<zyga> and merge the 2nd approach
<zyga> if you don't mind I'd prefer that
<jdstrand> zyga: I don't mind at all. it makes sense to me
<zyga> perfect, thank you
<niemeyer> It's quite unbelievable.. I just spent more than 10 minutes trying to join the meeting from an Android phone.. no go
<niemeyer> Any hangout links send me to the application.. the application doesn't know what to do with it
<niemeyer> zyga: How did you manage to join yesterday?
<niemeyer> Anyway.. see you soon
<zyga> niemeyer: I have an iPhone
<zyga> niemeyer: maybe we can dial you in with good old phone number
<zyga> one sec
<niemeyer> zyga: That's even more ironic
<niemeyer> zyga: Can you send me a direct invite maybe?
<zyga> niemeyer: I tried to dial you in from the hangout
<zyga> but that doesn't work because we're out of credit
<zyga> yes, sure
<niemeyer> Hangouts seems able to do one-on-one.. maybe with an invite it'd wake up
<zyga> sent
<katnip> which hangouts
<katnip> from G Suite?
<niemeyer> It joined, and then the phone rebooted /o\
<niemeyer> zyga: Thanks, I'll continue the trip.. next time I'll use the laptop tethered
<zyga> niemeyer: you connected for a se
<zyga> you're still connected here
<zyga> can you hear us?
<zyga> ah
<zyga> I just noticed your phone rebooted :?
<zyga> man, that's not fun
<mup> PR snapd#4868 closed: cmd/snap-update-ns: add secure bind mount implementation for use with user mounts <Squash-merge> <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4868>
<zyga> mvo: https://docs.ubuntu.com/snap-enterprise-proxy/en/install
<mup> PR snapcraft#1992 closed: tests: run integration tests on trusty <Created by elopio> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1992>
<mup> Bug #1620755 changed: x509: certificate signed by unknown authority <certificate> <proxy> <Snappy:Won't Fix> <https://launchpad.net/bugs/1620755>
<mvo> zyga: thank you
<diddledan> jdstrand: you're my hero today :-) webtorrent-desktop appears to be unblocked now thanks to confinement rules updates
<jdstrand> diddledan: nice! :)
<Chipaca> mvo: pedronis: fwiw I SIGQUITed snapd when it had 18 threads, and it only had ~4 goroutines
<mborzecki> interesting
<Chipaca> myeah
<Chipaca> next I'll run it with the tracer and see what that says
<mborzecki> then what are the other threads doing? :)
<mvo> zyga: how many goroutines do you have if you SIGQUIT your 100ish threaded snapd?
<mborzecki> afk, taking my son for a vaccination :/
<zyga> One sec
<zyga> mvo: o, so just pkill SIGQUIT snapd
<mvo> zyga: yeah
<zyga> ok, done
<zyga> I see tons of debug in journal
<zyga> and I see 10 threads now
<zyga> mvo: https://pastebin.ubuntu.com/p/kKkGJp2Hbb/
<Chipaca> zyga: can you 'grep -c "goroutine [0-9]"' that?
<zyga> kwi 10 16:02:58 t470 snapd[1943]: goroutine 234 [syscall, 110 minutes]:
<zyga> one sec
<Chipaca> it seems go keeps the threads around once it's done with them
<Chipaca> which makes sense :-)
<zyga> 114
<Chipaca> zyga: whoa
<Chipaca> zyga: is this reproducible?
<zyga> yes
<Chipaca> zyga: can you patch your snapd to run with the tracer, then?
<zyga> it looks like most of this is read from htt
<zyga> http
<zyga> just tell me how sir
<Chipaca> zyga: http://paste.ubuntu.com/p/PstYvgMygh/
<Chipaca> zyga: then run it (make sure it doesn't re-exec :) ) and when it gets to have that many threads, ctrl-c it
<zyga> k
<Chipaca> zyga: and put the /tmp/snapd.trace file somewhere :-)
<Chipaca> (maybe compress it first)
<mvo> zyga, Chipaca interessting, thats a lot of stuff
<Chipaca> yus
<zyga> patched snapd, disabled reexec
<zyga> 15 threads
<kyrofa> mwhudson, sorry, I was EOD by the time you pinged me, but yes, happy to talk about it!
<zyga> _obviously_
<zyga> I'm watching the number of threads
<zyga> installed a snap to do some activity
<zyga> interesting
<zyga> I installed tizonia
<zyga> refreshed lxd to different channel
<zyga> and I'm at 19 now
<Chipaca> in that dump from your sigquit you've got a lot of things stuck on read
<zyga> refreshed lxd back to stable, still 19
<zyga> yes
<Chipaca> from (*ucrednetConn).Read(
<Chipaca> I wonder if anything's changed with 1.10, there
<zyga> hmmm https://www.irccloud.com/pastebin/JFpqggZU/
<zyga> is this expected
<zyga> there's no core restart anymore
<zyga> I stopped snapd.socket,service
<zyga> started snapd manually with sudo
<zyga> this is on master + the patch from chipaca about tracing
<Chipaca> zyga: restart is done by systemd, not us
<zyga> are we opening the snapctl socket ourselves?
<Chipaca> zyga: snapd just goes away and comes back
<zyga> Chipaca: but I don't refresh core now
<zyga> Chipaca: and reexec is off
<Chipaca> zyga: you're running snapd in another terminal, by hand, yes?
<zyga> yes
<Chipaca> zyga: what does the other terminal tell you :-)
<zyga> 2018/04/10 16:14:11.222937 handlers.go:189: cannot get state of snap "no state entry for key": %!s(MISSING)
<zyga> that's fun
<zyga> rest of the snapd output https://www.irccloud.com/pastebin/Wyuc0qHX/
<Chipaca> zyga: you're running with debug on, yes?
 * Chipaca looks
<zyga> no :)
<zyga> sorry, just regular
<zyga> but that handlers.go thing is a clear bug
<Chipaca> zyga: https://github.com/chipaca/bin/blob/master/run-snapd-srv
<zyga> man, ignore me
<zyga> that's an old build
<mup> PR snapd#5025 closed: interfaces/shutdown: allow calling SetWallMessage <Created by alfonsosanchezbeato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5025>
<zyga> it's working on actually patched and compled snapd
<zyga> *compiled
<zyga> but still 17 threads
<kyrofa> mwhudson, ah, I see you forum post now
<zyga> and wayland crashed
<zyga> I wish gnome-shell would not log errors every other second
<Son_Goku> zyga, so looks like RHEL 7.5 arrived
<Son_Goku> and with it, apparently GNOME was rebased to GNOME 3.26
<Son_Goku> I'll have to check and see if all the components of GNOME were rebased
<zyga> mvo, Chipaca: no idea why the snap from core has all those weird threads
<zyga> and this one does not
<zyga> golang 1.6 vs 1.10.1?
<zyga> Son_Goku: are you saying snapd for RHEL can now be a thing?
 * zyga jokes about windows for warships
<pedronis> zyga: 1.6 on different kernel though
<Son_Goku> probably not
<zyga> pedronis: same kernel here
<Son_Goku> but I can certainly try to rebase my current test packages
<zyga> pedronis: I have the 100+ threads if I use the snapd from core
<pedronis> zyga: I'm saying, on  the xenial kernel,  go 1.6 snapd  IÂ don't see tons of threds
<zyga> ah
<zyga> I see
<pedronis> anyway we should really medidate how to stop using  1.6 for the snapd that goes into core
<Chipaca> 1.10 would be nice :-)
<pedronis> well something supported (by upstream) at least
<zyga> pedronis: I think snapd.snap can be built on 18.04
<mvo> zyga: fwiw, I have a bionic vm (and my real system) where I don't see this amount of threads
<zyga> and we sunset 1.6 support
<Son_Goku> zyga: build the snapd.snap on Fedora :P
<Son_Goku> be different :)
<zyga> Son_Goku: well, I do build it on fedora, but people who ship it tell me they need to build it in the archive
<zyga> ok, I'll keep my copy running, I need to get back to coding
<koza> hey, folks what is the forecast on having the 2.32 in the stable channel?
<pedronis> koza: plan is today
<koza> awesome
<mvo> cachio: any word from the store about the release
<cachio> mvo, I'll ask now
<Chipaca> so, an interesting thing is
<Chipaca> once it starts a thread, it doesn't seem to let it go
<Chipaca> (which is probably fine)
<Chipaca> but the threads aren't doing anything
<Chipaca> that is, in the trace they don't appear as busy
<mvo> cachio: thank you
<pedronis> Chipaca: IÂ looked if we had interesting LockOSThread around, but seems we don't
<pedronis> go itself might though
<mvo> all crazy - i386 adt tests fail because of https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 apparently. just in very non-obvious ways :(
<mvo> I add code
<pedronis> ah
<zyga> mvo: man, that's nasty
<zyga> maybe kernel leaks in apparmor profiles
<zyga> wow
<zyga> man that thread is golden
<popey> jdstrand: brave have a problem with their latest build in edge (19). The previous build works fine. I see an apparmor fail in ibus... https://paste.ubuntu.com/p/gsYkbhX2kQ/
<popey> jdstrand: anything we have seen before, and can help?
<mvo> zyga: yeah, I think there is a leak somewhere in the kernel and its especially bad on i386
<mvo> zyga: because the kernel uses lowmem only for whatever reason there
<zyga> why not on arm?
<mvo> zyga: I want to add a check in our restore code that checks for oom and errors hard
<mvo> zyga: I don't know
<jdstrand> popey: oSoMoN is working on that ibus bug. aiui, it is non-fatal
<mvo> zyga: because right now the error is very indirect and also very unclear why it hangs journalctl
<zyga> if journal is synicing and were OOM (and perhaps swapping already) maybe it is the IO load
<popey> jdstrand: brave coredumps :(
<zyga> but yeah, the memory leak looks like the issue behind it
<mborzecki> Chipaca: yeah, there's just few goroutines doing 'real' stuff, the rest is parked https://paste.ubuntu.com/p/T2WJXWwnPF/
<jdstrand> popey: bluez is nothing to worry about. the /etc/opt/chrome they need to adjust something-- they don't have DAC write access to that anyway. I can add something for /sys/devices/system/memory/block_size_bytes
<jdstrand> popey: it may core dump, but the ibus access is probably not what is causing that. that is coming from a library that doesn't check the return code: https://bugs.launchpad.net/ubuntu/+source/ibus/+bug/1761585
<mup> Bug #1761585: ibus_bus_init does an unconditional call to chmod on $HOME/.config/ibus/bus <amd64> <apport-bug> <bionic> <verification-needed> <verification-needed-xenial>
<mup> <ibus:Fix Released> <ibus (Ubuntu):Fix Released by osomon> <ibus (Ubuntu Xenial):Fix Committed> <https://launchpad.net/bugs/1761585>
<popey> jdstrand: ok
<jdstrand> popey: you can add to the profile: 'owner @{HOME]/.config/ibus/bus/ w,' to prove that to yourself
<jdstrand> popey: you can connect the bluez interface to get rid of that denial
<popey> brave 18 works even with those denials
<jdstrand> popey: you can add: '/sys/devices/system/memory/block_size_bytes r,' to see if that is it (again, I doubt it)
<jdstrand> popey: right, that is what I figured
<jdstrand> popey: the /etc/opt/chrome is possibly interesting. that needs to be $SNAP/etc/opt/chrome
<popey> in brave rev 19 the gui appears then immediately disappears again
<jdstrand> popey: it could be something is going on down in $SNAP_USER_DATA or $SNAP_COMMON such that on first start, things are ok, then on next run they aren't. unless you are saying on first run after a refresh it shows then dies. that might suggest a gl issue
<jdstrand> SNAP_USER_COMMON*
 * jdstrand adds /sys/devices/system/memory/block_size_bytes to list for next batch of updates
<popey> jdstrand: I have tested with a clean install (wiped out ~/snap/brave before running)
 * zyga still has just 15 threads
<jdstrand> popey: gl is working ok elsewhere?
<popey> yes, and rev 18 works
<popey> i have also tested 18 vs 19 in a 16.04 VM, same issue.
<popey> https://paste.ubuntu.com/p/PkrmcR7g62/ seeing that lot on console in 19, not in 18
<diddledan> is there a reasonable way of ensuring that xdg reports that the Downloads folder is in $SNAP_USER_COMMON instead of $SNAP_USER_DATA?
<diddledan> this is probably a reasonable thing for many snaps
<popey> For some snaps I set environment: "HOME": "$SNAP_USER_COMMON" in th apps section in the yaml
<diddledan> e.g. why should downloads saved through firefox get versioned?
<diddledan> thanks, popey , I'll try that
<jdstrand> popey: maybe they updated browser_main_loop.cc without considering snapd, or series 16 stage-packages, or something in the desktop part. may need desktop team help
 * jdstrand thought the desktop part setup symlinks from SNAP_USER_wherever to ~/Foo
<diddledan> no the desktop parts can't do that because they might be used on snaps that don't include the `home` plug
 * zyga thinks we should have snapctl is-connected thing
<diddledan> bug. if you specify a remote part that you've not already cached, and try to run `snapcraft update` in the project that includes the remote part in an `after` clause, snapcraft doesn't actually fetch the updated definitions until you remove the `after`
<jdstrand> zyga: if 'is-connected' is about network connectivity, if you add that and it needs some sort of specific access that the default doesn't allow, add it to network-status
<diddledan> https://www.irccloud.com/pastebin/necbNhqK/
<zyga> jdstrand: we have is-connected command already?
<diddledan> ^^^^ that's an attempt to fetch updated remote parts
<popey> jdstrand: ugh, browser_main_loop.cc comes from chromium upstream. oSoMoN have you seen anything like this in chromium recently? https://paste.ubuntu.com/p/PkrmcR7g62/
<jdstrand> zyga: there is an interface that is meant to answer that question. it needs a slot implementation. I'm saying if you make core that slot implementation, add it there
<oSoMoN> popey, no, that doesn't ring a bell
<popey> oSoMoN: ok, thanks!
<zyga> jdstrand: I mean in the "snap connect" sense
<zyga> a way to check if a plug is connected
<zyga> or a slot
<zyga> it would be useful for apps to make simple decisions
<jdstrand> zyga: oh, I thought you meant "am I online". ignore me
<jdstrand> pstolowski probably would know best, iirc
<jdstrand> I thought there were hooks for that, but maybe they are only planned
<zyga> there are hooks
<pedronis> mvo: mmh, it was lost in the other errors but #5021 also needs new api first, because of tests
<mup> PR #5021: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5021>
<zyga> but this means you need to mirror state
<zyga> if we can just ask
<zyga> at runtime, at any moment
<pstolowski> zyga jdstrand the hooks executed on connect haven't landed yet; and yes, a way to check if a plug/slot is connected via snapctl would be nice
<skomorokh> Aha, here you are. FYI, it wasn't super clear on the webpage that this is the channel (so I wound up guessing wrong a couple times with #snapcraft and #snap)
<pedronis> mborzecki: I reviewed your 'system' key in config defaults PR
<mvo> pedronis: thank you! ok, so lets land the new api soon (once we got the stable out without issues :)
<JonelethIrenicus> any steam snaps
<skomorokh> Is there an FAQ for curmudgeonly debian types that have questions/paranoia about telemetry/tracking/fingerprinting and the like?
<kyrofa> skomorokh, haha, no, but perhaps there should be!
<kyrofa> Do you have any specific concerns?
<skomorokh> I trust Canonical more than Slack/Microsoft/Google so would like to switch to using snaps vs. vendor-supplied .debs ...excecpt now  I wonder what this snapd is doing and what it's telling this central service about me :)
<kyrofa> skomorokh, well, would looking at the snapd source code make you feel better?
<zyga> skomorokh: there's a few things we tell
<zyga> skomorokh: like /etc/os-release level info
<skomorokh> I'd prefer an executive summary.
<zyga> and the snaps you refresh
<JonelethIrenicus> snap uses apparmor
<zyga> and the version of snapd
<skomorokh> Can it tell I'm the same user that installed a package last week?
<zyga> skomorokh: we have some extra data sent when something fails (apparmor style error reporting) but this is configurable (PR is up for that)
<skomorokh> eg. is there an identifier tying my usage of the system together?
<zyga> skomorokh: yes, I believe it uses /etc/machine-id (needs checking)
<skomorokh> Is that optional?
<zyga> skomorokh: plus, if you log in that's that
<zyga> I don't believe that's optional but I honestly don't remebmer
<kyrofa> zyga, what is the use-case for the unique identifier?
<zyga> I need to check if we really send that
<zyga> maybe I'm mistaken
<zyga> sorry
<skomorokh> First thing I did was go to replace my slack deb with a slack snap, only to have it tell me I have to pass it a parameter to let it run unconfined.
<zyga> we don't send that
<skomorokh> Yay! I'm happy you don't!
<nacc> skomorokh: right slack is a 'classic' snap still
<skomorokh> And while I'm sad I can't sandbox slack out of the box, I'm happy that it told me it wants to be unconfined.
<zyga> but we do use it
<zyga> when an error happens
<zyga> we hash the machine id
<zyga> and send that hash
<zyga> but error reporting is optional
<kyrofa> zyga, I didn't know snapd had error reporting. Is it enabled by default?
<kyrofa> How does one opt in or out?
<zyga> kyrofa: yes, it is enabled by default but that may change soon
<skomorokh> Is snapcraft.io optional? eg. can I use a different hub?
<pedronis> kyrofa: it will follow whoopsie settings
<zyga> kyrofa: this goes to the ubuntu error tracker
<pedronis> at least on ubuntu
<kyrofa> Ah, okay
<zyga> and some people can see statistics
<zyga> we used it a few times when bugs caused widespread errors in the field
<zyga> and we were ignorant to that before we had the error tracker data
<zyga> skomorokh: there's no hub in snapd, there's a store and each machine talks to exactly one store
<mup> PR snapcraft#2062 opened: packaging: simplify snapcraft.yaml <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2062>
<zyga> stores are configurable but you will realistically still only use either the official store or your private deployment of a store proxt
<pedronis> kyrofa: it's not for all errors, or errors from snaps,  is really errors on refresh or install
<pedronis> of snaps
<zyga> yes, it's when snapd malfunctions really
<skomorokh> Is the code for the store public?
<zyga> no, it is not
<kyrofa> Whenever snapd panics, I expect
<skomorokh> Aw. So if you turn evil or something the OSS community can fork away :(
<skomorokh> *can't
<kyrofa> skomorokh, note that all the APIs are documented
<zyga> it's a matter of implementing the store side and starting a new root of strust (store is a root of trust in the snapd model)
<zyga> so if we turn evil, there's some hope still ;-)
<mup> PR snapd#5026 opened: tests: add check for OOM error after each test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5026>
<skomorokh> Right, but that's a big barrier, implementing that whole stack!
<skomorokh> Or is it? I've only been thinking about snaps for a handful of minutes, maybe the store is quite lightweight?
<mborzecki> pedronis: thanks
<zyga> skomorokh: but also big advantage of having one place where apps come from, with sane securty, comprehensive snadbox (it's always something that can improve but I think we're doing pretty well)
<zyga> skomorokh: I think it depends on one's perspective
<skomorokh> Oh, I like that, that's why I want to use it.
<skomorokh> I just want the option for the community to bail on you without starting over.
<zyga> skomorokh: there are a few URLs we use to search, query and download snaps and assertions
<skomorokh> Everyone maintaining snaps is investing into the ecosystem.
<zyga> but I'm not an expert in that area
<zyga> I think that option is there, if there's desire someone can always fork snapd, implement some simple store, deploy it and update the store URL
<zyga> not saying it's easy but it's not impossible either, snapd is complex in general
<skomorokh> I see snapd is developed in public.
<zyga> having a store that scales, etc is another thign
<zyga> yes
<zyga> all work, code and design is public
<skomorokh> I think that'd make it easier, having the commits, the issues, etc.
<zyga> I'm a developer that works on execution layers for example
<skomorokh> So I think being able to search the store counterpart would help.
<zyga> snap find ...
<zyga> funny that "snap find foo" finds so many foo snaps :)
<skomorokh> I mean, search the history of development communications around the store too the way we can by searching snapd issues.
<zyga> ah I see
<zyga> well, store is not publuc
<skomorokh> Ya exactly :)
<zyga> most of the store changes are coming directly from snapd
<zyga> and can be found in the snapd history
<zyga> plus there's a lot on forum.snapcraft.io
<noise][> and there is discussion on store features https://forum.snapcraft.io/c/store
<popey> The click store that pre-dates it wasn't either. The community founded an "open store" which has now taken over on Ubuntu phone.
 * zyga hugs noise][ 
<zyga> thank you!
<skomorokh> Interesting.
<popey> When Ubuntu Phone was dropped, the community rallied and have built a pipeline for apps in the open store
<noise][> also, you can always side-load snaps without a store
<popey> It's more active now than when we maintained it ;)
<zyga> popey: do you know I still use my reall retail ubuntu phone
<skomorokh> 'cause so far I'm convinced I want to use this because it feels more trustable than dpkg which is basically "here's root, go nuts"
<zyga> I still have it, it's running ubuntu with the open store
<noise][> you lose benefits but it's there as an option
<popey> zyga:  me too :)
<skomorokh> But I'm not quite convinced I want to _advocate_ for it and maintain snaps etc.
<zyga> skomorokh: yes, the sandbox is very interesting
<popey> I have a bq 4.5 on my desk, updated it today
<zyga> skomorokh: I'm also familiar with the sandbox in case you have questions
<skomorokh> zyga: Can I sandbox things that don't want to be sandboxed?
<popey> skomorokh: I work on the developer advocacy side. I'd welcome your feedback if you did look at making a snap.
<zyga> skomorokh: try making some software and ensuring it is up-to-date (yourself) in 3 most common distros (and maybe 2-3 older releases that still have users)
<zyga> skomorokh: then look at snaps again :)
<zyga> it's a godsend
<popey> skomorokh: we're always looking for people outside the project who have snapped something, to give us honest critical feedback.
<zyga> jdstrand: do you want one last look at https://github.com/snapcore/snapd/pull/4957 before I merge it
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<skomorokh> Well, so far I'm leery about investing myself that much in it because the store is closed.
<zyga> skomorokh: well, use it, try some snaps
<zyga> skomorokh: package something, learn how that works
<zyga> skomorokh: see how the interface systems looks like
<skomorokh> I understand why it makes sense to have it centralised, but it feels sketchy to have something so closed aspire to become central to OSS
<zyga> skomorokh: how the sandbox looks like
<zyga> there's tons of great stuff in snapd
<jdstrand> zyga: LGTM
<zyga> thanks!
<jdstrand> please commit
<zyga> skomorokh: then people say how great android is because android is linux, this is way way way more open
<zyga> for one,you can commit here
<zyga> we don't throw code over the wall once in $RELEASE_CYCLE
<zyga> you can discuss with the devs, not with press people
<skomorokh> Good points!
<zyga> you can influence the design, the code, everything really
<zyga> there are business points (store) but that's actually good, it means it can sustain itself
<zyga> it's not going to spy on you to make that money
<popey> skomorokh: like github? :)
<zyga> and unlike other solutions it is more complete
<zyga> it's not limited to some class of apps
<skomorokh> popey: Quite, hence gitlab :)
<popey> :)
<zyga> and doesn''t have hand-wave'y "optional security" that nobody actually uses and is actually not strong and sensible security
<skomorokh> firejail is just handwavey?
 * zyga made terrible allusions to other packaging systems
<zyga> use of firejail with <something else> is very handwave'y
<zyga> and note one thing: the instruction on how to confine an app comes with the app
<zyga> that's not useful
<zyga> that's 15.05 snappy 1.x design
<zyga> and it doesn
<diddledan> I'm still randomly getting "invalid association handle" whenever I try to login to build.snapcraft.io via ubuntu sso
<zyga> and it doesn't scale or work really
<zyga> oh, and it is optional, so nobody uses it really
<zyga> compare that to snapd sandbox and interface system, where everyone gets the same predictable non-optional sanbox
<zyga> and there are well-defined ways to extend it
<skomorokh> except slack gets to opt out and run as root
<skomorokh> (which it wonderfully tells me about!)
<zyga> where well-defined is that each snap uses the same definition, users can learn what that means
<zyga> yes, but that's not sandboxed really
<skomorokh> can I tell it to sandbox anyway?
<zyga> and it's very honest about it as you noticed
<zyga> yes but most software that requests this won't work
<zyga> you can snap install --jail slack
<zyga> er
<zyga> --jailmode
<zyga> it will just put it in a regular sandbox
<zyga> but slack won't work then
<zyga> eventually slack may opt into confinement
<skomorokh> slack is just electron going to their webpage + stuff for facilitating the tray icon ya?
<zyga> but they have not yet
<zyga> I honestly don't know
<skomorokh> Hm, so if I get really enthusiastic about snap and spend a bunch of time building a slack image that works in confined mode, can I publish that somehow?
<skomorokh> I assume I can't redistribute their software, but can I maintain a patch to their packaging that lets me lock it down?
<diddledan> hmm, who has registered the name `webtorrent-desktop` in the store? have they actually used that name at all or can snapcrafters nab it? :-p
<zyga> skomorokh: yes, but it won't be called "slack", it would have to be something else
<zyga> plus, I don't know if you have the right to modify their application
<zyga> but you can install it on your machine, yes
<zyga> sure
<zyga> is *this* _supported_ in this __client__ **maybe**?
<zyga> no
<zyga> diddledan: how did you format webtorrent-desktop?
<zyga> maybe like `this`?
<zyga> yes
<zyga> ah, nice
<popey> diddledan: it was registered back in june 2016
<popey> diddledan: no uploads.
<diddledan> is it owned by upstream or a random passer-by?
<zyga> skomorokh: plus, snappy is pushing some boundaries, it's a very fun project to live in
<popey> diddledan: upstream
<zyga> from kernel side to linux desktop technology
<diddledan> if it's upstream then I'll just file a PR against their repo and they can publish directly, but I wanted to get something out
<popey> Feross registered it
<noise][> diddledan: appears to be upstream
<diddledan> right-oh, I'll just file a PR against their repo then :-)
<diddledan> thanks
<skomorokh> How do snaps persist their local configs? They can access my home directory from their confinement?
<zyga> skomorokh: there are more nice features that you may not know about (channels are so obviously missing from classic packaging)
<zyga> skomorokh: snaps get their private place for storing data, that's $SNAP_DATA, $SNAP_USER_DATA
<zyga> skomorokh: for services and apps
<zyga> skomorokh: there's also SNAP_COMMON and SNAP_USER_COMMON for specialized use-cases
<zyga> skomorokh: snaps don't see the real HOME variable so they have a mini-home elsewhere
<zyga> skomorokh: that's in your real $HOME/snap/$SNAP_NAME/$SNAP_REVISION/
<skomorokh> So it copies my configs between versions as it updates?
<zyga> skomorokh: snaps can read and write to most of your regular home if they use the "home" interface (run "snap interface home")
<zyga> skomorokh: yes
<zyga> skomorokh: we are working on integrating desktop portals so that portal-aware apps can use them too
<skomorokh> Nice, so I can rollback to my previous config if I have issues with the new version. Does it clean up old ones or just suck up infinite space over time?
<zyga> (so typical GTK apps will use portals for opening files from arbitrary places, under user's explicit choice)
<skomorokh> Can I protect sensitive parts of my home directory eg. exclude ~/.ssh from the "home" interface?
<zyga> skomorokh: that's done by default
<zyga> skomorokh: all dot-files are off-limits
<skomorokh> Ah, nice.
<skomorokh> But not for classic, it does w/e?
<zyga> no, classic confinement == no confinement
<zyga> like in "classic linux systems"
<skomorokh> Ya, so there's no light jail to give a false sense of security, it's proper confinement or no.
<skomorokh> Seems sensible.
<zyga> skomorokh: for instance this is the whole definition of the home interface: https://github.com/snapcore/snapd/blob/master/interfaces/builtin/home.go
<skomorokh> Oh sweet, it's go!
<zyga> yes, we are trying not to run large complex C apps as root
<zyga> you can see all the other interfaces here: https://github.com/snapcore/snapd/tree/master/interfaces/builtin
<diddledan> ok, PR filed against webtorrent-desktop: https://github.com/webtorrent/webtorrent-desktop/pull/1353
<mup> PR webtorrent/webtorrent-desktop#1353: add snap packaging <Created by diddledan> <https://github.com/webtorrent/webtorrent-desktop/pull/1353>
<skomorokh> Oh man, this is so close to everything I hoped it would be.
<popey> diddledan: nice one!
<zyga> interfaces cannot be added by apps so nobody will add "all access to everything" interface in a note taking app
 * diddledan crosses his toes
<skomorokh> So I tried a snap, figured okular is a good one because it didn't want classic and so my pdf viewer is going to get some confinement.
<skomorokh> Which is nice because it's handling random stuff from the internet so it's attack surface.
<skomorokh> 'cept I can't purge okular's deb since kubuntu depends on it.
<cachio> mvo, so far so good, 2.32.3 is stable now and smoke test passed
<skomorokh> How do I tell it to prefer the snap? Does this tie in to update-alternatives?
<nacc> skomorokh: /snap/bin in your PATH
<nacc> skomorokh: that's provided by snapd into /etc/profile.d on Ubuntu
<skomorokh> But not early enough since which okular is still showing /usr/bin
<nacc> skomorokh: is /snap/bin in your PATH?
<skomorokh> I assume it based on what you say.
<nacc> skomorokh: are you on ubuntu?
<skomorokh> Yup, kubuntu 17.10
<nacc> skomorokh: easy enough to check, to be sure, of course
<nacc> skomorokh: /snap/bin is the last entry in PATH, iirc, so if you want to prefer snaps over debs, you need to edit the profile
<zyga> cachio: good
<zyga> skomorokh: hash -r
<skomorokh> Ya, exactly. And I've confirmed.
<zyga> skomorokh: which okular
<nacc>  /etc/profile.d/apps-bin-path.sh
<zyga> skomorokh: you can always "snap run okular"
<zyga> snap run --help has some extra options
<skomorokh> heh, I need to connect it to more snaps.
<zyga> skomorokh: play, explore, learn ask
<zyga> welcome to the community!
<skomorokh> Thanks! I definitely do feel welcome.
<skomorokh> And I really appreciate the project, it's going to help make Linux easier to adopt for less technical users.
<skomorokh> Plus help everyone be more secure.
<zyga> and everyone can be in one boat of apps
<zyga> not in fractured silos
<zyga> chihchun_afk: hey
<zyga> oh you're afk
<skomorokh> That's got pros and cons.
<zyga> mborzecki: around?
<zyga> I'd like a 3rd review for https://github.com/snapcore/snapd/pull/4957
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<zyga> skomorokh: snaps complement classic packages so each distribution can still innovate by itself
<zyga> but innovation doesn't zero the app counter
<skomorokh> And that's why I would hope there is more transparency around the store if it really does have a chance of being a central hub for OSS app developement.
<zyga> and innovation doesn't mean apps need to be re-packaged every 6 months or whatever the release cycle is
<zyga> oho, storm is coming
<skomorokh> So I have a suggestion for the monetisation... I can't buy software with it because then I'd need to register an account with the snapd on my computer at which point I'm tying my behaviour to my identity.
<zyga> skomorokh: when linux is 1% of your userbase, the last thing you want is to spend x5 effor to cover ubuntu, fedora and maybe something else
<skomorokh> But I'd love to login to my account in a browser and conveniently contribute money to a project.
<zyga> skomorokh: how would you then tell snapd that you can use a for-pay snap/
<skomorokh> I never will, for that reason.
<skomorokh> Just like I subscribe to the guardian but don't login to my account.
<zyga> but the guardian is available anyway
<zyga> (I also subscribe btw :)
<zyga> if a snap is free you can already use it
<skomorokh> Right, that's why I subscribe ;)
<zyga> note that the buy story is still in wraps
<zyga> and there's plenty of room for improvement
<skomorokh> I don't subscribe to papers I can't read without subscribing because then they learn what articles I read (hell, they learn how I move my mouse while I'm reading the article)
<skomorokh> Is there any risk that associating an account with snapd will become mandatory?
<skomorokh> I imagine there'd be some pressure to do that...
<zyga> no, I doubt that
<nacc> don't you already have to login to snapd?
<zyga> it used to be
<zyga> but we made it optional now
<nacc> ah ok
<nacc> zyga: good to know, thanks
<zyga> it was just a matter of work, it's a 2.0 but still pretty early stages
<skomorokh> That's a good direction but kinda worrisome it was ever like that.
<zyga> it was like that because we didn't have polkit support and other things
<zyga> again, very early days back then
<zyga> you could always use sudo to do stuff
<skomorokh> Even at a cursory glance it's clear this is a massive engineering effort.
<zyga> ah, sorry, my memory is rusty
<zyga> sudo was since forever
<zyga> authorization was needed in GUI apps before we had polkit
<zyga> now it's fully optional
<zyga> because GUI apps are regular users (not root) talking to snapd
<zyga> so there was no way to prove you can install / remove apps
<zyga> when you sudo snap stuff we use peer credetnials over the socket to konw
<zyga> *know
<zyga> so that's why we had to login to the store
<zyga> because once logged in you'd get a polkit prompt from the GUI and authenticate
<zyga> and that was used as proof
<skomorokh> Heh.
<zyga> now it's all history
<skomorokh> Can I selectively deny interfaces?
<skomorokh> Awww vscode is classic too ;(
<zyga> skomorokh: you can disconnect them
<zyga> skomorokh: there's a forum thread about why IDEs are classic currently
<skomorokh> ty, I'll look for that.
<zyga> there's some missing technology to make them strict still
<zyga> (without making them useless)
<zyga> skomorokh: once you disconnect an automatically connected interface it won't auto-connect on that snap again
<zyga> skomorokh: we have a policy system so that powerful interfaces are not auto connected
<zyga> skomorokh: and some cannot even be declared at all
<zyga> skomorokh: each snap has an assertion that is issued by the store
<zyga> skomorokh: the assertion can grant access to some powerful interfaces on a per-snap basis
<skomorokh> Can I install something without it ever being allowed to use an interface?
<zyga> skomorokh: this is why you can install LXD as a snap
<skomorokh> So even if it might be autoconnected I can choose to not let it be?
<zyga> skomorokh: no, we don't have that right now, what would be your use case?
<zyga> skomorokh: if it's about home that is a transitional interface that will be phased out over time
<zyga> skomorokh: it's a matter of getting portals and momentum to use them
<zyga> skomorokh: note that home is only auto-connected on "classic" devices (classic that they use regular packages as well)
<zyga> skomorokh: on core devices (that only use snaps for everything on the system) this is no longer the case
<skomorokh> Hypothetically I want to use vscode but want to be sure that Microsoft never learns that my current IP used it.
<zyga> skomorokh: I see, well, network is granted by default so I don't think there's a way today
<skomorokh> If it autoconnects to the interface that lets it connect to the internet, it alerts them that my IP uses it.
<skomorokh> Whereas if I can snap install vscode --without-interface=internet
<zyga> skomorokh: I'm not saying no, just that it's not a feature today
<zyga> you can open a forum thread about it
<skomorokh> The main reason my IDE would ever need to use the internet is updating, and if snap does that for me, tada!
<popey> well, no
<zyga> we can discuss it with the security team and with designers
<popey> most modern IDEs have plugins
<popey> vscode included
<zyga> yeah
<skomorokh> Yah, I know, vscode especially, actually.
<zyga> sadly modern IDEs are pretty much mini-OSes (without confinement between plugins)
<popey> vscode will go and get (for example) golang components when you're editing .go files
<skomorokh> That's why this is a hypothetical.
<skomorokh> But it's the one that came to mind.
<zyga> I'm very much waiting for the first real attempt at a code editor with untrusted plugins
<zyga> with proper sandboxing
<popey> vscode oss is built without those features
<zyga> it's a ticking time bomb
<popey> so you could use that instead
<skomorokh> However, if I was cool with just using the ones it came with, I'd like to be able to --without-internet it.
<zyga> skomorokh: you can install it
<zyga> skomorokh: disconnect network
<zyga> and then run it
<popey> unplug the network cable and snap diconnect network
<zyga> note that if it had a confiugre hook or other install hook it would execute by that time
<zyga> *configure
<skomorokh> Ya, that's not making this super convenient though.
<zyga> you can also make a network namespace
<zyga> and run vscode there
<zyga> I think it's a better solution for networking specifically as you have full control
<skomorokh> Yeah, I'm interested in transparency as to what my applications do on the internet.
<skomorokh> If snap is partitioning them somehow that I can differentiate which apps are generating which traffic that'd be neat.
<skomorokh> Like an alias interface per snap so I can wireshark vscode alone?
<zyga> snapd doesn't use the network namespace so networking is "real"
<skomorokh> Aw. Well, one thing at a time. Is that an eventual goal?
<zyga> no, that's not a goal now
<zyga> maybe eventually but we have plenty of things to do for now
<kyrofa> skomorokh, you want this:
<kyrofa> https://forum.snapcraft.io/t/autoconnection-override/2465
<kyrofa> zyga, install and then disconnect doesn't cut it-- daemons are fired up first
<zyga> yes, I agree
<zyga> we have the way to represent that now
<zyga> so it's just a matter of designing and making the UI
<zyga> "UI"
<skomorokh> (Just checking, that's overriding that you can represent just have no UI ...not per-snap network usage?)
<zyga> skomorokh: not specific to network
<zyga> skomorokh: you can put some stuff into the "state" /var/lib/snapd/state.json that will tell snapd not to auto-connect a given interface to a given snap
<zyga> state is interesting too
<skomorokh> Does snap use cgroups?
<zyga> skomorokh: yes
<skomorokh> So potentially that could give some visibility into which snap is associated with which network traffic?
<zyga> skomorokh: we use seccomp bpf, apparmor (all of it+more than mainline), device and freezer cgroup
<zyga> skomorokh: we only use the two cgroups I mentioned
<skomorokh> Ohhh.
<skomorokh> So not per-snap cgroup.
<zyga> we have per-snap cgroups
<zyga> but we only use device and freezer cgroups
<zyga> and I don't believe you can do what you want with just them
<zyga> we also use some other things but those are the "main" guys
<zyga> all of the sandbox code is in interfaces/ directory in the tree
<zyga> we use mount namespaces heavily
<zyga> man, I didn't mention that
<zyga> that's like my life now and I didn't mention that
<pedronis> mvo: fyi, all my backport branches are green now,  but we would need to start with 5002 once we feel ok about 2.32.3
<zyga> pedronis: mvo is offline
<pedronis> I always forget there are people that do that :)
<zyga> yeah
<zyga> irc cloud is really great
<skomorokh> Hm, but if all the processes for a snap are in its per-snap group ...it seems like that's all we need is already in net_filter? https://lwn.net/Articles/569678/
<skomorokh> Except it's confusing when you say you have per-snap cgroups but don't use them:
<skomorokh> <zyga> we have per-snap cgroups
<skomorokh> <zyga> but we only use device and freezer cgroups
<zyga> sorry, I meant to say that we only use two cgroup _types_
<zyga> if xtables can do that that's cool, I wasn't aware of that
<zyga> brb, dog.walk()
<JonelethIrenicus> any steam snaps
<popey> JonelethIrenicus: there isn't a steam snap from valve in the store currently.
<skomorokh> lemme guess, --classic?
<zyga> There is a steam runtime snap from ikey
<zyga> WIP but promising and confined
<skomorokh> Niiiice!
<skomorokh> Is the sandboxing relatively new?
<zyga> There is a interface review for steam specifically
<zyga> Depends on which part
<zyga> Some is old, some is still not in mainline
<zyga> Man, this feels like summer
<zyga> So warm outside
<zyga> There was snow all around just a moment ago
<kyrofa> I miss snow
<kyrofa> Spring is the worst
<zyga> The design of the sandbox is new IMO,
<zyga> Whaaaat kyrofa how can you say that
<skomorokh> Ok, so there's hope yet that slack, etc. will provide contained snaps? It's most they haven't got to it and things weren't ready when they first adopted the platform rather than they're refusing to go that way?
<popey> It depends on the ISV
<popey> We're talking to all of them. Some are motivated to get them confined, others are not.
<zyga> I think it depends on the cost for them. If they see the sandbox as a cost for the people that support Linux
<zyga> Itâs all about users
<popey> Worth noting that for some of the really big ISVs Linux represents a vanishingly tiny proportion of their userbase.
<zyga> Confinement has some advantages
<popey> So you get a tiny proportion of their time to work on it.
<zyga> Snaps that are confined run in more places
<zyga> So I think over time classic snaps will be rare
<skomorokh> Well, I'm thinking specifically of slack/vscode so fairly developery things where presumably linux has a larger-than-usual marketshare.
<zyga> Again, begging of the adoption curve, early adopters, etc
<popey> Depends on your definition of large.
<zyga> Yeah
<zyga> Itâs all subjective
<zyga> Linux is not large IMO (and I use it since forever)
<skomorokh> Well, I'd imagine that linux use is an order of magnitude more common in the developer community than the world at large.
<popey> slack-term is in the store and is strictly confined btw ;)
<popey> https://snapcraft.io/slack-term
<katamo> [help please] building my first snap. need to read the output of a `cat` command. getting an error "Error: Can't read from stdin: read /dev/stdin: permission denied" from the cat command. snap was built and installed locally using the "--devmode --dangerous" flags
<zyga> Slack is used by lots of people, not just developers
<katamo> *everything works before being snapped
<popey> katamo: hi, can you point us to your yaml somewhere online?
<skomorokh> Is there a way I can browse snaps like the store but with added info about which are confined and which interfaces they require?
<zyga> katamo:  when you use âdangerous you disable enforcing confinement
<popey> zyga: uh, you mean devmode?
<zyga> skomorokh: gnome software, eventually
<zyga> Yes popey
<zyga> It implies devmode afair
<katamo> skomorokh https://gitlab.com/kat.morgan/ScoutPlane/blob/master/snapcraft.yaml
<skomorokh> zyga: but why would I need an app for browsing a catalogue, seems like a very web-suitable task?
<katamo> *oops popey
<popey> skomorokh: you can browse the store at snapcraft.io/store
<zyga> skomorokh: store front can probably show this too
<popey> skomorokh: not all features of the snap are shown currently, the web site is under constant redesign
<katamo> popey to be specific, line 170 of build-img is failing with the stdin permission error https://gitlab.com/kat.morgan/ScoutPlane/blob/master/bin/build-img
<katamo> popey snapcraft.yaml is here: https://gitlab.com/kat.morgan/ScoutPlane/blob/master/snapcraft.yaml
<skomorokh> Ya, I don't see either of those pieces of info on the store and would hope to.
<popey> skomorokh: yeah, it's not straightforward to expose at the moment
<popey> katamo: lxc config is going to want to poke things in hidden in folders in your home directory, isn't it? That will be blocked by confinement?
<skomorokh> Is there a tool to replicate my snap installs on another machine?
<katamo> popey, hmmmm, good thing to consider. "--devmode --dangerous" would eliminate that for the sake of argument, right?
<skomorokh> Since it's not just a flat list of snaps but also connections...
<popey> skomorokh: not currently.
<katamo> so far, i've been able to do everything with lxd from the snap except that one line
<popey> katamo: hm, I don't know what's going on there then.
<katamo> :/ grr, time for more digging. alrighty
<popey> maybe try the forum for long form Q&A?
<zyga> skomorokh: no, not at present
<skomorokh> popey: Okay, I should get back to work anyhow.
<popey> That's entirely scriptable though. "snap list" and "snap interfaces" on one end and "snap install" and "snap connect / disconnect" on the other
<skomorokh> Thanks a lot for all the welcoming / super patient replies! And ya, epic software endeavour.
<popey> Thanks for the friendly chat :)
<zyga> skomorokh: good day and drop by again :)
<zyga> pedronis: can you please do a 2nd review on https://github.com/snapcore/snapd/pull/5026
<mup> PR #5026: tests: add check for OOM error after each test <Created by mvo5> <https://github.com/snapcore/snapd/pull/5026>
<skomorokh> ooo, actually, before I disappear
<skomorokh> I sync my home dir between three machines using unison
<skomorokh> That shouldn't be any more crazy with snaps, I think, because their local files are in ~/snap/snapname ...no generated uuids or anything
<zyga> yeah
<zyga> you may see some odd issues though
<popey> might be a challenge if the machine apps get out of sync
<zyga> when on machine-a you have snap foo at revision 1
<skomorokh> Does anything leap out at you as likely to blow up?
<zyga> but on machine-b it will refresh and get to revision 2
<skomorokh> Ya, I carefully manage my updates to keep them in sync
<zyga> skomorokh: snaps update automatically
<skomorokh> ...
<skomorokh> Can they not?
<zyga> skomorokh: and you can use "snap revert" to go back to revision you had before
<zyga> skomorokh: you can control when they refresh (very precisely)
<zyga> but we don't want to add a global toggle because the vendors do the silly thing and turn that off and ship devices with no updates, ever
<zyga> and we don't want that
<skomorokh> So I can leave refresh at "never" and set it to "now" when I want updates?
<zyga> no
<skomorokh> It's my computer though :)
<zyga> so we are very opinionated and try very hard to give lots of control without a way to for someone to turn it off forever
<zyga> because then people are the victim of a vendor who does that
<zyga> and most people are really comfortable with that already
<zyga> (not all clearly)
<zyga> it has to be refreshed at least once a month AFAIR
<skomorokh> I'm uncomfortable with how many people are comfortable with that :)
<zyga> you can also deploy an enterprise proxy and tie your specific device to that proxy
<zyga> and control updates through the proxy
<skomorokh> Well, I'm not interested in me.
<popey> I'm uncomfortable with how many people run easily compromised out of date software on the internet
<zyga> skomorokh: it's a tricky balance, if we give the off switch you will read an article about ubuntu routers being insecure and out of date when next major thing happens
<zyga> because someone in china slaps ubuntu on a batch of no-brand machines and ships them for 15$
<skomorokh> True points.
<zyga> skomorokh: so on your private deployment, you can and should use the enterprise proxy
<zyga> skomorokh: if you have a super important snap that cannot break you can buy gating and control when core refreshes so that you are not broken by canonical shipping updated base libraries
<zyga> skomorokh: you can schedule updates to go weekly on Tuesday night
<zyga> but you cannot turn it off because then you would be fine but 1000s of others would suffer
<skomorokh> I just don't like the general notion that end users are so fully conditioned that software is something managed externally.
<skomorokh> That either you are full-time devops and that's your life or you let your most sensitive affairs be managed by one of a small handful of vendors.
<skomorokh> It feels like there is room for a level of autonomy between OS X and Gentoo :)
<skomorokh> At any rate, for my actual use case it sounds fine because I assume I can trigger a refresh on demand? And thus update my laptop to current before I sync things over.
<popey> you can "snap refresh" any time
<petan> some idea? https://pastebin.com/MWSkCdde this crash I get when I run snapcraft :(
<mup> PR snapd#5023 closed: spread.yaml: try to switch to run tests on gcloud (2.32) <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5023>
<mup> PR snapcraft#2060 closed: package: ensure all relevant files are in for sdist <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2060>
<mvo> cachio: yay, thank you
<zyga> hey mvo
<zyga> still trying to release
<cachio> mvo, yaw
<mvo> zyga: we released
<mvo> zyga: its all great!
<zyga> wooooot
<zyga> thank /dev/urandom
<zyga> that's great
<zyga> thank you for getting us here
<zyga> mvo: do you have 3 more minutes?
<mvo> zyga: yeah, not 100%
<zyga> https://github.com/snapcore/snapd/pull/4957
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<zyga> do you want to do a 3rd review
<zyga> it's small
<mvo> zyga: I have a look in a little bit
<zyga> mvo: can I help with anything release-wise?
<mvo> zyga: I think its all good, I will do the SRU in my morning and we need to keep an eye on bugs
<zyga> ok
<zyga> that's .4 that you will SRU
<zyga> or still .3
<mvo> zyga: I hope I will be be able to announce it again later tonight but that is about it
<mvo> zyga: probably .4
<mvo> zyga: I want to have at least the fix for the oom detection
<zyga> .3 is very solid but .4 has a few more fixes and the all new API
<mvo> well "fix"
<zyga> I'm somewhat worried about the new store api there
<mvo> zyga: yeah, then .3+X
<zyga> but I realise it's important
<zyga> mvo: oom "fix" will surely show up in adt
<zyga> so "yay" for working on this bug
<zyga> it was under my radar, I was surprised by how old that thread was
<mvo> zyga: "yay" - really a frustrating day, oom bug, threading explosion and refresh-mode: sigterm not working. oh well, tomorrow will be better
<zyga> is the SIGTERM refresh issue real?
<zyga> that is, it's not an application level bug?
<mvo> zyga: it may be applicatoin dependent
<mvo> zyga: its strange, the strace indidate its real
<zyga> hrm
<zyga> let me know if you want me to look tomorrow
<zyga> it would be a .5
<zyga> and 2.33 would be more off if true
<zyga> but it may mean 2.32 is our first LTS :)
<zyga> and I would welcome that
<pedronis> well, if .4  is just oom, we need .5 soon (that would have been .4)
<pedronis> and then later is .6
<zyga> 2.32.19 is the charm
<zyga> it will also include the YAMA fix ;-)
<pedronis> mvo: so  what was suppored to be .4  will be .5 ?
<pedronis> will .4 be SRU only?
<pedronis> IÂ mean no core build?
<diddledan> ooh. I just spotted that 2.32.3 landed stable
<diddledan> :-)
<mvo> pedronis: I think we will do .4
<mvo> pedronis: and for the sru I do .3.1 or something
<mvo> pedronis: or .3ubuntu1
<pedronis> ok
<mvo> pedronis: just the OOM thing
<pedronis> mostly because IÂ communicated that APIÂ would be in .4
<pedronis> I can communicate again if needed
<mvo> pedronis: yeah, I'm still onboard with that
<mvo> pedronis: I think its fine
<pedronis> mvo: all the backports are green
<pedronis> (still marked as blocked tough)
<zyga> mvo: once .4 is out I will massage a release page
<zyga> and do suse updates
<popey> ooh! 2.32 is out?
<zyga> popey: _again_ :D
<popey> lulz
<zyga> popey: snapd is so cool we can release the same version twice
<popey> Thanks guys!
<zyga> take that classic packages!
<popey> only twice?
<zyga> popey: you only release twice
<mvo> pedronis: \o/
<mvo> pedronis: great that they are green
<pedronis> mvo: I closed the PR about usign google for 2.32
<mvo> pedronis: ok
<mvo> zyga: heh, the PR is small but the amount of discussion is not ;) I check it in my morning
<diddledan> is there any way you know of to prevent the /tmp/$temporary_name files from being deleted when something goes wrong? I'm receiving the message I'm about to paste, but running with --debug doesn't reveal anything further, and the files are gone when I try to investigate what's wrong
<diddledan> https://www.irccloud.com/pastebin/gZMbloyw/
<sergiusens> diddledan: mind trying out `edge`?
<diddledan> ok, gimme a sec
<diddledan> running....
<petan> is there any way to start a script that alters the source code (like patch) before the snap start building it?
<diddledan> you'd love this snapcraft.yaml, sergiusens, it's now sitting at 1340 lines long :-p
<petan> now it changes the source somewhere, but seems to build it elsewhere and the patch is not applied :/
<nacc> petan: https://docs.snapcraft.io/build-snaps/scriptlets
<diddledan> petan: the scriptlet you want is `prepare`
<nacc> petan: prepare ?
<sergiusens> petan: `prepare` if on stable or https://forum.snapcraft.io/t/proposal-expanding-scriptlets/4673 if on edge
<petan> nacc: I did try prepare, but as I said, the script is executed but source code which is actually built by snapcraft is not touched by it
<petan> seems like prepare is touching some different copy of source code
<diddledan> cmake?
<petan> if that's question for me, yes the project is using cmake
<nacc> petan: that seems like it would depend on the plugin (and whether it builds in place, or makes copies, etc)
<diddledan> bingo!
<sergiusens> diddledan: I am waiting for you to snap up the new gnucash!
<petan> how is it related to cmake
<diddledan> yeah cmake references the source in `src` while the build executes in `build` so you need to adjust your prepare to reference `../src`
<sergiusens> cmake does out of source builds, unfortunately we carry a bad legacy on that one
<petan> oh
<petan> will try
<sergiusens> I need to leave for now, feel free to create forum posts I can follow up on those later
<sergiusens> cheers
<petan> cmake is very popular thingie it should be supported properly
<nacc> petan: it seems like it is?
<nacc> petan: cmake just does a build copy
<kyrofa> petan, the typical way to use cmake is out-of-source. That's what snapcraft does
<kyrofa> You're not supposed to be messing with source code in prepare
<kyrofa> That's part of the build step
<kyrofa> The fact that it works on some plugins and not others is because it's not how you're supposed to use prepare :P
<petan> but I want to "prepare" the source code for building
<petan> so what should I use instead of prepare to prepare source?
<kyrofa> petan, then you need to use edge and use override-pull instead
<petan> what
<petan> what is edge and what is override-pull and who says I am pulling anything?
<kyrofa> petan, https://forum.snapcraft.io/t/scriptlets/4892
<kyrofa> petan, where are you getting the snapcraft you're using?
<petan> I made it myself huh
<kyrofa> So... a venv?
<petan> anyway, that forum page is lacking simple example
<petan> I don't want to "override" something, which is only example there...
<petan> anywa
<petan> it works now with prepare
<kyrofa> petan, overriding the pull step is exactly what you want to do there
<petan> maybe not "correct way" but it works
<kyrofa> The example is even patching
<petan> hmm
<kyrofa> But yeah, if you're happy with prepare, go for it. Just know that it's not the proper and supported way to patch code. There wasn't a proper and supported way to do that until override-pull
<kyrofa> (other than implementing a local plugin)
<mup> PR snapcraft#2063 opened: many: add snapcraftctl set-version <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2063>
<Caelum> zyga: something just broke snaps on TW, I'll look into it later today
<mup> PR snapd#5027 opened: client: snapshot sets, snapshots, snapshot actions, oh my! <Created by chipaca> <https://github.com/snapcore/snapd/pull/5027>
#snappy 2018-04-11
<Son_Goku> kyrofa, I think you've made the steps in snapcraft.yaml too magic
<Son_Goku> to me, prep, build, etc should be stages where you explicitly describe what it should do
<Son_Goku> rather than having to do the backwards thing of overriding default behaviors
<zyga> Caelum: do you have more info?
<mborzecki> morning
<zyga> Hey
<zyga> Maciej, can you please boot tumbleweed
<zyga> If you have one
<mborzecki> don't have one installed atm
<zyga> Ah, ok
<zyga> Ill check
<mborzecki> what's with tw?
<zyga> Something broke apparently
<zyga> Just woke up, will check soon
<mup> PR snapd#5003 closed: cmd/snap-seccomp: graceful handling of non-multilib host <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5003>
<mborzecki> zyga: ok, let me know if you need help, i have a spare t60 i could try it on, though i don't remember if there's an hdd inside
<zyga> I thought you have VMs on your beefy box :-)
<mborzecki> zyga: cloud vms yes, graphical ones, not so much
<zyga> re
<mup> PR snapd#5028 opened: cmd/snap-seccomp: graceful handling of non-multilib host (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5028>
<mborzecki> trivial review ^^
 * zyga updates his opensuse tunmbleweed snapd to what is in system:snappy repo
<zyga> Caelum: I cannot see any issue
<zyga> please tell me what you experienced
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/4957
<mup> PR #4957: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4957>
<zyga> 3rd review just to be sure
<mborzecki> ok
 * zyga -> breakfast
<zyga> chihchun: tee-hee-hee
<chihchun> zyga: tee-hee-hee
<zyga> I hope this boosts code reviews
<chihchun> zyga: I guess you pinged the wrong person
<zyga> oh
<zyga> sorry, yes
<zyga> chipaca sometimes has a nickname similar to the one you use
<zyga> I missed that :)
<chihchun> :)
<zyga> morning mvo
<mvo> zyga: good morning! how are you?
<zyga> good morning, I'm not taking a longish walk today :)
<zyga> so hopefully I'll make some code
<mvo> zyga: :)
<mvo> zyga: no reports yet about any issues with 2.32.3 afaict?
<mvo> zyga: did you see anything?
<zyga> no, nothing about 2.32.3 yet
<mborzecki> mvo: hey, can we land #5028?
<mup> PR #5028: cmd/snap-seccomp: graceful handling of non-multilib host (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5028>
<mup> PR snapd#5028 closed: cmd/snap-seccomp: graceful handling of non-multilib host (2.32) <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5028>
<mborzecki> mvo: thanks!
<mvo> np! 5026 needs a second review, very trivial
<mup> PR snapd#5026 closed: tests: add check for OOM error after each test <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/5026>
<mup> PR snapd#4987 closed:  tests: add test to ensure `snap refresh --amend` works with different channels <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4987>
<mvo> mborzecki: 5024 looks very good, just some testing tweaks and it is golden
<pstolowski> mornings
<zyga> morning
<mvo> hey
<mborzecki> mvo: yes, thanks for you suggestions, i'll be pushing a patch soon
<mborzecki> pstolowski: hello
<mvo> and a second look at 5020 would be great, sorry for being pushy, want to get the SRU out this morning :)
<mvo> hey pstolowski
<kalikiana> good morning
<zyga> hey ho
<kalikiana> o/ zyga
<mup> PR snapd#4845 closed: snap, store: store version numbers in the commands database <Squash-merge> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4845>
<mvo> mborzecki: curious why is 4942 marked as blocked? it looks like its ready to go in, no? modulo the small ugliness in the journal but thats ok IMO for now
<mborzecki> mvo: heh, forgot about the label :) let me fix that
<mborzecki> mvo: squash merge right?
<mvo> mborzecki: yes please
<mup> PR snapd#4942 closed: cmd/snap: user session application autostart v3 <Squash-merge> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4942>
<mup> PR snapd#5029 opened: cmd/snap: user session application autostart v3 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5029>
<mup> PR snapd#5030 opened: packaging/amzn2: initial packaging of 2.32.3 for Amazon Linux 2 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5030>
<mborzecki> need more coffee
<mup> PR snapd#5020 closed: errtracker: check for whoopsie.service instead of reading /etc/whoopsie <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5020>
<zyga> mborzecki: question about 5030, why are we using /var/lib/snapd/snap there?
<mborzecki> zyga: it's very rhel like and also lists `ID_LIKE="centos rhel fedora"` in /etc/os-release
<zyga> so just because?
<mborzecki> zyga: yeah, we already have the right switches to cover rhel/fedora
<zyga> sure but we can add a new distro to the list
<zyga> and just use /snap
<mup> PR snapd#5031 opened: errtracker: check for whoopsie.service instead of reading /etc/whoopsie (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5031>
<mborzecki> zyga: no strong opinions here, this just saves vetting DistroLike switches and there's one rpmlint warning less
<zyga> I'd go for /snap
<zyga> mborzecki: added three comments
<mborzecki> zyga: thanks
<zyga> willcooke: hey, there's an issue that skype crashes wayland on startup
<zyga> is that something on anyone's radar on your team?
<willcooke> zyga, oh, no, not something I was aware of
<Chipaca> zyga: why do you torture yourself with wayland :-)
<zyga> willcooke: just login into wayland ssh in and look at the journal
<zyga> run Skype and boom
<zyga> Chipaca: x11 corrupts screen on my thinkpad
<zyga> Chipaca: not sure why, wayland works better for that
<zyga> (apart from taking down gnome-session when things go)
<Chipaca> zyga: intel board?
<om26er> popey: ping
<zyga> Chipaca: my thinkpad
<popey> om26er: good morning
<om26er> good day popey :)
<popey> om26er: I spoke to the store team, turns out we cannot rename snaps, so we should publish s-t and remove s-t-3
<Chipaca> zyga: btw is the fix for #1760841 in a core already?
<mup> Bug #1760841: snapd does not parse /etc/fstab properly when using mhddfs <Snappy:Fix Committed by zyga> <https://launchpad.net/bugs/1760841>
<zyga> Chipaca: yes, it's in .3
<om26er> aha
<om26er> popey: so lets merge that one then ?
<om26er> well actually my current "ping" was for https://github.com/snapcrafters/android-studio/pull/19 :)
<mup> PR snapcrafters/android-studio#19: Fix app startup based on latest snapcraft changes <Created by om26er> <https://github.com/snapcrafters/android-studio/pull/19>
<om26er> popey: android studio release that we pushed yesterday won't start so this fixes it
<om26er> speaking of which, I think if we(I) enable the CI for that snap, we won't have that kind of issue again.
<om26er> "build and try to run"
<zyga> Chipaca: some comments on 5027
<zyga> and sorry for the branch summary change ;)
<zyga> lol :D
<zyga> 10 best patches you read this week
<willcooke> zyga, confirmed.  LP: #1762954
<mup> Bug #1762954: Running the skype snap under the Wayland session crashes the whole session <amd64> <apport-bug> <bionic> <wayland-session> <gnome-shell (Ubuntu):New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1762954>
<zyga> thank you!
<willcooke> np, thanks for the ping
<zyga> probably a good chunk of our users will just use wayland for some reason and will bump into this
<zyga> thanks for the review on 4957
<zyga> I'll get right to it
<Chipaca> willcooke: zyga: FWIW I think there's already a bug for that issue
<Chipaca> or is it an issue for that bug
<Chipaca> ah, maybe i'm thinking of https://forum.snapcraft.io/t/skype-crashes-gnome-on-ubuntu-18-04/4927
<mup> PR snapd#5031 closed: errtracker: check for whoopsie.service instead of reading /etc/whoopsie (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5031>
<Chipaca> or https://forum.snapcraft.io/t/vs-code-makes-shell-crash/4362
<Chipaca> willcooke: zyga: from that last one, https://bugs.launchpad.net/snappy/+bug/1760252
<mup> Bug #1760252: starting slack crashes xwayland on 18.04 <bionic> <Snappy:New> <https://launchpad.net/bugs/1760252>
<willcooke> so generally classic snaps then
<Chipaca> on wayland
<Chipaca> i mean, it's wayland (or xwayland?) that crashes
<zyga> maybe bundled lib input?
<willcooke> yeah, was just looking at that, seems like it could be xwayland
 * willcooke uploading stack traces
<zyga> it was xwayland from what I've seen
<Chipaca> call me ornery but imo if a client can crash wayland, there might be a bug in the client but there is a bug in wayland
<willcooke> one or two
<Chipaca> :-)
<Caelum> zyga: sorry, looks like the problem disappeared
<zyga> no worries, what was the problem?
<Caelum> snaps weren't starting from gnome app menu
<willcooke> k, hopefully LP will do some retracing and I will tidy up all the various bugs once that's happened.
<willcooke> Off to the office now, will be back later on
<zyga> sure, thank you willcooke
<seb128> willcooke, you are on a wayland session?
<willcooke> seb128, I was to test that
<seb128> oh, k
<seb128> thx
 * Chipaca is off to the dentist's. ttfn!
<popey> om26er: ok.
<mup> PR snapd#4957 closed: cmd/snap-update-ns: remove the need for stash directory in secure bind mount implementation <Created by jhenstridge> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4957>
<mup> PR snapd#5032 opened: repo: pass and return ConnRef via pointers <Created by stolowski> <https://github.com/snapcore/snapd/pull/5032>
<zyga> pstolowski: why by pointer?
<pstolowski> zyga: to save on passing, that was pointed out by pedronis in interface hooks review
<zyga> mvo: is .4 ready?
<mvo> zyga: .3.1
<mvo> zyga: yes it just got pushed to xenial-proposed and once my test builds finished also to the other releases
<zyga> 3.1? is that a deb only or a real upstream release?
<mvo> zyga: its pretty small and *finally* use git-buildpackage which makes me incredible happy
<zyga> nice, thank you!
<mvo> zyga: its deb only but we could still put it into the beta channel for consistency
<zyga> is that only the OOM thing?
<mvo> zyga: either way .4 needs to wait a little bit until we are sure we don't need to do anything for 2.32.3, i.e. no regressions
<mvo> zyga: a little bit more, one sec
<zyga> should it be on releases page on GitHub?
<mvo> zyga: https://github.com/snapcore/snapd/blob/2.32.3.1/packaging/ubuntu-16.04/changelog
<zyga> mvo: let me know when you push the tag
<mvo> zyga: probably, I'm a bit hesitant because .4 will happen soon and I don't want to put too much burden on the downstream packagers but otoh I think its more correct to have a release on GH
<mvo> zyga: it is pushed
<zyga> I can drop it on the release page
<zyga> thanks!
<mvo> zyga: also the release script can now be simplified because the orig.tar.xz is sane now (snapd-2.32.3.1)
<zyga> whee, good
<zyga> so orig.tar.gz doesn't need renaming internally
<mvo> zyga: yeah, I upload the file to the ppa in a sec
<pedronis> mvo: we should discuss at the standup when to cut .4
<mvo> pedronis: +1
<mvo> pedronis: my strawman would be tomorrow morning
<mvo> pedronis: but happy to discuss
<mborzecki> 14.04 journalctl, no --show-cursor, no --after-cursor, no --identifier, damn
<zyga> yeah
<zyga> lack of cursor sucks
<mborzecki> does anyone mind not running user session app autostart spread test on 14.04?
<zyga> it's fine, 14.04 was supposed to be server-only
<mborzecki> mvo: want me to look into #5029?
<mup> PR #5029: cmd/snap: user session application autostart v3 (2.32) <Created by mvo5> <https://github.com/snapcore/snapd/pull/5029>
<zyga> mborzecki: want to look at https://github.com/snapcore/snapd/pull/5033
<mup> PR #5033: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <https://github.com/snapcore/snapd/pull/5033>
<zyga> it's very straightforward
<mup> PR snapd#5033 opened: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <https://github.com/snapcore/snapd/pull/5033>
<mup> PR snapd#5034 opened: userd: set up journal logging streams for autostarted apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
<pstolowski> mborzecki: hey, how do we go vendor stuff in fedora? it's seems to be the only one unhappy about my new dependencies (go-udev..)?
<mborzecki> pstolowski: which pr?
<zyga> pstolowski: we package
<pstolowski> mborzecki: https://github.com/snapcore/snapd/pull/4940
<mup> PR #4940: RFC: added UDevMonitor for future hotplug support <Created by stolowski> <https://github.com/snapcore/snapd/pull/4940>
<pstolowski> zyga: package as separate rpm for every go package we need?
<zyga> pstolowski: package according to the way we need to in fedora, yes
<mborzecki> pstolowski: btw. do have a solution for go-dev already? other deps from from rps
<mborzecki> and iirc go-udev was not packaged for fedora yet
<pstolowski> mborzecki yes, that's very probable, it's a small and not very popular project i think
<zyga> gofed is pretty nice
<pstolowski> zyga. mborzecki ok, if that's the case then I think I need a general +1 on the PR first before investing time into packaging (it's ~3 go packages as go-udev pulls others)
<mborzecki> anyways i think the tests were using vendored deps on fedora
<mborzecki> pstolowski: do you know what the transitive deps are? govendor list -v should show it
<Son_Goku> mborzecki, they'd better not be
<Son_Goku> I delete the vendor directory in prep
<Son_Goku> I've already had that happen once and found out that we were testing Fedora wrong
<mborzecki> Son_Goku: yeah, saw that, i'm thinking of something to just unblock spread in that pr
<mborzecki> or maybe we should just package go-udev for fedora and submit it for review
<Son_Goku> if you package the godeps, I'll review and merge them into the archive
<Son_Goku> as zyga knows, I can be very fast with go package reviews
<zyga> yes
<Son_Goku> and go deps are easy to package because the gofed tool does nearly all the work
<mborzecki> i can probably take a look, unless pstolowski you want to give it a 'go' :)
<pstolowski> mborzecki: happy to do it, although as I said perhaps it makes sense to get general +1 on using go-udev first, because it hasn't been decided yet
<Son_Goku> dependencies aren't free :)
<mborzecki> pstolowski: hm thought we were already good with using it
<mup> PR snapcraft#2058 closed: python plugin: install python-distutils when run on bionic <bug> <Created by bjornt> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2058>
<pstolowski> mborzecki: I'm not sure, Gustavo hasn't yet commented on the branch (and on the HLD)
<pstolowski> Son_Goku: thanks for the hints!
<mborzecki> gofed is in .... python?
<Son_Goku> yes
<Son_Goku> most of Fedora tooling is in Python
<Son_Goku> most of openSUSE tooling is in ruby :P
<Son_Goku> and most of Debian tooling is in Perl
<mup> PR snapcraft#2062 closed: packaging: simplify snapcraft.yaml <enhancement> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2062>
<mborzecki> Son_Goku: gofed generates a busted spec, https://paste.debian.net/1019710/ there's no newline after %changelog
<Son_Goku> I know :/
<Son_Goku> the changelog entry is also wrong
<mborzecki> other than that the rpm gets built :)
<mborzecki> off to pick up the kids, coming back for standup
<pedronis> cachio: mvo:  I'm looking again at tests again staging,   seems we need to copy canonical-livepatch to staging, and test-snapd-only-in-edge
<pedronis> we probably want to copy core from edge to edge as well
<cachio> pedronis, sure,I'll do it
<pedronis> cachio: once we have solved the cred problems with spread-cron, we should revisit the various store tests branches there and add back staging I think
<cachio> pedronis, ok, we could have a nightly exec
<pedronis> I think we could trigger on store deploys
<pedronis> but we'll see
<pedronis> probably next week at this point
<cachio> ok
<Chipaca> whoo, dentist anesthetic waring off
 * Chipaca is not having fun
<Chipaca> wearing off*
<cachio> pedronis, my internet is so slow today
<cachio> it is taking long time to upload the core
<cachio> pedronis, snaps ready
<Chipaca> pedronis: standup?
<mborzecki> something new: 2018-04-11 11:08:43 Cannot allocate linode:fedora-27-64: cannot allocate new Linode server for fedora-27-64: no open slots for this plan!t
<mborzecki> pstolowski: sorry, i've just restarted the travis build in 4940
<pstolowski> mborzecki: np, it's going to fail unless you pushed something to the branch?
<mborzecki> pstolowski: no, i did not, it's going to fail ;)
<pstolowski> ok ;)
<pedronis> mvo: should IÂ squash-merge #5002 given that it has many commits?  otoh it means that the next two might need to be changed because of conflicts with the squash
<mup> PR #5002: many: use the new install/refresh /v2/snaps/refresh store API (2.32) <Critical> <Created by pedronis> <https://github.com/snapcore/snapd/pull/5002>
<mvo> pedronis: no squash please
<pedronis> ok
<mvo> pedronis: this will be a super messy merge back otherwise
<mvo> pedronis: thanks
<mup> PR snapd#5002 closed: many: use the new install/refresh /v2/snaps/refresh store API (2.32) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5002>
<pedronis> mvo: merging
<mup> PR snapd#5022 closed:  overlord/snapstate: on multi-snap refresh make sure bases and core are finished before dependent snaps (2.32) <Critical> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5022>
<pedronis> mvo: my 2.32 stuff is merged
<mup> PR snapd#5021 closed: overlord/snapstate: introduce envvars to control the channels for bases and prereqs (2.32) <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5021>
<mvo> pedronis: thank you
<mvo> mborzecki: 5029 needs a review - just double checking that its the right commit etc
<mup> PR snapd#4840 closed: many: add `core.problem-reports.disabled` option <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4840>
 * cachio afk
<mup> PR snapd#5029 closed: cmd/snap: user session application autostart v3 (2.32) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5029>
<sergiusens> Wimpress and kenvandine does this (https://forum.snapcraft.io/t/snap-application-and-snap-themes/4946) not somewhat align with what was discussed around a month ago? That theme does a bit more, I'll let you comment on that though :-)
<kenvandine> sergiusens, yes, i replied with a link to jamesh's post
<mup> PR snapd#5035 opened: release: snapd 2.32.4 <Created by mvo5> <https://github.com/snapcore/snapd/pull/5035>
<zyga> Chipaca: hey, could you look at https://github.com/snapcore/snapd/pull/5033
<mup> PR #5033: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <https://github.com/snapcore/snapd/pull/5033>
<zyga> nothing major
<sergiusens> kenvandine: your the man!
<sergiusens> 're
<diddledan> who fancies digging into snapcraft? https://forum.snapcraft.io/t/error-while-building-argument-list-too-long/4948
<kyrofa> diddledan, yuck
<diddledan> I aim to please :-p
<kyrofa> diddledan, can you try on edge?
<diddledan> I did
<diddledan> the second paste
<kyrofa> diddledan, scriptlets give better errors there
<kyrofa> Oh
 * kyrofa scrolls down further
<kyrofa> Dang, still not helpful
<kyrofa> diddledan, but yeah, I'll own this one
<diddledan> yey
<diddledan> did you look at the yaml yet? ;-)
<diddledan> a mere snip at 1350 lines
<kyrofa> diddledan, no, you're scaring me
 * kyrofa cries
<diddledan> haha
 * diddledan cuddles kyrofa 
<Chipaca> diddledan: hey, at least three of those lines are comments now
<diddledan> :-p
<kyrofa> diddledan, ignoring the actual cause, the fact that this is so opaque is problematic. In an ideal world, how would this be presented to you?
<diddledan> well to begin with I think actually telling me what command was being executed would help me to understand what it's doing when it fails
<diddledan> at least then I'd be able to determine whether there is a workaround while the problem gets fixed
<diddledan> I guess it would also help me discern whether it's my fault with wonky build configuration or an endemic problem with snapcraft itself
<Chipaca> zyga: is #5033 part of not landing new stuff?
<mup> PR #5033: cmd: generalize locking to global, snap and per-user locks <Created by zyga> <https://github.com/snapcore/snapd/pull/5033>
<pedronis> Chipaca: it was proposed in the morning
<niemeyer> pstolowski: Do you want to have a call in a few mins to discuss it?
<zyga> haha, but that was posted in the morning
<zyga> :)
<zyga> no more newies
<pstolowski> niemeyer: what is that?
<niemeyer> We tried to have a call on Monday but it didn't work.. wondering if you'd like to discuss now.. there's not hurry since per the meeting we should be stabilizing until next week
<pedronis> mvo: I completely missed  that 2.32.4 is now in beta
<noise][> pedronis: .4 has new refresh API?
<pedronis> noise][: yes
<pstolowski> niemeyer: ah, about udev? if so then yes, i'd be happy to do it in a moment
<mvo> pedronis: it happend ~15sec ago
<mvo> pedronis: ok, maybe a bit longer but armhf literally finished in the last 5min
<pedronis> I just saw it in info for amd64
<mvo> pedronis: yeah, that finished ~ 15min ago or so
<mvo> jdstrand: bad news, the issue https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 is back it seems https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic/bionic/i386/s/snapd/20180411_152411_beda4@/log.gz is the most recent autopkgtest, we added a check for lowmem and it seems like its running out of low kernel mem during the tests
<zyga> :-(
<mvo> jdstrand: for refrence this is from http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd
<zyga> low memory is that special area that is below 4G (not-PAE) or is that the special memory limit so that PCI devices can map it with their limited address space?
<zyga> jdstrand, jjohansen: do we have any news on the kernel memory leak when apparmor profiles are unloaded/reloaded
<zyga> mvo: I have alternative solution that would make that test pass
<zyga> mvo: but it's new code and definitely risky at this stage
<zyga> mvo: I talked about this to jdstrand without association to the leak issue that I was unaware of at the time
<zyga> mvo: I need to double check by looking at the test first
<zyga> but the general idea is that we would defer apparmor parser invocation until end of transaction
<mup> Bug #1763071 opened: Error message installing a paid snap as unauthenticated user <Snappy:New> <https://launchpad.net/bugs/1763071>
<zyga> mvo: now we run it way more often than needed, in some cases
<mvo> cachio: all well with the sru validation so far?
<zyga> mvo: actually, I think it would not help with this issue but let me read this more carefully :/
<zyga> mvo: no, it would not help here
<zyga> Son_Goku: 2.32.4 is out
<zyga> :-)
<zyga> Son_Goku: how is that server WG proposal coming along
<zyga> can I help in writing down the plan somehwere?
<Son_Goku> I will have something drafted in a few minutes
<Son_Goku> gotta grab lunch :)
<mvo> zyga: thanks, well, we need to figure out what is going on. it also relatively new
<zyga> aww, my pohne just died
<mvo> zyga: lets see if we also see it in artful
<zyga> Son_Goku: awesome, I'll say in touch
<mvo> zyga: that can't be - its an iphone ;)
<zyga> I forgot to charge it yesterday
<zyga> mvo: but I take the joke
<zyga> mvo: still, way happier with it than with my android phones
<mvo> zyga: I know, just teasing
<zyga> mvo: the current software shows battery health now and it claims my battery is at 83%
<zyga> not so low that I'd be tempted to replace it yet
 * zyga -> grocieres
<zyga> mvo: and btw, thinkpad modems are worth every penny :)
<zyga> I love working outside
 * mvo hugs zyga 
<popey> mvo: i have had a user ping me that they have a serious issue when installing a snap and had a full lock up and reboot
<popey> wondered if i get them in here you or someone else on the team might be able to help if you're around
<popey> the machine may have state info on it that could help debugging perhaps?
<mup> PR snapd#4832 closed: tests: move fedora 27 to google backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4832>
<pedronis> popey: do we know with what version and what snap?
<pedronis> a full lock and reboot is quite a lot
<pedronis> IÂ mean snapd version
<popey> pedronis: a snap he made, he installed devmode
<popey> not yet, he's booting a live cd now
<popey> will hopefully drop by here soon
<ogra_> out of diskspace ?
<popey> we'll see.
 * zyga is back from shopping
<zyga> popey: I could help
<zyga> popey: ping me if you have anything I can jump on
<popey> thanks. he's having trouble getting online
 * zyga hopes vmware workstation will work on the next wave of LTS distros
<zyga> I cannot use the zoo of libvirt-based things as they all are more or less broken in more or less obvious ways :/
<pstolowski> Son_Goku: what's the process of proposing go-udev package in fc once i've it ready (currently spinning fc27 vm up)? do you have a wiki describing it?
<Son_Goku> yes
<suebt> Howdy, popey led me here:  I ran into the following issue with snap: I installed a package I created (daemon snap, devmode) but unfortunately it led to completely locking up/freezing the whole system. After some time I did a hardware shutdown and tried to reboot. The system starts until displaying the cursor but then completely locks up/freezes again (tried several times now). Is there anything I can do to try debug this issue before tr
<popey> zyga: ^
<Son_Goku> pstolowski: https://fedoraproject.org/wiki/Package_Review_Process
<pstolowski> Son_Goku: thanks
<Son_Goku> pstolowski, zyga and kyrofa can walk you through it too, as they've both done it
<kyrofa> pstolowski, yeah, docs are pretty good, let me know if you want any help
<jdstrand> mvo (cc zyga and jjohansen): we never did anything about that leak. the conclusion was that while there was a small apparmor leak, it was just that. I recorded that in the forum. jjohansen was going to look at the small leak
<jdstrand> mvo (cc jjohansen): zyga's idea of batching the loads makes a lot of sense to me-- I think it would might help with timeouts in the spread tests (separate issue)
<jdstrand> s/would might/might/
<pstolowski> thanks kyrofa! I think i'll attack this tomorrow morning; do you have a link to any of your specs? i wonder how much cleanup is expected from the gofed-generated spec
<kyrofa> pstolowski, totally, although I'm not sure I'd suggest mine as model specs, haha. Let me get them for you
<pstolowski> kyrofa: if it passed the review, it's model ;)
<kyrofa> :D
<Son_Goku> https://src.fedoraproject.org/user/zyga
<Son_Goku> you can see zyga's packages
<Son_Goku> and kyrofa's: https://src.fedoraproject.org/user/kyrofa
<kyrofa> Yep, there you go. With git repos to everything
<pstolowski> awesome, thanks!
<Son_Goku> and then mine... https://src.fedoraproject.org/user/ngompa
<kyrofa> Don't look at Son_Goku's, they'll make you feel inferior
<Son_Goku> :D
<pstolowski> lol
<pedronis> so we found another instance where there reading of snaps ignoring errors is hiding other problems
<popey> i believe zyga is away, pedronis are you able to help suebt ?
<pedronis> popey: probably needs to boot into emergency mode and look around at logs , it's a bit hard to understand what from snapd would take over the system so much
<suebt> Hey pedronis. I'm currently logged into a live session on the machine. Can I access logs from there?
<ogra_> suebt, that sounds a bit like your daemon simply goes mad
<ogra_> do you have the surce for that snap public ?
<suebt> Yeah, I assume so. Could be constantly rebooting or something. Wondering whether snapd doesn't stop it at some point from doing that, though?
<ogra_> *source
<Caelum> zyga: you said there was some other gnome software that needs packaging, can I help with this?
<suebt> Nope, it's neither public nor finished yet, unfortunately, was just the first try of snapping it up ._.
<ogra_> there are some self checks for snaps, but if the daemon first starts fine and then ... say ... fills up all RAM, snapd wont be able to do anything about that
<suebt> s/rebooting/restarting/
<suebt> ogra_: yeah, right ...
<pedronis> suebt: once is installed snapd mostly let the management be done by systemd
<pedronis> for services
<ogra_> yeah
<suebt> Okay, is there any log I could check to find out?
<ogra_> you should be able to just remove the systemd units from disk
<ogra_> from your live session
<ogra_> then you can reboot into your normal system
<pedronis> /var/log/syslog  and  then  you would need to point journalctl from the live session to the logs on your main disk
<pedronis> which should be possible, but IÂ never tried myself it seems (I see there are relevant options though)
<ogra_> well, syslog from disk should be enough
<ogra_> at least if the daemon logs anything
<ogra_> if it just goes crazy in I/O or fills your ram (just enough to not hit OOM) you might not see anything at all
<pedronis> otherwise it seems   journalctl --root=your/main/disk/root ..  could help
<suebt> Okay, thanks, I'm not seeing anything helpful, just a bunch of 00\00\00\00\00\00 at the end
<suebt> Okay, well, when there are no additional snap-specific logs that could be helpful, I'll try to restore my system as you proposed ogra_. Thanks!
<pedronis> suebt: btw it seems you can also disable your daemon    using   systemctl --root=...  disable  snapd.snap-service...
<ogra_> snaps usually just log to logger ... which writes to syslog and journald ...
<ogra_> oh, wow, i didnt know that one
<suebt> oh ok, thanks ogra_ pedronis
<pedronis> ogra_: yea, haven't quite tried but apparently both journactl and systemctl can take an alternative root dir
<ogra_> very cool
<suebt> pedronis: systemctl --root worked just fine, so that was easier than I thought it would be. Thanks! Okay, will report in case I find anything interesting which is not related to my application going wild for some reason .-.
<ogra_> make a wrapper script around your daemon that reports ram and disk usage or some such ... and prehaps add a timeout so you dont kill the system again
<zyga> re
<zyga> I'm home
<Caelum> zyga: hey, you said earlier we need to package some other things for OS, can I help with any of that?
<zyga> yes, there is a glib wrapper for talking to snapd that is a dependency of gnome-software
<zyga> but I think we should see what it would take to submit the package to factory
<zyga> as the extra package I'm talking about won't work without snapd
<Caelum> ah ok
<Caelum> well let me know if you need help with anything
<pedronis> zyga: seems there's a real bug where during install we think a snap is mounted but is not, somebody hit it with beta, but it's not a regression (it fails strangely because of the ignore error code we have in readInfo)
<pedronis> it's rare though we have a report now and one from long ago , Chipaca might know more
<zyga> pedronis: interesting, so we think it is mounted and then go an and try to use it
<zyga> pedronis: I added some code that prevents snaps with snapInfo.Broken from entering the repository
<zyga> pedronis: but it is a new thing that landed in 2.32.3 first
<zyga> Caelum: I think we should send a mail out to the packaging mailing list
<zyga> Caelum: and propose the current incarnation of snapd
<zyga> Caelum: and see what the response is
<pedronis> zyga: but it fails much earlier in this case, we really need to revist readInfo
<pedronis> and really decide when returning broken vs error makes sense
<zyga> Caelum: I bet we will get some quick things like "change that, fix this" etc
<zyga> pedronis: I agree
<pedronis> zyga: we did to support listing and removals
<zyga> pedronis: but I also think this is a secondary effect, we should understand what is wrong with mounting
<zyga> pedronis: yes, I remember
<pedronis> but right now it makes other places fail in very strange ways
<zyga> pedronis: for interfaces we should probably fail
<pedronis> because they were never changed to look at broken
<pedronis> nor tbh it makes a lot of sense for them
<zyga> pedronis: though now we kind of do (but again, since just a moment ago)
<pedronis> they would much better get an error
<pedronis> zyga: yea, but it is earlier, it seems doMountSnap itself can explode (strangely because of the ignored error) on a not really mounted snap
<mvo> jdstrand: re oom> thanks for your update. so you say that apparmor leak is too small to trigger this oom situation and something else is mostly likely eating the lowmem?
<zyga> Caelum: so I think we should definitely just do that
<pedronis> zyga: it means do that our mount code has problems ,  we trust something that isn't correct (or yet something else is going on but unclear what)
<zyga> Caelum: let's propose what we have
<zyga> Caelum: and see what the feedback is
<zyga> Caelum: can you do that?
<pedronis> s/do/though/
<zyga> pedronis: I would like to know if it happens inside a container or inside a non-container
<zyga> pedronis: perhaps FUSE is the thing that makes it more "broken"
<pedronis> I can ask about the last case
<zyga> pedronis: who was the last case? what do we know about it?
<pedronis> somebody on the store team
<pedronis> I'm asking him (but he was having lunch)
<pedronis> zyga: not a container apparently
<zyga> that's good information, so it probably is a generic issue
<pedronis> xenial
<zyga> I'll get some tea, keep talking about what we know
<jdstrand> mvo: that was the conclusion before: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/7
<zyga> back
 * zyga checks what systemd does for mount units in xenial
<jdstrand> mvo: nothing was changed in apparmor wrt this. the fact that it went away and came back coupled with ^ suggests it is something else. I can't comment on the progress of the work to make the 30M smaller or the 2M leak go away
<pedronis> zyga: he also said he remove the snap and reinstalled,  might also be some interaction between lazy detaching and remounting
<pedronis> mvo: somebody hit a old bug with the beta, seems we really have some corner cases in which SetupSnap returns without errors but the snap is not really mounted (yet)
<zyga> pedronis, mvo: let's add some simple code that after the mount call, checks
<zyga> we can wait, raise red flags, etc
<zyga> and then run it in a very long loop
<zyga> maybe something will come up
<zyga> opinions?
<Caelum> zyga: sure
<mvo> jdstrand: well, we have more tests I think it never went away we just didn't trigger it because we ran less tests. but fair enough, I start looking tomorrow again, its pretty important as it blocks us from entering bionic right now
<mvo> pedronis: oh, interessting
<zyga> mvo: is it easy to reproduce?
<cachio> mvo, do you know who is the owner of the dragonboard-kernel snap
<cachio> dragonboard-kernel_45.snap is getting stuck starting
<mvo> zyga: I think so, I think its a matter of installing removing a snap
<zyga> cachio: I think the kernel team owns all kernel snaps
<cachio> zyga, do you know who?
<mvo> zyga: http://paste.ubuntu.com/p/26xzSJ8NHJ/
<zyga> mvo: on which kernel? any?
<zyga> specifically i386 bionic?
<mvo> zyga: bionic/i386
<zyga> ok, I'll try to reproduce it now
<sergiusens> jdstrand: hi there, we are having an isolated issue and might find it interesting if you could provide insight (snapcraft snap inside lxd). Here's a paste I have https://paste.ubuntu.com/p/mkhz73q7K7/ where on first run everything works but on a second one (where we do not install core nor snapcraft again) it fails with "cannot change profile for the next exec call: No such file or directory"
<mvo> zyga: also artful :/
<mvo> zyga: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-artful/artful/i386/s/snapd/20180411_144134_835a7@/log.gz
<zyga> sergiusens: what prints that line
<zyga> cannot change profile for the next exec call: No such file or directory
<zyga> is that snap-confine?
<sergiusens> zyga: running snapcraft
<sergiusens> zyga: yeah, most likely
<zyga> sergiusens: right, but as a part of that you are runnig some snaps, right?
<zyga> can you add export SNAP_CONFINE_DEBUG=yes please
<sergiusens> snapcraft is a snap
<zyga> and reproduce
<zyga> may be some hint
<zyga> what this tells us is that we're trying to switch to some profile
<zyga> but that profile doesn't exist
<sergiusens> zyga: yeah, not me, popey and it seems he can consistently reproduce. This also only happens for him on on lxd 3.0.0
<zyga> you can also get one more thing
<zyga> when it fials
<mvo> niemeyer: hm, did spread change and is no longer compatible with go1.6 or something? I see in the xenial autopkgtest output: + go get -u github.com/snapcore/spread/cmd/spread
<mvo> package context: unrecognized import path "context" (import path does not begin with hostname)
<sergiusens> zyga: yeah, interesting that it works on the first pass and fails on the second, so it seems something is lost on container stop/start
<zyga> when it fails run "sudo cat /sys/kernel/security/apparmor/profiles"
<zyga> sergiusens: yeah, likely so
<zyga> mvo: yes, spread changed and it is not compatible with go 1.6 anymore
<zyga> mvo: we discussed this last week
<sergiusens> zyga: the `cat` inside the container or outside or is it irrelevant?
<mvo> zyga: right, the next question is - what can we do about it :)
<sergiusens> zyga: also, snapcraft is classic, so there should be no profile to switch to, right?
<jdstrand> mvo: with the way that interfaces are connected (run apparmor_parser after each snap connect/disconnect, even if a particular command has multiple interfaces rather than only running it once) and sooo many tests, I wonder if the leak, even though it is small, might compound and therefore aggravate the situation. I don't really know how the leak happens though, so that might be a question for jjohansen when he is around again. he seems timme shifted,
<zyga> mvo: we discussed this at length, one idea is to get the pre switch spread in a branch and build it for go 1.6
<mvo> niemeyer: anything we can do to make spread 1.6 compatible again? right now this blocks the autopkgtests in xenial. or should we use a fork for spread on xenial?
<mvo> zyga: right, did we discuss with gustavo?
<mvo> zyga: yet?
<zyga> mvo: no, not yet
<zyga> mvo: both you and gustavo were away at that time
<sergiusens> mvo: you could probably enable backports and pin in your adt test to get the latest go
<mvo> jdstrand: ok, thank you. its late in my TZ but i can try to gather data tomorrow
<mvo> zyga: aha, indeed
<sergiusens> or install the go snap, prior to enabling squashfuse to get the arches running in containers covered
<mvo> sergiusens: that is a good idea
<mvo> sergiusens: we don't support testing in containers currently so that is ok
<sergiusens> unless spread is part of the packaging, then I have no ideas
<mvo> sergiusens: also 2.32 fixes the squashfuse issue :)
<zyga> sergiusens: actually, I don't think that is true
<zyga> sergiusens: classic has profiles, just very open
 * zyga checks
<zyga> sergiusens: yes, classic has profiles and is confined
<sergiusens> mvo: but armhf runs in a container, or do you get special hw for adt?
<jdstrand> mvo: did you see the bit about jjohansen time-shifted? looking back, it seems my comment may have been too long
<sergiusens> zyga: ok, just a lean and mean one :-)
<mvo> sergiusens: we skip if we detect containers, we don't run tests there right now unfortunately
<zyga> jdstrand: do you know which timezone jj currently inhabits/
<mvo> jdstrand: heh, I did see that, thank you :)
<sergiusens> mvo: ok, I was looking at installing squashfuse in debian/test/control to figure out if we could get that going
<jdstrand> mvo: did you see the bit about jjohansen time-shifted? looking back, it seems my comment may have been too longwhen he is around again. he seems timme shifted, so you might ask him when you come online tomorrow"
<sergiusens> I'll report back, as it might interest you (we currently skip build-snaps tests on armhf and such)
<jdstrand> man
<jdstrand> mvo: ok, you saw it, I'll stop trying to paste it :)
<mvo> niemeyer: about spread and go1.6 - a fix in the spread upstream repo would be great as it would allow us to avoid another upload. if that is hard/impossible I can try to workaround it via installing a different go when building spread or using the snap or trying to be creative in other ways.
<suebt> ogra_, pedronis: Hey, regarding my lockup issue we just talked about: I found out that the application basically just crashes and exits. I just reproduced it with a one-line app that just panics and quits. Looks like snap by default makes daemons auto-restart in case of failure. Is it expected that this will lead to locking up the whole system when the app is quitting straight away?
<zyga> suebt: hey, sorry for being absent earlier
<zyga> I think system will back off eventually
<suebt> hey zyga, no problem :)
<zyga> but even if you essentially create a "while true; crash; done" app
<zyga> it should not bring the system down
<suebt> I can post the code, give me a sec
<jdstrand> sergiusens: fyi, what zyga asked for is what is needed to understand what is happening. the profile (likely for the lxc command if I were to guess) seems to have been unloaded
<zyga> can you provide as much information as possible please
<zyga> suebt: oh, perfect
<zyga> jdstrand: maybe when the container is stopped and started something is off and apparmor profiles are not loaded
<zyga> mvo: I think the "stable quiet period" is a good thing for now
<zyga> we have plenty of things to attack
<mvo> zyga: oh yes!
<jdstrand> zyga (cc sergiusens): that's interesting and plausible. a snapd restart on container start would workaround that
<zyga> jdstrand: note that what is super odd
<zyga> jdstrand: is that snap-confine would say "aha, I'm not confined"
<zyga> jdstrand: and would bail out way before reaching that code
<zyga> jdstrand: so its own profile must have been loaded
<zyga> jdstrand: but it is only loaded by apparmor init scripts
<zyga> jdstrand: and whenever we install core
<zyga> jdstrand: so ... ?
<zyga> something is off
<zyga> or
<zyga> well, that's silly
<zyga> or the profiles from /var/lib/snapd/apparmor are not loaded
<jdstrand> snapd will load it if it detects overlay or nfs too
<zyga> we changed one thing recently
<suebt> zyga: here you go: https://github.com/tim-sueberkrueb/snap-daemon-lockup-example I'm on Ubuntu 17.10
<zyga> we have the system key
<jdstrand> not that this is the case, just mentionign that
<zyga> we don't reload profiles like we used to do, all the time
<jdstrand> does reexec make sure it is there?
<jdstrand> anyway, need more data
<zyga> suebt: perfect, me too
<suebt> get a live stick ready xD
<zyga> jdstrand: reexec yes but only when core is installed (that is during that operation)
<zyga> jdstrand: what I am saying is that now with the system key we are not loading profiles on startu
<zyga> jdstrand: so if there was a bug since forever in lxd
<zyga> jdstrand: it was masked
<zyga> jdstrand: but not anymore
<zyga> suebt: my desktop runs 17.10
<suebt> ok, I just mean in case of locking your system up ^^
<zyga> suebt: inspecting now
<suebt> thanks :3
<zyga> thank you for using snaps :)
<zyga> and sorry for the bad experience
 * zyga loves rust
<suebt> Yeah, rust is awesome
<suebt> just started learning it though :)
 * suebt is still a noob in rust
<jdstrand> I wonder if this is related to https://bugs.launchpad.net/ubuntu/+source/apparmor/+bug/1746463
<mup> Bug #1746463: apparmor profile load in stacked policy container fails <aa-kernel> <verification-needed-artful> <snapd:Triaged> <apparmor (Ubuntu):Confirmed> <linux (Ubuntu):Confirmed> <linux-gcp (Ubuntu):Fix Released> <apparmor (Ubuntu Xenial):Won't Fix> <linux (Ubuntu Xenial):Invalid> <linux-gcp
<mup> (Ubuntu Xenial):Fix Released> <apparmor (Ubuntu Artful):Fix Committed> <linux (Ubuntu Artful):Fix Released> <linux-gcp (Ubuntu Artful):Invalid> <apparmor (Ubuntu Bionic):Confirmed> <linux (Ubuntu Bionic):Confirmed> <linux-gcp (Ubuntu Bionic):Fix Released> <https://launchpad.net/bugs/1746463>
<jdstrand> perhaps the kernel is out of date
<jdstrand> sergiusens (cc zyga): ^
<jdstrand> anyway, I need to move to another task now. if there is more data, we can look
<zyga> jdstrand: perhaps, good call
<zyga> suebt: what does snap version say?
<zyga> are you on 2.32.3/
<suebt> yep
<zyga> perfect
<zyga> ok, installing now
<zyga> (I hope it doesn't explode that hard :)"
<suebt> ok, hope you can reproduce it :D
<zyga> suebt: nope
<zyga> it starts, it is restarted a few times
<zyga> nothing happens
<zyga> I'm typing this from that system
<suebt> Well, this is both good and bad ^^
<suebt> Hmm ...
<zyga> can you ssh into your machine
<zyga> from something else
<suebt> I didn't build it with cleanbuild
<zyga> run journalctl -f
<suebt> But that doesn't make any difference
<zyga> neither did I
<zyga> and then install the snap
<zyga> and let's see what you get
<suebt> Okay
<sergiusens> jdstrand: well popey is on kde neon
<jdstrand> sergiusens: perhaps popey should be talking to us :) popey, make sure your kernel is up to date (there was a fix last week for the above bug) and try the lxd stuff again
<Pharaoh_Atem> zyga: review? https://paste.fedoraproject.org/paste/IBruVUkBu79voKY439~bOg
<suebt_> zyga: uhm, ya, writing this from the other machine: https://paste.ubuntu.com/p/nxqmQydfrp/ that's all
<sergiusens> jdstrand: heh, I wanted to rule out snapcraft any lxd interaction, but it seems the error is not snapcraft originated (while it is snapcraft driven)
<zyga> Pharaoh_Atem: ack
<zyga> suebt_: nothing there, what happens with your system
<zyga> is the ssh session dead?
<suebt_> Yep it is xD
<suebt_> it completely locked up again
<suebt_> The other suebt just died
<zyga> hmmmm
<jdstrand> sergiusens: yeah, I think it is how snapcraft is driving lxd that is uncovering the issue
<zyga> I wonder if your kernel crashed
<zyga> is it a laptop/desktop?
<zyga> do you have a screen
<suebt_> It's a laptop.
<zyga> can you reboot it
<zyga> go to vt4
<zyga> or something without X
<zyga> log in into the consoel
<zyga> ssh in remotely
<zyga> trigger the error remotely
<zyga> if the kernel crashed there's bound to be something on the tty
<sergiusens> jdstrand: so the line that fails almost looks like `lxc exec <container-name> -- snapcraft`
<suebt_> Okay, will try
<zyga> suebt_: ok, perfect, thank you
<zyga> Pharaoh_Atem: reading now
<jdstrand> sergiusens: yeah, that is what I figured
<sergiusens> jdstrand: the difference from the first run and second is that on the first run we snap install core and snapcraft while on the second run it is already there (so we do not install)
 * jdstrand nods
<sergiusens> jdstrand: and it works for me too; but I did not go through an upgrade path of 2.0 to 3.0.0 as he has (I installed 3.0.0 from scratch)
<sergiusens> oh, and I am on bionic
<zyga> sergiusens: that hints at the fact that core installation triggers profile setupo
<jdstrand> sergiusens: I did go from 2 to 3. what do I need to do to reuse the container? (I use cleanbuild all the time)
<jdstrand> that said, I suspect it has nothing to do with lxd
<sergiusens> jdstrand: look at the top of the paste for the feature flag
<sergiusens> export SNAPCRAFT_CONTAINER_BUILDS=1
<sergiusens> it behaves like a local build but inside a container, so you can run `snapcraft pull` and it will do the pull in the container and you get to see the bits locally
<jdstrand> sergiusens: that's nice
<jdstrand> sergiusens: yes, it works fine here (bionic)
<jdstrand> sergiusens: I'd like to see what kernel popey has
<sergiusens> ok, we can probaly use a smaller test case for this when he's back by installing a small classic confined snap and go with that
<jdstrand> sergiusens: a good reproducer would be nice. that said, I can snapcraft twice on a small snap just fine and fast
<zyga> Pharaoh_Atem: it looks good
<zyga> let me think if there's anything to tweak
<suebt_> Hey zyga: On the laptop screen I get: "watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [snap-exec:10B49] ..."
<zyga> aha
<zyga> let it run
<zyga> it's not dead
<suebt_> how long should I let it run?
<zyga> I wonder what's the kernel shortcut to get a backtrace from stuff
<zyga> a few minutes
<suebt_> okay
<zyga> looks like a deadlock
<zyga> suebt_: can you send me the snap you are running
<zyga> the built one
<zyga> (next time after reboot)
<zyga> but don't reboot yet
<zyga> and uname -a
<zyga> and tell me if you have any kernel modules you've built from source or dkms
<suebt_> Sure, as soon as I'm able too reboot again. Okay, then I'm going to wait 5 more minutes?
<zyga> Pharaoh_Atem: +1 from me
<zyga> I think it's a start of a new era :)
<zyga> suebt_: yes, I think there's a keyboard combo that can be useful
<zyga> but I don't recall it
<mborzecki> zyga: sysrq?
<zyga> yes
<zyga> mborzecki: do you know which one panics the kernel or shows something useful (backtrace)
<mborzecki> hmm i have muscle memory for sending one over uart ;)
<mborzecki> zyga: echo l > /proc/sysrq-trigger
<mborzecki> zyga: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/admin-guide/sysrq.rst#n51
<mup> Issue snapcraft#2026 closed: Implement a passthrough feature <bug> <enhancement> <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/2026>
<mup> PR snapcraft#2053 closed: meta: implement pass-through of properties to snap.yaml <Created by kalikiana> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2053>
<zyga> mborzecki: do you know what to press on suebt_'s keyboard to get useful backtrace?
<mborzecki> zyga: On x86   - You press the key combo :kbd:`ALT-SysRq-<command key>`. and then l or t, probably l if it's a lockup
<zyga> Pharaoh_Atem: can you please cross-post this to the forum
<zyga> suebt_: ^^ what mborzecki said
<zyga> can you try?
<suebt_> okay, sure, so alt print l?
<mborzecki> suebt_: did it work?
<suebt_> hmm nothing happens, maybe I try the wrong combo for my laptop
<suebt_> tried alt+print+l
<mborzecki> if it's a laptop you may need to press Fn+prtscr
<suebt_> ok
<suebt_> Nothing, also tried with the external keyboard
<mborzecki> hm it may be disabled then :/
<mborzecki> on arch & thinpad x220, it's press alt, press Fn, press prscr, release prscr, release fn, press l, and then ther's a nice message in dmesg "This sysrq operation is disabled"
<mup> Issue snapcraft#2064 opened: Support for set-grade <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/2064>
<suebt_> hmm
<suebt_> in the lenovo forum FN + S seems to be also a thing, but that doesn't work either
<suebt_> okay, meh, sorry, then I'll reboot now, I gues?
<suebt_> *ss
<zyga> suebt_: yeah, go for it
<zyga> suebt_: send me uname -a
<zyga> and your snap
<zyga> I will look into it
<zyga> but not tonight, I have some high priority work now
<suebt_> okay, will provide the info you requested in a few minutes, thanks!
<Pharaoh_Atem> zyga: why would I post this to the forum?
<Pharaoh_Atem> this is the email I'm going to send to server WG
<zyga> Pharaoh_Atem: cross post, this is a big and important topic
<zyga> this way people will know it happens
 * Pharaoh_Atem sighs
<Pharaoh_Atem> I guess
<suebt> snap package: https://drive.google.com/open?id=1eXHPcZLn-lVFf38EWvke-k8SWflOW6l-
<suebt> system info: https://paste.ubuntu.com/p/ZySVSw8GQn/
<suebt> No custom kernel
<suebt> anything I forgot?
<suebt> zyga ^^^
<zyga> looking
<zyga> ah,
<zyga> I'm on a custom kernel!
<zyga> I'll boot to -38 and try
<zyga> thank you, that's all for now
<zyga> can you hop in tomorrow
<zyga> and check with us again please?
<suebt> Sure, I will try to be around 18 UTC :)
<suebt> *18 pm
<suebt> 18 pm is not a thing nevermind xD
<suebt> ok, thanks!
<mvo> meh, too late - I have the answer for sysreq on the new lenovo keyboards: https://mvogt.wordpress.com/2017/05/24/sysreq-on-lenovo-x250/ - oh well
<petan> is there a way to display very old builds?
<petan> I see only like last 10
<petan> I need to check some like 100 builds ago
<mvo> petan: snapcraft history <snapname> iirc
<petan> ok
<mvo> mwhudson: did I mention today how great "snap install go --channel=1.6/stable" is?
<mvo> mwhudson: thank you so much for this
<popey> jdstrand: 4.13.0-37-generic. KDE neon
 * diddledan peeks
<mvo> niemeyer: I pushed a possible fix for the spread go1.6 compat in https://github.com/snapcore/spread/pull/56 - as a stop-gap. if that is acceptable I can trigger the autopkgtests again on xenial (after that is merged of course). but please do let me know if you prefer a different approach
<mup> PR spread#56: add go1.6 compatibility <Created by mvo5> <https://github.com/snapcore/spread/pull/56>
<niemeyer> mvo: What's that about?
 * niemeyer ooks
<niemeyer> looks
<mvo> niemeyer: in a nutshell our autopkgtests on xenial are broken because they try to build spread with go1.6
<niemeyer> mvo: That's an easy one
<niemeyer> mvo: It's in
<mvo> niemeyer: \o/
<mvo> niemeyer: man, thank you so much
<niemeyer> mvo: Thanks, and sorry for missing this earlier
<mvo> niemeyer: I will trigger the tests to re-run now, thank you!
<jdstrand> popey: linux (4.13.0-38.43) artful; urgency=medium
<jdstrand> popey: that ^ has the fix for the bug I mentioned. please upgrade to that and try again
<popey> jdstrand: I am on xenial
<jdstrand> popey: linux-hwe (4.13.0-38.43~16.04.1) xenial; urgency=medium
#snappy 2018-04-12
<zyga> o/
<mborzecki> morning
<zyga> mborzecki: hey
<zyga> https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
<mborzecki> yup reading
<mborzecki> zyga: any clue if mvo got access to a vm where the refresh-mode issue was reproducible?
<zyga> no
<zyga> let's make a spread test that has similar characteristics
<mborzecki> zyga: do we know what disto tha was?
<zyga> and strace the hell out of it
<zyga> not really
<zyga> note that we have not reproduced it yet
<zyga> but I will let mvo discuss tihs
<zyga> he knows the most
<mborzecki> hm that memory usage, we could play with GOGC, but there's another possibility that we're just keeping that much stuff in memory
<mborzecki> (i'm taking about RES, VIRT is high but it should not be a problem)
<zyga> mborzecki: yes, RES is key, though VIRT is weirdly huge
<zyga> but maybe that's the nature of golang gc
<zyga> ok, kids off to school
<zyga> and I can have my coffee and focus
<mborzecki> gdm is just so useless, it stats a whole gnome session, does nothing else than shows a login screen and has a 50% chance of locking up the system when switching back to it after logout
<mborzecki> at least autostart works as expected with 2.32.4
<zyga> Heh, the modern desktop stack
<mborzecki> btw. clicking on quit label in tray menu of discord: https://paste.ubuntu.com/p/CtG3Kx7Kxt/
<zyga> Well
<zyga> On my system gnome shell logs errors every second
<zyga> Finalization issue with some object
<zyga> I frankly miss unity quality
<zyga> Later on unity was way more solid
<mborzecki> ok, bumped arch package to 2.32.4
<mvo> good morning
<mborzecki> mvo: morning!
<zyga> hey mvo
<mvo> hey mborzecki and zyga ! how is life this morning?
<zyga> great, it's a bit chilly in the morning though
<zyga> I'm looking into the memory leak
<zyga> but if I get stuck or it goes nowhere I will look at the mount issue
<pedronis> hello
<zyga> hey good morning
<pedronis> so I discovered that init is 2M and snapd nowadays 21M , just the executable  (of course systemd has other daemons)
<zyga> I really wonder what is inside golang executables
<zyga> small instance of google Borg?
<pedronis> well, as I said,  systemd has many daemons
<pedronis> so it's not a fair comparison
<pedronis> but it doesn't put in a good spot
<pedronis> we have not to run at all, not to use memory
<mborzecki> that ~21M would mostly count to virt though
<pedronis> mborzecki: looking at smaps it doesn't seem so
<mborzecki> but it still needs to be loaded into memory and so on
<pedronis> anyway on a constrained system probably even running and stopping is bad
<pedronis> mvo: let me know if we should have a HO in 1h or so to talk about that issue at least and options
<mvo> pedronis: yeah, sounds good a HO in the morning sounds good, I am currently baby-sitting autopkgtest but hopefully that does not take too long
<pstolowski> morning
<zyga> hey pawel
<zyga> http://paste.ubuntu.com/p/GtVYbzfgC8/
<zyga> pstolowski: FIY https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954
<pstolowski> zyga: yes reading
<zyga> with GOGC=10 http://paste.ubuntu.com/p/Gbnz675BT3/
<mborzecki> playing with GOGC, off -> 33MB, 5 -> 19MB, 50 -> 20MB, 100 (default) -> 22MB
<mvo> zyga: what tool is that?
<zyga> pmap
 * mvo nods
<mborzecki> zyga: comparison of GOGC=1 and GOGC=100 https://paste.ubuntu.com/p/74zgkbZBWj/
<mborzecki> (disabled ASLR so that we get stable addresses)
<zyga> nice
<zyga> how did you disable ASLR?
<mborzecki> /proc/sys/kernel/randomize_va_something
<zyga> but the bottom line is that rss shrinks just a little and virt doesn't
<mwhudson> you can also disble aslr for one invocation with setarch
<mwhudson> setarch `uname -m` -R whatever
<mborzecki> nice
<mborzecki> wonder why there's 7 * 64MB and 6*8MB blocks, 64MB ones are ---p, 8MB are rw-p
<mup> PR snapd#5035 closed: release: snapd 2.32.4 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5035>
<mvo> good news, spread on xenial is happy again and we have some tests passing already, the other ones are retriggered
<mvo> (missing build of test-snapd-account-services on s390x was one failure which is fixed now)
<zyga> mborzecki: noite that the 64MB ones are empty
<zyga> they take almost no memory
<mborzecki> zyga: cow?
<zyga> they feel like a/b gc
<mborzecki> hm bottom line, we're not going to get lower than whatever is the size of snapd binary, i.e. ~16MB
<mborzecki> zyga: installing core snap https://paste.ubuntu.com/p/dQDYNJz2Vf/
<mborzecki> also the binary in core built with go 1.7 right?
<mborzecki> zyga: before and after installing core snap and reexec https://paste.ubuntu.com/p/xPpCQjV4j8/
<pstolowski> zyga, mvo, mborzecki would it make sense to add profiling code to snapd and land it in edge, eg something like https://flaviocopes.com/golang-profiling/ in the daemon?
<mborzecki> pstolowski: there's pprof which is super simple
<zyga> pstolowski: I don't have experience with that, no idea
<mborzecki> i can try building it locally though
<pstolowski> yeah i'm going to try local build too
<zyga> man we are leaking that memory quickly
<zyga> I'm in a loo where test-snapd-poicy-app-consumer:bluez is constantly discon reconnected
<zyga> this also stresses udev
<mvo> mborzecki: the binary in core is build with go1.6 (xenial)
<pedronis> mvo: I'm around
<mvo> zyga: kernel mem?
<mvo> pedronis: ok, I join in 2min then
<zyga> mvo: perhaps, I'm not sure yet
<zyga> interestingly doing this puts lots of load on X as well
<zyga> (perhaps due to udev)
<zyga> to the point where session is unresponsive (not stuck but very slow)
<zyga> I see constantly raising buffer_head allocations
<zyga> I see several dozen udev processes at a time
<zyga> the leak may be unrelated to apparmor if udevadm trigger / settle leaks something into the kernel / netlink area
<mwhudson> BjornT_: hi, do you have a ppa with a snapcraft that has https://github.com/snapcore/snapcraft/pull/2058 applied by any chance?
<mup> PR snapcraft#2058: python plugin: install python-distutils when run on bionic <bug> <Created by bjornt> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2058>
<BjornT_> mwhudson: no. but it's in the snap edge channel now
<mwhudson> BjornT_: hm but you can't build a snap in launchpad from a snapcraft from a snap can you?
<mwhudson> (that sentence is quite a tongue twister)
<BjornT_> mwhudson: right, you can't. but i'm guessing you will have problems building a bionic snap in launchpad anyway, won't you?
<Chipaca> mvo: I saw you put #1616629 into 'in progress', does that mean you have a branch for it?
<mup> Bug #1616629: could not unmarshal state entry "snap-type" <Snappy:In Progress> <https://launchpad.net/bugs/1616629>
<mwhudson> BjornT_: nope, been doing that for months :)
<mvo> Chipaca: it means "we are looking at it", pedronis  is working on improving the error at least to fail way earlier
<Chipaca> mvo: ah, ok
<pedronis> Chipaca: one theory is that it relates to removing and reinstalling   (maybe we the fs of the snap in use) and lazy unmounting
<Chipaca> pedronis: was that what pindonga did yesterday?
<pedronis> yes, he said he had removed the snap
<pedronis> Chipaca: anyway current plan is 1) improve error, 2) possibly add belt and suspenders 3)Â somebody might want to play with loops of remove and install of the same thing
<Chipaca> i can start on 3 right no
<Chipaca> now*
<pedronis> thx
<pedronis> I will work now on 1)
<mvo> zyga: here is something strange. this is the LowMem value after running each of the tests, the tests are in order http://paste.ubuntu.com/p/k8wvw689B9/
<mvo> zyga: the fluctuation is also strange
<zyga> I suspect what is going on is that as memory pressure raises kernel is dropping more and more caches
<zyga> releasing some memory in that zone
<mvo> zyga: aha, yeah, that makes sense
<mborzecki> pstolowski: hooked up pprof finally, https://paste.ubuntu.com/p/XXBv8qFFym/ :6060 is the regular http one, the one over /run/snapd.socket you need to wrap around with socat
<mborzecki> pstolowski: something like `socat -v tcp-listen:6070,reuseaddr,fork "unix-connect:/run/snapd.socket"` should work
<pedronis> mborzecki: pstolowski:  we discussed with mvo some ideas about not starting at all  , it seems hard to  halve or /3 memory usage in one week
<mborzecki> pedronis: especially as the binary is 16MB already ;)
<mborzecki> pedronis: so what are the current ideas?
<pedronis> mborzecki: mvo is working on that I think,   but basically only play at the level of the systemd units
<pstolowski> mborzecki: thanks, checking; i was pursuing something else in the meantime - run 2.32.4 snapd under gcvis but didn't find anything conclusive
<Chipaca> is it still the case that a snap can't call a binary in another snap?
<mvo> mborzecki: the idea is to use a generator that looks if there is a snap or a seed and if none of this is true generates a service file that is socket activated only
<mvo> mborzecki: this way we do not run at all on cloud instances until first use
<mvo> mborzecki: the downside is that we don't get the c-n-f data so we need to put that into an external timer
<mvo> but I think its an acceptable trade-off given the time contrains
<mborzecki> sounds fair
<mborzecki> mvo: do you need help with that?
<mvo> mborzecki: sure, I also have the sigterm issue that needs attention, if you want to add the generator that would be great.
<mvo> mborzecki: we have two options: a) generator b) snapd is also socket activated and we add a "wakeup" service that has conditions on /snap/* and /var/lib/snapd/seed/*
<mvo> mborzecki: and this wakeup would just run snap version to ensure the daemon runs
<mvo> mborzecki: plus one idea from zyga was to use the "idle" option of systemd so that snapd starts a bit later (when it starts) when the system has settled
<mvo> mborzecki: sounds sensible? happy to have a quick HO if you want
<mvo> mborzecki: alternatively the SIGTERM issue is something I am willing to trade too, whatever you find more interessting :)
<pedronis> to be clear: /snap/*   OR  /var/lib/snapd/seed/seed.yaml
<pedronis> not AND
<mborzecki> mvo: let's do HO
<Chipaca> pedronis: /snap/*/current i guess
<pedronis> something
<pedronis> it's really /snap/* ignoring bin
<pedronis> and also /snap is not always snap
<Chipaca> the problem with doing install/remove in a loop is that i quickly remember how badly that grows :-(
<Chipaca> loop #1: ~1s; loop #200: ~6s
<mup> PR #200: Improve error handling in client package <Created by zyga> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/200>
<Chipaca> mup: er... thanks
<mup> Chipaca: I apologize, but I'm pretty strict about only responding to known commands.
<mvo> mup: #1
<mvo> *pfff*
<Chipaca> mvo: istr #1 being an issue, which are now gone
 * cjwatson is lost in a twisty maze
<cjwatson> Is there some way to force snapd to forget about its existing store device macaroon?
<cjwatson> It must be serialised to disk somewhere to persist between snapd startups, but I can't find it
<mvo> Chipaca: yes, gone, let me update the post
 * zyga builds 4.17
<zyga> well, master
<pedronis> cjwatson: it's in   state.json  under  data.auth.device
<zyga> kissiel: /me hugs his computer :)
<pedronis> cjwatson: session-macaroon
<Chipaca> mvo: which post?
<pedronis> cjwatson: /var/lib/snapd/state.json.  stop and restart snapd for editing
<cjwatson> Aha, thanks
<mwhudson> mvo: np on go 1.6/stable, i'm just waiting for the coinstallable tracks feature :)
<mwhudson> zyga: would you be interested in my "use x/net/context instead of context" sed of doom? :)
<mwhudson> find -type f -name \*.go \! -path '*/.pc/*' -print0 | xargs -0 sed -i -e 's%^\(\s\+\)"context"$%\1"golang.org/x/net/context"%'
<mwhudson> zyga: it works on docker.io :)
<zyga> mwhudson: across the whole tree?
<zyga> mwhudson: well, I don't mind that, though I don't see how that helps us this week (fire squad)
<mwhudson> zyga: i saw something about spread not building with go 1.6?
<zyga> ah
<zyga> mvo fixed that earlier today
<mwhudson> ok
<mwhudson> never mind me then :)
<zyga> mwhudson: but thank you for the offer
<zyga> we are working through this list: https://forum.snapcraft.io/t/issues-to-address-ahead-of-ubuntu-18-04-release/4954/1
<mup> PR snapd#5036 opened: overlord/snapstate: allow to get an error from readInfo instead of a broken stub, use it in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5036>
<pedronis> mvo: Chipaca: ^
<mvo> pedronis: thank you!
<mborzecki> hmmm /snap/README, there goes ConditionExistsGlob
<Chipaca> mborzecki: /snap/*/current
<mborzecki> Chipaca: oh, that's good
<mborzecki> pedronis: just to be sure, that's an /snap/.. OR /var/lib/../seed.yaml ?
<mvo> mborzecki: yes, either of those should trigger a wakeup
<Chipaca> Apr 12 11:09:21 fleet snapd[7512]: 2018/04/12 11:09:21.252174 services.go:226: DEBUG: StopServices called for [%!q(*snap.AppInfo=&{0xc820397600 webserver [] command-webserver.wrapper simple 0        map[network:0xc8203f9270 network-bind:0xc8203f92c0] map[] map[] {[] map[]} [] [] <nil>})], reason: remove
<mup> PR #12: Bugfix/lp1480248 test reenable <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/12>
<Chipaca> hmmm
<mborzecki> mvo: ok
<Chipaca> something awry in a printf :-)
<mvo> Chipaca: woah, where did you get this?
<Chipaca> mvo: snap remove a snap with a service with debug on
<Chipaca> i looped installing/removing a snap without a service and it couldn't repro 1616629, so now trying with a service
<pedronis> Chipaca: doInstall also has int flags, yes but things that are exported or go into state I agree we shouldn't use int flags
<Chipaca> pedronis: we still have a lot of int flags, and i don't think it's a blocker
<mborzecki> so the wakeup service works
<mborzecki> spread test for this will be tricky
<zyga> jdstrand: hey
<zyga> jdstrand: is apparmor@lists.ubuntu.com still the place to send patches?
<mwhudson> sergiusens: fwiw 'd bet patchelf is doing something differently horrible to java
<mwhudson> +i
<mup> Issue snapcraft#1676 closed: Support for set-version <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1676>
<mup> PR snapcraft#2063 closed: many: add snapcraftctl set-version <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2063>
<pedronis> Chipaca: btw seems we don't have undo on error code in doMountSnap, not sure it's good time to add that tough
<mborzecki> pedronis: where?
<mup> PR snapd#5037 opened: snap: snap.AppInfo is now a fmt.Stringer <Created by chipaca> <https://github.com/snapcore/snapd/pull/5037>
<Chipaca> pedronis: undo as in in-task undo?
<Chipaca> mvo ^ 5037 fixes that %!q thing
<mvo> Chipaca: nice
<pedronis> Chipaca: yes, in-task undo
<mborzecki> pedronis: around readInfo?
<Chipaca> pedronis: what are we missing?
<Chipaca> pedronis: removing the mount unit?
 * Chipaca looks
<pedronis> removing the mount unit
<pedronis> I suppose
<pedronis> in fairness SetupSnap is an opaque name
<Chipaca> no, we remove the unit
<Chipaca> one rror
<Chipaca> RemoveSnapFiles removes the unit
<Chipaca> stops and removes, even
<pedronis> yes, but now ReadInfo itself can fail
<pedronis> (well it always could but not materially)
<Chipaca> pedronis: ah! now i gotcha
<Chipaca> pedronis: sounds like you want a m.backend.RemoveSnapFiles there then
<pedronis> yes, seems so
<Chipaca> or maybe UndoSnapSetup?
<Chipaca> UndoSetupSnap*
<Chipaca> which, er, just calls RemoveSnapFIles :-) but might make the intent clearer from the calling side
<pedronis> yes
<zyga> woah?
<zyga> WOAH
<zyga> mvo: wanna hear a funny story?
<zyga> my test
<pedronis> Chipaca: sadly that thing needs a type
<zyga> where I ate 8GB of ram pretty quickly
<zyga> this was my command
<zyga> sudo sh -c 'for i in $(seq 10000); do snap connect test-snapd-policy-app-consumer:bluez && snap disconnect test-snapd-policy-app-consumer:bluez; done'
<zyga> I took a snapshot of all the profiles before/after this
<zyga> before disconnect and after disconnect
<zyga> it was connected initially
<zyga> and the profiles are identical
<zyga> all the apparmor profiles on my system
<zyga> so we were leaking all that memory _despite_ not having _any_ changes
<Chipaca> pedronis: which thing?
<pedronis> UndoSnapSetup
<pedronis> sorry, UndoSetupSnap
<pedronis> now, that IÂ look at the code, there's a lot of silliness going on
<zyga> so, a bit of a WTF moment
<Chipaca> pedronis: :-)
<zyga> I will write a loop that recompiles that one profile in a loop and see if that is eating any memory
<pedronis> Chipaca: SnapSetup read the type from the snap,   and the its caller tries to read the type from the mount
<Chipaca> zyga: wtf yes
<zyga> iff it does that's also very interesting
<zyga> because apparmor parser supposedly does nothing when you are not really changing the profile
<Chipaca> zyga: the 8G is kernel, not snapd?
<zyga> so perhaps simply reading one of the apparmorfs files leaks
<zyga> Chipaca: yes
<Chipaca> noice
<zyga> almost all in kmalloc-1024
<zyga> I'm on mainline master
<zyga> so that should give us all the fixes
<zyga> I'll start by confirming the loop I used before still leaks
<pedronis> Chipaca: so apart details of how is easy it is to untangle this,   the readInfo is not stricly needed, it's a nice fence though
<Chipaca> pedronis: only if we check the error
<pedronis> but then we need the type to undo
<pedronis> IÂ wonder how painful it is to add returning the type to SetupSnap
<pedronis> and how tisky
<pedronis> risky even
<popey> jdstrand: updating the machine (kernel) fixed that issue, thanks.
<zyga> mvo: I have a feeling this issue, whatever it is, is fixed in mainline
<zyga> so it _might_ be in ubuntu sauce
<pedronis> Chipaca: I'll try to see what I can do
<zyga> or just not present in mainline
<zyga> I'm on a mainline kernel now
<Chipaca> pedronis: you could even return the whole info
<Chipaca> pedronis: and avoid that readinfo entirely
<zyga> I'll leave it running for 15 minutes
<Chipaca> ah, but we only use the type
<mborzecki> what would be the idiomatic way to disable just one service in debian/rules?
<Chipaca> pedronis: now i gotcha
<zyga> but even if it is raising, it's doing so at a far slower pace
<pedronis> the readInfo is realy a check, it this thing mounted at all
<Chipaca> mborzecki: carg-cult copying of a 2MB bash file, probably
<pedronis> but yes we need only the type
<zyga> jdstrand: ^ FYI
<Chipaca> zyga: the 8GB was also on mainline, and the difference now is just reloading in a loop?
<zyga> Chipaca: AFAIK we never used mainline kernel before
<zyga> on the ubuntu kernel we quickly eat memory
<Chipaca> zyga: so the 8GB was on ubuntu kernel?
<zyga> yes
<sparkiegeek> *cough* is the forum inaccessible to everyone, or just me?
<zyga> sparkiegeek: oh?
<zyga> I _just now_ posted a message
<zyga> https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/11?u=zyga
<sparkiegeek> zyga: The certificate expired on 12 April 2018, 11:17. The current time is 12 April 2018, 12:01
<sparkiegeek> zyga: with HSTS enabled
<zyga> oops :)
<zyga> perhaps my browser is more lousy
<Chipaca> i also don't see that fwiw
<zyga> niemeyer: ^ FYI, it looks like forum cert is has expired
<sparkiegeek> https://www.ssllabs.com/ssltest/analyze.html?d=forum.snapcraft.io&latest
<sparkiegeek> confirms that it's expired
<zyga> after running for ~10 minutes my memory usage is below 2GB
<Chipaca> speaking of expiry, i need to go make lunch for the tribe
<Chipaca> ttfn
<sparkiegeek> Chipaca: bon appetit
<niemeyer> zyga: Yeah, I was going to make sure it was renewed yesterday and missed it...
<niemeyer> I'm on it
<zyga> woot, thanks
<vidal72[m]> are you aware of expired cert for https://forum.snapcraft.io ?
<sparkiegeek> vidal72[m]: has just been fixed
<vidal72[m]> sparkiegeek: I can confirm, thx
<mup> PR snapd#5038 opened: data/systemd: helper service for waking up the main snapd service <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5038>
<jdstrand> popey: nice!
<jdstrand> zyga: yes, posting your findings to the mailing list would make sense, or adding to https://bugs.launchpad.net/apparmor/+bug/1750594
<mup> Bug #1750594: Eventual OOM with profile reloads <AppArmor:New> <https://launchpad.net/bugs/1750594>
<zyga> jdstrand: nice, thanks
<zyga> jdstrand: I found some interesting things already: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/11?u=zyga
<zyga> and sent some silly patches to apparmor tree
<jdstrand> zyga: I see that. that should help jjohansen. I also summarized the email I sent yesterday in that topic
<zyga> I see that, thanks
<sergiusens> mwhudson: yeah, it seems to be the case as it is not an isolated incident
<mwhudson> sergiusens: reading the patchelf code makes it seem a bit ... optimistic, maybe?
<sergiusens> mwhudson: eventually I will have to do what I wanted to avoid doing when tasked to work on classic confinement and just master that code base and elf
<mwhudson> sergiusens: i learnt waaaay too much about all that stuff doing go shared libraries
<mwhudson> it's fun, mostly :)
<mup> PR snapd#5039 opened: overlord/snapstate: use the readInfo in doMountSnap as a check only, undo if it errors <Created by pedronis> <https://github.com/snapcore/snapd/pull/5039>
<pedronis> Chipaca: mvo: digging deeper ^
<mwhudson> sergiusens: have you read ian lance taylor's blog? https://www.airs.com/blog/archives/38 through https://www.airs.com/blog/archives/57
<sergiusens> I have not; adding to the reading list. Thanks!
<didrocks> cjwatson: hey, sorry if the question was probably already asked (it was probably already done), but is there any way to get daily build of a snap (even if the branch didn't change, as a snapcraft.yaml can refer to multiple repos) on https://build.snapcraft.io/ or launchpad?
<didrocks> I guess the workaround can be to use launchpad API to start a build, but I would prefer something more integrated
<mup> PR snapcraft#2065 opened: many: update the yaml loading logic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2065>
<popey> didrocks: i personally use lp-build-snap (a snap) to poke the launchpad API daily via a cron job to do that
<popey> build does do daily builds now AIUI.
<didrocks> popey: oh? (well, I guess it's still building on xenial, which is an issue for me), but I didn't find any option
<popey> it doesnt have to be building on xenial
<popey> you can pick in your repo what it builds on
<didrocks> on build.snapcraft.io?
<popey> no, launchpad
<popey> I dont use build, because i need the flexibility launchpad offers
<didrocks> ah yeah, for this, sure :)
<popey> build isn't supposed to cover every use case.
<didrocks> "build does do daily builds now AIUI" -> you meant launchpad or build.snapcraft.io?
 * cachio afk
<popey> build
<didrocks> ok ;) so yeah, I have to use launchpad and having a ping script (like lp-build-snap) seems necessary
<didrocks> thanks popey ;)
<popey> np
<mup> PR snapd#5037 closed: snap: snap.AppInfo is now a fmt.Stringer <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/5037>
<mborzecki> finishing up with spread test
<cjwatson> didrocks: the above all seems correct.
<didrocks> thx for confirming cjwatson
<mborzecki> off to pick up the kids, coming back for standup
<zyga> jdstrand: some more leak findings on the forum
<mup> PR snapd#5040 opened: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5040>
<zyga> mvo: I have to break now and go to the vet but I can propose a simple tweak to apparmor backend to limit memory usage
<mup> PR snapd#5041 opened: interfaces/apparmor: don't reload unchanged profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/5041>
<zyga> mvo: hey
<zyga> mvo: can you run adt tests against that PR somehow?
<zyga> I need to break now and go to the vet or I will miss my time
<zyga> I will resume my analysis later today,
<mvo> zyga: yeah, I can
<zyga> thanks
<zyga> I'll go now, I'll be on telegram/irc on the phone though
 * kalikiana lunch
<diddledan> popey: for atom, in snapcrafters, there's a new release upstream (a point release: x.y.1) do I just need to trigger a manual build in the build service to get it to update?
<diddledan> alternatively, Wimpress ^^^^
<Wimpress> Yep
<diddledan> aww, it says I don't have admin perms on the github repo so I can't trigger it :-(
<zyga> mvo: standup postponed by one hour, right?
<pedronis> mvo: IÂ proposed a chain of PR,   John reviewed them, we need to decide a bit what to do with them (whether we care more to understand the bug vs preventing it)
<pedronis> it's also rare afawk
<mvo> pedronis: I have a look, thank you and Chipaca
<pedronis> mvo: I also tried to play with remove/install while keeping the old mount in use, but seems to just work
<pedronis> at least here
<mvo> zyga: standup is in 3min
<mvo> mborzecki: I think I figured the refresh-mode issue out
<mborzecki> mvo: what was it?
<zyga> mvo: Gustavo asked to postpone
<mvo> zyga: oh, ok, sorry, I miseed that
<mvo> zyga: in this case, sure
<pedronis> by 1h
<mvo> mborzecki: we need KillMode=process in the service file for the non -all signal because it looks like system cleans up the whole cgroup if the main pid dies otherwise
<mvo> mborzecki: which makes sense
<mvo> mborzecki: I changed the test a bit and added some code to do this and *hopefully* this fixes this
<mborzecki> mvo: a maze of manpages
<mvo> mborzecki: I looked at the source :)
<mvo> mborzecki: but yeah, its a bit difficult to get the picture
<mvo> mborzecki: I may still miss pieces but it all makes some sense now
 * mvo is a happy camper again
<pedronis> it's a maze of non-orthogonal settings
<pedronis> btw it does make sense
<pedronis> :/
<mborzecki> mvo: does ssytemctl stop work correctly still?
<pedronis> probably not
<pedronis> we need to specify --kill-who=all then?
<pedronis> for when is not just a refresh
<pedronis> but that's the default
<pedronis> mborzecki: my reading is that stop will kill all processes one by one, instead of killing the cgroup
<pedronis> (I haven't tried)
<mvo> mborzecki: looking now, sorry for the delay
<mvo> pedronis: yeah
 * pedronis needs a break
<mborzecki> there's a problem with snapd.wakeup.service on fedora, it's disabled by systemd presets, explicitly enabling it will probably make Son_Goku unhappy
<mborzecki> and fedora has presets
<Son_Goku> it needs to be requested to be enabled via central presets
<mborzecki> opensuse has none?
<mborzecki> Son_Goku: bz ticket then?
<Son_Goku> yep
<Son_Goku> openSUSE has central presets too
<popey> diddledan: thanks for the ping - I triggered a build
<pedronis> mborzecki: can't we do it only on ubuntu, and keep the other distros as is for now
<diddledan> thankyou popey
<mborzecki> pedronis: yeah, i'm afraid that's what we'll have to do
<mvo> mborzecki, pedronis you are right about the "stop", with KillMode=process the refresh mode works like we want it to work (yay) but the side-effect of course is that "systemctl stop service-that-uses-refresh-mode-sig{term,hup,..}" also only stops the main process
<mborzecki> omg
<mborzecki> mvo: mixed?
<mvo> mborzecki: oh
<mvo> mborzecki: let me try that
<pedronis> mvo: btw, how did the autopkgtests in xenial go?
<mvo> pedronis: it died in interfaces-many but I try again without this one, this test is especially problematic
<pedronis> ok, but at least unblocked
<pedronis> thx
<mvo> pedronis: well, not sure yet if unblocked or not, I had to restart
<pedronis> well, it's no worse than bionic
<pedronis> something runs :)
 * pedronis is about the small victories these days
<mvo> pedronis: heh, yeah
<mvo> mborzecki: test with mixed running now :)
<greyback> kalikiana: hey, snapcraft stuck at "Preparing to build desktop-gtk3" for me, using 100% of a cpu. How could I track down what's wrong?
<mvo> mborzecki: the way I read it I don't have high hopes *but* I was wrong before!
<mborzecki> mvo: aiui if the main process ignores sigterm kill is tried again, but this time everyone gets sigkill
<mvo> cachio: how is the sru validation going? any fires there?
<mvo> mborzecki: oh, that would be what we want I think. if the main process dies the rest is ignored if it does not die/restart the entire group is killed
<cachio> mvo, hey
<cachio> I finished it
<mvo> cachio: yay, any issues?
<mvo> mborzecki: the answer is just a spread run (and some patience) away :-D
<cachio> mvo, but I saw the oom on autopackgtests for i386
<mborzecki> mvo: patience is key today
<cachio> for artful and bionic
<zyga> mvo: hey, just checking about that auto package test in my PR
<zyga> Is it triggered, I cannot see that on the pull request page
<cachio> mvo, that's the only relevant issue
<cachio> mvo, I think it is because of the environment
<jbicha> hi, somehow my gnome-characters snap got disconnected from the gnome-3-26-1604 snap. I'm on bionic and it used to work. I'm using stable channels for this stuff
<jbicha> how can I figure out how this happened?
<mvo> cachio: yeah, the oom is what we also see everywhere its a sad and known issue
<cachio> the rest is
<cachio> ok
<cachio> mvo, well known issues on autopckgtests
<mvo> cachio: great, I think we can document that in the bug and then move on and set it to validated
<mvo> cachio: are there more known issue that need addressing?
<cachio> yes
<cachio> mvo, just that the tests on xenial are not being executed because spread cannot be built
<mvo> mborzecki: mixed did not work the way we want it to work, it did kill the children
<mvo> cachio: spread is fixed now
<mvo> cachio: since last night :)
<mvo> cachio: gustavo applied my fix (yay)
<cachio> mvo, great
<cachio> mvo, ok, but it failed for the sru :(
<mvo> zyga: tests are running, I had to restart because it died in interfaces-many?
<mvo> cachio: http://autopkgtest.ubuntu.com/browse.cgi/packages/s/snapd <- xenial is mostly green again
<jbicha> hmm, gnome-characters worked after restarting my computer ð¦
<mvo> cachio: I manually restarted some
<cachio> mvo, nice
<cachio> thankis
<mvo> zyga: interfaces-many is a bit of a beast, I disabled that (and it is already disabled for autopkgtest)
<mvo> zyga: so if the run survives the remaining tests, that would be huge
<mvo> zyga: its at 17/224 right now
<zyga>  Thanks
<greyback> kalikiana: ignore me, seems it was doing legitimate work
<mup> PR snapd#5042 opened: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5042>
<cachio> mvo, sru in lp updated
 * kalikiana totally ignores greyback and walks away again
<greyback> kalikiana: I'm trying to use cleanbuild, where my part has its source in a directory elsewhere in the system. It builds ok with dirty build, but with cleanbuild it complains it cannot determine the source type - and I see no source type specifier for a directory
<greyback> any ideas?
<kenvandine> jbicha, so it resolved itself on reboot?
<jbicha> kenvandine: yes
<kenvandine> :/
<kalikiana> greyback: elsewhere meaning outside of the source tree? is it a folder?
<greyback> kalikiana: correct, and yes
<kalikiana> greyback: so how do you get the folder into the container?
<greyback> kalikiana: I'm not, hence the problem.
<kalikiana> greyback: Can you manually copy it to the tree? Well, or if that's not an option, you could... use a persistent container that you've prepared beforehand.
<greyback> kalikiana: I'm doing option 2.
<greyback> kalikiana: I'll log a bug tho
<kalikiana> greyback: Okay.
<greyback> kalikiana: https://bugs.launchpad.net/snapcraft/+bug/1763394
<mup> Bug #1763394: cleanbuild gets confused with directory source type <Snapcraft:New> <https://launchpad.net/bugs/1763394>
<kalikiana> Thanks!
<Chipaca> hah, browser crashed
<Chipaca> and now y'all're gone
<pedronis> mvo: about my PRs, the easiest is probably to squash merge #5040 with everything (so it's easier to backport for the SRU)  but IÂ can wait for that, as you prefer
<mup> PR #5040: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <https://github.com/snapcore/snapd/pull/5040>
<mvo> pedronis: yeah, otoh, its just three commits so we can just backport those via three cherry-picks (hopefully not too many conflicts)
<pedronis> mvo: as your prefer
<pedronis> you I merge them today? or wait a bit?
<pedronis> sorry
<pedronis> mvo: should I merge them today or wait a bit?
<mup> PR snapd#5042 closed: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5042>
<pedronis> mvo: I marked them blocked for now, let me know
<mvo> zyga: adt run died with oom in 153/224, sorry for that
<mvo> pedronis: either is fine, its edge so feel free to merge and we can backport at our leisure
<pedronis> mvo: IÂ think I'll merge them tomorrow,  IÂ need to EOD in a bit to go to some event
<pedronis> for some of my evening
<pstolowski> zyga: one question to 5401
<mvo> pedronis: sure, enjoy
<mvo> pedronis: its not urgent
<pedronis> mvo: I don't think we have fires not under control at this point,  I can be pinged on TG if needed
<jdstrand> zyga: thanks for those patches! nothing silly about typo fixes :)
<mvo> pedronis: yeah, thanks for all the fires you extinguished! have a great evening
<zyga> pstolowski: ack, looking
<zyga> pstolowski: replied
<zyga> mvo: do you have an URL to the test results?
<pstolowski> zyga: thanks!
<mvo> zyga: I ran it locally
<zyga> ah
<zyga> and? :-)
<mvo> zyga: its easy to reproduce, just use the ubuntu-18.04-32 image
<mvo> zyga: it died at test 153 or so :(
<zyga> :/
<mvo> zyga: what kind of data do you want?
<zyga> crap, same way as before, right?
<zyga> mvo: I wanted a pass/fail status, I got that
<mvo> zyga: yeah, *maybe* it survived longer
<mvo> zyga: but its hard to say as the pattern is not consistent, I would have to run with the same -seed= setting once with the branch and once without
<zyga> I will do more checks at home, I need to write a small automatic program that triggers the bug and checks that memory is leaking
<zyga> then try all the kernels gustavo suggested
<mvo> zyga: cool, thanks
<popey> diddledan: atom now in stable, thanks for the nudge
 * zyga is starving, having feed the dog I need to eat something myself
<mup> PR snapd#5043 opened: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<mup> PR snapcraft#2061 closed: go: only use Go build package if not using the snap <Created by kalikiana> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/pull/2061>
<mvo> Chipaca: 5043 might also be interessting for you, I think it is really as simple as this, when systemd sees the main-pid die it goes into stop-state which triggers the cleanups. but double checking is certainly appreciated
 * kalikiana eod, o/
<suebt> zyga: hey there :]
<zyga> suebt: hi
<Chipaca> mvo: what happens in 5043 if start-refresh-mode-sigterm tries a little harder?
<zyga> Iâm busy now, sorry, no change yet. Iâll tell you what I know back home
<suebt> zyga: Okay, no problem, will hang around for a while, thank you
<zyga> Sorry for keeping you waiting. It is a busy day
<Chipaca> mvo: i mean, something like 'setsid nohup sleep' instead of just sleep :-)
<mup> PR snapcraft#2066 opened: errors: feature flag error reports <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2066>
<nacc> is there possibly a bug in snapd that let's older snaps get unmounted when they are in use?
<nacc> :)
<nacc> *older snap revisions
<nacc> specifically, i've got a long-running app from a snap in the edge channel, which is building from master
<nacc> it was at r409, now at r418
<nacc> the r409 run ended up dying suddenly because it could not find executables in it's squashfs
<nacc> i'm guessing because it got unmounted on some update
<Chipaca> nacc: we have a bug around long-running processes and refreshes
<Chipaca> nacc: basically if an app is running, and the snap gets refreshed, the file descriptors it has are now useless
<nacc> Chipaca: yeah
<nacc> that's ... seriously bad for us
<Chipaca> nacc: it's on the 'fix soon' list, i think it's one of the first things zyga will work on post 18.04
<Chipaca> nacc: how so?
<nacc> Chipaca: because we are importing Ubuntu source packages using a snap and it crashes
<nacc> for 'official' Ubuntu use :)
<Chipaca> nacc: you are importing Ubuntu source packages using a snap, and the snap refreshes while the import is happening? Every time?
<nacc> Chipaca: the snap *can* refresh while it is happening yes
<nacc> not every time, but when it does, this clearly would break things
<nacc> so we have an importer, which is short-lived (sort of)
<nacc> and control scripts which are long-lived (watching the publisher itself)
<nacc> the latter is quite long-lived (one never dies)
<Chipaca> nacc: long lived but not a daemon?
<nacc> Chipaca: right, not yet
<nacc> would a daemon avoid this?
<Chipaca> nacc: the daemon would be restarted on refresh (unless you ask not to be, but then presumably you're only using _COMMON
<nacc> Chipaca: restarting the daemon is 'bad' for us, sort of too
<nacc> Chipaca: hence why it's not a daemon yet :)
<Chipaca> nacc: as a short term workaround you can ask snapd to hold off refreshes until you're done
<nacc> Chipaca: yeah, i might need to do that, quick syntax/cli?
<Chipaca> nacc: ach, i always get that one wrong
<nacc> :)
<Chipaca> it's 'snap set <something something>'
<Chipaca> :-)
<Chipaca> mvo knows -- and it should be documented
<Chipaca> and I've got to go make dinner
<nacc> Chipaca: np, i'll look it up
<nacc> https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/6 i think
<Chipaca> nacc: snap set core refresh.hold=<when>
<Chipaca> nacc: some work to be done around the UX of it though
<mup> Issue snapcraft#2033 closed: LP: #1752344 <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2033>
<mup> PR snapcraft#2065 closed: many: update the yaml loading logic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2065>
<nacc> Chipaca: thanks
<Chipaca> nacc: it requires a timestamp (the error will show you the format)
<nacc> Chipaca: ok :)
<Chipaca> nacc: but the expectation is that a script or something would say "give me 5 minutes" every 5 minutes until it was done
<Chipaca> hence, ux needs more work (or maybe an interface that isn't 'snap set')
<Chipaca> anyhoo. dinner.
<zyga> nacc: refresh sanity is on my plate post 18.04
<zyga> Is the bug related to an apparmor denial?
<nacc> zyga: Chipaca: thanks, i was able to set it to be at least a week away
<nacc> zyga: is that to me?
<zyga> Yes
<nacc> zyga: no apparmor denials in dmesg
<zyga> About refresh breaking some source import
<nacc> zyga: it just failed to find the `git` binary that was in the snap
<zyga> Can you let me know what is the problem?
<nacc> because, i'm guessing, the fd was closed underneath it
<zyga> Hmmm
<Chipaca> o/
<zyga> It would not be closed
<zyga> But can be revalidated
<zyga> But that would log a denial
<zyga> Can you give me a link to a case that reproduces the issue
<nacc> zyga: i don't have the logs handy anymore, but i can try and scrape them (about to leave though) -- basically our snap was running (git-ubuntu.source-package-walker) ... and it ran for some time
<nacc> at an older review
<nacc> *revision
<zyga> Including a refresh to another channel in a side terminal is ok if that helps
<nacc> we then refreshed (auto) edge from which we're running
<zyga> Is that snap classic or strict?
<nacc> at some point, we must have gotten past the 'keep 2 versions' or whatever snapd does
<nacc> classic
<nacc> and our snap crashes becasue it's unable to find an executable that is in the snap
<zyga> Hmmm
<nacc> i believe with a 'no such file or directory'
<zyga> Classic snaps have no constraints
<zyga> So it is probably another part
<zyga> Thanks
<zyga> I know what I needed now
<zyga> Right, I understand why this happens
<nacc> confirmed i got a no such file or directory for 'git' in our case (which we build from source and is in our snap's path)
<nacc> zyga: ok :)
<zyga> Thank you
<nacc> zyga: we admittedly are a weird classic snap -- we are basically confined (by munging the environment) but we need to be able to write anywhere on the fs
<zyga> re
<zyga> nacc: classic snaps are confined but have wide open permissions and are not sealed in a mount namespace
<nacc> zyga: yeah i know
<nacc> well the former part is why :)
<nacc> *why we use a classic snap
<zyga> to have access to /var/lib/snapd/hostfs easily?
<zyga> (as in, at /)
<nacc> zyga: yeah basically (and network)
<nacc> but network obviously we could use an interface for
<nacc> last i checked there was not a 'hostfs' interface
<zyga> network?
<zyga> network should not be a problem
<zyga> we could add an interface for hostfs and hand it out just like classic
<zyga> if that helps
<nacc> zyga: that would probably help us, yes
<nacc> not sure if we have other needs, but that woudl be my guess right now
<nacc> zyga: gotta go afk for a bit
<zyga> thanks, no worries :)
 * zyga is still at school, waiting to talk to the teacher
 * zyga is very sleepy somehow
<mup> PR snapcraft#2067 opened: many: add snapcraftctl set-grade <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2067>
 * zyga returns for evening hacking
<zyga> jdstrand: hey, can you please look at https://github.com/snapcore/snapd/pull/5041 and specifically at the question from pawel as well as my response there
<mup> PR #5041: interfaces/apparmor: don't reload unchanged profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/5041>
<zyga> jdstrand: I'm mainly trying to raise any red flags that you may notice
 * cachio afk
<mup> PR snapcraft#2068 opened: states: track override scriptlets <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2068>
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<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>
<jjohansen> zyga, mvo: with your testing you are only seeing this with the bionic kernel?
<mup> Issue snapcraft#1681 closed: Design/document support for architecture selection during builds <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1681>
#snappy 2018-04-13
<mup> PR snapcraft#2066 closed: errors: feature flag error reports <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2066>
<mup> PR snapcraft#2069 opened: Reports <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2069>
<zyga> jjohansen: artful is also affected. I will give you more results today
<jjohansen> zyga: ah good, I was going through the diff and going htf is artful not affected and bionic is :)
<zyga> Mainline is not affected or very little
<zyga> Loading one profile over and over leaks very very quickly
<zyga> Maybe some new table is not released?
<zyga> I wrote some tests but went to sleep. I will keep looking today
<jjohansen> mainline certainly has a leak
<jjohansen> which kernel version for mainline are you not seeing it on?
<jjohansen> zyga: ^
<zyga> jjohansen: I built mainline from yesterday, I was at e241e3f2bf97
<jjohansen> okay, thanks
<zyga> jjohansen: when I say there was no leak I mean that loading a profile over and over (unchanged) ran for over 30 minutes with minimal memory bump (probably noise from other programs)
<zyga> jjohansen: at most 300MB
<zyga> jjohansen: on a affected kernel a few minutes of this would consume all my ram
<zyga> jjohansen: I will give you more data soon, sorry, yesterday I just collapsed
<zyga> jjohansen: this is the base64-encoded binary profile I was loading in a loop http://paste.ubuntu.com/p/Jfs3RRKcPw/
<zyga> jjohansen: on 4.13.16 inserting that 10K times leaks 440MB
<zyga> (on amd64)
<zyga> jjohansen: perhaps other profiles we tested inside spread+snapd leaked more memory but I wanted to keep using one profile for experiments
<mborzecki> morning
<zyga> hey mborzecki, good morning
<mborzecki> any fires today?
<zyga> mborzecki: no, I think all is the same for now
<zyga> jjohansen: on xenial kernel the jump is from 946 all the way up to ~2GB
<zyga> (this time using distribution kernel, not my build of the corresponding tag)
<zyga> jjohansen: xenial kernel is misleading, this was 4.13.0-37
<zyga> jjohansen: 4.4.0-119 on xenial is also affected but very slightly so, same profile, same count, 626MB->660MB
<zyga> jjohansen: I'll test intermediate kernels now
<zyga> jjohansen: 4.8.0-58 goes from 699M -> 773M
<zyga> jjohansen: 4.10.0-42 goes from 698M -> 723M
<zyga> jjohansen: so that feels like noise so far
<zyga> the real jump is in 4.13
<zyga> where we drop significant amount of memory
<zyga> jjohansen: 4.15.0-13 goes from 640M to 1.61G
<zyga> jjohansen: so for all practical purpose the diff between 4.10 and 4.13 has introduced the major part of the leak
<zyga> jjohansen: but note that even on 4.4 there's some memory going somewhere, maybe that's just slab growing
<zyga> jjohansen: I'll introduce a variant that does 10M insertions to see if slab stabilizes
<mborzecki> zyga: do you know if issue #3 'Memory use on minimal/constrained systems' had any further developments?
<zyga> jjohansen: on the xenial 4.4 kernel 10M insertions doesn't seem to actually leak memory, after some initial growth (of non-free memory) slab stabilises at 929M and just stays there
<zyga> mborzecki: no, I didn't focus on it
<mborzecki> i know we said it's won'tfix for 18.04, but didn't see any messages that would indicate it was further discussed later yesterday
<zyga> mborzecki: sorry, I don't know more than that
<zyga> mvo: did you end up having the meeting with cloud guys?
<zyga> I'll terminate testing 4.4., it's pretty much rock solid
<pedronis> mborzecki: hi, some of the things you worked on recently (autostart, timers? ) need to be added here https://forum.snapcraft.io/t/the-snap-format/698 ?
<mborzecki> pedronis: thanks, will do
<pedronis> mborzecki: as usual we need put then version (2.xx+) where it starts working
<mvo> zyga, mborzecki yeah, we had a meeting yesterday. we will not do anything right now, its too risky, but we want to prepare so that we can provide a fix post-release asap
<zyga> jjohansen: 4.4 is rock solid, doesn't leak memory over extreme number of insertions, I'm looking at 4.10 now and it also looks good, memory use stops at ~1.03GB after 10s of thousands of insertions
<zyga> jjohansen: I'll keep it running for some more time and then try 4.13 where I suspect we really leak memory constantly
<zyga> mvo: sounds very godo
<zyga> good
<mborzecki> pedronis: mvo: one thing about exiting when idle, we don't have snap.refresh.timer anymore to wake us up, but we could schedule a command to run as a on-demand timer using systemd-run
<kalikiana> moin moin
<mvo> zyga: nice findings on the kernel mem leak front
<mvo> mborzecki: indeed
<zyga> mvo: i hope we can find the leak soon enough :-)
<pstolowski> good morning
<pedronis> mborzecki: it depends what's the goal
<pedronis> mvo: is the plan to make exit on idle, generalized behavior?
<pedronis> mvo: did you discuss just timings or also a bit the goals?
<pedronis> mborzecki: is setting configuration with "set system"Â  landed?
<mborzecki> pedronis: yes
<pedronis> it's on edge but not 2.32 , right?
<mborzecki> but iirc it's in master only
<pedronis> ok
<pedronis> bit unfortunate, but oh well
<mborzecki> hm timer services are in egde too
<mborzecki> but not in 2.32.*
<pedronis> ah
 * pedronis admits to have lost track of things a bit (2.32 being so long lived)
<pedronis> mborzecki: anyway that's bit less of an issue
<pedronis> the issue with set core vs set system is that it must work before one installs core
<mvo> pedronis: gustavo preferes the wake up, do stuff, exit approach over not doing anything at all. but its still a bit undecided so worthwhile to have another meeting to discuss options. I personally still favour the "do as little as possible via units" approach
<mvo> pedronis: yeah, 2.32 is the new 2.33 :/ its a bit annoying
<pedronis> so basically we need to document set core  and support it
<pedronis> for the life of bionic
<pedronis> (more or less)
<pedronis> mvo: discussion for monday I suppose?
<mvo> pedronis: yeah, *maybe* today but I think gustavo is pretty busy today
<mborzecki> pedronis: it's 2 small patches, should be easy to cherry-pick in case we want fixes in 2.32
<pedronis> it's too late IÂ think
<mvo> mborzecki: you can prepare a PR and target it so that *if* we need to rebuild we have it. but I'm with pedronis probably too late
<mborzecki> mvo: sure
<pedronis> mvo: so IÂ imagine we concluded that it's called 2.32.4 , not 2.33 ?
<mvo> pedronis: yes, I had a call with Adam about it, the amount of work to make it 2.33 is just too high at this point
<pedronis> IÂ don't think we have promised/enforced minor releases to be small or have no features
<pedronis> we try to
<pedronis> in theory we have assumes , but seems they stay unused
<pedronis> (anyway they are not relevant for the API, it's transparent)
<mup> PR snapd#5044 opened: 'system' nickname for 'core' in snap get/set (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5044>
<pedronis> mvo: I'm going to merge my PRs about doMountSnap,  should IÂ prepare cherry-picks?  or will you later?
<mup> PR snapd#5036 closed: overlord/snapstate: allow to get an error from readInfo instead of a broken stub, use it in doMountSnap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5036>
 * pedronis is clearly not rested enough
<Caelum> zyga: I posted on opensuse-packaging, but it's a very low traffic list, will let you know if I get any replies
<mborzecki> 5038 failing on travis, works if i run it from host, cleaned the git tree but still
<mborzecki> and it's awkward, afaict all services are getting enabled by dh snippets in postinst, but the snapd.wakeup.service is disabled when the test starts
<mborzecki> https://media1.giphy.com/media/12NUbkX6p4xOO4/giphy.gif probably
<zyga> Caelum: perfect, thanks!
<mborzecki> i really have packaging at times
<cwayne> if only someone invented a simple way to package stuff!
<zyga> slackware?
<mborzecki> zyga: could you take another look at https://github.com/snapcore/snapd/pull/4989 later on?
<cwayne> lol
<mup> PR #4989: tests: add arch to CI <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4989>
<zyga> mborzecki: sure
<Chipaca> moin moin
<mvo> hey Chipaca
<Chipaca> mvo: do you remember why switch didn't have --devmode and etc?
<mvo> Chipaca: I think there is no reason, its a nice idea
<Chipaca> also what we agreed about --no-devmode
<Chipaca> ditto --classic vs --no-classic, etc
<mvo> Chipaca: iirc nobody asked that switch would have this capability but I think its a nice idea
<Chipaca> mvo: people have asked, we've just not been paying attention =)
<mvo> Chipaca: I had this problem too (wanting to swtich from strict to devmode and vice-versa)
<mvo> Chipaca: *cough*
<mvo> Chipaca: details ;)
<mvo> Chipaca: don't destroy my narative
<Chipaca> mvo: https://forum.snapcraft.io/t/refresh-into-devmode/4130 and https://forum.snapcraft.io/t/refreshing-snaps-in-devmode/4942
<Chipaca> mvo: but also I remember niemeyer had a reason for not having --no-devmode etc, but I don't remember it
<Chipaca> and I'm not sure it wasn't due to him confusing go-flags and flags, wrt --<boolean flag>=<boolean>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/4989/files#r181321369
<mup> PR #4989: tests: add arch to CI <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4989>
<mvo> Chipaca: sorry, I don't remember why we would not want --no-devmode etc
<zyga> mborzecki: after that +1
<Chipaca> mvo: how do you get out of devmode?
<mvo> Chipaca: I think you need to refresh to a new revision for this right now, no?
<Chipaca> mvo: I think so yes
<zyga> the memory leak was introduced in one of 144 patches
<zyga> I will review them quickly and see if I can automate a test loop
<zyga> interestingly this patch is in that list a7c3e901a46ff54c016d040847eda598a9e3e653
<mvo> zyga: nice
<mvo> zyga: bisect ftw
<zyga> it's not the bug yet though
<mup> PR snapd#5039 closed: overlord/snapstate: use the readInfo in doMountSnap as a check only, undo if it errors <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/5039>
<mup> PR snapd#5040 closed: overlord/snapstate: poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/5040>
<zyga> jdstrand: I didn't know we already supported loading arbitrary extended data into profiles!
<mvo> mborzecki: thanks for your review for 5043
<mvo> mborzecki: I will dig a bit more in a bit but right now I think there is no way to disentangle --kill-who=main and KllMode=process
<Chipaca> mvo: so! what can i help with today?
<mvo> Chipaca: smart ideas about 5043 are in short supply right now :)
<mup> PR snapd#5045 opened: overlord/snapstate:  poll for up to 10s if a snap is unexpectedly not mounted in doMountSnap (2.32) <Created by pedronis> <https://github.com/snapcore/snapd/pull/5045>
<pedronis> mvo:  ^ prepared the backport
<mvo> pedronis: \o/ thank you
<Chipaca> mvo: I hear good things about runit
<mvo> Chipaca: :-D
<Chipaca> mvo: :-)
<pedronis> so things that appear described as unrelated are interacting in obscure ways and are not orthogonal :/
<Chipaca> mvo: so, if I understand the issue correctly, it's that if a daemon has refresh-mode=potato but does not hangle sigpotato and instead dies, then the whole service is killed?
<mvo> Chipaca: yeah, all processes in the cgroup will be killed, that is my understanding
<Chipaca> mvo: right
<Chipaca> mvo: but isn't a daemon not handling the signal it asks to be delivered on refresh a bug?
<mvo> Chipaca: from reading the source (my understaning is still a bit incomplete) I think what happens is that the main pid dies and that triggeres sigchld in systemd which notices that the main pid of the given unit died
<mvo> Chipaca: this makes the unit enter "stop state" and systemd will do what it needs to do when this state appears. which includes the cleanup of the cgroup (AIUI)
<mvo> Chipaca: in the sigterm case what we want is that the daemon restarts, I guess one could argue it should re-exec and use the same pid
<mvo> Chipaca: this would solve the problem but I think this is not how most apps deal with it :/
<Chipaca> mvo: what are we trying to accomplish? with refresh-mode=<foo>, when the snap refreshes, we do what? and the daemon does what? and systemd does what?
<Chipaca> we=snapd there
<pstolowski> zyga: have you seen jdstrand's comment to 5041?
<mvo> Chipaca: on snap refresh with --refresh-mode=sigterm what we want is that the main process of the unit in question gets a sigterm. but that the other processes in the cgroup are left alone and survive
<mvo> Chipaca: the use case is e.g. libvirt when it has a bunch of vms running that should not stop
<mvo> Chipaca: we tell systemd to do "systemctl kill --kill-who=main -s TERM snap.name.app"
<mvo> Chipaca: instead of the usual "systemctl stop snap.name.app"
<mvo> Chipaca: making sense so far?
<Chipaca> yes
<mvo> now the problem seems to be that the option --kill-who=main is not orthogonal to KillMode= in a service file
<mvo> Chipaca: or it is but in a different way, there is some entanglement
<mvo> (the enganglement I described above, main pid dies, systemd wants to cleanup)
<Chipaca> yes
<Chipaca> mvo: what do we _want_ systemd to do?
<mvo> Chipaca: on "systemctl kill --kill-who=main" we want it to kill the main pid and leave the rest alone
<mvo> Chipaca: on unit stop we want it to stop everything
<Chipaca> mvo: do we want it to restart the thing?
<Chipaca> or _just_ kill it?
<mvo> Chipaca: do whatever is defined in Restart=
<mvo> Chipaca: it seems that this is a decision for the snap
<mvo> Chipaca: but normally it would be Restart=on-failure (which is our default)
<mvo> Chipaca: for a lot of things (SIGHUP) its a non-problem because the process will handle it and not die but sigterm is the problematic one
<mvo> Chipaca: still making sense :) ?
<Chipaca> restart=on-failure does not restart the thing when killed with TERM
<Chipaca> might this be the reason it's entering stop mode at all?
<mvo> Chipaca: I think I tested with "Restart=always"
<mvo> Chipaca: and it had no effect but I can do so again
<zyga> pstolowski: looking
<Chipaca> mvo: sigterm is like sighup, in that the process can catch it etc (sigkill is the uncatchable one)
<Chipaca> but, ok
<mvo> Chipaca: I know
<mvo> Chipaca: but it seems the services we care about do not catch it
<Chipaca> mvo: a'ight
<mvo> Chipaca: we could argue they should and the problem would go away
<Chipaca> mvo: and AIUI the problem with using KillMode is that 'stop' will no longer work as expected?
<zyga> jdstrand: I replied to your comments on 5041
<mvo> Chipaca: correct
<mvo> Chipaca: it will mean there are processes hanging around (potentially)
<Chipaca> mvo: and can ExecStop itself call systemctl?
<mvo> Chipaca: a good question, I think so, what do you have in mind?
<Chipaca> mvo: wondering whether we can manually use ExecStop to get the 'stop' behaviour we want
<Chipaca> mvo: as all the rest seems to be ok with the particular choice of restart/killmode
<mvo> Chipaca: hm, won't systemd just call ExitStop= in both cases? when kill was used and when stop was used?
<Chipaca> mvo: will it?
<mvo> Chipaca: it seems to be, I added "ExecStop=/bin/sh -c "echo foo >/tmp/foo"" and ran a kill (with Restart=always) and /tmp/foo with the content got created
<Chipaca> mvo: and is ExecStopPost _also_ run with kill?
<mvo> Chipaca: let me check
<mvo> Chipaca: yes, I also get a debug file with it
<Chipaca> mvo: it sounds to me like the lesser weevil is to document that if you use refresh-mode, systemctl stop will be weird
<mvo> Chipaca: yeah, and on remove do a extra kill --kill-who=all
<mvo> Chipaca: I can't figure another way but I can poke at it a bit more after lunch
<Chipaca> mvo: and do that on 'stop' itself also
<mvo> Chipaca: on snap stop service?
<Chipaca> ie 'snap stop' should work as expected even when systemctl stop doesn't
<mvo> Chipaca: thats a nice idea
<Chipaca> yeh
<mborzecki> re
<zyga> jjohansen, jdstrand: I took the profile with a leak and started removing features from it; I want to see if any of the newly-added features may be responsible
<zyga> jjohansen, jdstrand: I also stress-tested all of the sysfs files in apparmorfs for extensive reading and can say that they are not a factor
<zyga> (though I found one curious behaviour of the "revision" file, is that documented anywhere?
<jjohansen> the revision file's behavior is known and going to change
<zyga> jjohansen: that it "sleeps"
<zyga> jjohansen: loading an empty profile leaks as well
<zyga> jjohansen: https://github.com/zyga/apparmor-bug-leak
<zyga> loading this is sufficient https://github.com/zyga/apparmor-bug-leak/blob/master/neutered-sample.aa
<zyga> so it's not like a new optional feature is there and causes the leak
<zyga> maybe something is not unref'd?
<mborzecki> mvo: there's a failure in https://travis-ci.org/snapcore/snapd/builds/365982227?utm_source=github_status&utm_medium=notification in linode:debian-9-64:tests/main/snap-service-refresh-mode https://paste.ubuntu.com/p/cxTNbkBbtb/
<mvo> mborzecki: thanks, looking
<mborzecki> mvo: just the paste, i've restarted the build
<mvo> mborzecki: thanks, I see it in the paste I will chase that
<mvo> mborzecki: looking into this area anyway currently
<mborzecki> mvo: yup, that's what i thought :)
<zyga> jjohansen: I varied the test to insert a profile with ever-changing contents, I will check how that behaves across kernel versions
<zyga> jjohansen: I noticed that one of the things that differs between the broken and working kernels is the presence/absence of symlinks in apparmorfs/policy/profiles/$PROFILE/
<zyga> jjohansen, jdstrand: loading _different_ profiles forever on an affecter kernels doesn't leak memory
<zyga> mvo: as a workaround I can generate random garbage rule like /tmp/.snapd.bug.1234.$RANDOM r,
<zyga> mvo: and inject that into all profiles
<zyga> mvo: we will lose all caching but we will not leak
<mborzecki> pstolowski: would you like to review https://github.com/snapcore/snapd/pull/5034 ? :)
<mup> PR #5034: userd: set up journal logging streams for autostarted apps <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5034>
<mborzecki> pstolowski: it's based on 5024, so it's just the last 2 patches that are different 5034 specific
<zyga> mvo: more ideas on v
<zyga> https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/18?u=zyga
<zyga> jjohansen, jdstrand: I'm now looking at error recovery in aa_replace_profiles
<mvo> zyga: yay
<mvo> zyga: let me know if you have anything to test
<zyga> mvo: look at the options I gave
<zyga> mvo: 1 is simple but wasteful
<zyga> mvo: 2 should have no downsides but is complex
<zyga> mvo: I can prepare a test with .1 quickly
<mvo> zyga: if (1) is simple, we we just do it as an expeiment?
<zyga> surte
<zyga> *sure
<mvo> zyga: yeah, lets do it if it does not take much time on your side
<pstolowski> mborzecki: sure
<zyga> mvo: after the break, now need to do stuff at home
<pstolowski> Son_Goku: hey! am i missing something, or copr.fedorainfracloud.org doesn't actually offer an option for uploading spec+srpm as advertised on the wiki?
<zyga> pstolowski: yes you are
<Son_Goku> you can upload a srpm via the copr CLI tool
<Son_Goku> or you can upload it somewhere and tell the web ui to fetch it
<zyga> pstolowski: you should be able to from http://copr.fedorainfracloud.org/coprs/pstolowski/go-udev/packages/
<Son_Goku> ah, and you can upload the srpm from the web ui too
<Son_Goku> pstolowski: https://copr.fedorainfracloud.org/coprs/pstolowski/go-udev/add_build_upload/
<pstolowski> Son_Goku: ah, there! I was staring at the Packages -> Add New Package where you need to have git/svn
<pstolowski> thanks
<mborzecki> reminds me to drop my copr packages, they're quite old anyway
<mup> PR snapd#5046 opened: snap, wrappers, tests: rename refresh-mode -> stop-mode, endure -> skip-refresh <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5046>
<mborzecki> mvo: ^^
 * kalikiana lunch
<zyga> re
<zyga> mvo: looking at that workaround now, it will be a moment, I'm almost done
<mvo> mborzecki: \o/
<mvo> zyga: yay
<mup> Issue snapcraft#2028 closed: When asking to release to a branch that's too long, a traceback is printed that gives no hints as to the source of the error <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2028>
<mup> PR snapcraft#2059 closed: storeapi: handle 500 error response when releasing snap <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2059>
<Chipaca> mborzecki: haven't we had a release with refresh-mode already?
 * Chipaca hunts for his headphones
<mborzecki> Chipaca: yes, that's why i have some doubts about backwards compat
<mborzecki> Chipaca: standup
<mup> PR snapd#5047 opened: tests: removing linode-sru backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5047>
<mup> PR snapd#5048 opened: tests: updating bionic version for spread tests on google <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5048>
<popey> Is it "known" that opengl apps on 18.04 on binary nvidia are broken?
<zyga> popey: no
<popey> shotcut "could not initialize opengl" but works on intel
<zyga> popey: on stable?
<popey> i am on beta
<popey> but i can go back to stable to test
<zyga> popey: can you give us some more data, which hardware, which snaps, etc
<zyga> mborzecki: ^
<popey> sure
<mborzecki> popey: after standup i'll reboot and check on bionic
<popey> filing a bug to capture it
<mborzecki> popey: how does it fail? is there any log?
<popey> https://bugs.launchpad.net/snapd/+bug/1763717
<mup> Bug #1763717: some opengl applications don't work on nvidia binary driver <snapd:New> <https://launchpad.net/bugs/1763717>
<mborzecki> popey: try to /usr/lib/snapd/snap-discard-ns <snap-name>, and then capture the log with SNAPD_DEBUG=1 SNAP_CONFINE_DEBUG=1
<popey> ok
<popey> added to the bug
<mborzecki> popey: it's a classic snap
<kalikiana> re
<popey> Is that bad? :)
<mborzecki> popey: if it's a classic snap then it does not get any of the nvidia namespace setup treatment
<popey> (I mean, we'd like it to not be classic)
<zyga> popey: classic snaps don't have any support for that
<popey> so it should "just work" right?
<zyga> it depends on how it is made
<zyga> but it's something for kalikana perhaps
<zyga> we don't influence i
<zyga> we don't influence it
<zyga> it probably doesn't work
<mborzecki> popey: shotcut snap right?
<popey> yes
<zyga> because 18.04 and 16.04 differ
<popey> its in the store
<zyga> host's handling of nvidia changed
<zyga> there's nothing we can do IMO
<mborzecki> i'll probably fail on arch too, let me try
<mborzecki> popey: aborts on arch too https://paste.ubuntu.com/p/qPtZStGWth/
<popey> :(
<ogra_> you can surely do something about it in a wrapper script in the snap itself
<ogra_> (hacks)
<mborzecki> popey: i've installed all dependecies and can run shotcut directly outside of snap
<popey> I'm at a loss what we suggest the developer does for a smooth experience installing snaps on multiple distros at different releases and have it work.
<ogra_> do not use classic :)
<zyga> mvo: I'll take the dog out now but then I will be back to propose the workaround
<mvo> zyga: thank you
<zyga> popey: you _can_ use nvidia but the snap needs some code for that
<zyga> popey: talk to kalikana and sergiusens
<zyga> popey: it's doable just nobody done it
<popey> ok
<zyga> popey: snapd is not preventing that
<zyga> popey: it's just not enabling that (because it cannot)
 * zyga -> afk
<ogra_> yeah ... as i said, wrapper hackery
<Chipaca> mvo: mborzecki: so...
<Chipaca> mvo: mborzecki: removing catalogrefresh from snapd drops it (with an ~empty state) from 25MB rss to 15MB rss on start
<Chipaca> pedronis: also ^
<pedronis> catalogrefresh is all kind of evil :)
<mborzecki> Chipaca: so basically .text + .data + .bss size
 * Chipaca covers catalogrefresh's ears
<mvo> Chipaca: woah
<Chipaca> all kinds of .bs
<pedronis> this is also because of bolt db code
<mborzecki> Chipaca: heh ;)
<pedronis> I suppose
<Chipaca> pedronis: that's my assumption, yes
<mborzecki> Chipaca: with GOGC=1 RSS was 19MB
<mvo> Chipaca: nice, lets move it out into a separate helper
<mvo> Chipaca: thanks, thats a huge win
<Chipaca> mvo: now, or post-1804
<pedronis> there are some issues around auth to move it out
<Chipaca> pedronis: why? i thought it didn't auth at all
<mvo> Chipaca: depends on your schedule for today, if you have free cycles I would say asap but does not have to be *now*
<pedronis> Chipaca: we need to talk with nessita, apparently /names can be per store
<pedronis> IÂ don't know if it is yedt
<mvo> oh
<mvo> ok
<Chipaca> mvo: I'll check with nessita and work on it today
<mvo> mborzecki: I will merge your reresh-mode-endur-rename PR into my snap-rereshmode-fixes PR and work from that, ok?
<mvo> Chipaca: sounds good, thank you
<pedronis> mvo:  if we do a .5 we should consiser #5044
<mup> PR #5044: 'system' nickname for 'core' in snap get/set (2.32) <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/5044>
<pedronis> IÂ don't remember how risky it is
<mvo> pedronis: +1 (cc mborzecki if you have cycles you could prepare a backport)
<pedronis> but it would be good to have that in bionic from the start
<mvo> pedronis: iirc not risky
<pedronis> mvo: that is already the backport
<pedronis> afaiu
<mborzecki> mvo: sounds good
<mborzecki> mvo: 5044 is a backport already
<mvo> mborzecki, pedronis: aha, excellet
<mborzecki> mvo: or did you mean a backport of the rename pr?
<pedronis> mborzecki: he said he will merge the rename in his PR
<mvo> mborzecki: I meant the system one
<mborzecki> mvo: ok, so 5044 is good then ;)
<mvo> mborzecki: yes!
<mvo> mborzecki: if you want you can look into a smarter way to do https://github.com/snapcore/snapd/pull/5043/files#diff-08088787360fb3ca74a0aed4c6103b22R312
<mup> PR #5043: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<jdstrand> roadmr: hey, can you pull r1025? this turns on by default (but that doesn't matter with your django changes), improves the resquash error message for snapcraft 2.38 and fixes a typo in overrides.py
<mvo> mborzecki: i.e. what we want is to ensure that on remove everything in the unit gets killed eventually
<roadmr> jdstrand: sure thing!
<jdstrand> roadmr: thanks!
<mvo> mborzecki: so something like "check unit, anything in there left? if so send sigterm. poll for up to 5 (or 10) seconds and check every ~1s if there is anything left. then do a hard sigkill on the group
<mup> PR snapcraft#2070 opened: extractors: support for setup.py <enhancement> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2070>
<mborzeck1> gnome shell froze again :/
<zyga> Pharaoh_Atem: Hey
<zyga> I will build a test snap on top of the
<zyga> Fedora base snap this weekend
<zyga> And I will try to publish your base
<mvo> mborzecki: did you got my last messages or shall I repaste?
<mborzecki> mvo: repaste please
<pedronis> mvo: ah, IÂ wondering if we should operate a bit more like systemd when we really try to kill the whole service
<mvo> mborzecki: so something like "check unit, anything in there left? if so send sigterm. poll for up to 5 (or 10) seconds and check every ~1s if there is anything left. then do a hard sigkill on the group
<mvo> pedronis: yeah, I think on remove we must be
<mvo> <mvo> mborzecki: if you want you can look into a smarter way to do https://github.com/snapcore/snapd/pull/5043/files#diff-08088787360fb3ca74a0aed4c6103b22R312
<mup> PR #5043: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<mvo> <mvo> mborzecki: i.e. what we want is to ensure that on remove everything in the unit gets killed eventually
<mvo> mborzecki: sorry, slightly out of order
<mborzecki> that's ok
<pedronis> I left a comment there
<pedronis> about a code org question
<pedronis> and John input
<pedronis> Chipaca: you should also look at #5043
<mup> PR #5043: many: fix "refresh-mode: sig{term,hup,usr[12]}" via KillMode=process <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<Chipaca> pedronis: I did, had a long chat with mvo about it this morning
<pedronis> heh, ok
<popey> zyga: mborzecki I am not convinced this is a classic only issue. snap install mame --beta, that's not classic and doesn't work on 18.04/nvidia, but does on 16.04/intel.
<popey> I am certain this worked previously on 18.04/nvidia (because both I and Wimpress have tested it on that platform)
<zyga> Yes, It worked on 16.04 by accident
<zyga> But Ubuntu changed so it no longer does
<zyga> It probably still works on 16.04
<zyga> Chipaca can confirm as he has the right software and hardware
<Chipaca> i what now?
<popey> This doesn't feel like an optimal response to "My snap worked and now it doesn't"
<mborzecki> popey: updating my bionic install now, i'll check in a minute
<Pharaoh_Atem> zyga: ?
<mvo> pedronis: thank you, I have a look, I just added stop-mode and tweaked a bit but I need to add more tests and tweaks but I think the direction is nice
<mup> PR snapd#5046 closed: snap, wrappers, tests: rename refresh-mode -> stop-mode, endure -> skip-refresh <Created by bboozzoo> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/5046>
<Pharaoh_Atem> zyga: before we publish anything, we need permission from Fedora Council and Server WG for usage of the name 'fedora'
<zyga> Pharaoh_Atem: that's a good point
<zyga> Pharaoh_Atem: how can we get that?
<Pharaoh_Atem> probably talk to sgallagh to see how to do that
<zyga> Pharaoh_Atem: can we can publish it as phedora for now?
<zyga> for development
<zyga> before anyone can think it's ready for use
<Pharaoh_Atem> fedora-release needs to be swapped for generic-release, and then we can call it whatever
<zyga> Pharaoh_Atem: that's nice
<zyga> Pharaoh_Atem: I'll make a test snap, if we agree on the name "phedora"
<zyga> or something like thaT :)
<Pharaoh_Atem> with generic-release, the system identifies as Generic Linux :)
<Pharaoh_Atem> https://src.fedoraproject.org/rpms/generic-release/blob/master/f/generic-release.spec#_136-154
<mborzecki> popey: ohmygiraffe works fine, trying out mame now, any roms you can recommend? :)
<zyga> mborzecki: did you play golden sun?
<zyga> mborzecki: I have it on an old Nintendo console, it's an amazing game
<zyga> Pharaoh_Atem: generic is ... too genric
<zyga> but we can come up with something I'm sure
<mborzecki> i'm a metal slug fan ;)
<popey> mborzecki: yes, omg works, but that was built and never rebuilt a year ago.
<zyga> mborzecki: ah, I love that game too :) man I'm so old now that I think of it
<Pharaoh_Atem> zyga: we can also fork generic-release and produce a <foo>-release package to brand as another distro that says "ID_LIKE=fedora"
<Pharaoh_Atem> again, fairly trivial stuff
<zyga> yeah, that's good
<popey> mborzecki: Personally I like ghosts & goblins, r-type, r-type 2, rtype leo, scramble, nemesis, side arms and bomb jack - and I own the arcade boards so I'm (allegedly) legal ;)
<zyga> I'll make some packages and stick it into copr
<Pharaoh_Atem> ;)
<zyga> popey: _wow_
<Pharaoh_Atem> zyga: you could even call it Ubuntu RPM Edition if you wanted :P
<mvo> pedronis: re https://github.com/snapcore/snapd/pull/5043#discussion_r181401324 - do you have a suggestion what place to use?
<mup> PR #5043: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode <Critical> <Squash-merge> <Created by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<zyga> Pharaoh_Atem: but then ubuntu trademark ;-)
<Pharaoh_Atem> though I think sabdfl would be a little bit peeved :P
<zyga> Pharaoh_Atem: I'll call it zygoonix
<Pharaoh_Atem> hehe
<mvo> Pharaoh_Atem: hahaha
<mborzecki> popey: yeah, mame does not work, but the nvidia libs get mounted at the proper location, i'll check the wrapper script in case it's doing something silly
<popey> Orange Hat
<Pharaoh_Atem> :D
<zyga> OMG
<mvo> lol
<Pharaoh_Atem> why not, eh?
<zyga> orange is the new hat ;-)
 * zyga gets back to kernel bug fixing and workarounds
<popey> mborzecki: I was using a manual launcher I made previously, I switched to desktop-glib-only
<Pharaoh_Atem> if you want to have more fun, there's also a generic-logos package you can fork and make up some fun branding for
<pedronis> mvo: I think the helper should just return if the mode if for all or main?  and then wrappers picks process based on that
<mvo> pedronis: yes, that sounds good
<mvo> pedronis: I will change it this way
<Pharaoh_Atem> popey: Purple Cap :P
<pedronis> mvo: thank you, is mostly for future readers, is a bit strange to be in snap
<mvo> pedronis: I will call it "KillEmAll()"
<mvo> pedronis: totally agreed, the wrong place
<zyga> mvo: how about SecureKillEmAll
<zyga> we want to be safe, after all
<popey> Pharaoh_Atem: I like!
<zyga> I think I have a name
<zyga> but I'll announce it later :P
<mborzecki> popey: strace shows it's not loading libGL from the right location
<Pharaoh_Atem> zyga: now don't forget, we need logos and stuff too :P
<Chipaca> mvo: it looks like I won't be splitting catalog refresh today
<zyga> Pharaoh_Atem: and a boot up chime
<Pharaoh_Atem> YES!
<zyga> Pharaoh_Atem: it can be "SCO LINUX" played backwards
<Pharaoh_Atem> haha
<Pharaoh_Atem> it takes ~40 minutes to make your own branded derivative of Fedora, satisfying _all_ of the necessary trademark guidelines
<Pharaoh_Atem> and with your derivative, you can do whatever you want
<mborzecki> popey: this is ld.so log from when it tries to load libGL https://paste.ubuntu.com/p/S5MyfKdyXT/ SNAP LIBRARY_PATH is not in LD_LIBRARY_PATH anymore
<mborzecki> that's why it does not pick up the right libGL
<zyga> mborzecki: can we inject that for classic snaps?
<popey> (this isnt classic)
<zyga> oh
<zyga> then we can definitely influence that
<popey> so could I work around this by adding an environment stanza which prepends SNAP_LIBRARY_PATH to LD_LIBRARY_PATH?
<zyga> popey: that's what snapcraft does
<mborzecki> popey: i'm looking into the wrappers now
<popey> ok
<popey> thanks
<Chipaca> huh, I did apt purge snapd and now have two loopback devices hanging around
<zyga> Chipaca: can you run
<zyga> losetup
<zyga> and paste that
<Chipaca> I can run, just not on open road just yet
<Chipaca> too hard on the back
<Chipaca> zyga: it lists two devices, both with "deleted"
<zyga> Chipaca: super interesting
<zyga> so two snaps were removed but their loop devices were not cleaned up
<Chipaca> yes
<zyga> what are those
<Chipaca> and I can mount them :-)
<zyga> some experiments or regular things?
<Chipaca> core and lxd
<zyga> intersting
<zyga> maybe related to what pedronis is chasing
<Chipaca> and i can't detach them even though they're not mounted
<pedronis> do you have lxd containers running?
<Chipaca> pedronis: I don't think so, but how do i check?
<Chipaca> huh, i do have lxd stuff running
 * zyga found one typo, closer to having a patch
<pedronis> that might explain why didn't go away
<pedronis> maybe
<Chipaca> dbus, lxd itself, and dnsmasq
<Chipaca> thinking about it I manually removed the lxd snap yesterday
<zyga> as in rm -f
<Chipaca> no, as in 'snap remove lxd'
<Pharaoh_Atem> zyga, mvo, niemeyer: Flock 2018 is in Dresden, Germany: https://fedoramagazine.org/flock-2018-venue-announcement/
<zyga> during holidays
<zyga> nice
<zyga> maybe I can come
<zyga> even totally unofficialy
 * pedronis is going to eow
<mborzecki> zyga: does RPHAT have higher priority than LD_LIBRARY_PATH?
<mborzecki> RPATH
<zyga> mborzecki: thinking
<zyga> mborzecki: I don't know :/
<zyga> I need to check spec for that
<sergiusens> rpath that has lower precedence than the LD_LIBRARY_PATH environment variable
<sergiusens> googled and memory recollection seems to align with that
<sergiusens> elf files can be disabled from looking at LD_LIBRARY_PATH though
<mborzecki> sergiusens: zyga: this is what I see: https://paste.ubuntu.com/p/8mbNy545Z4/
<mborzecki> if i LD_PRELOAD then mame works
<mborzecki> and I can see the paths from LD_LIBRARY_PATH being used when searching for other libs
<mup> PR snapd#5048 closed: tests: updating bionic version for spread tests on google <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5048>
<sergiusens> mborzecki: don't you need to snap --shell run `mame` and set LD_LIBARARY_PATH in there?
<mborzecki> sergiusens: i'm inside the snap ns
<mup> PR snapd#5047 closed: tests: removing linode-sru backend <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/5047>
<sergiusens> oh, I read incorrectly
<sergiusens> can I see all of readelf's output?
<sergiusens> but will look shortly, need to do a pickup
<mborzecki> sergiusens: http://paste.ubuntu.com/p/bGPHtsMHMs/
<mborzecki> sergiusens: LD_DEBUG=all http://paste.ubuntu.com/p/Zm57vmQCwR/, at first it's only looking at RPATH, then around line 5217 it picks up LD_LIBRARY_PATH when it moves to loading deps of other libraries without RPATH
<mborzecki> pff no clue what's happening, i could probably try to patch mame binary and strip/fixup rpath
<zyga> mvo: testing the fix now
<mvo> zyga: testing as in running spread with 18.04-32 ?
<zyga> yes
<mvo> cool
<zyga> mvo: I've added a constraint that runs this only on classic
<zyga> we can further refine it to look for apparmor "feature" non-leaking kernel or something
<zyga> btw, where did you get bionic 32 image
<zyga> I had to use my hacky scripts to make one
<zyga> for qemu
<mvo> zyga: autopkgtest-buildvm-ubuntu-cloud -r bionic -a i386
<zyga> yeah
<zyga> that's what I do
<mvo> zyga: oh, and it did not work?
<zyga> no, I mean, I hoped we had a google image
<mvo> zyga: aha, not yet afaict
<mvo> afaik
<zyga> mvo: quick pre-review?
<zyga> https://github.com/snapcore/snapd/compare/master...zyga:tweak/inject-random-profiles?expand=1
<mvo> Chipaca, zyga 5043 is ready I think for a review, tests still running so maybe some tweaks needed but hopefully its ok
<zyga> ok, looking
<zyga> holly molly
<zyga> that's not a small change sadly
<zyga> but let me read on
<zyga> jdstrand: hey
<zyga> jdstrand: if around, can you look at the link above please
<pedronis> zyga: did you see jdstrand commented in the forum?
<zyga> checking
<zyga> yeah, just saw
<mvo> zyga: fwiw, it looks reasonable - does it help? i.e. is the test working now?
<zyga> still going for now
<zyga> it definitely does help in my simplified testing where I just insert random profile in a tight loop
<zyga> that's stable over 100K insertions
<mvo> nice
 * kalikiana wrapping up for the week o/
<ogra_> jdstrand, [Apr13 16:23] audit: type=1400 audit(1523636600.835:36): apparmor="DENIED" operation="open" profile="snap-update-ns.classic" name="/dev/urandom" pid=1811 comm="3" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<ogra_> jdstrand, looks like the classic-support interface would like /dev/urandom support ;)
<zyga> snap-update-ns.classic
<zyga> what would make it open /dev/urandom?
<zyga> ogra_: that profile is applied to a program that modifies snap namespaces, not to the program itself
<ogra_> zyga, thats the classic (developer chroot) snap on a core system
<zyga> yes, but the denial is odd, this is not a profile for the application
<ogra_> something inside tries to access urandom i guess
<zyga> it is a profile for the tool that constructs the execution environment
<zyga> it never should open /dev/urandom
<zyga> can you tell me how to reproduce this?
<ogra_> not really but i can try to proxy ... afaik ian only noticed it in his logs after working a day with his dragonboard
<zyga> in any case it should not cause any actual harm
<ogra_> no, thats clear
<ogra_> but i thought it was just missing device access in the classic-support interface
<mup> Issue snapcraft#1920 closed: Design error reporting <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1920>
<mup> PR snapcraft#1951 closed: repo: do not pull in libc6-dev by default for stage-packages <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1951>
<pedronis> zyga: snap-update-ns might load bits of snapd  that try to use random generation
<zyga> ah, indeed
<zyga> perhaps osutil does need it
<pedronis> we would need to investigate, it might not be something that snap-update-ns uses but some init of something linked might use it
<mup> Issue snapcraft#2071 opened: patchelf to handle RUNPATH <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/2071>
 * cachio afk
<mvo> hrm, hrm, no travis slots, the typical friday evening problem after a busy week
 * mvo is slightly sad about this
<kyrofa> roadmr, are there issues with the staging store right now?
<kyrofa> roadmr, having trouble logging in, do you see any issues here? https://pastebin.ubuntu.com/p/KVXTxkYZBf/
<roadmr> kyrofa: what's a 504?? hehe let me see
<kyrofa> A timeout, indeed, that seemed odd to me as well
<roadmr> weird
<roadmr> a sec
<mup> Issue snapcraft#1918 closed: Add y/n support for sending errors back <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/issue/1918>
<mup> PR snapcraft#2069 closed: Reports <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2069>
<roadmr> kyrofa: I'm able to "snapcraft login" to staging just fine
<kyrofa> roadmr, I actually had a success with another account as well-- any chance there could be an issue with a specific account?
<kyrofa> Either that or it doesn't always happen
<kyrofa> Although I got it twice in a row with the same account
<roadmr> kyrofa: could be! can you authenticate with that account at login.staging.ubuntu.com?
<kyrofa> Let me try
<roadmr> kyrofa: hm, the URL that's timing out on you is actually in the staging store / dashboard. Incremented Retry for (url='/dev/api/account'): Retry(total=4, connect=None, read=None, redirect=None)
<roadmr> kyrofa: when was this?
<kyrofa> Just now
<roadmr> kyrofa: ok, let me check whether any of the app servers are wonky
<roadmr> (they were earlier today, that's why I asked "when")
<roadmr> kyrofa: everything looks healthy :(
<roadmr> kyrofa: I'm about to go lunch but you can ask in #snapstore, anyone there should be able to look at this
<kyrofa> roadmr, note that I can indeed login to login.staging.ubuntu.com
<zyga> wooooot
<zyga> first thunderstorm of the season
<zyga> !!!
<zyga> waterfall from the sky
<popey> zyga: do you know if mb figured out what was breaking mame?
<popey> (is there something i can do in the launcher?)
<zyga> popey: sorry, I don't know
<popey> ok
<popey> I'll ask next week
<zyga> I'm looking at a kernel leak all day
<suebt> hey zyga, any news about the daemon thingy? :)
<zyga> suebt: hey, no, I will try next week, sorry :/
<suebt> ok np
<mup> PR snapd#5049 opened: interfaces/apparmor: workaround kernel memory leak <Created by zyga> <https://github.com/snapcore/snapd/pull/5049>
<roadmr> kyrofa: yes, per my earlier comment, it's not a login.staging.u.c issue, but a dashboard.snapcraft.io one
<kyrofa> Ah, okay
<popey> jdstrand: I can't upload with snapcraft 2.40 - despite your thread suggesting 2.40 implements this -no-fragments thing
<popey> https://forum.snapcraft.io/t/automated-reviews-and-snapcraft-2-38/4982
<popey> Hang on, this is an electron application - built with electron-builder. Does that bake in something older than 2.40?
<roadmr> kyrofa: just so we're clear, things are working well for you now, and you'll let me (or anyone in store team) know if you see this again, right?
<roadmr> kyrofa: (just to avoid an expectation mismatch "I thought you were looking into it" "I thought you'd tell me if it broke again" :)
<kyrofa> roadmr, no, something is wrong. I can definitely login with other accounts, but not this one. Ever
<kyrofa> Same thing happens every time
<roadmr> kyrofa: oh! ok, let's look at it from this angle then
<cprov> kyrofa: oi oi
<kyrofa> Hey there cprov
<cprov> kyrofa: the `account` endpoint (used on login to cache account-id, IIRC) is returning a lot more data in `snaps` and it's  undeniably slower, specially for crazy testing users we have in staging
<kyrofa> cprov, if you look at the snap names, we testing things like registration
<kyrofa> cprov, and then we never touch some again. Is there a way we can tell the store to toast them?
<cprov> kyrofa: cleaning up snaps is not operational yet, for now the best suggestion I have is to create a new user
<kyrofa> Ouch
<kyrofa> This is all CI
<kyrofa> Can we manuall clear out the snaps?
<kyrofa> manually*
<cprov> kyrofa: it's not that bad, a new user will be performing well up to 1000s snaps, which is weeks of testing
<cprov> kyrofa: cleanup is too manual atm, via the UI one by one, we need come up with a script to do that properly
<kyrofa> cprov, okay. Is there a different endpoint we could be using that won't give us every single snap?
<cprov> kyrofa: not yet, but what do you have in mind ?
<kyrofa> cprov, just seems silly to return a bunch of data we don't need
<kyrofa> I don't want to create a new user every few weeks
<cprov> kyrofa: why does it need the account/ on login ?
<cprov> kyrofa: ftr, there are 4200 u1test* snaps in staging
<mvo> zyga: I see #5049 - did it survive ubuntu-18.04-32?
<mup> PR #5049: interfaces/apparmor: workaround kernel memory leak <Created by zyga> <https://github.com/snapcore/snapd/pull/5049>
<kyrofa> cprov, no idea, do you think it shouldn't?
<kyrofa> I can find out if you think it unnecessary
<cprov> kyrofa: let me check the code, I don't see an obvious reason
<zyga> mvo: my workaround worked
<zyga> mvo: it failed on network on one test
<zyga> mvo: I restarted but it works
<kyrofa> cprov, _check_dev_agreement_and_namespace_statuses I think
<zyga> mvo: I get dinner now
<kyrofa> We check to ensure the account is properly setup with the dev namespace and whatnot
<cprov> kyrofa: ah, I see
<mvo> zyga: nice
<mvo> zyga: I'm also waiting for tests
<mup> PR snapcraft#2072 opened:  lifecycle: handle missing version correctly  <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2072>
<jdstrand> popey: you said 'hold on'. I don't know if electron builder pins snapcraft in any way, but I can say the store queue is empty
<jdstrand> popey: make sure that schroot, lxd containers, your snaps, your debs, your git checkout, etc is using the latest snapcraft
<jdstrand> popey: if you refresh the review-tools snap, you can do 'snap-review /path/to/snap' and it will have better error reporting on the issue and can let you know if -no-fragments was used or not, or something else
<jdstrand> popey: you mentioned electron-- if you are using 'allow-sandbox: true' with a setuid chome sandbox, that will also cause it to fail this test (it will also fail *other* tests though too)
<sergiusens> any ideas about: cannot change profile for the next exec call: No such file or directory
<sergiusens> snap-update-ns failed with code 1: No such file or directory
<sergiusens> jdstrand, zyga: ^
<jdstrand> popey: but ultimately, you didn't give a store url so I can't look into it more
<sergiusens> that's when running corebird, previously working
<zyga> Yes
<zyga> But not debugged
<zyga> Watching movie with family now
<mvo> zyga: enjoy. still no travis slot for me, I call it a day
<zyga> Boo :/ sorry to hear that
<zyga> Travis has a weekend mode
<jdstrand> popey: please see the forum
<mup> PR snapcraft#2068 closed: states: track override scriptlets <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2068>
<popey> jdstrand: ok. i dont know how electron does it
<popey> jdstrand: there's none in the queue I guess because it never got to the store
<kyrofa> popey, I believe they call mksquashfs themselves
<roadmr> kyrofa: ah, nice! if that's true and electron-builder can be poked at, their mksquashfs call can be made to conform to what Jamie suggested
<kyrofa> No, I lied: https://forum.snapcraft.io/t/snapcraft-push-error-keyerror-architectures/4056/9
<kyrofa> Sounds like they use snapcraft pack
<kyrofa> But what version?
<roadmr> aha :)
<kyrofa> They have a docker image, I bet it hasn't been respun
<kyrofa> Though I can't pretend to understand fully how it works
<roadmr> their instructions ask to install snapcraft as a deb
<roadmr> 2.40 is available for xenial, artful and bionic, and from this I understand it'd use the deb installed on the system... which popey said was 2.40
<kyrofa> Interesting
<popey> it looks like e-b manually does some unsquashfs / mksquashfs, but I'm not a developer, so I am going by what I think i see on github
<popey> https://github.com/electron-userland/electron-builder/blob/7800ce1301154281564a23b5707e9a79bf3aa52d/scripts/snap-template.sh#L8
<kyrofa> I saw that too... but it looked more like a test
<popey> looks like the node module electron-builder-lib
<popey> I don't understand this :(
<popey> one for monday.
<mup> PR snapcraft#1911 closed: Add support enable configurable runtime version for .NET Core applications <enhancement> <Created by rakeshsinghranchi> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1911>
<cachio> niemeyer, there?
<niemeyer> cachio: Here, but still in the conference
<cachio> niemeyer, nice, just 1 quick question
<cachio> I am working with the amazon image
<cachio> it is working but still trying to resize it
<cachio> I read it is not possible to shrink xfs filesystems
<cachio> and it is using an xfs
<cachio> I see 2 alternatives
<cachio> I could create a snaller partition and copy the fs to there
<cachio> or leave it with the same size and make a change in spread to skip setting the size of the disk when it is defined in the sprad.yaml
<cachio> niemeyer, do you see other alternatives?
<cachio> what do you prefer?
<niemeyer> cachio: What happens if you set the image to exactly 10GB? I hope it won't try to resize it
<niemeyer> cachio: We shouldn't change the nature of the image though.. shouldn't be a different filesystem for example
<cachio> niemeyer, you mean if I truncate the image to 10GB?
<niemeyer> cachio: Worst case we can have a setting in spread to preserve the image size
<cachio> niemeyer, yes, that was the other alternative
<cachio> I can try to resize the partition but we could loose data
<cachio> If you agree I could make a PR in spread to preserve the image size iÂ¿
<cachio> niemeyer, in that case we can use the amazon image which it already uploaded
<mup> Issue snapcraft#2064 closed: Support for set-grade <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/2064>
<mup> PR snapcraft#2067 closed: many: add snapcraftctl set-grade <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2067>
<mup> PR snapcraft#2073 opened: meta: validate extracted and scriptlet metadata <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2073>
<niemeyer> cachio: Yeah, I think that's fine.. we can use "preserve" as a value, that internally sets the value to zero, and we interpret it as such
<niemeyer> cachio: Actually, zero won't work as that's the default in which we want to resize as what most cases need.. preserve could set it to -1 though
<cachio> niemeyer, ok
<cachio> I'll try it
<cachio> thanks
#snappy 2018-04-14
<mup> PR snapcraft#2070 closed: extractors: support for setup.py <enhancement> <Created by sergiusens> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/2070>
<mup> PR snapcraft#2072 closed:  lifecycle: handle missing version correctly  <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2072>
<jjohansen> zyga, mvo: I've got a fix, and a test kernel building
<zyga> jjohansen: awesome
<zyga> jjohansen: I will check your tree
<jjohansen> zyga: I pushed it to http://kernel.ubuntu.com/git/jj/ubuntu-artful.git/log/?h=lp1750594
<zyga> Looking
<jjohansen> I need to do a larger fix for the other error paths, but those can go separately
<zyga> Ha, it would take me a week to find this
<zyga> Thank you again
<zyga> Can we this still go into 4.17?
<jjohansen> maybe, we are past kernel freeze, but. There is still some room for critical patches
<jjohansen> I would poke leann
<jjohansen> even if it doesn't make the release kernel it could go into the first fix kernel which is usually released on release day
<jjohansen> zyga: to be clear I will poke leann, but you should too, if this is to have a chance to go in
<jjohansen> she won't be around until monday morning
<zyga> Ack, I will do so as well
<zyga> Is this a clear bug? What is a the chance that the fix may cause more issues?
<jjohansen> I will also poke sforshee and let him know we want it in if possible, that way he can prep
<jjohansen> it is a clear bug
<zyga> Ok
<jjohansen> the fix won't cause issues, that is part of the reason I didn't make a larger change to the error paths that will do the same leak
<zyga> I will update the forum and talk to leann on Monday
<jjohansen> zyga: I have sent to the kt list, and sforshee, and fed him additional info
<jjohansen> so all that is us contacting Leann on monday
<zyga> Thank you
<jjohansen> np. And thanks for all your work in chasing this down, it really helped
<mup> PR snapd#5043 closed: many: add "stop-mode: sig{term,hup,usr[12]}{,-all}" instead of conflating that with refresh-mode <Critical> <Squash-merge> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/5043>
<zyga> jjohansen: woot, thank you, I really enjoyed that :)
<mup> PR snapcraft#2073 closed: meta: validate extracted and scriptlet metadata <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2073>
<pbek> I wonder if there is a way to write to a nfs mount from a snap, I can't find an interfaces to allow that
<mup> Issue snapcraft#1697 closed: Documentation for sources of information extraction <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1697>
<mup> PR snapcraft#2056 closed: Fix formatting of some store errors <bug> <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2056>
<mup> PR snapcraft#2074 opened: Release changelog for 2.41 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2074>
<zyga> pbek: hey
<zyga> NFS should work transparently now but it needs to be in a location that is otherwise allowed (eg home)
<mup> PR snapcraft#2075 opened: errors: skip the sentry test if raven is no installed <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2075>
<r04r> how can i locally overwrite files in a snap?
<r04r> say i install some software using snapd, and i want to change a line of code in one of its scripts. how?
<r04r> everything is readonly for some reason
<thresh> is there a way to mark a package not to be installed in the stage-packages phase?
<zyga> r04r: you can unpack the squashfs, change anything you like and then install your own version instead
<r04r> zyga: any pointers to documentation regarding this? i have no idea where to start
<zyga> But doing so will disable updates since now you are the developer
<r04r> yeah understandable and fine with me
<zyga> Use unsquashfs on the snap file in /bar/lib/snapd/snaps
<r04r> the goal would be to try and upstream the changes anyway
<zyga> Then âsnap packâ to repack
<zyga> Then âsnap installâ with the new file you get
<r04r> ah cool
<r04r> thanks
<zyga> Good luck
<zyga> You can also âsnap tryâ Iâm unpacked tree
<zyga> See snap try âhelp
<r04r> i keep getting google results about snapchat lol
<zyga> do you know about forum.snapcraft.io
<r04r> yeah, i just have a (possibly bad) habit of googling first
<zyga> No worries, try asking on the forum if you get stuck
<zyga> IRC is emptier on weekends
<r04r> yeah, thanks though. i had been sitting on this question for a while actually, but only just now thought to look into it a bit more. so time is not of the essence :)
<zyga> Snaps are read only filesystems
<zyga> That is why you could not modify anything
<r04r> makes sense, this was my first time playing with snap
 * Pharaoh_Atem waves
<Pharaoh_Atem> zyga: zygoonix?
<Pharaoh_Atem> or are we calling it something different now :P
<zyga> I have an idea for something else
<Pharaoh_Atem> oh?
<Pharaoh_Atem> zyga: what is it?
<zyga> Iâm afk, walking home
<zyga> Still many km left
<zyga> Pharaoh_Atem: I'm back
 * zyga is somewhat tired 
<zyga> but that's perfect for evening hacking from the couch
<zyga> Pharaoh_Atem: so the idea is super silly
<zyga> Pharaoh_Atem: we have ubuntu orange, we have red hats and fedoras. We could mix the colours and make a nice tie :)
<zyga> Pharaoh_Atem: so "{violet,lilac,lavender,mauve} tie"
<Pharaoh_Atem> :D
<zyga> it could have a clean and simple icon made out of three thriangles
<zyga> triangles*
<Pharaoh_Atem> neat
<zyga> ><==> (sideways, wish)
<zyga> ish*
<zyga> I'm in line to take the shower but after that I'll see what I can get
<zyga> that is, if I can make a mini fedora derivative
<zyga> and snap it :)
<Pharaoh_Atem> :)
<zyga> Pharaoh_Atem: as a native speaker, is there a nice way to say "violet tie" just more fancy/funny
<Pharaoh_Atem> I don't know of many
<Pharaoh_Atem> specific kinds of ties maybe...?
<zyga> if you think of something better we can just tweak it
<zyga> I'm the last person that would know that there are various kinds of ties :)
<zyga> anyway, it's just a joke/prank name :)
<Pharaoh_Atem> hmm
<Pharaoh_Atem> ascot would work
<Pharaoh_Atem> it has a double meaning (a type of cap, and a type of cravat/scarf)
<mup> PR snapcraft#2076 opened: patches: improve ctypes patch for python 3.5 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2076>
<Pharaoh_Atem> zyga: another option is cravat: https://en.wikipedia.org/wiki/Cravat
<Pharaoh_Atem> ascot (https://en.wikipedia.org/wiki/Ascot_tie & https://en.wikipedia.org/wiki/Ascot_cap )
<zyga> Pharaoh_Atem: cravat is nice, it's also something that's used in polish
<Pharaoh_Atem> does it also mean a necktie?
<zyga> Pharaoh_Atem: though on second thought tie is interesting too
<zyga> Pharaoh_Atem: tie as in "it's a tie"
<zyga> Pharaoh_Atem: but also something that "ties things together"
<Pharaoh_Atem> mmm
<zyga> Pharaoh_Atem: I'm next in line for the shower, after that I'm hacking
<mup> PR snapcraft#2077 opened: python plugin: do not invoke wheel install if empty <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2077>
<mwhudson> wtb new snapcraft in bionic
#snappy 2018-04-15
<pbek> zyga: thank you for answering my NFS mount question! the removable-media interface didn't help me, so I'd have to mount it into the users home directory (with the home-interface) or go to classic confinement, right?
<thiras> spotify is not working
<thiras> $ snap run spotify
<thiras> cannot create user data directory: /home/thiras/snap/spotify/13: Permission denied
<mup> Bug #1764069 opened: Can't install snaps (X-Ubuntu-Series header is required - connection refused) <Snappy:New> <https://launchpad.net/bugs/1764069>
<zyga> pbek: hey, so you can mount it into the home directory, yes
<zyga> pbek: classic confinement is discouraged
<mup> PR snapcraft#2077 closed: python plugin: do not invoke wheel install if empty <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2077>
<mup> PR snapcraft#2075 closed: errors: skip the sentry test if raven is no installed <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2075>
<mup> PR snapcraft#2076 closed: patches: improve ctypes patch for python 3.5 <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2076>
<Caelum> zyga: that list is completely dead, I'll wait a few more days, but I think I'd have better luck asking on the irc channel
<zyga> Caelum: I see, I have some contacts, I'll try to help
<Caelum> zyga: we could also just try submitting it, there are a lot of automated checks anyway
<zyga> yeah, we can
<Caelum> zyga: there is another list for factory, I'll see if that one is more alive
#snappy 2019-04-08
<Son_Goku> zyga, I need karma for these updates:
<Son_Goku> F28: https://bodhi.fedoraproject.org/updates/FEDORA-2019-2d75eaae81
<Son_Goku> EL7: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-be55f1a139
<Son_Goku> F29: https://bodhi.fedoraproject.org/updates/FEDORA-2019-a93e7637d2
<mup> PR snapd#6697 opened: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<mborzecki> morning
<mborzecki> google:ubuntu-18.10-64:tests/main/refresh-app-awareness failing randomly?
<zyga> Good morning
<zyga> Oh
<zyga> How?
<zyga> I am afk with the dog
<mborzecki> zyga: hey
<zyga> Back
<zyga> mborzecki: how are you doing
<zyga> mborzecki: I'll test neal's package update
<mborzecki> zyga: found some weird things about snap[d] binaries with mvo on friday
<zyga> what did you find?
<mborzecki> zyga: we don't know why that's happening yet, but armhf binaries coming from core snap would attempt to perform mmap2() with ridiculously large sizes
<mborzecki> zyga: afaik that's the initial allocations that go runtime attempts
<zyga> anonymous mapping?
<zyga> go's new GC
<mborzecki> yes, MAP_ANONYMOUS, and some were done with | MAP_FIXED
<zyga> oh
<zyga> that is interesting
<mborzecki> for instance, the `snap` comand would try to alocate 150MB with MAP_ANONYMOUS | MAP_FIXED, and then another 800M with MAP_ANONYMOUS
<zyga> fixed implies they use address-based zones
<mborzecki> i was like wtf?
<zyga> funny
<zyga> I was reading a book about this over weekend
<zyga> https://www.amazon.de/Garbage-Collection-Handbook-Automatic-Management/dp/1420082795/ref=sr_1_1?__mk_pl_PL=ÃMÃÅ½ÃÃ&keywords=garbage+collection&qid=1554702790&s=gateway&sr=8-1
<zyga> I recommend it
<zyga> that's the new garbage collector in place
<zyga> since it's just address space it's okay
<zyga> but pehraps it has some side effects
<mborzecki> fwiw, i think it's exhausting system wide overcommit limits
<mborzecki> zyga: and we found some bug reports about that for 32bit arches
<zyga> mmm
<zyga> so
<zyga> google doesn't really care about 32bit
<mborzecki> zyga: oh, and another thing, i dropped a snap binary built by me (although cross compiled), but it had none of the crazy mmap() calls
<zyga> mmmm
<zyga> which go versions were involved?
<mborzecki> zyga: theoretically same go version as in xenial (1.10.4), though i got mine from golang.org
<zyga> what kind of patches do we see in ubuntu?
<mborzecki> zyga: haven't looked at that yet, we stopped at ~11pm on friday :P
<zyga> mborzecki: good results!
<zyga> mborzecki: I'm eager to learn more as you discover what's changed
<zyga> mborzecki: one hint:
<zyga> look at golang's source code to see if the new garbage collector is uncoditional and see if there are any knobs (environment?) to control it
<zyga> perhaps we cannot reverse course on how go behaves but we can tweak it enough to be sufficient for our needs
<zyga> though I strongly worry about the long term viability of 32bit snapd
<zyga> unless we change our model
<zyga> (e.g. snapd doesn't run unless API calls are in place)
<zyga> (and snapd has more smaller binaries for particular tasks)
<zyga> (e.g. only daemon runs and dispatches to new binaries for tasks)
<mborzecki> zyga: some pages i have open since friday: https://github.com/golang/go/issues/21044 https://github.com/golang/go/issues/28114 https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c
<mborzecki> zyga: idk, but armhf is 32bit, rpi3 is still running 32 userspace, unless you forfeit the gpu and run 64bit instead
<mborzecki> zyga: oh, and if anyone uses ubuntu core on atom, those are 32bit too
<zyga> mborzecki: sure, I know we will be stuck with 32bit systems for al ong time
<mborzecki> zyga: btw. on friday we got to a state, where it wasn't possible to run any snap command :P, you'd type snap list and got runtime: out of memory :P
<zyga> rust baby ;-)
<zyga> I'd love a rust dispatcher for tasks with go backends to run stuff we have already
<zyga> snapd taking 3MB of ram while idle
<zyga> we could call it "project schizo"
<mborzecki> heh
<mborzecki> zyga: fwiw, if any, i think it's a bug somewhere in the compiler or runtime
<zyga> bug as in undesired behavior?
<zyga> perhaps
<mborzecki> zyga: the binaries that i built would ask for 2M not 150M
<zyga> I doubt it is an actual algorithm bug
<zyga> I wonder if cross compiling is a factor
<zyga> perhaps that is the bug
<zyga> compile natively on arm perhaps?
<mborzecki> yeah, idk, that's why i'm setting up my rpi
<zyga> like our builders do
<zyga> ok :)
<mborzecki> btw. mvo mentioned when he passed mem=256 on kernel command rpi classic wouldn't boot, wonder why
<zyga> memory split for gpu?
<zyga> I think though that modern systems struggle at that amount
<zyga> (128MB)
<mborzecki> i should buy a new case for my rpi, one that exposes the gpio header
<zyga> mborzecki: just find one you like and I'll print you a copy
<zyga> I have some spare official cases
<zyga> those expose the gpio header but not in a useful way for serial
<zyga> hmm, I have issues with my fedora system :/
<mvo> zyga: hey, good morning
<zyga> good morning :)
<mborzecki> mvo:  hey
<mvo> hey mborzecki
<zyga> "a start job is running for /dev/mapper/fedora"
<zyga> eh
<mvo> mborzecki: anything new in armhf land :) ?
<zyga> I think my disk got corrupt somehow
<mborzecki> mvo: not yet, pulled down rpi image, flashed, and nothing on the serial port :/ maybe my uart adapter dones't work anymore
<zyga> mborzecki: screen?
<mvo> mborzecki: meh, ok
<zyga> mborzecki: how did you wire the serial?
<mborzecki> zyga: same as usual, idk i dragged it some meetups recently, maybe something got loose
<zyga> I gave up on my fedora system
<zyga> it's odd because it can boot to recovery
<zyga> but not to normal mode
<zyga> I will try some more later
 * zyga breaks for quick breakfast and then back to RPs
<zyga> PRs
<pstolowski> morning
<zyga> back from breakfast
<zyga> hey pawel
<mvo> ppisati: can I run a 64bit pi3 kernel on a 32bit userland, what do I need to do to get this working? tracking down a nasty go bug and I want to replicate our buildd setup as closely as possible
<mvo> sil2100: do you know if we have a machine to native build on arm that is close to a buildd? i.e. 64bit kernel, 32bit userland ? I tried the armhf porter box but for some reason I don't get access there
<pedronis> mvo: mborzecki: hi, is this that you are observing: https://github.com/golang/go/issues/28081 ?
<mborzecki> pedronis: maybe, we looked at that on friday too
<mborzecki> pedronis: if you scroll back, i liked some other issues too
<mvo> pedronis: we are still a bit in the dark, the worst part it is not reproducible on a pi2 (neither core nor classic)
<mvo> pedronis: and it goes away when cross building on amd64 and scp to arm even with the same toolchain (or we think its the same toolchain, we need to 100% replicate I think)
<mvo> pedronis: some (very hard to read notes) https://gist.github.com/mvo5/f3a4e330f8bf32bd514d9a038665f591 - mborzecki has a similar stakc of notes
<mvo> pedronis: my theory right now is that the allocator tries to map a way to large chunk of "mheap_arena_used" but its totally unclear why - it may be a red herring but its definitely wrong and we don't see it anywhere else
<pedronis> mvo: well they tell they are allocating much larger chunks
<pedronis> 64mb vs 2mb
<mborzecki> pedronis: fwiw, there's a request for 800M at some point
<pedronis> ah
<mborzecki> in the notes, ther's a strace log, first mmap requests 115MB (well, large but ok), and then the next requests 800M+
<mborzecki> and that's when even snap commands would keep failing
<pedronis> mborzecki: that's on the device ?
<mborzecki> pedronis: yes
<pedronis> but we don't see it on rpi2
<pedronis> (so far)
<mvo> mborzecki, pedronis AIUI the big problem is MAP_FIXED here
<sil2100> mvo: hm hm, did you have access to the porter boxes previously?
<pedronis> mborzecki: are we seeing the same allocation (800M+) on rpi2 and they succeed ? or we not seeing them instead?
<mvo> sil2100: do we have a arm porter box? maybe I was doing it wrong
<mborzecki> wow, my rpi3 does not even boot anymore
<mvo> mborzecki: did you add mem=256M the the kernel commandline ? I tried that and nothing worked anymore
<mvo> mborzecki: as in - I would not even get kernel messages that it initializes correctly
<mborzecki> mvo: i can't boot any of the rpi images on my rpi3, only raspbian works
<mvo> mborzecki: woah, thats strange
<zyga> mborzecki: do you have the 3B+ model?
<zyga> that is not supported yet officially AFAIR
<zyga> for that reason my 3B+ is also running raspbian
<zyga> mborzecki: note, if you need a 3B I can arrange on in ~1 hour
<zyga> exposed over the network for you
<mborzecki> zyga: i used a core image before on this device
<ppisati> mvo: if you don't use uboot, copy the arm64 kernel in the vfat partition and call it kernel8.img, remove kernel7.img, and have a fairly recent firmware, it should work
<zyga> mborzecki: oh
<zyga> that's new
<mborzecki> i remembed i did some tweaking, but don't recall what exactly that was
<mvo> ppisati: thank you!
<zyga> mvo, sil2100: https://github.com/snapcore/core18/pull/126
<mup> PR core18#126: hooks: reduce snapd skeleton directories <Created by zyga> <https://github.com/snapcore/core18/pull/126>
<mup> PR core18#126 opened: hooks: reduce snapd skeleton directories <Created by zyga> <https://github.com/snapcore/core18/pull/126>
<zyga> mborzecki: question
<zyga> mborzecki: when I mkdir a thing from snap-confine
<zyga> mborzecki: should I worry about selinux label?
<zyga> mborzecki: specifically, can you review this patch https://github.com/snapcore/snapd/pull/6642/commits/44a0f5283bbf753151e45c6d3fdf7482bf6c2430
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> er
<zyga> https://github.com/snapcore/snapd/pull/6642/commits/47018f084e66965ef51a67bc80c8820be8b75893
<mborzecki> afaict it should be fine, /var/lib/snapd is snappy_var_t, everything created under that dir will get the same label
<mup> PR snapd#6698 opened: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <https://github.com/snapcore/snapd/pull/6698>
<zyga> pstolowski, mborzecki: thank you for the reviews for https://github.com/snapcore/snapd/pull/6643
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> I updated the branch in response to the review
<zyga> I would appreciate a 2nd look
 * zyga switched to investigate google:ubuntu-16.04-64:tests/main/refresh-app-awareness
<mborzecki> looks like we may indeed have some memory problems with go 1.7 - 1.10, https://paste.ubuntu.com/p/FqczCC22WN/
<mborzecki> that's a request that actually counts towards overcommit, go.16 requested 1M, 1.7-1.10 requests 17M, 1.11 requests 4M
<pstolowski> np, zyga: will do later today!
<mborzecki> oh, and that's for the minimal program which does virtually nothing
<pstolowski> mborzecki: ouch
<zyga> in case anyone notices regressions in refresh-app-awareness, please let me know
<zyga> Chipaca: hello sir, would you mind attempting to review https://github.com/snapcore/snapd/pull/6690 today?
<mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
<Chipaca> zyga: I would not
<Chipaca> zyga: but, note today I am not doing too good
<zyga> I wish you to get better soon, I understand
<pedronis> pstolowski: I did pass a on #6662
<mup> PR #6662: overlord/snapstate,snapshotstate: create snapshot on snap removal (3/4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6662>
<pedronis> zyga: hi, have you seen the incoming comments on the new tmp logic ?
<pstolowski> pedronis: ty, also for the remarks on 4/4!
<pedronis> pstolowski: np
<zyga> pedronis: hey, perhaps not, where are they?
<pedronis> zyga: https://github.com/snapcore/snapd/pull/6614#discussion_r272974008
<mup> PR #6614: cmd/snap-confine: use fixed private tmp directory <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6614>
<zyga> ah, interesting, I didn't notice that
<zyga> thank you
<pedronis> zyga: I will look at 6690 today
<zyga> thank you!
<zyga> I will check if there are any other comments on closed branches
<zyga> my github.com/notifications is rather long
<mup> PR snapd#6699 opened: daemon: add RootOnly flag to commands <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6699>
<zyga> pstolowski: reviewed https://github.com/snapcore/snapd/pull/6698#pullrequestreview-223799068
<mup> PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <https://github.com/snapcore/snapd/pull/6698>
<zyga> Chipaca: is https://github.com/snapcore/snapd/pull/6699/files driven by the suse audit?
<mup> PR #6699: daemon: add RootOnly flag to commands <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6699>
<Chipaca> zyga: no, it's one of the changes to users raised last week
<Chipaca> there's another two coming
<Chipaca> (one of which needs agreement before i do it)
<zyga> so it's unrelated to the security review we received?
<Chipaca> maybe even three
<Chipaca> zyga: it changes nothing security-wise beyond perhaps making the logic easier to follow
<zyga> understood, thank you
<Chipaca> (which is a win)
<Chipaca> zyga: one of the things coming is to not have the user endpoints when not needed/supported, which might impact the sec review
<zyga> thank you
<Chipaca> zyga: another change is moving the user stuff to api_user
<Chipaca> zyga: a further change that i'd like to do but it's arguably v3 material is moving all the user actions to /v2/users
<zyga> Chipaca: I reviewed the auth code
 * zyga -> small break
<pedronis> Chipaca: hi, what's the status of #6653 ?
<mup> PR #6653: tests: try to be a little bit invariant <Created by chipaca> <https://github.com/snapcore/snapd/pull/6653>
<Chipaca> pedronis: need to fix it
 * zyga reads tests/main/security-private-tmp and is puzzled
<zyga> looking at it now
<pedronis> Chipaca: standup?
<Chipaca> pedronis: ye
<zyga> ah, I think I understand what the problem is
<zyga> with refresh awareness thing
<zyga> re, partially
<zyga> mborzecki: I'm fixing that bug you ran into in the morning
<zyga> just still in partial capacity away from the office
<Chipaca> what is /usr/lib/sysimage/rpm/Basenames and why do i hate it
<zyga> whaat?
<zyga> no idea, which system is that on?
<Chipaca> zyga: opensuse-15.0-64
<pstolowski> zyga: have you seen my general meta-question re #6643?
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<Chipaca> hrmph, it looks like core18 spread tests are rather messy wrt leaving core behind
<Chipaca> EOD for me
<Chipaca> o/
<zyga> pstolowski|afk: not yet, looking now
<zyga> pstolowski|afk: responded
<pstolowski|afk> zyga: ty
 * zyga resumes work
<zyga> sorry, took a nap after dinner
<zyga> hmm
<zyga> core18 prepare hanging ... ? https://www.irccloud.com/pastebin/MyVsgbcc/
<zyga> hmm
<zyga> but the system has seeded
<zyga> changes from the system https://www.irccloud.com/pastebin/loXhyaB3/
<zyga> I think I fixed that  now
<zyga> another round of testing...
<zyga> almost there
<om26er> is there a way to tell multipass through snapcraft to use more cores when packing a snap ? currently it default to 2, I would like it to use all available threads
<om26er> zyga Hey! Were you able to find a fix for https://bugs.launchpad.net/snapd/+bug/1819318 ?
<mup> Bug #1819318: no interfaces when installing only core18 <snapd:In Progress by zyga> <https://launchpad.net/bugs/1819318>
<om26er> So we have a server software as a snap and it won't build on 16.04 because a package it depends on, requires a version of python that is not in 16.04
<om26er> If we go with base: core18 then the above issue is problematic as Ubuntu Server on many VPSs doesn't come with core preinstalled
<zyga> and ... got it
<zyga> om26er: yes, but it's not near yet
<zyga> om26er: we need to install core in such cases
<zyga> I spent some time researching this but it's the closes solution for now
 * zyga just understood a pair of bugs
<om26er> that's kind of the workaround I have already been using, even before discovering ogra's bug ;-)
<om26er> will see if we can update our docs...
<zyga> it will get properly fixed by snapd.snap
<zyga> but for now...
<zyga> nothing else
<om26er> re: the python plugin in snapcraft, is there a way to set the `source` to a specific branch ?
<zyga> GAAH
<roadmr>  /o\
<mup> PR snapcraft#2524 closed: Snapcraft try <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2524>
<mup> PR snapcraft#2519 closed: packaging: use local patchelf <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2519>
<mup> PR snapcraft#2525 opened: catkin plugin: check stage-snaps for ROS dependencies <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2525>
<mup> PR # closed: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR # opened: core-build#11, core-build#22, core-build#26, core-build#37
<mup> PR snapcraft#2526 opened: Release changelog for 3.4 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2526>
#snappy 2019-04-09
<mborzecki> morning
<mborzecki> bisecting go in the morning
<zyga> mborzecki: hey
<zyga> I found a bag of bugs around that flaky test
<mborzecki> zyga: hey
<zyga> One core18 seeding bug
<zyga> One raciness bug in the test
<zyga> And a bug around my use of MATCH
<zyga> it is a miracle it passed at all
<mvo> mborzecki: anything interessting from the bisect so far?
<mvo> zyga: uh, bugs, bugs, bugs
<mborzecki> mvo: not yet
<mvo> mborzecki: thank you
<zyga> mvo: hello
<zyga> Just making coffe
<zyga> Yes, bugs in test code
<zyga> The one about core18 is generic
<zyga> The rest are just test specific
<zyga> I will be preparing patches. Just making coffee
<mvo> zyga: thanks!
<zyga> I spent all evening iterating on those, such a time sink to understand a trivial bug
<zyga> re
<mvo> mborzecki: quick question - you mentioned that using qemu -m 256 (or even 128) and buildmode=pie does not trigger the bug? i.e. its only observable on a low-mem arm system?
<mup> PR snapd#6700 opened: packaging: disable -buildmode=pie to fix memory issue on armhf <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
<mborzecki> mvo: 256 worked with qemu
<mborzecki> and pie ofc
<mvo> mborzecki: and strace showed now abnormal allocations and the auxv no anomal start address?
<mborzecki> mvo: oh, and couldn't get pi to run with mem=256M, even when tweaking gpu_mem
<mvo> mborzecki: thanks!
<mvo> mborzecki: this is slightly sad as we will not be able to test if we can ever re-enable buildmode=pie :/
<mborzecki> mvo: didn't look at auxv, but brk was in the lower range
<mvo> mborzecki: yeah, thats fine then
<mvo> mborzecki: brk I think is the key
<mvo> mborzecki: thanks again, I wonder if we should ask the guys if they can loan one of these boards to us or what we can do
<mborzecki> mvo:  do you know if it's a regular chip board?
<mvo> mborzecki: I don't know much, I think its a cheap/special one and the manufactor is no longer in business
<mvo> mborzecki: I can try to find the datasheet and mail it to you
<mborzecki> mvo: i have 2 chip boards, though regular ones, not -pro, at least one of those works
<mvo> mborzecki: oh, nice. so you say we could use those for testing?
<mborzecki> mvo: yes, iff it's the same board and i get the image
<mvo> mborzecki: nice!
<zyga> mvo: I added a comment to the PR
<zyga> please check that if you have the setup
<zyga> I'm trying to wrap up findings from last night
<mvo> mborzecki: there is a datasheet in the "Subject: Re: core 2.38 memory issue
<mvo> " mail
<mvo> mborzecki: you are on CC :) thats all the data I have
<mvo> zyga: is it? I build snap/snapd without buildmode=pie and "file" showed me a buildid that looks valid
<zyga> without buildmode= what is the default mode
<zyga> I think it differs  across go distributions
<zyga> I certainly noticed this on suse
<mvo> zyga: what go version is suse using?
<zyga> I think it's the patches/config more than the version
<zyga> suse is fully up to date, as usual
<zyga> but please  just check what you get
<zyga> and perhaps add a spread test for build-id
<mvo> zyga: yeah, adding a spread test seems to be the right thing to move forward here with confidence
<pedronis> mvo: mborzecki: do we know if the bug exist on 1.11 ? (I was looking at the relevant code and it's quite different in 1.11)
<zyga> mvo: +1
<mborzecki> pedronis: no 1.11 seems ok
<mvo> pedronis: I think mborzecki tested on 1.11 - I let him speak
<mborzecki> mvo: pedronis: i'm bisecting between 1.10beta2 (bad) and 1.11beta3 (good)
<mvo> mborzecki: nice
<pedronis> ok, as I said, my impression is that they rewrote the relevant code in between
<pedronis> arena_used doesn't exist at some point in 1.11
<mborzecki> pedronis: yeah, it might be that they rewrote chunks of code and fixed it (or made it not be triggered) by accident
<mborzecki> mvo: they use chip PRO, slightly different than my board, idk maybe their image would work with some tweaks to dt
<mvo> mborzecki: nice
<mborzecki> mvo: heh, this reminds me of the -buildmode=shared that was triggerd by someone with yocto on i386
<mup> PR snapd#6687 closed: snap-confine: set rootfs_dir in sc_invocation struct <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6687>
<mup> PR snapcraft#2527 opened: Add -h short option for help <Created by techtonik> <https://github.com/snapcore/snapcraft/pull/2527>
<pstolowski> morning
<mborzecki> mvo: first commit that fixes our issue
<mborzecki> mvo: https://github.com/golang/go/commit/c0392d2e7fbdcd38aafb959e94daf6bbafe2e4e9
<mvo> mborzecki: aha! thank you
<zyga> re after breakfast
<mvo> mborzecki: that makes sense
<mborzecki> mvo: we've looked at a commit just 3-4 revisions later
<zyga> mvo: could we build with go 1.11?
<mvo> zyga: we don't have that unfortunately
<mborzecki> mvo: we've looked at this one https://github.com/golang/go/commit/2b415549b813ba36caafa34fc34d72e47ee8335c and it was mentioned in the issues that seemed related
<zyga> mvo: don't have it where? in the repo?
<mvo> zyga: correct, rmadison golang tells me we are on 1.10
<mvo> zyga: even in disco
<zyga> understood
<mvo> zyga: aha, sorry - we have 1.11 in disco
<mvo> zyga: as non-default but only disco, I doubt we will get a lot of support when we try to get this backported into xenial,bionic and trusty :/
<mborzecki> mvo: iirc the official policy is use the latest and n-1 releases, otherwise you're on your own
<pedronis> yes
<pedronis> so we need to discuss
 * mvo nods
<mborzecki> we'd probably need to start with having 1.11/12 packaged
 * pstolowski test 123
<pstolowski> guess it works now.. morning everyone
<mvo> pstolowski: welcome back!
<pstolowski> zyga: the failure on #6643 is unrelated to the PR right`?
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> pstolowski: yes
<zyga> I debugged it and the fixes are coming up soon
<pstolowski> k
<zyga> whhee
<zyga> it passed :)
 * zyga runs it a few more times
<mup> PR snapd#6701 opened: [ONLY FOR TESTS] Refresh awareness test debug <â Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/6701>
<mborzecki> zyga: do you have beaglebone black by any chance?
<zyga> yes
<zyga> two in  fact
<mborzecki> ha!
<mborzecki> zyga: any chance you could load 16.04 armhf image on it and hook it up to the network?
<zyga> sure, give me the URL and 15 minutes please
<mborzecki> so now we just need to find a suitable image
<zyga> do you want core  or classic?
<zyga> classic is more convenient for this test, I suppose
<mborzecki> zyga: classic
<mborzecki> hm elinux used to have the images, but i see none now
<zyga> mborzecki: let me look
<zyga> https://elinux.org/BeagleBoardUbuntu
<zyga> let me try one  of those
<zyga> I'll report back soon
<mborzecki> zyga: hm can't even locate 16.04 armhf rootfs :/
<mborzecki> zyga: is there a core 16 image maybe? i don't see one either
<zyga> h
<zyga> back in the office
<zyga> let me look at what 's on my board now
<zyga> mvo: https://paste.ubuntu.com/p/SsqgjbFqfy/ how does this look like?
<zyga> mborzecki: powering up
<zyga> and nothing yet, obviously
<zyga> I will look at flashing an image then
<zyga> mborzecki: wait
<zyga> it booted :D
<zyga> woot
<zyga> core16
<mborzecki> well, that's good enough i think
<zyga> let me try to log into it
<pstolowski> Chipaca: hey, wdyt about Samuele's remark re warnings in https://github.com/snapcore/snapd/pull/6662 ? sounds reasonable to me
<mup> PR #6662: overlord/snapstate,snapshotstate: create snapshot on snap removal (3/4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/6662>
<Chipaca> pstolowski: sounds like a separate pr to me
<zyga> mborzecki: I have the IP address but I cannot get access yet,
<zyga> maybe it refreshed to 2.38 :D
<Chipaca> pstolowski: because it's not the only instance of 'this failed but nothing to do except alert the user' in snapshotstate
<pstolowski> Chipaca: that's fine; isn't it as simple as one API call?
<pstolowski> Chipaca: ah i see your point
<zyga> mborzecki: when I ssh in I get logged out instantly
<zyga> hmmm
<Chipaca> pstolowski: but yes, it's st.Warnf(), probably
<zyga> I've attachec a keyboard
<zyga> and ... no luck?
<zyga> connection closed again
<zyga> I rebooted
<zyga> odd
<mborzecki> zyga: maybe it's updating?
<zyga> maybe
<mborzecki> zyga: do you have console attached?
<zyga> I will leave it for 15 minutes
<zyga> mborzecki: console?
<zyga> serial?
<zyga> no
<mborzecki> zyga: yeah
<zyga> I have a display
<zyga> but keyboard doesn't interact with it
<mborzecki> zyga: not once have i used display with bbb :D
<mborzecki> zyga: if it's an old core iamge, it might be getting updated now
<mborzecki> btw. figured out why the addresses are so high for the the PIE binaries on that kernel
<zyga> mborzecki: woot
 * zyga is really impressed by the debugging on this issue
<zyga> fantastic work guys!
<mborzecki> https://paste.ubuntu.com/p/c8MQWPy7fn/
<mborzecki> it's actually kernel config, need to check what's used elsewhere
<mborzecki> oh, and the address changed over kernel versions, 5.x seems to use 0x40000000
<mborzecki> as in fixed
<mvo> mborzecki: nice job! so if CONFIG_PAGE_OFFSET = 0xc0000000 was lower things must also work?
<mborzecki> mvo: 'may' :P
<mvo> mborzecki: yeah, not asking for this, just curious
<mvo> mborzecki: is ELF_ET_DYN_BASE = 0x7f555555 derived from this config somehow?
<mborzecki> mvo: yes, see the paste
<mvo> mborzecki: aha, nice, yeah, now I see it
<mvo> mborzecki: great job
<mvo> mborzecki: that was pretty hard to debug, thanks for all the effort here
<Chipaca> on core, what's the easiest way of knowing if i'm core18 or core16?
<Chipaca> also, on core18, can i remove core?
 * Chipaca is about to try it but thought he'd ask first
<mvo> zyga: it looks like build-id is available everywhere (or the system-key spread test is broken)
<zyga> mvo: +1
<mvo> zyga: would you mind double checking ? just "go build github.com/snapcore/snapd/cmd/snap -o /tmp/lala" file /tmp/lala
<mvo> zyga: to see if there is a build-id?
<mvo> zyga: on suse
<zyga> checking now
<mvo> zyga: again, just as an extra pre-caution
<mvo> zyga: thank you!
<zyga> zyga@yantra:/tmp> go build -o lala github.com/snapcore/snapd/cmd/snap; file lala
<zyga> lala: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=43261688d0e2e49bede15de8619def1bbea5e0fa, for GNU/Linux 3.2.0, not stripped
<zyga> looks ok
<zyga> perhaps that aspect of go has changed in suse since
<zyga> +1 from me
<mvo> zyga: \o/
<mvo> zyga: yeah, I think it did
<mvo> zyga: (but a quick google search did not bring up anything interessting :/
<zyga> mborzecki: one more try, if it fails I will reflash
<zyga> mborzecki: fixed auth
<zyga> mborzecki: I can now log in
<zyga> mborzecki: I'm refreshing core to stable
<zyga> it was running a local build
<zyga> mborzecki: I will install some more tools
<zyga> mborzecki: do you still need access?
<mborzecki> zyga: yes, that'd be great
<zyga> k
<zyga> mborzecki: how do we add an user to an existing system?
<mborzecki> oh
<mborzecki> haha
<mborzecki> snapd api?
<zyga> perhaps
<zyga> it's still installing a few things
<zyga> mborzecki: what kind of username do you prefer on my gateway?
<mborzecki> zyga: mborzecki?
<zyga> k
<zyga> mborzecki: ping
<zyga> https://github.com/snapcore/snapd/pull/6702 <- refresh-app-awareness fixes
<mup> PR #6702: tests: fixes discovered debugging refresh-app-awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
<mup> PR snapd#6702 opened: tests: fixes discovered debugging refresh-app-awareness <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
<zyga> mborzecki, mvo : ^
<zyga> please look, it's affecting master
<mvo> zyga: thanks
<zyga> if you feel like it I will gladly split this into core vs test fixes
<mborzecki> ogra: hi, any clue where i can find the source code of linux-generic-bbb 4.4.0-93-1 rev 21 kernel?
<ogra> mborzecki, apt-get source linux (in xenial)
<ogra> mborzecki, it is only re-packing the binary deb
<mborzecki> ogra: ah, excellent then
<ogra> (might be a bit behind in versions though)
<ogra> mborzecki, for core18 images, you can use the pc-kernel snap, in core18 we have an officially supported armhf build from the kernel team, so there is no need anymore for my hackish bbb kernel
<ogra> http://people.canonical.com/~ogra/snappy/pocketbeagle/ uses it ...
<mup> PR snapd#6701 closed: [ONLY FOR TESTS] Refresh awareness test debug <â Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/6701>
<zyga> Chipaca: hey
<zyga> Chipaca: shall I merge https://github.com/snapcore/snapd/pull/6621 now?
<mup> PR #6621: overlord/snapstate: track time of postponed refreshes <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/6621>
<Chipaca> zyga: sure
<zyga> cool, thank you
<mup> PR snapd#6621 closed: overlord/snapstate: track time of postponed refreshes <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6621>
<zyga> pedronis: hey, I noticed you were looking at https://github.com/snapcore/snapd/pull/6690
<zyga> do you have any idea about time.Time comparison?
<mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
<pedronis> yes, I'll comment there in a bit
<pedronis> (not the most important thing overall but I got curious)
<zyga> cool, I'm eager to see what you found out
<zyga> it depends on TZ that is different in tests and on local machines, I didn't dig deeper though
<ogra> just add a snap that sets the timezone (iz trivial) :)
<pedronis> zyga: commented there
<zyga> checking
<pstolowski> re
<cmatsuoka> do we run binaries using an explicit elf interpreter at some point?
<cmatsuoka> I'm having a problem with binaries with patched interpreters, but only when running with an explicit interpreter, and only on s390x :\
<cachio> mvo, pedronis zyga pstolowski mborzecki Chipaca cmatsuoka hey, I am having troubles with freenode, please if you need to contact me today please find me in the internal snappy channel
<zyga> ack
<Chipaca> pedronis: all the tests pass \o/
<Chipaca> pedronis: they really shouldn't /o\
 * Chipaca is having fun
<dot-tobias> jdstrand / ogra: I'm using the timezone-control interface on Core 16 (Raspi 3). No denials and the timezone shows up in timedatectl briefly, but afterwards timedatectl as well as date revert back to UTC. If I set the TZ with sudo timedatectl via SSH, it sticks. Am I doing something wrong, or is https://bugs.launchpad.net/snappy/+bug/1733881 affecting this?
<mup> Bug #1733881: timezone set to n/a on ubuntu core <Snappy:Confirmed> <https://launchpad.net/bugs/1733881>
<dot-tobias> ^ addendum: My app calls systemd-timezoned via DBus (tried with Ruby gem ruby-dbus as well as a test shell script which invokes dbus-send)
 * jdstrand_ defers to ogra (I would expect the dbus interface to work)
<ogra> dot-tobias, it only gets reset on reboot right ?
<dot-tobias> ogra: Just rebooted to confirm, I think I'm hitting two issues here: 1) timedatectl does not retain timezone information across reboots, but date +"%Z %z" still has proper output 2) when I set the timezone via DBus from a snap (as opposed to sudo timedatectl via SSH), /etc/writable/localtime is not written and not symlinked to /etc/localtime, thus both date and timedatectl report UTC
<ogra> dot-tobias, i have a hack to work around this ... gimme a bit
<dot-tobias> ogra: Great, thanks!
<ogra> dot-tobias, this should work (untested) https://github.com/ogra1/timezone-snap
<ogra> just install it in your image and make sure timezone-control is connected for it
<dot-tobias> ogra: Thank you! Will try out and let you know. FWIW: Is this also required on Core 18? Otherwise I could migrate my snap to core18
<ogra> i think core18 will have the same issue ... there was another bug in core18 (cant set any of hostname, timezone or locale) that i'm not sure is completely fixed yet
<mup> PR core#38 closed: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<mup> PR core#83 closed: 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#104 closed: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<mup> PR core#38 opened: Add another pi-config option <Created by sergey-borovkov> <https://github.com/snapcore/core/pull/38>
<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#104 opened: snapcraft.yaml: use remote fc-cache-builder <Created by mvo5> <https://github.com/snapcore/core/pull/104>
<zyga> https://github.com/snapcore/snapd/pull/6702 <= please review to fix master
<mup> PR #6702: tests: fixes discovered debugging refresh-app-awareness <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
 * zyga breaks for lunch
<mup> PR snapcraft#2528 opened: packaging: use our patchelf branch <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2528>
<pedronis> Chipaca: have you seen this:  https://bugs.launchpad.net/snapd/+bug/1823768 ?
<mup> Bug #1823768: snap refresh failure during task: Consider re-refresh of snap: snap has "refresh-snap" change in progress <snapd:New> <https://launchpad.net/bugs/1823768>
<Chipaca> pedronis: i had not
<pedronis> Chipaca: it seems we are detecting a self-conflict with the change, or we are missing something
<Chipaca> yep
<pedronis> Chipaca: can I assing to you, to look at it when you have some time?
<Chipaca> pedronis: yep
<pedronis> thx
<zyga> Chipaca: could you do a 2nd review on https://github.com/snapcore/snapd/pull/6702 please
<mup> PR #6702: tests: fixes discovered debugging refresh-app-awareness <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/6702>
<mup> Bug #1823988 opened: CAP_NET_ADMIN not being provided with the recommended plugs <Snappy:New> <https://launchpad.net/bugs/1823988>
<Chipaca> zyga: +1
<zyga> Chipaca: thank you!
<mup> PR snapd#6702 closed: tests: fixes discovered debugging refresh-app-awareness <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6702>
<mup> PR snapcraft#2529 opened: build providers: idempotent destroy for LXD <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2529>
<mup> PR snapd#6703 opened: tests: add deferred actions <Created by zyga> <https://github.com/snapcore/snapd/pull/6703>
<oSoMoN> jdstrand, there's a couple of chromium snap revisions awaiting manual approval, if you don't mind approving those
<jdstrand> oSoMoN: yep, I saw earlier. I'll get to them in a bit
<oSoMoN> thanks
<zyga> Chipaca: updated https://github.com/snapcore/snapd/pull/6690 based on pedronis review, could you have one last look before merging
<mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
<zyga> jdstrand: hey, how are you doing :)
<Chipaca> no
 * Chipaca closes his eyes and goes LA LA LA LA
<Chipaca> zyga: it's a-ok
<jdstrand> zyga: I'm good. you? lots of meetings today. plan on picking up more PR reviews toady
<zyga> jdstrand: good, feel happy about making progress lately :)
<zyga> jdstrand: also endless debugging of shell :)
<zyga> jdstrand: also some improvement towards better shell tests
<zyga> jdstrand: good luck with the meetings, don't get lost in them
<jdstrand> nice :)
<jdstrand> they're done now. got some takeaways to get to right away, but hopefully can finish the PR reviews then pickup daemon user tomorrow
<zyga> jdstrand: question, do you want to review https://github.com/snapcore/snapd/pull/6643
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> it's the regression test and helper program for the ioctl bug
<jdstrand> zyga: nah. I looked at it before. I only care about the result cause it is just build code and we have spread tests that will detect if we generate it wrong
<zyga> jdstrand: +1
<mup> PR snapd#6704 opened: overlord/devicestate,snapstate: measurements around ensure and related tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6704>
<zyga> I think I should break now
<zyga> jdstrand: one last word today: I noticed your branch and I will get to it soon, some of the changes there collide with upcoming changes to group handling but I will deconflict those as conflicts arise in, either branch
<jdstrand> zyga: ack
<jdstrand> I can deconflict too, but if you're keen to do it, that works
<mup> PR snapcraft#2528 closed: packaging: use our patchelf branch <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2528>
<Chipaca> zyga: getopt, not getopts
<Chipaca> zyga: util-linux, not bash
<Chipaca> oh wait your comment was about local
<Chipaca> hm
<zyga> Chipaca: thank you for the review!
<Chipaca> zyga: /bin/sh also has 'local'
<zyga> Chipaca: I replied, happy to iterate on the points raised
<zyga> Chipaca: /bin/sh may have it but it is not POSIX and shellcheck complains
<zyga> Chipaca: but I will adjust the shebang and use local happily
<Chipaca> ah ok
<zyga> Chipaca: I'm very curious about the RETURN idea, can you tell me more please
<zyga> Chipaca: ideally scope would be gone
<zyga> Chipaca: and defer would do the right thing by sourcing the file
<zyga> Chipaca: if it wasn't for prepare/restore it would be totally useless
<Chipaca> zyga: well, the execute thing is run inside a function, right?
<zyga> Chipaca: perhaps... I don't know
<zyga> I think they are all concatenated internally
<zyga> we could look at spread source code or at spread -vv output
<Chipaca> hm
<Chipaca> something for tomorrow, if it's me doing it
<Chipaca> I'm gonna EOD
<Chipaca> zyga: you should too :-)
<zyga> Chipaca: gladly
<zyga> Chipaca: thank you for the review!
<Chipaca> np! looks good
<zyga> Chipaca: defer review :)
<mup> PR snapcraft#2525 closed: catkin plugin: check stage-snaps for ROS dependencies <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2525>
<mup> PR snapcraft#2529 closed: build providers: idempotent destroy for LXD <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2529>
<mup> PR snapd#6705 opened: bootloader: little kernel support <Created by kubiko> <https://github.com/snapcore/snapd/pull/6705>
#snappy 2019-04-10
<mwhudson> anyone around who wants to talk about https://github.com/snapcore/snapd/pull/6700
<mup> PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
<mborzecki> morning
<zyga> good morning
<zyga> mwhudson: hey
<zyga> mwhudson: I think that's mborzecki and mvo
<zyga> mborzecki: did you see the feedback on https://github.com/snapcore/snapd/pull/6700
<mup> PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
<mborzecki> zyga: hi, yeah, i've seen it, i think maybe we should hold the pr for a bit and wait for the feedback about kernel patches
<zyga> pedronis: https://github.com/snapcore/snapd/pull/6642 is green and has +2, do you want to review it or can I merge it?
<mup> PR #6642: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> mborzecki: https://eventhorizontelescope.org/blog/media-advisory-first-results-event-horizon-telescope-be-presented-april-10th <- something to look at later today
<mborzecki> zyga: interesting, thanks!
<zyga> good morning mvo
<zyga> mvo: some feedback on https://github.com/snapcore/snapd/pull/6700
<mup> PR #6700: packaging: disable -buildmode=pie to fix memory issue on armhf <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6700>
<mvo> hey zyga
<mvo> zyga: looking
 * zyga tries to control his tabs-as-backlog disease 
<mborzecki> mvo: hey
<mvo> zyga: I replied, I guess we may need a HO with michael and alex
<pstolowski> morning
<zyga> mvo: there is also a response by seth arnold on the bug report
<zyga> hello pstolowski
<mborzecki> pstolowski: hey
<mvo> zyga: thanks, reading this as well
<mvo> zyga: I can understand their reaction
<zyga> yes
<mvo> zyga: *but* we are in a different situation - if we break devices because of -buildmode=pie its *our* head not theirs
<zyga> well, good luck with that
<zyga> arguably they are saying that there are other solutions
<mvo> zyga: yes, to me this is about risks. a) risk of random bug because -buildmode=pie is hardly tested and barely supported upstream  b) risk of not having buildmode=pie preventing a security issue - at this point risk(a) > risk(b) to me
<mvo> zyga: maybe I'm just grumpy this morning
<mvo> zyga: I will definitely think about it
<pedronis> mvo: notice that we don't have a regression test in that PR
<pedronis> pie is only a part  of picture, what the go allocator does is also part of the picture
<mvo> zyga: and we should talk about it (either in a HO or in the standup)
<mvo> pedronis: yes
<pedronis> I marked it blocked for now
<mvo> pedronis: what do you have in mind for such a test? in a sense the entire testsuite is a regression test. if we have a 32bit system with a 4.4 kernel that does not have the two patches mentioned in the LP bugreport then the testsuite will not survive 5s. so in a sense we have a regression test. or do you think we need soemthing that tests that we really don't have -buildmode=pie?
<mborzecki> anyways, it was fun debugging that issue :) wish we had perf on the device, then maybe we could finger point the exact line where mmap2 failed
<pedronis> mvo: but that test will never be run again
<pedronis> in the suite
<pedronis> unless we add such a device in the lab
<pedronis> or fake the sitution in the suite somewhere
<mvo> pedronis: maybe a HO? I may be too slow this morning
 * zyga notices more BPF love https://lwn.net/Articles/785263/
<mvo> pedronis: not sure I understand the suggestion/question
<pedronis> mvo: I can undo  those changes and nothing will turn red
 * zyga would love to listen in on the call 
<mvo> pedronis: right, so we want a test that checks if "-buildmode=pie" is really *not* used
<zyga> if pedronis and mvo will HO please indicate so
<pedronis> mvo: we can test that but is kind of shallow
<mvo> zyga: sure thing - maybe its not needed - probably better if not or I will just rant
<pedronis> because as I said pie is only one part of the problem
<mvo> pedronis: correct
<mvo> pedronis: ok, maybe a HO afterall? I think this is complex (or might become complex)
 * pedronis needs to have breakfast first
<zyga> https://meet.google.com/gik-uony-oni?authuser=0 <- in case anyone want to meet
<pedronis> zyga: ^
<zyga> ack, I saw
<mvo> pedronis: just ping us when you are ready and no worries :) maybe I'm less grumpy by hte time you had breakfast
<zyga> mvo: join, you can vent any frustration ahead of the discussion :)
<mvo> zyga: haaha
<zyga> mvo: mic is not allowed
<zyga> I can hear you though
<zyga> mvo: my 2fa device
<zyga> no microphone found
<zyga> hold on :D
<zyga> mvo: I'm a perfect listener today
<zyga> glib or glibc
<pstolowski> Chipaca: hey, any thoughts on https://github.com/snapcore/snapd/pull/6698#discussion_r273011330 ?
<mup> PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <https://github.com/snapcore/snapd/pull/6698>
<Chipaca> pstolowski: hm?
<Chipaca> pstolowski: why is client/ caring about the length of it?
<pstolowski> Chipaca: re zyga's question
<Chipaca> re zyga's question, if it's going to get shortened, yes
<pstolowski> Chipaca: (the unicode thing)
<pstolowski> Chipaca: ok. it's cosmetics. thanks
<Chipaca> pstolowski: but
<pstolowski> i knew there will be "but" ;)
<zyga> but then you have to handle dumb terminals
<pstolowski> zyga: ok, no point in doing this then
<Chipaca> my 'but' was going to be: if you want it to be <12, then it's not str[:12]+"â¦" (nor str[:12] + "...")
<Chipaca> assuming str starts out as ascii, if len(12) you want str[:11]+"â¦", or str[:9]+"..."
<Chipaca> if you don't know if str is ascii, then none of those slices are going to be ok
<pstolowski> Chipaca: it's ascii only, it's for sha256 checksum string
<Chipaca> ah, then it's fixed length!
<Chipaca> pstolowski: what we've done elsewhere to handle that is just "%.7sâ¦"
<pstolowski> Chipaca: ah, indeed
<Chipaca> pstolowski: in o/sh/backend
<pstolowski> thanks
<Chipaca> zyga does have a point about dumb terminals, but for â¦ we don't worry too much (it's supported on the default framebuffer font, and if it's not supported the resulting rhombus is not too hard to figure out)
<zyga> +1 Chipaca
<mup> PR snapd#6577 closed: many: make Remodel() download everything first before installing <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6577>
<pedronis> \o/
<mvo> pedronis: I also updated the two followups
<pedronis> ok
<pedronis> pstolowski: I'm not sure I need to review 6698, if we switched â¦ though, we should do it also for the vendor ?
<pstolowski> pedronis: yes, i did it for vendor in same PR
<pstolowski> pedronis: and np, i will ask around for 2nd review
<pstolowski> mborzecki: hey, do you have a moment to review #6698?
<mup> PR #6698: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <https://github.com/snapcore/snapd/pull/6698>
<mborzecki> pstolowski: sure, in a bit, looking at the LK pr now
<mborzecki> need a 2nd review on #6692, it's super simple, just a cleanup
<mup> PR #6692: interfaces: cleanup internal tool lookup in system-key <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
<mborzecki> stepping out for a bit, teachers' strike is still on but i need to take the kids to some extra classes in robotics :)
<mborzecki> re
<mup> PR snapd#6698 closed: overlord/ifacestate: introduce HotplugKey type use short key in change summaries <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6698>
<mborzecki> zyga: idk if you've seen this: https://forum.snapcraft.io/t/compatibility-issues-running-snaps-under-fedora-29/10402/7
<mborzecki> i'm updating my fedora vm now
<mborzecki> zyga: obviously none of that happens in a vm :/
<mborzecki> zyga: https://forum.snapcraft.io/t/compatibility-issues-running-snaps-under-fedora-29/10402/12 some logs here too
<mborzecki> looks like snap-device-helper cannot be executed?
<mborzecki> zyga: ha, i can reproduce with 2.38 on fedora
<zyga> mborzecki: i have not seen this yet
<mborzecki> zyga: i cannot reproduce it with other snaps i tried where i've seen snap-device-helper being invoked too
<zyga> eh
<zyga> I know this bug
<zyga> libexec vs lib
<mborzecki> zyga: but other snaps on fedora also invoke /usr/lib/snapd/snap-device-helper and it works
<zyga> nno
<zyga> it's more complex than that
<zyga> there are two consumers
<zyga> one on the inside of the ns and one on the outside
<mborzecki> zyga: https://paste.ubuntu.com/p/NTNMJFkkdq/ hahaha
<mborzecki> zyga: ehh, so fedora patches their snap-device-helper to use #!/usr/bin/sh
<mborzecki> zyga: and with base specified, we take host's libexecdir into snap mount ns right?
<mup> PR snapcraft#2530 opened: Patchelf test branch <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2530>
<zyga> back at the office
<zyga> mborzecki: I responded on the forum
<zyga> mborzecki: right
<zyga> we knew about this for a while :/
<zyga> mborzecki: correct
<zyga> mborzecki: it's all broken because of complexity
<zyga> it's hard to reason about anythiign
<zyga> and many things have to be ultra portable in consequence
<mborzecki> zyga: still, intersting why they end up using /usr/bin/sh, probably some flatpak/ostree requirement
<mborzecki> zyga: oh, and where that happens, i don't see anyting obvious in rpm build log
<zyga> mborzecki: it's an automatic change
<zyga> mborzecki: merged usr probably
<zyga> mborzecki: I reported it when it broke spread tests
<zyga> mborzecki: our spread tests take the incorrect assumption that a locally built snapd can work in re-exection context and can be injected into core snaps
<mborzecki> zyga: hm maybe we should just have a symlink /usr/bin/sh -> /bin/sh in core18
<zyga> no no no
<zyga> I mean
<zyga> I don't care about symlinks
<zyga> we need to fix the complexity aspect
<zyga> and clearly indicate in each executable where it is expected to run
<zyga> as a quick fix I would rewrite snap-device-helper in C
<mborzecki> zyga: there was a pr from jamesh to rewrite it in go iirc
<zyga> yes
<zyga> I would prefer C to speed up startup time
<zyga> it's quite expensive already
<mborzecki> zyga: we could probably keep it within ~1M range with go
<zyga> it doesn't need to be in go, really
<zyga> we need to rethink
<zyga> perhaps it is obsolete entirely
<zyga> mborzecki: it's the fact that it is  invoked numerous times that bugs me
<zyga> on app startup
<mborzecki> right, but it should be cached after first call
<zyga> but starting a 1MB executable is not free
<zyga> anyway, I don't see the point for go there
<zyga> or the need for the executable if we do things right
<mborzecki> and we could write it in minimal go, like print() instead of fmt.*
 * zyga is not  conviniced by any of that 
<mborzecki> anyways, looks like we need to address this soon-ish
<zyga> low-cost fix is to change fedora  package to undo  the interpreter change
<zyga> then I would like to rip it out of snap-confine exec path
<zyga> then the path doesn't  matter anymore
<mborzecki> zyga: provided there isn't some made up policy that disallows that :P
<zyga> lastly I would remove the executable entirely
<zyga> by changing how snapd uses it
<zyga> mborzecki: we can talk tomorrow
<popey> zyga: something appears to have broken gl in 19.04
<popey> snap install godot --classic, works on 18.04, 18.10, not on 19.04
<popey> We had this with 18.10 iirc, is there some hard-wired path that's changed again?
 * zyga doesn't know and remarks that the gl solution is a hack that outgrew its usefulness vs cost
<zyga> mvo: did you see https://errors.ubuntu.com/problem/5e58e04cdc647a1fd50f71f02724dd0b5b8c1f4b
<zyga> popey: please report a bug with hardware details
<popey> ok
<mvo> zyga:  I did see it
<zyga> popey: we still hope to start gl work this cycle but it's not something to be finished yet
<zyga> mvo: any ideas? go's backtraces are useless
<mvo> zyga: I did not really dive into it, sorry, I suspect correction
<zyga> correction?
<zyga>         err.data = 0x20 <error: Cannot access memory at address 0x20>
<mvo> zyga: corruption
<mvo> zyga: sorry
<zyga> #3  0x0000563c3ac477a7 in github.com/snapcore/snapd/systemd.SdNotify (notifyState=..., ~r1=...) at /build/snapd-DbAuQM/snapd-2.38+18.04/_build/src/github.com/snapcore/snapd/systemd/sdnotify.go:51
<zyga> seems like when we try to talk to systemd something goes south
 * mvo nods
<popey> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824168
<mup> Bug #1824168: classic opengl application on 19.04 fail to find gl drivers <amd64> <apport-bug> <disco> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824168>
<zyga> popey: I don't have the hardware to debug this
<zyga> popey: but I believe it  is the switch to libgl
<zyga> that is out of sync with 16.04 based solution currently present
<popey> you might be able to debug in virtualbox
<zyga> popey: how?
<popey> run 19.04 in virtualbox and install the snap inside it
<popey> (which also fails)
<popey> but it works on 18.04 and 18.10 in virtualbox on the same host
<zyga> popey: understood
<mup> PR snapd#6706 opened: ubuntu: disable -buildmode=pie on armhf to fix memory issue <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6706>
<zyga> popey: https://twitter.com/zygoon/status/1115993934927421440
<popey> shared
 * cachio lunch
<tomwardill> zyga: I've got a GTX 960
<tomwardill> currently running 19.04 pre-release
<zyga> tomwardill: and proprietary drivers?
<tomwardill> yep
<tomwardill> release 390, according to software center
<zyga> tomwardill: can you pastebin lsmod, dpkg -S nvdia-* (not sure what the package names are); run a steam game and while it is running cat /proc/pid-of-game/maps
<tomwardill> yep
<tomwardill> will report back in a few minutes :)
<zyga> tomwardill: thank you, that will allow me to collect this kind of stuff into a script later
<zyga> sure, thank you!
<zyga> tomwardill: also, if you have any, run a non-trivial non-steam game
<tomwardill> will factorio do?
<zyga> tomwardill: via strace -ff  -o
<zyga> I suspect so :)
<zyga> and also collect the log, it may be heavier though
<zyga> tomwardill: do you know how to reach me via email?
<tomwardill> I can look you up in the directory :)
<zyga> perfect
<zyga> tomwardill: perhaps attach to https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824168
<zyga> more useful this way
<mup> Bug #1824168: classic opengl application on 19.04 fail to find gl drivers <amd64> <apport-bug> <disco> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824168>
<zyga> I need to go AFK, running for classes
<zyga> ttyl
<tomwardill> zyga: added files to the bug
<Chipaca> zyga: can a snap that exposes a content interface itself have apps?
<cachio> https://www.irccloud.com/pastebin/NqYOg55m/
<cachio> Chipaca:
<mup> PR snapd#6707 opened: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests  <Created by pedronis> <https://github.com/snapcore/snapd/pull/6707>
<cachio> mvo: hey, ubuntu-core snap is being use currently?
<cachio> Chipaca:
<cachio> Chipaca:  Chipaca: There is an issue when we install with --dangerous, which is that it is not resuming a .partial file for hte base snap and it is affecting the core18 tests when we run install_local xxxx
<cachio> Chipaca: any idea if it is working as designed or it is a bug?
<Chipaca> cachio: what does a partial have to do with --dangerous?
<Chipaca> .partial files are from the store
<cachio> Chipaca: I implemented a new mechanism to speedup the installation of snaps on out test suite
<cachio> Chipaca: so the idea is to download a snap and leave it in /var/lib/snapd/snaps as a .partial
<Chipaca> cachio: right
<Chipaca> cachio: but that only works for snaps that you download
<Chipaca> cachio: install_local doesn't look at .partials
<cachio> right
<cachio> so in ubuntu core 18
<Chipaca> I mean, literally, the code that checks .partial is in store/, it never reaches that for InstallPath
<cachio> I install jq
<cachio> and it uses the core_*.snap.partial
<cachio> which is the base
<cachio> but if I do snap install test-snapd-tools --dangerous
<cachio> it is not resuming the .partial for core
<cachio> so it downloads core
<Chipaca> oh, no i got it
<Chipaca> that sounds like a bug
<cachio> ahh, ok
<cachio> it should resume ritght?
<Chipaca> yes
<cachio> ok
<cachio> do you want a forum post, a lp bug?
<cachio> nothing :)
<cachio> Chipaca: https://travis-ci.org/snapcore/spread-cron/builds/518148049#L2108
<cachio> initially I saw that just running locally
<cachio> but now I also see errors on the boards which run in the lab
<Chipaca> cachio: lp bug
<cachio> Chipaca: nice, thanks
 * cachio akf
 * cachio afk
<pedronis> zyga: 6642 can land
<zyga> pedronis: ack, thank you. Iâll land it now
<Chipaca> zyga: can a snap that exposes a content interface itself have apps?
<zyga> Chipaca: technically yes
<mup> PR snapd#6642 closed: cmd/snap-confine: prevent cwd restore permission bypass <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6642>
<zyga> E.g. a hypothetical Java JRE snap
<zyga> Chipaca: though today I donât know of any that do
<zyga> Iâm on a bus so please forgive my inconsistent response speed
<Chipaca> zyga: does a snap that uses a content interface need to specify a default provider?
<zyga> Chipaca: I believe it may but does not have to. I would have to consult specifications to see if this is required
<Chipaca> zyga: np
<Chipaca> zyga: does a content interface exposed by a snap and used by another get connected when you install one of the two and have the other one installed?
<zyga> Yes
<zyga> Assuming the connection is not ambiguous
<zyga> I donât believe we changed that yet
<Chipaca> zyga: ambiguous as in have more than one snap expose the same one?
<zyga> We discussed having hints about the number of accepted connections that might allow an app to, for example, connect all plugins
<zyga> Ambiguous as in having more than one connection candidate available
<zyga> What are you looking at Chipaca?
<Chipaca> zyga: some weird integration req's; i'll cc you in
<zyga> Thank you sir!
<jdstrand> niemeyer: hey, not a bug deal, but it seems the forum checkbox plugin thing went away again (ie, I can't see it in https://forum.snapcraft.io/t/manual-review-for-squaremetrics-ble-scanner/10836/2)
<jdstrand> s/bug/big/
<Chipaca> jdstrand: note the forum is now in IS's hands
<jdstrand> Chipaca: oh, I did not know that
<jdstrand> Chipaca: does that mean RT?
<Chipaca> jdstrand: probably
<om26er85> come on
<om26er> Hi! How can I make my snap be able to read a config file from ~/my_config.yaml ?
<om26er> My software reads its runtime configuration from that file, So basically a user can just open that file, edit it and then run my snap
<cachio> om26er: hi, you need to use the home interface for that
<om26er> hmm, I do have home interface connected apparently, but $HOME seems to resolve to $SNAP_USER_COMMON still, what am I missing ?
<cachio> om26er: which error do you see when you try to access the config file?
<om26er> cachio my snap is not able to see that file because it expands $HOME to /home/om26er/snap/surc/14 instead of /home/om26er
<Chipaca> om26er: it's not SNAP_USER_COMMON, but yes
<Chipaca> that's expected
<Chipaca> om26er: if you need to get actual HOME, you'll need to use look it up
<cachio> Chipaca: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1824230
<mup> Bug #1824230: Download not resumed for base snap when using "snap install --dangerous" <snapd (Ubuntu):New> <https://launchpad.net/bugs/1824230>
<om26er> Chipaca hmm, like checking if /home/$USER/my_file.yaml exists and reading that ?
<Chipaca> om26er: or https://github.com/chipaca/icdiff/blob/master/snap/snapcraft.yaml#L73
<om26er> ^ that's intelligent though I'll find a somewhat similar solution that doesn't require me to stage a new package in my snap
<Chipaca> om26er: what package does that require you to stage?
<Chipaca> om26er: (it uses nothing that's not in core)
<om26er> git-icdiff ?
<Chipaca> om26er: that's the snap that's used on
<Chipaca> om26er: that sed line adds a perl command at the top of the script
<Chipaca> om26er: the perl command is the one you might want
<Chipaca> om26er: i.e. HOME=$(perl -we "print((getpwuid $>)[7])")
<om26er> Chipaca sorry, I misunderstood that, seems it just work :)
<Chipaca> no problem
<mup> PR snapcraft#2531 opened: snap: revert to patchelf 0.9 with local patches <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2531>
<om26er> thanks Chipaca
<zyga> Chipaca: can I land https://github.com/snapcore/snapd/pull/6690 ?
<mup> PR #6690: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <https://github.com/snapcore/snapd/pull/6690>
<Chipaca> zyga: you can land _everything_
<zyga> that's very encouraging
<zyga> landing then :)
<mup> PR snapd#6690 closed: overlord/snapstate: inhibit refresh for up to a week <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6690>
<Chipaca> zyga: the one i'd asked you to hold, i'd tagged with blocked, and then removed the tag when it was done
<roadmr> https://memegen.link/_eHkJbGFuZC9hbGxfdGhlX3RoaW5ncwkJ.jpg
<Chipaca> zyga: what roadmr said
<zyga> Chipaca: woot
<zyga> I'm off to watch black hole stuff with my kids
<zyga> we have to watch it in spanish because that's the best intersection of comprehension and quality :D
<Chipaca> zyga: https://xkcd.com/2135/
<zyga> that's great
<zyga> it's really difficult to talk about the scale of that thing using human scales
<zyga> ha
<Chipaca> yeah, my scales only go up to about 120kg
<zyga> and the author is wrong here
<zyga> the event horizon is much smaller than the black ring
<zyga> er, black hole inside the ring
<zyga> so voyager woud be surely "past" it in this sense
<zyga> anyway, very exciting times to live :)
<Chipaca> zyga: also, https://www.youtube.com/watch?v=zUyH3XhpLTo
<ahasenack> hm, hi, I just got this error in a script that installs snapd, and then a snap: https://pastebin.ubuntu.com/p/VHpxMY9grP/
<ahasenack> is it because it was too fast? Is there a way to tell when snapd is ready?
<ijohnson> ahasenack: try using `snap wait system seed.loaded`
<ahasenack> that seems to have helped
<mup> Bug #1824240 opened: snapd can't be purged with latest AWS Xenial AMI <Snappy:New> <https://launchpad.net/bugs/1824240>
<mup> Bug #1824240 changed: snapd can't be purged with latest AWS Xenial AMI <Snappy:New> <https://launchpad.net/bugs/1824240>
<mup> PR snapcraft#2531 closed: snap: revert to patchelf 0.9 with local patches <Created by cmatsuoka> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2531>
<sergiusens> cmatsuoka: just manually tested the new edge using 0.9+snapcraft, seems like we are back in business
 * cachio afk
<mup> PR snapcraft#2530 closed: Patchelf test branch <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2530>
#snappy 2019-04-11
<ijohnson> plars: canceled the job
<plars> ijohnson: thanks, feel free to resubmit, just keep that section of the yaml from the example
<mborzecki> morning
<zyga> Good morning
<mborzecki> zyga: hey
<mborzecki> mvo: hi
<mborzecki> mvo: zyga: i'll be out for a while in the morning, sent a message in the forum
<mvo> hey mborzecki
<mvo> mborzecki: no worries, thanks for letting us know
<mvo> zyga: good morning to you as well
<zyga> Hey mvo
<zyga> Mvo some bad news from last evening
<zyga> Mvo: snapd broke in adt
<zyga> There is a bug with the details
<zyga> Iâm with the dog outside so no links, sorry
<zyga> Just sort by snapd but numbers
<mvo> zyga: oh, interessting
<mvo> zyga: reading now, we need to investigate
<mvo> having snap changes output would be good
<zyga> mvo: I can look back home
<mvo> zyga: it really looks a bit mysterious, no trace of core there
<mvo> zyga: that sounds more like a bug in out testsuite
<dot-tobias> good morning!
<zyga> mvo: note that it happens outside of the test suite
<zyga> It affects docker, for example
<zyga> Hey dot-tobias :-)
<dot-tobias> Hi zyga ð
<mvo> zyga: oh, hmmmmm
<zyga> I'm back home; I'll make coffee and see what I can find
<zyga> back from breakfast
<pstolowski> morning
<zyga> good morning pawel!
<mvo> hey pstolowski
<mvo> 6706 needs a review
<zyga> mvo: doing
<mvo> ta
<zyga> done
<mvo> ta
<mvo> zyga: the indent in 6706 was added to make it easier to read, is that bad in some way?
<zyga> it looks like there is an extra space there
<zyga> perhaps tabs spaces?
<mvo> zyga: it looks like its just a strange formating of the diff, let me double check with side-by-side view
<mvo> zyga: it looks ok here (unless I miss something) the first "ifneq" is unchagned, maybe this is why it looks strange
<zyga>  https://usercontent.irccloud-cdn.com/file/sqaMmc5M/Screenshot%202019-04-11%20at%2009.47.03.png
<zyga> does the line with the + has a space up front?
<zyga> oh
<zyga> mvo: the logic is wrong
<zyga> no?
<zyga> you want ifeq, not ifneq
<zyga> because when you have two ifneq lines , one will always match
<zyga> ah, I see, they *are* nested
<zyga> mvo: let me suggest something
<mvo> zyga: hm, let me look. if thats so then the test is also broken
<mvo> zyga: I can change it to use "dpkg-architecture -qDEB_TARGET_ARCH_BITS"
<zyga> mvo: added one more comment
<zyga> mvo: +1 on that idea
<zyga> mvo: on both the test and the build rules
<mvo> zyga: ok, let me look at this
<zyga> mvo: we have one more bug report https://bugs.launchpad.net/snapd/+bug/1824242
<zyga> perhaps something that warrants an SRU?
<mup> Bug #1824242: snapd can't be purged with latest AWS Xenial AMI <cloud-images:New> <snapd:New> <https://launchpad.net/bugs/1824242>
<mvo> zyga: yeah, if that is missing from 2.38 we definitely need to add the cleanup in 2.38.1
<mvo> zyga: 2.38.1 will also include 6706
<zyga> sorry for the  busy morning
<zyga> I am looking at the adt issue now
<mvo> zyga: thanks, +1
<mvo> yeah, 2.38 has the right "rm -rf" call
<zyga> let's update the bug to reflect that 2.38 fixes it
<mvo> zyga: I just did that
<pedronis> mvo: hi, I added this card: https://trello.com/c/tx49EL3F/221-add-black-box-test-testing-memory-mappings-mmap-sizes-and-max-resident-memory-against-decided-limits-budget-for-snapd-and-snap-i
<willcooke> Hi gang.  We're suddenly seeing this bug:  https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1824188
<mup> Bug #1824188: Software tab is empty on clean 19.04 install <amd64> <apport-bug> <disco> <rls-dd-incoming> <gnome-initial-setup (Ubuntu):Confirmed> <https://launchpad.net/bugs/1824188>
<willcooke> GNOME Initial Setup is getting a "connection reset" from snapd when trying to get the list of software for promotion at the end of set up during first login
<willcooke> Could you take a look?
<willcooke> or lend a hand
<zyga> hey willcooke
<seb128> " Failed to get featured snaps: Failed to read from snapd: Error receiving data: Connection reset by peer"
<zyga> I think we will have to, there are some more 19.04 reports coming in yesterday
<zyga> I'll prep a VM as soon as I'm done looking at ADT issues
<willcooke> thanks zyga
<seb128> I had snap list failing also yesterday, but disk was full so maybe a side effect of that
<willcooke> I'll add some more logs to the bug
<seb128> thx zyga
<zyga> thank you!
<mvo> zyga: I updated 6706 - anything new on the ADT issue?
<zyga> mvo: not yet, pulling many things at the same time makes my link slow; just constructed adt image
<mvo> zyga: ok
<mvo> zyga: it was specifically cosmic, right?
<zyga> yes
<zyga> I just spawned the test
<zyga> we'll know shortly
<mvo> ta
<mborzecki> re
<mvo> hey mborzecki - welcome back
<mvo> mborzecki: want to look at 6706? should be easy
<zyga> eh
<zyga> I love hand-holding adt
<zyga> nothing works in that thing
<zyga> obviously it cannot talk to the network
 * zyga is debugging
<mborzecki> mvo: sure, looking
<mborzecki> ah that's the PIE thing
<zyga> mvo: do you know how to spawn adt in qemu with bridged network or something that is not just broken?
<zyga> I used
<zyga> autopkgtest -s -U snapd_2.38+18.10.dsc -- qemu ./autopkgtest-cosmic-amd64.img
<zyga> this doesn't work
<mvo> zyga: oh, thats strange, that should work
<zyga> let me grab some logs
<mborzecki> mvo: posted some comments there
<mborzecki> mvo: basically, i think it  would make sense to include s-c in the test and make sure it's built with PIE, because it's C, so it's bad and all that :)
<mborzecki> zyga: is snap confine poking $SNAP_DATA now? see a new denial in the selinux branch
<zyga> mborzecki: details please
<mborzecki> type=AVC msg=audit(1554975937.636:129): avc:  denied  { getattr } for  pid=1099 comm="snap-confine" path="/var/snap/test-snapd-service/x1" dev="vda1" ino=393657 scontext=system_u:system_r:snappy_confine_t:s0 tcontext=system_u:object_r:snappy_var_t:s0 tclass=dir permissive=1
<mborzecki> zyga: ^
<mborzecki> ha, maybe it's the cwd changes in snap-confine
<zyga> mborzecki: so, snap-confine always did that
<mvo> mborzecki: sounds good, go for it
<zyga> getattr?
<mvo> mborzecki: or in a separate PR, no strong opinion
<zyga> mborzecki: perhaps it is a combination of two things:
<zyga> this being a service
<mborzecki> zyga: yes, fstat probably
<zyga> so HOME is set to $SNAP_DATA
<zyga> and the cwd changes
<zyga> since apparmor does not mediate fstat at all
<zyga> it was not showing up
<mborzecki> zyga: i see we set WorkingDirectory for generated services to $SNAP_DATA
<zyga> why did it not show up in the selinux test?
<mborzecki> so that's probably it
<zyga> mborzecki: I agree
<zyga> mborzecki: is the selinux test capable of seeing the denials now?
<zyga> mborzecki: was it one test or a restore-time check in all tests?
<mborzecki> zyga: intersting how this test will be able to detect this :)
<mborzecki> zyga: it's the selinux-clean test, specificaly targeted to catch any denials that may come up
<zyga> I see
<zyga> perhaps we should move the check to post-restore stage
<zyga> like we do with apparmor, I believe
<mborzecki> zyga: yeah, seems like we'll be able to update the policy proactively now, rather than waiting for bug reports in rhbz
<zyga> +1
<zyga> popey: on the 19.04 opengl issue, as you know I asked for some help on twitter and got a very useful response
<popey> Excellent
<popey> Good to hear twitter isn't just for nazis :D
<zyga> popey: I will look at what the situation is inside a virtual 19.04 system in the context of a separate issue that was raised by willcooke today; after that I should be able to make some progress towards understanding the cause of the opengl regression
<popey> Thanks for letting me know!
<zyga> popey: arguably that was even more useful than insta-ordering a gtx on amazon
<zyga> because I got feedback from more diverse collection of systems
<popey> Wellll....
<popey> I mean, okay, but if we had some QA on these GTX systems *before* I found the issue, that argument doesn't hold.
<zyga> We don't do QA like that I'm afraid
<zyga> but we also know about the shortcomings of the solution we have now
<zyga> and we have the improvements in the roadmap
<zyga> for this cycle (though arguably we will be late)
<zyga> I'm saying that the wheels started spinning already
<zyga> mborzecki: some failures from autopkgtest in qemu:
<zyga> https://www.irccloud.com/pastebin/vUlozfth/
<zyga> perhaps insufficient mocking?
<zyga> running more tests
<mborzecki> hm maybe
<mborzecki> btw. there's no 18.04-32 in the spread suite?
<mborzecki> zyga: the nvidia card is in an older system i have here, i can look into 19.04 later on if i manage to install it on a usb stick
<zyga> mborzecki: I have useful data already, I need to process it first
<mborzecki> zyga: ah, that's fine then
<mborzecki> zyga: has anything changed with the libs again?
<zyga> not sure yet
<pstolowski> pedronis: hey, toughts on snap debug timings --ensure=... output: https://paste.ubuntu.com/p/dXZqyDxVG6/ ?
<pedronis> pstolowski: thx, need to think a bit. I will look at the PR producing the data today
<zyga> brb
<zyga> Chipaca: hey, are you looking at the 19.04 empty software tab bug?
<Chipaca> zyga: ye
<zyga> great, thanks!
<Chipaca> why is journalctl still broken on 19.04?
<Chipaca> stuff is going to /var/log/syslog skipping journalctl entirely
<Chipaca> this is a breaking change :-(
<zyga> woah
<zyga> that's odd
<mborzecki> btw. 19.04 beta ok to use for install or should i rather try a daily one?
<zyga> I downloaded daily but did not install it yet
<mvo> zyga: anything new on the ADT issue? I ran it in qemu 3 times and no failure :/
<zyga> same here, more iterations
<zyga> I updated the bug report a moment ago
<Chipaca> willcooke: why is journalctl not showing logs on 19.04, do you know?
<willcooke> Chipaca, we had this problem before when we were trying to work out why it wasnt installing some snaps.  I don't think we ever got to the bottom of it.  It seems that it was just snapd that wasn't logging properly, even with the logging turned right up.  Was it that it was just taking a while to get flushed to the log?
<Chipaca> willcooke: the logs are in /var/log/syslog, immediately, but journalctl always reports empty
<willcooke> seb128, any ideas? ^
<mup> PR snapd#6706 closed: ubuntu: disable -buildmode=pie on armhf to fix memory issue <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6706>
<mvo> I cherry picked 6706 now for 2.38
<zyga> mvo: will you also tackle the PIE of snap-confine?
<mvo> zyga: not right now, also not as part of 2.38.1 - no time today. but feel free to grab it (or maybe mborzecki)
<seb128> Chipaca, willcooke, I guess snapd doesn't use the proper logging api/could integrate to the journal? a problem on the snapd side for sure
<zyga> seb128: how does that explain difference between 19.04 and prior releases?
<Chipaca> seb128: ? how can it be "a problem on the snapd side for sure" when the exact whatever-it-is-snapd-does works on anything other than 19.04?
<seb128> Chipaca, like you are sure it works on fedora 30 or other distros with the same systemd stack?
<mvo> ddstreet: re failing autopkgtest - do you have a machine around that you can ssh into that has the failure? I would love to see the "snap changes" output of it
<seb128> zyga, I don't know what snapd is doing, maybe it's relying on old syslog and should integrate better with systemd journal?
<seb128> well, I guess it could be an issue on the systemd side
<mvo> ddstreet: fwiw, it looks like things started to fail at 2019-04-03
<zyga> seb128: I see, perhaps the question is: how should snapd log?
<seb128> it should integrate to journalctl
<seb128> imho
<seb128> it could be that it's doing things in a "legacy" way and that regressed in the journal side so a bug
<seb128> anyway, I think that needs looking at by someone who understand the snapd logging code and what is done exactly
<ddstreet> mvo, let me see if i can repro it in a system on the canonical vpn
<Chipaca> snapd, and all snaps that have daemons, rely on the behaviour that a service printing to stdout/stderr ends up in the journal
<Chipaca> seb128: ^
<seb128> Chipaca, snapd re-exec itself? could that confuse the systemd units or something
<seb128> Chipaca, zyga, in any case it's an issue specific to snapd so unsure what it's doing differently but imho the best person to debug that is someone who knows what snapd is doing exactly
<seb128> or maybe talk to foundation if you believe the issue is on the journal side
<seb128> but they are probably going to need a testcase/details on what snapd is doing and how it's different from other services that work fine
<Chipaca> gah
<Chipaca> ok, the problem is different
<Chipaca> seb128: 'journalctl -u snapd' says no entries
<Chipaca> seb128: 'sudo journalctl -u snapd' works
<Chipaca> so, it is a behaviour change in journalctl, but not as bad as i thought it was
<seb128> ah, so logging is working, good :)
<zyga> Chipaca: perhaps it's just permission difference
<zyga> Chipaca: on many distributions journalctl is locked down
<Chipaca> zyga: yes, but you get an error when you try
<Chipaca> not a 'no entries'
<zyga> Chipaca: is it possible that you just reach the per-user instance of journalctl ?
<Chipaca> Â¯\_(ã)_/Â¯ i have no idea
<Chipaca> i'm trying to debug wacky interactions with snapd elsewhere in this
<seb128> journalctl -u snapd works on disco here, without sudo
<Chipaca> not figure out why systemd changed the rules again
<seb128> but it's not a new install
<seb128> so maybe some permission is not correctly set or something
<seb128> Chipaca, does it work for other units? like gdm or upower?
<Chipaca> seb128: no
<seb128> Chipaca, and "systemctl --system -u snapd"?
<Chipaca> insufficient permissions
<seb128> k
<seb128> so that's the issue
<seb128> probably worth talking to xnox about and/or reporting on launchpad against systemd
<xnox> que?!
<seb128> xnox, is it normal that journalctl on disco new installs require sudo to access the system logs?
<xnox> what do you expect for "systemctl --system -u snapd" to do? there is no verb, maybe "journalctl -u snapd" ?
<seb128> (it doesn't on my upgraded system)
<seb128> xnox,
<seb128> <Chipaca> seb128: 'journalctl -u snapd' says no entries
<seb128>  seb128: 'sudo journalctl -u snapd' works
<xnox> seb128, it depends which groups the person is in. and what "new install" is - container, desktop, server?
<seb128> xnox, I think people see the problem on disco desktop/ubiquity install
<xnox> one does need to be like in sudo group, or in adm, or somewhere like that.
<xnox> hmmm
<xnox> on desktop, the first user should be able to read all the logs i think.
<seb128> what group is that you need?
<xnox> checking
<xnox> i believe it was `adm` group, but that's from memory, looking at code
<seb128> Chipaca, what groups is your user in? does it include adm?
<xnox> and $ sudo getfacl /var/log/journal/
<xnox> this has possibly regressed.... because i don't see us configuring adm group
<seb128> Chipaca, ^
<Chipaca> user is in adm cdrom sudo dip plugdev lpadmin sambashare
<Chipaca> seb128: https://pastebin.ubuntu.com/p/6rg6tGVMJY/
<mvo> zyga: fun observation - docker.io deb package has a shell defer in debian/tests/common
<zyga> mvo: oh, would you mind pasting it?
<zyga> I wonder how they implemented it
<mvo> zyga: common
<Chipaca> systemd-journal systemd-timesync systemd-network systemd-resolve systemd-coredump
<mvo> zyga: http://paste.ubuntu.com/p/dw3kKtzPJq/
<Chipaca> huh, xenial also has 'em
<zyga> mvo: interesting, thank you!
<seb128> Chipaca, xnox, on my upgraded system there is a "group:adm:r-x" extra line compared to that
<seb128> Chipaca, can you file it on https://bugs.launchpad.net/ubuntu/+source/systemd/+filebug ?
<seb128> I guess something for xnox to poke at
<xnox> Chipaca, and like doing $ sudo setfacl -nm g:adm:rx,d:g:adm:rx /var/log/journal/
<xnox> doesn't seem to help
<xnox> oh, maybe i need to restart journald
<kjackal> Hi jdstrand how is it going? I am officialy appointed to strict confinement of microk8s! Going through the instructions/patches gathered, i am facing problems. I am now focusing on kube-proxy. Can you spare some time to get me upto speed with your work?
<Chipaca> xnox: do you need the bug?
<xnox> Chipaca, yes, please
<Chipaca> what's the name for the user that gets created on install?
<kjackal> jdstrand: I see you have pushed the interfaces since early November but I wonder if i am missing something
<Chipaca> 'default user'?
<seb128> that should be good enough
<seb128> I don't think we have a defined wording, default/first/...
<xnox> Chipaca, can you fix it with:
<kjackal> jdstrand: this is how kubeproxy is failing: https://pastebin.ubuntu.com/p/cN3sK5gpX8/ although I request for iptables proxy setup it falls back to userspace
<xnox> $ sudo setfacl -R -nm g:adm:rx,d:g:adm:rx /var/log/journal
<xnox> ?
<mvo> mwhudson: did anything in the go snap changed around 2019-04-03?
<seb128> willcooke, ^ in case you didn't follow, snapd logging works, journal just regressed and the default user doesn't have the permission to read it without using sudo (workaround, 'sudo journalctl -u snapd' if you need some log)
<mvo> ddstreet: I ran autopkgtest a couple of times on my machine for cosmic no luck to reproduce the issue so far. trying with -smp 1 now just to see if that makes a difference
<mwhudson> mvo: there was a point release around then i think?
<mvo> ddstreet: also on our side nothing should change, snapd bundles all go deps so it must be some package or other change, I wish there was a way to query what packages changed
<mwhudson> mvo: ah no that was more recent, there were updates on 2019-03-14 and 2019-04-08
<mvo> mwhudson: its probably just coincidence, I'm just looking at some autopkgtest issue and it seems to have started around this time (and we use go snap during adt to build spread - but probably unreleated, sorry, I'm stabing a bit in the dark right now)
<mvo> mwhudson: cool, thank you
 * mvo rules that out then
<Chipaca> xnox: yes
<Chipaca> xnox: seb128: https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1824342
<mup> Bug #1824342: in 19.04, default user cannot access system journal <systemd (Ubuntu):New> <https://launchpad.net/bugs/1824342>
<Chipaca> hth
<seb128> Chipaca, thx!
<xnox> Chipaca, seb128 - this smells like a regression in systemd-tmpfiles utility implementation... bisecting.
<Chipaca> popey: willcooke: figured out #1824188
<mup> Bug #1824188: Software tab is empty on clean 19.04 install <amd64> <apport-bug> <disco> <rls-dd-incoming> <gnome-initial-setup (Ubuntu):Confirmed> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1824188>
<Chipaca> interesting how 19.04 lets you log in before seed.loaded is done
<Chipaca> mvo: is that expected?
<seb128> it's a bit unfortunate that snapd is not ready by the time the graphical session starts
<Chipaca> seb128: well, the service that waits for seeded does have a WantedBy=multi-user.target
<Chipaca> seb128: so it shouldn't
<Chipaca> ah but it doesn't have an Before/After thing?
<Chipaca> mvo: WDYT of having snapd.seeded.service have Before=multi-user.target ? (it alreayd has WantedBy=)
<Chipaca> seb128: that would slow down first boot considerably, though, which i'm sure would make xnox happy
<xnox> Chipaca, allowing login is unrelated to reaching multi-user.target.
<willcooke> seb128, could we have g-i-s wait until snapd is done seeding?
<Chipaca> xnox: oh? oh.
<xnox> there was a separate job that removes the nologin flag
<seb128> willcooke, and have your desktop sitting there doing nothing for like 3 min or slow systems?
<xnox> it's quite early, in like either logind or getty starts
<seb128> willcooke, I would prefer not
<willcooke> seb128, well, the desktop could be up and working, just that g-i-s doesn't start right away;
<seb128> Chipaca, did snapd change/is that a core18/seeding change side effect?
<willcooke> s/;/?
<cachio> mvo: hey I need to take my son to the doctor, I'll try to be back for standup
<Chipaca> seb128: no
<Chipaca> seb128: sorry, no to the first one
<seb128> we only started having those "things are not ready under seeding is done which takes a while" this cycle it looks like :/
<Chipaca> seb128: to the second one, maybe? as i say, it's racy, so maybe before you were always not hitting the restart
<Chipaca> seb128: snapd has always restarted, on ubuntu, after first install of core
<seb128> willcooke, I think it's still suck as an user experience, boot the system, have it clean, start some apps, start working and then the welcome thing pops up
<willcooke> yeah
<Chipaca> two things
<Chipaca> 1. retrying would be fine, nothing wrong with it
<Chipaca> 2. i don't know what changes with the "these things are installed", but the things _aren't installed_ unless seeding is done, so that logic is bogus
<seb128> yes, still depends of how long it takes
<seb128> I think the issue is mainly that it takes that long to snapd to be "ready"
<seb128> any way we work around that from the desktop will be suboptimal
<seb128> either we need to delay the welcome screen
<Chipaca> it's always going to take non-zero time to seed
<seb128> or have it to display spinner for $minutes on the software page
<Chipaca> so the race will always be there if you don't handle it
<seb128> yes
<seb128> but seconds it's fine
<seb128> desktop takes like 10 seconds+ to load
<seb128> you probably have 30 seconds before an user hit that wizard page
<Chipaca> well, that's part of the problem
<Chipaca> it does not hit the query when it hits that wizard page
<Chipaca> it hits it at the beginning
<seb128> that we can easily change
<Chipaca> seb128: if you wait on first page of the wizard until seeding is done (watch it in a terminal), the last page is still blank (with the error in syslog)
<Chipaca> seb128: could you 'busy' the next button on the before-last page of the wizard?
<seb128> Chipaca, that we should fix yes
<Chipaca> until snapd is sod?
<Chipaca> and then do the query
<seb128> it has been an issue for no user in bionic though
<seb128> so it's an indications things used to be ready much earlier from the snapd side
<Chipaca> i could reproduce what i've done here in bionic and tell you exactly why it's not been an issue
<seb128> it was reliably ready before the desktop load and that stopped being true
<seb128> (our code didn't change)
<Chipaca> seb128: it could be earlier _or later_
<Chipaca> to be clear the 'restart' is not the last thing that happens for seeding
<Chipaca> more like the first thing
<Chipaca> seb128: tbh, it's probably 19.04 being so amazingly fast at starting up
<Chipaca> not sure what changed but you get to log in very fast
<Chipaca> and that's awesome
<Chipaca> but it catches snapd with its pants down
<seb128> I see
<seb128> Chipaca, willcooke, let's fix g-i-s to do the query when it loads the tab (if that's doable without refactoring the code a lot, we need to check) and see if that's enough
<seb128> then we can try to do the "retry if not ready and spin"
<seb128> that should be good enough, unless it spins then for 3 minutes
<willcooke> seb128, sounds like a plan, thanks.  Shall I ask ken to look?
<seb128> willcooke, wfm, we can also ask Andy
<willcooke> seb128, oki, let's move to -desktop and work from there
<willcooke> thanks Chipaca
<seb128> Chipaca, thx
<Chipaca> seb128: in this kvm it took snapd 95 seconds from startup to seeded, and the query from g-i-s arrived at 30s
<Chipaca> so it is a full minute later
<seb128> :(
<seb128> that's a sucky user experience still :/
<seb128> willcooke, ^
<willcooke> ouch
<willcooke> perhaps if it's not ready we just have to skip that page
<willcooke> while being less than ideal, no page is better than a blank page
<seb128> willcooke, well, then we are going to skip it for most users :/
<mvo> cachio: good luck
<seb128> we maybe just need to kill it
<seb128> and do the hint on the launcher icon for gnome-software mp_t recommended
<willcooke> lets talk in -desktop
<seb128> but that's not for disco at this point
<seb128> k
<willcooke> yeah
<Chipaca> willcooke: FWIW, http://paste.ubuntu.com/p/8rpHjxBmkq/
<Chipaca> although that's more for us than for you, it might shed some light on it all
<pedronis> Chipaca:  23.382s            -  Make snap "core" (6673) available to the system , that is interesting and weird
<Chipaca> pedronis: even more
<Chipaca> Apr 11 12:03:23 ubuntu snapd[620]: taskrunner.go:426: DEBUG: Running task 7 on Do: Make snap "core" (6673) available to the system
<Chipaca> Apr 11 12:03:46 ubuntu snapd[620]: task.go:337: DEBUG: 2019-04-11T12:03:46+01:00 INFO Requested daemon restart.
<mup> PR #11: Publish coverage reports to coveralls <Created by elopio> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/11>
<Chipaca> pedronis: ^ that's the majority of that time right there
<Chipaca> pedronis: (those lines are consecutive in the logs)
 * Chipaca hugs elopio 
<willcooke> thanks Chipaca
<Chipaca> willcooke: that's the output of 'sudo snap debug timings 1', which gives you the per-task times of the seed change
<willcooke> very handy, thx
<pedronis> newer snapd will show even more info
<pedronis> Chipaca: anyway sounds we need to dig there at some point, because link-snap is not supposed to a particularly slow one
<pedronis> especially for core that doesn't have services or apps
<pedronis> Chipaca: standup?
<Chipaca> omw
<pedronis> mborzecki: mvo: btw I did a PR to simplify prepare-image (not high prio):  https://github.com/snapcore/snapd/pull/6696
<mup> PR #6696: image: simplify prefer local logic  and fixes <Created by pedronis> <https://github.com/snapcore/snapd/pull/6696>
<mvo> pedronis: thanks
<mborzecki> pedronis: thx, will review
<Chipaca> mvo: the change that creates .../aux also changed the postrm rm of cache to -r
<Chipaca> mvo: but if you have a newer snapd and use an older postrm, it'll likely break like that
<Chipaca> mvo: that is a895e537c55a350af30250e5bedc1b16e0c095ab, #6034, which is in 2.38
<mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<jdstrand> kjackal: hey, did you connect the kubernetes-support interface? the snap isn't allowed to load modules itself, but kubernetes-support tells snapd to load those ip_* modules. you also need to plugs and connect firewall-control (for the nf_* modules, though that should autoload)
<jdstrand> kjackal: additional, like in journal logs for security policy violations
<kjackal> ah I probably missed that
<zyga> jdstrand: hey
<zyga> jdstrand: having fun with getline
<zyga> it's a peculiar beast
<pstolowski> Chipaca: i can reproduce the "make snap core available" taking 23s issue on disco install; interestingly it looks all fine if i start with a clean state on my 18.04 test box, does that match your observations?
<jdstrand> kjackal: yeah, when you do an unasserted install, you have to manually connect all the interfaces. once in the store we can issue a snap declaration that autoconnects them
<Chipaca> pstolowski: i have not tested starting without a seed, if that's what you mean
<jdstrand> zyga: interesting. note, this isn't a regression (the previous behavior was the same afaics), so a followup pr would be fine (unless you think otherwise)
<zyga> yes
<zyga> kernel plays ball so it's okay
<zyga> but I want to fix it anyway
 * jdstrand nods
<zyga> I may split this depending on the size
<zyga> I started by adding sc_error support for mountinfo to really know what's wrong
<zyga> parsing with scanf is only good for programming interviews and programming contents
<cachio> Chipaca: hi
<cachio> I think the issue with the resume for the .partial file is under some conditions
<cachio> I could reproduce it many times but on a clean environment it doesn't happen
<cachio> Chipaca: then, could you please take a look to this one #6694 ? thanks
<mup> PR #6694: tests: improve how snaps are cached <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6694>
<Chipaca> cachio: i need to see the conditions :-)
<cachio> mvo: is it ok if we start testing snapd on 19.04 on travis?
<mvo> cachio: yes please
<mvo> Chipaca: yeah, this was exactly the problem, old snpad is purged but fails
<pstolowski> Chipaca: removing snapd on disco, removing state, unmounting everything, reinstalling snapd and letting it seed all the snaps from /var/lib/snapd/seed works fine (no 23s slowness). it's something during install only
<pedronis> pstolowski: I did a pass over #6704 , some questions there
<mup> PR #6704: overlord/devicestate,snapstate: measurements around ensure and related tasks <Created by stolowski> <https://github.com/snapcore/snapd/pull/6704>
<pstolowski> pedronis: ty
<mup> PR snapd#6708 opened: packaging/ubuntu: enable PIE hardening flags <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<mvo> zyga, Chipaca I cherry picked 6668 into upstream/2.38 which should hopefully make travis on 2.38 happy again
<zyga> mvo: ack, thank you
<zyga> jdstrand: I decided to split the getline fix into a new branch because it still needs some work to be properly propsable
<zyga> I just pushed the changes you asked for (comments) and will merge when green
<zyga> mvo: any idea why it only sometimes failed?
<pstolowski> Chipaca, pedronis the "Make snap core..." slowness comes from regeneration of fc-cache. fc-cache-v6+fc-cache-v7 take at least 17s when i start with clean fontcache
<zyga> mvo: is it because the aux directory is only sometimes created?
<zyga> pstolowski: aaaah
<pedronis> pstolowski: ah,  so obvious but unpleasant
<Chipaca> the installer could do that before the reboot, with some care
<zyga> Chipaca: the installer might come with that cache
<zyga> pre-baked
<pstolowski> Chipaca: for me it happened before the reboot, i didn't reboot immediately though as i was investigating it
<Chipaca> pstolowski: wat
<pstolowski> Chipaca: i'd need to double check to be sure
<Chipaca> pstolowski: the snapd 'inside' isn't running before the reboot
<mvo> zyga: yes, I think its a race but again, no time to debug in detail
<pstolowski> Chipaca: ah yes you're right, i forgot i'm running the snap from the live cd
<jdstrand> zyga: thanks, I saw. sounds go to me
<pstolowski> pedronis: we could maybe run fc-cache-v6 and v7 at the same time instead of in sequence, that could win a little bit?
<zyga> pstolowski: ha, nice idea, especially in parallel
<zyga> unless fc-cache itself is multi-threaded
<pedronis> well 10s vs 20s is still a lot
<pedronis> is good we understand the problem
<pedronis> but we should probably talk with the installer people
<pedronis> what's the best path forward
<pstolowski> pedronis: shall i talk to them (i don't remember who the installer people are though)
<pstolowski> ?
<seb128> pstolowski, you want foundations' team for the installer
<pstolowski> seb128: ah, thanks!
<pstolowski> i'm going to add timings around this area anyway, might be useful to have complete picture of first boot experience
<seb128> indeed
 * cachio lunch
<zyga> mborzecki: could you have another look at https://github.com/snapcore/snapd/pull/6643
<mup> PR #6643: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <https://github.com/snapcore/snapd/pull/6643>
<zyga> not sure if it requires more changes
<pedronis> pstolowski|afk: yes, do add timings around there
<mvo> hrm, opensuse 15 is failing in travis at least in 2.38 - is that known?
<mvo> does anyone has the curl command handy to revert a snap using the api?
<mup> PR snapd#6709 opened: release: 2.38.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6709>
<cachio> mvo: sru for 2.38 is still needed?
<cachio> I see you created sru for 2.38.1
<mvo> cachio: yes please
<mvo> cachio: well, its a good question actually
<mvo> cachio: yes
<mvo> cachio: lets do 2.38 as its already in the queue
<cachio> ok
<mvo> cachio: it will only be a problem for people with low-mem arm devices that use an old 4.4 kernel before 4.4.78 - all ubuntu kernels are fine
<cachio> mvo: nice, I'll start right now
<cachio> thanks
<mvo> thank you
<cachio> mvo: http://people.canonical.com/~ubuntu-archive/proposed-migration/xenial/update_excuses.html#snapd
<cachio> tests didn't run for xenial
<mvo> cachio: aha, I see, poking
<mvo> cachio: I raised in in #ubuntu-release
<mvo> cachio: there is no golang-1.10 for powerpc it seems
<cachio> mvo: ahh
<cachio> ok
<cachio> I'm running the other validations
<cachio> thanks
<mup> PR snapd#6605 closed: cmd/libsnap,osutil: fix parsing of mountinfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6605>
<mup> PR snapd#6710 opened: tests: run spread tests on ubuntu 19.04 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6710>
<mvo> cachio: 2.38.1 is in beta now, please validate
<cachio> mvo: sure
<mup> PR snapcraft#2532 opened: catkin stage-snaps test: limit to amd64, arm64, and armhf <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2532>
 * zyga EODs
<mup> PR snapcraft#2532 closed: catkin stage-snaps test: limit to amd64, arm64, and armhf <Created by kyrofa> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2532>
<mup> PR snapcraft#2533 opened: tests: classic confinement spread tests for and maven  <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2533>
#snappy 2019-04-12
<mborzecki> morning
<mborzecki> xdg mime handling feels like a maze
<mup> PR snapd#6709 closed: release: 2.38.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6709>
<mborzecki> mvo: hi
<mborzecki> mvo: can you upload 2.38.1 source packages to the releases page?
<zyga> Good morning
<zyga> A bit sleepy today
<zyga> I stayed way too long hacking on snap confine last night
<mborzecki> zyga: hey
<mup> PR snapd#6661 closed: data/selinux, tests/main/selinux-clean: fine tune the policy, make sure that no denials are raised <SELinux> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/6661>
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> zyga: btw. tried 19.04 with my gt1030 and did not run into any problems (at least with proprietary drivers)
<mup> PR snapd#6711 opened: tests/main/selinux-lxd: make sure LXD from snaps works cleanly with enforcing SELinux <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6711>
<mup> PR snapd#6238 closed: [WIP] many: add minimal SELinux support, refactor the policy <SELinux> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6238>
<mborzecki> #6692 is super simple and needs a 2nd review
<mup> PR #6692: interfaces: cleanup internal tool lookup in system-key <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6692>
<mup> PR snapd#6707 closed: overlord: factor out mocking of device service and gadget w. prepare-device for registration tests  <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6707>
<zyga> mborzecki: curious why it didnât work for popey
<mborzecki> zyga: do you know if there was a specific snap that failed for him?
<zyga> No, I donât recall
<mborzecki> zyga: to be exact, there's 418 nvidia drivers installed on the host, my graphics-debug-tools-bboozzoo snap seems to work fine with core and core18 bases
<mborzecki> hm maybe it's godot specific
<mborzecki> zyga: fwiw godot is classic :/
<mborzecki> zyga: aand it doesn't work
<mvo> mborzecki: hey, sorry for the delay, had a meeting
<mvo> mborzecki: 2.38.1 is not really needed outside of ubuntu/debian, its only packaging changes
<zyga> mborzecki: great, so it's consistent
<zyga> mborzecki: so what did work and what did not work and what are the symptoms of not working?
<zyga> man, it's cold today
<mborzecki> zyga: confined snaps worked (core, core18), classic does not
<zyga> mborzecki: that's most curious
<zyga> mborzecki: if yo want to learn more please do, I'm going to keep pushing on bugfixes from last weeks
<zyga> mborzecki: arguably
<zyga> mborzecki: once we have the support for classic mount namespaces
<zyga> mborzecki: we could enable driver support for classic snaps as well
 * zyga is gardening email
<pstolowski> hmmmmm
<pstolowski> why do we update fc-cache twice in LinkSnap - before and after changing current symlink?
<mborzecki> pstolowski: the after part is bc you may be updating from pre-fc-cache version of core/snapd
<pstolowski> (the second is probably a no-op if fc-cache finds all the files in place)
<mborzecki> pstolowski: the before part will make sure the cache was updated before the snap is runnable
<pstolowski> mborzecki: ah, i see, the logic there is a bit subtle
 * Chipaca is having a paperwork-y kind of day
<pedronis> Chipaca: we never did but at this point we could remove the code about AnonymousDownloadURL from store, right?
<Chipaca> pedronis: we have AnonymousDownloadURL code?
<pedronis> Chipaca: we do
<Chipaca> ah, AnonDownloadURL
<kjackal> Hi snappy people, I am not able to connect to kubernetes-support https://pastebin.ubuntu.com/p/ZhdT3gPvgD/  "Multiple definitions for hat systemd_run in profile (null) exist,bailing out." is the error. ANy hints?
<zyga> kjackal: hey, looks like a bug in snapd
<zyga> kjackal: can you please report it
<kjackal> Sure, seem like I cannot do two connections in the kubernetes support interface
<zyga> can you tell me more how you got the two connections?
<kjackal> sure
<kjackal> let me push the yaml
<Chipaca> pedronis: we'd have to check that in all cases the other url is populated though
<kjackal> zyga: Here are the two flavors of the kube-support interface https://github.com/ubuntu/microk8s/blob/feature/strict-v2/snapcraft.yaml#L21
<kjackal> Â 
<kjackal> The second connect is failing:
<kjackal> >Â sudo snap connect microk8s:k8s-kubeproxy  :kubernetes-support
<kjackal> Â >Â sudo snap connect microk8s:k8s-kubelet :kubernetes-support
<kjackal> error: cannot perform the following tasks:
<kjackal> zyga: ^
<zyga> kjackal: the reason for the failure is as follows:
<zyga> kjackal: the definitions are mutually exclusive
<zyga> kjackal: the plug definitions  at the top of the snap yaml are global
<zyga> kjackal: if an app has no plugs or slots defined it gets access to *all* plugs and slots defined at the global level
<zyga> kjackal: the ctr app is one example in your yaml
<zyga> it will get access to docker-privileged, k8s-kubelet  and k8s-kubeproxy
<zyga> kjackal: snapd does not detect mutually exclusive plugs or slots from being connected
<zyga> kjackal: apparmor parser detects the conflicting permissions granted and rejects the generated apparmor profile
<zyga> kjackal: that is all
<kjackal> thank you zyga I will need some time to ingest exactly what you said, and I will get back to you
<kjackal> brb
<zyga> kjackal: I encourage you to seek clarifications for any of the items I listed at any time
<zyga> brb
<mborzecki> cachio: hi, can we update fedora & centos images?
<mborzecki> cachio: seems like there,s a bunch of pending updates that have not been applied yet
<cachio> mborzecki: hi, yes, I just reviewed that because both have been updated but seems to be an error during the process
<cachio> https://travis-ci.org/snapcore/spread-cron/builds/517200642#L2633
<cachio> I'll fix that and recreate the images
<mup> PR snapd#6712 opened: overlord/snapstate: add timings to critical task handlers and the backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/6712>
<mborzecki> cachio: ah, so it's not related to fedora/centos running tests, but rather a problem with gcp project config
<cachio> mborzecki: yes
<cachio> It failed to create the image but the build is in green
<cachio> I'll retrigger the image and poke this issue
<mborzecki> spread does not build anymore, golang.org/x/net dropped the context package
<cachio> niemeyer:  hey,  seems to be a permissons issue on gce, I wuold need this one https://paste.ubuntu.com/p/CHYvrgDnvC/
<cachio> mborzecki: we are not creating any image because a change in the permissions
<cachio> mborzecki: we need gustavo for this
<cachio> mborzecki: I am trying to workaround that untils we fix the permissons issue
<zyga> mborzecki: thank you
<mup> PR snapd#6713 opened: tests/upgrade/basic: restore SELinux context of /var/cache/fontconfig <SELinux> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6713>
<mborzecki> pstolowski: if you could ^^
<mborzecki> zyga:  do you know of other classic snaps that may want to use opengl?
<zyga> no
 * pstolowski lunch
<mup> PR snapd#6714 opened: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
 * cachio afk
<Girtablulu|Away> is it possible to set the value refresh.retain while packaging snapd and not just after it?
<zyga> mborzecki: godot uses locally embedded libGL.so
<zyga> Girtablulu|Away: no, not at present
<Girtablulu|Away> thanks for the answer
<mborzecki> zyga: duh, why would they do that?
<zyga> mborzecki: it's one of the problems with snapcraft and GL today
<zyga> we need to change that across the ecosystem to fix the problem
<zyga> ldd of godot https://www.irccloud.com/pastebin/0Y1v1Jfc/
<zyga> this is not sustainable: we cannot expect to support new hardware when everything is frozen like  that
<zyga> mborzecki: I'm thinking of several solutions, happy to discuss
<zyga> mborzecki: one of those elements is to package a new shim gl library that snapcraft will use instead of the real libraries
<zyga> the shim gl is just there to satisfy dependencies, it does not actually contain any gl system
<zyga> at runtime it would always be supplied by snapd, even for things like mesa
<zyga> the problem is that this is complex to execute
<zyga> at the same time I don't see anything that doesn't involve fixing snaps
<jdstrand> zyga (cc kjackal): I think you mispoke
<zyga> oh?
<jdstrand> zyga: the plugs at the top are only global if there are no plugs down below
<zyga> not quite, if an app has zero plugs or slots defined, it does get all globally defined plugs and slots
<zyga> I don't know if we have a way to say "I want none"
<zyga> like plugs: []
<zyga> or if snapcraft would not remove that
<zyga> "down below" I assume you mean at app level?
<jdstrand> yes
<jdstrand> also, I used the pasted snap.yaml and there were no issues
<jdstrand> https://paste.ubuntu.com/p/sRcydgPNhb/
<zyga> hmmm
<zyga> that's odd
<jdstrand> zyga, kjackal: ^
<zyga> jdstrand: offtopic: https://github.com/snapcore/snapd/pull/6714
<mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
<kjackal> yes... it is failing over here... jdstrand how do you connect the two interfaces?
<jdstrand> zyga: also, 'enable' has no plugs and it didn't get both interfaces. it got precisely 0
<zyga> hmm
 * zyga checks stuff
<jdstrand> zyga: so it is operating how I understand it, not how you described it
<zyga> that code was changed a while ago to fix a related bug
<zyga> perhaps there were some unexpected consequences or perhaps I just plain misremember how it is supposed to work
<zyga> aha, I see
<zyga> so a plug or slot defined at top level is only added to apps or hooks if it is not bound to any app or hook
<zyga> that's actually sensible and less surprising
<zyga> jdstrand: thank you for correcting me
<zyga> kjackal: jdstrand is correct, my previous explanation is invalid
<jdstrand> kjackal: https://paste.ubuntu.com/p/BpGjHgmfmj/
<zyga> jdstrand: I'm working on https://github.com/snapcore/snapd/compare/master...zyga:fix/suse-audit-4?expand=1
<zyga> jdstrand: I will add some spread tests for how this behaves before opening the PR though
<kjackal> jdstrand: then why am I getting this: https://pastebin.ubuntu.com/p/ZxTF2j4tyg/
<jdstrand> zyga: I'm going to pick daemon user today
<zyga> jdstrand: on top of that I will add packaging changes to make the snapd socket and key executables owned and only executable by the new snapd group
<zyga> pick?
<kjackal> Sorry I am very new to the strict confinement
<zyga> jdstrand: one thing that I'm worried about, with regards to the snapd group, is that we have no stable GIDs across distributions
<zyga> jdstrand: therefore it is unclear to me what should be placed in the core/snapd snaps
<jdstrand> kjackal: what is the output of 'snap version'
<zyga> jdstrand: perhaps, however ugly, that should be checked inside the snap* commands
<kjackal> jdstrand: http://paste.ubuntu.com/p/MdR8yPmzYc/ 2.38
<jdstrand> zyga: if you set daemon user aside, the concept as a whole is that snapd has a predictable mapping
<zyga> (so they remain being root-owned and root-group-owned and executable by all but perform an explicit check at runtime)
<jdstrand> zyga: let me rephrase, if you set system users aside, there is a predicatable mapping
<zyga> jdstrand: I'm not sure I follow
<jdstrand> zyga: it would take a lot to explain in irc. it is in the spec. I'll attempt to summarize. there are several types of these things. for 'shared-users' (aka 'global-ids' in the spec), the store maintains the uid/gid and username/group mappings so it is global across the ecosystem
<jdstrand> zyga: same is true for private-users (aka private-ids)
<zyga> jdstrand: perhaps I misunderstand how that answers one question: what is the GID of /usr/lib/snapd/snap-confine in the core snap
<jdstrand> zyga: let me finish summarizing
<jdstrand> zyga: with shared-users and private-users, they are prefixed with snap_
<jdstrand> zyga: so claim a uid/gid range that is high and create the users/groups everywhere predictably
<zyga> jdstrand: hmmm
<zyga> jdstrand: I see
<zyga> initially I was assuming that the "snapd" GID would be < 1000
<jdstrand> zyga: for 'system-users' (aka system-global-ids) there is no snap_ prefix, so we can't guarantee that the username, group isn't taken
<zyga> so a typical system gid value
<zyga> jdstrand: so the new group would be snap_snapd?
<zyga> with some high value?
<jdstrand> so we would create these users on the fly if they don't exist, just like traditional packaging
<jdstrand> then snapd does a lookup and injects the gid for that system into the policy
<jdstrand> zyga: hold on
<jdstrand> zyga: oh wait, this whole time you are talking about the setgid user
<zyga> correct
<jdstrand> zyga: I thought you were questioning the daemon user
<zyga> ah, no
<jdstrand>  /o\
<zyga> sorry, maybe I was not clear about that
<jdstrand> ok, please restate your concern
<zyga> ok
 * jdstrand flushes cache
<zyga> given that the core snap is shared by all systems alike
<zyga> the same applies to snapd snap
<zyga> I was wondering what we should do about the value of GID on key executables like snap-confine and snap inside said snaps
<zyga> my starting point was that I was trying to add a typical system group that has GID < 1000
<jdstrand> kjackal: can you unsquashfs the snap you are trying to install and paste the squashfs-root/meta/snap.yaml
<zyga> but coordinating that in the ecosystem is hard
<zyga> jdstrand: perhaps there's a better way, I just started thinking about this
<jdstrand> zyga: ok right, that is likely a sisyphean task (trying to coordinate a low gid)
<ogra> jdstrand, would you mind letting https://dashboard.snapcraft.io/snaps/smart-ad-demo/revisions/1/ pass ? (it is gone into manual review, being a kiosk daemon using the x11 plug/slot combo for xwayland)
<jdstrand> zyga: I'm not even sure the line of demarcation (1000) can be depended upon everywhere
<jdstrand> ogra: sure. I think I have an idea about how to fix that in the base declaration
<ogra> lovely !
<zyga> jdstrand: perhaps the solution then is to not use the actual value
<kjackal> jdstrand: Here it is: http://paste.ubuntu.com/p/hTWhshW239/ (learning new tricks)
<jdstrand> ogra: can you create a forum topic, then I can express my idea?
<zyga> jdstrand: but instead query if the calling user is a member of the snapd group
<zyga> whatever that value is
<zyga> and then deny or allow
<ogra> jdstrand, willcooke do
<ogra> HAHA
<ogra> *will do
<willcooke> :D
 * willcooke does too
<ogra> one tab too much
<jdstrand> hehehe
 * zyga notices a joke fly past him
<jdstrand> that is probably the most humorous tab complete fail I've seen (at least in recent memory :)
<ogra> :D
<jdstrand> kjackal: that seems like a different snap.yaml from what you posted earlier
 * jdstrand will examine it
<jdstrand> zyga: yes, I think that is what you must do
<zyga> jdstrand: thank you, I think, while unfortunate, it is unavoidable
<zyga> hmm, mount-observe is not working?
<zyga> https://paste.ubuntu.com/p/fpFsX36ZCb/
<jdstrand> zyga: ie, yoy make it build time configurable what group snap-confine will verify. then the packager ensure that group exists
<zyga> jdstrand: how does that help?
<jdstrand> zyga: it actually is ok. this is how lots of stuff works like this. eg, libvirt, lxd, docker, etc on their socket
<zyga> I mean, are you aiming for names other than "snapd"
<jdstrand> zyga: something like this:
<jdstrand> ./configure --with-group=whatever
<jdstrand> then for that build it is hardcoded to use 'whatever'
<jdstrand> then the suse packager does 'addgroup whatever'
<jdstrand> then it is all fine
<zyga> right, I understand that
<zyga> I'm seeing to understand why we want that to be configurable
<zyga> I assume that "whatever" is a string, not an int
<jdstrand> zyga: yes, precisely
<jdstrand> not a string
<zyga> ooh
<zyga> hmmmm
<zyga> so how does this help with the core snap
<zyga> how will the shared snap-confine be configured?
<jdstrand> of course, that only works with the non-rexec snap-confine
<zyga> or are you saying that the shared one should not enforce this check?
<zyga> I see now
<zyga> hmm hmm
<zyga> I would rather do something that works in both cases
<jdstrand> you can
<jdstrand> --with-group=snapd
<jdstrand> but then you'd want to make it so that if the group doesn't exist, use old behavior
<zyga> indeed
<jdstrand> otherwise new. that is a little weird
<zyga> also sometimes snap-confine starts on the inside of a mount namespace
<zyga> so all a bit more complex
<jdstrand> suse doesn't want re-exec anyway afaik
<zyga> but yeah, I think that's workable
<jdstrand> a first step might be just to support non-rexec using --with-user
<zyga> yes, that's right, but I prefer to create features that don't impede global reexec as a _technical_ possiblity
<jdstrand> zyga: /etc always comes through though
<zyga> oh, /etc
<zyga> how I hate that we did that
<jdstrand> cause this is in /etc/group
<zyga> we should have not done that and instead forge special /etc
<jdstrand> in this case it is a good thing :)
<zyga> I think we should explore /etc being an empty tmpfs managed with mount backend
<zyga> it could ship symlinks for the 5-6 files we want
<jdstrand> well, in this case it doesn't have to be a bad thing
<zyga> (those would go to hostfs)
<zyga> yes, I agree, it's just something that I recalled now that you mentioned it
<zyga> (in context of the opencl test snap)
<jdstrand> zyga: that's not going to work for people. there is a *ton* of stuff in /etc that snaps want. not least of which system-file
<zyga> jdstrand: but the things in /etc are not consistent
<zyga> I know what you are saying but we should work towards *predictable* and managed /etc
<zyga> many things will need to alter what /etc contains
<zyga> currently this is hard
<zyga> and it is done so in a way that is not benefiting from snap-update-ns features
<jdstrand> zyga: true, but that's life. people configure host certs, nss, users, groups, etc, etc, etc, etc
<zyga> ssl certs don't work fully, it only works on ubuntu and debian AFAIK
<jdstrand> anyway. I have other things to do. we can discuss something like that over a beer sometime
<zyga> yeah :)
<zyga> I think we're in agreement
<zyga> and I think I broke gid restore somehow
 * zyga debugs
<ogra> jdstrand, for later ... https://forum.snapcraft.io/t/kiosk-apps-with-xwayland-kiosk-launch-needing-an-x11-slot-that-makes-them-go-into-manual-review/10892
<kjackal> jdstrand: I see you are using a test-k8s, is there a repository for this? Is it a fork of microk8s?
<jdstrand> kjackal: I just took the yaml you pasted and changed the name and the 'command' lines
<jdstrand> it isn't a thing
<jdstrand> I'm now looking at your unsquashed one
<kjackal> thanks
<jdstrand> ogra: I did smart-ad-demo
<ogra> thx !
<jdstrand> kjackal: I can't reproduce
<jdstrand> kjackal: did you snap try or use a different snapd or anything else that might be relevant?
<jdstrand> kjackal: can you perhaps try to install and connect everything in a clean vm?
<kjackal> I am doing a snapcraft cleanbuild on the branch I pasted above and then snap install ./microk8s_latest.snap --dangerous
<jdstrand> kjackal: what does 'snap list microk8s' say?
<kjackal> jdstrand: http://paste.ubuntu.com/p/b4jKFyB2Y7/
<jdstrand> kjackal: please 'snap remove microk8s' then paste: ind /var/lib/snapd -name "*microk8s*"
<kjackal> jdstrand: I now see that the error I get is presents on any interface i am trying to connect https://pastebin.ubuntu.com/p/vVx8ZppVJX/
<jdstrand> s/ind/find/
<Chipaca> profile (null) for life
<kjackal> jdstrand: here is the find in /var/lib/snapd
<kjackal> https://pastebin.ubuntu.com/p/jTRkZYFPW2/
<mup> PR snapd#6715 opened: interfaces/builtin/desktop: fonconfig v6/v7 cache handling on Fedora <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6715>
<kjackal> https://pastebin.ubuntu.com/p/3ggcdDVFvq/
<jdstrand> kjackal: ok, good. now install and do the snap connects one by one until you see the first error, then show me that series of commands
<kjackal> jdstrand: Here it is https://pastebin.ubuntu.com/p/wgg7qsfyJq/
<jdstrand> kjackal: can you paste /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet
<andyrock> Hi! Is there a way to manually put snapd in the status that triggers https://bugs.launchpad.net/ubuntu/+source/gnome-initial-setup/+bug/1824188 ?
<mup> Bug #1824188: Software tab is empty on clean 19.04 install <amd64> <apport-bug> <disco> <rls-dd-incoming> <gnome-initial-setup (Ubuntu):Confirmed> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1824188>
<kjackal> jdstrand: here it is http://paste.ubuntu.com/p/VMVTNpm4CW/
<andyrock> otherwise debugging a fix is a mess
<jdstrand> kjackal: ok, the profile looks ok. let me try to parse that in different place. gimme a minute
<jdstrand> kjackal: this is just a standard bionic system. not in a container or anything?
<kjackal> no, that is my 18.04 laptop
<kjackal> I have a Vm on aws running if you want me to try
<jdstrand> no
<mup> PR snapcraft#2526 closed: Release changelog for 3.4 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2526>
<jdstrand> kjackal: ok, please remove microk8s, then install, then do:
<jdstrand> sudo snap connect microk8s:k8s-kubeproxy :kubernetes-support
<jdstrand> then: /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/before
<jdstrand> sudo snap connect microk8s:k8s-kubelet :kubernetes-support
<jdstrand> then:
<jdstrand> cp /var/lib/snapd/apparmor/profiles/snap.microk8s.daemon-kubelet /tmp/after
<jdstrand> kjackal: I missed the 'cp' in the 'before'
<kjackal> trying it now
<jdstrand> kjackal: fyi, I can't reproduce in my bionic vm either
<jdstrand> kjackal: once you have before and after, please paste: diff -Naur /tmp/before /tmp/after
<kjackal> Yes I understand jdstrand, no worries. I might have something wron on my system. Here is the diff: https://pastebin.ubuntu.com/p/TXpxKVm9X4/
<jdstrand> kjackal: ok, can you paste both before and after?
<kjackal> jdstrand: Here is the before: http://paste.ubuntu.com/p/qqcFm9Zxqk/
<kjackal> jdstrand: here is the after: http://paste.ubuntu.com/p/HZFTPFmxk5/
<jdstrand> ok
<jdstrand> the profile looks fine
<jdstrand> can you make the snap available to me? perhaps via wormhole?
<jdstrand> (snap install wormhole ; wormhole send /path/to/thing)
<dot-tobias> kyrofa / jdstrand : I'd like to use MySQL in a snap and found https://kyrofa.com/posts/snapping-nextcloud-mysql incredibly helpful (thanks kyrofa!) Just before I start adapting the conf files and pull all the customizations + patches in my snap: Is it still the case that snapd prevents setpriority calls, or does process-control (https://github.com/snapcore/snapd/blob/da75b241f517d11d38f620e1d71a899e36f2c037/interfaces/builtin/process_control.
<dot-tobias> go#L50) work for this?
<jdstrand> kjackal: if using wormhole, privmsg me the code
<jdstrand> dot-tobias: by default a snap may setpriority to >= 0
<jdstrand> dot-tobias: if it tries < 0, the call is denied but the application is not killed or anything
<jdstrand> dot-tobias: process-control allows for < 0
<jdstrand> kjackal: ok, downloading. it'll be ~10 minutes
<jdstrand> kjackal: while we are waiting, what is 'apt-cache policy apparmor'
<roadmr> jdstrand: so a question - if there's no explicit slot configuration, a snap will allow any autoconnection from same-publisher snaps. But if there's explicit "allow-auto-connection" configuration, then it will only allow the explicit ones and deny anything else, even from same publisher. Does this sound correct?
<jdstrand> roadmr: it depends on the interface. that is how content is setup, yes
<roadmr> jdstrand: yes, the interface in question is content
<jdstrand> roadmr: if the snap decl says anything about the constraint (in this case auto-connection), only the snap declaration is used. there is no merging or falling back to the base decl
<kjackal> jdstrand: Here is the apt apparmor policy http://paste.ubuntu.com/p/6dkCJmxNgf/
<roadmr> jdstrand: ah, got it - that explains it very clearly
<dot-tobias> jdstrand: Ok, thanks. So for me (with next-to-none knowledge about this) this means that mysql-server should work OOTB without the patch that kyrofa applies for the Nextcloud snap: https://github.com/kyrofa/mysql-server/commit/dd0e4e497794da2650536097655f4bf732b261a9 (you added the process-control ~ 1 month after kyrofa's blog post which stated that there is no suitable interface for setpriority calls â or did snapd's behavior change from
<dot-tobias>  kill to a mere denial?)
<jdstrand> roadmr: it is very easy to get the content stuff wrong. perhaps privmsg me and describe what you are trying to do?
<roadmr> jdstrand: so this snap has 10 content interface slots, we added config for 4 of them which a cross-pub snap needs; and of course per the above,it means in order to allow same-publisher snaps to auto-conn to the other 6 interfaces I'll need to add those explicitly too, even though they weren't needed before
<roadmr> jdstrand: sure! I'll hit you in a sec
<cwayne> sorry we make things so tricky :)
<jdstrand> dot-tobias: I don't have the dates at hand, but yes we changed from kill to just EPERM. whether mysql works depends on how it handles the error condition
<pedronis> mvo: cachio: this one I reviewed a while ago, it just needs some tweaks: https://github.com/snapcore/snapd/pull/6594
<mup> PR #6594: [RFC] tests: run smoke tests on (almost) pristine systems <Created by mvo5> <https://github.com/snapcore/snapd/pull/6594>
<cachio> pedronis: sure, I'll take a look, thanks
<mup> PR snapd#6716 opened: store: serialize the acquisition of device sessions <Created by pedronis> <https://github.com/snapcore/snapd/pull/6716>
<mborzecki> heh, so i could not build spread, because context was removed from my tree of golang.org/x/net :/
<jdstrand> kjackal: ok, with your snap in a vm, I am able to reproduce
<mup> PR snapd#6643 closed: tests: deny ioctl - TIOCSTI with garbage in high bits <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6643>
<kjackal> jdstrand: I will not be surprised if its something wrong I am doing
<jdstrand> I'm not convined it is you
<jdstrand> but now I can debug
<jdstrand> the hooks
<jdstrand> the hooks are getting the profiles added
<jdstrand> both of them
<jdstrand> zyga: ^
<zyga> ah
<zyga> indeed!
<zyga> the question is, why should the hooks behave differently from apps that have no plugs assigned
<jdstrand> kjackal: for now, you can workaround this be removing the hooks. this is a bug in snapd
<zyga> I would argue they should not, rigth?
<zyga> pstolowski: ^ remember the hooks and interfaces?
<jdstrand> zyga: they 100% should not imo
<zyga> jdstrand: I'll look now
<kjackal> ok, jdstrand, I will see what i can do, thanks
<zyga> I see the bug
<zyga> man
<jdstrand> zyga: hooks can plugs stuff, they need to behave like apps
<jdstrand> I think we agree
<zyga> yes
<jdstrand> fyi, this is what I saw: https://paste.ubuntu.com/p/WhJQpHjKVQ/
<jdstrand> after I connected the second one
<jdstrand> snap.microk8s.daemon-kubelet and snap.microk8s.daemon-proxy correctly only have the one systemd_run, but all the hooks have two
<pstolowski> zyga: what about them?
<zyga> pstolowski: wait a sec
<zyga> patch upcoming
<jdstrand> zyga: heh, I was gonna ask if you or someone else would work on it cause kjackal needs it, but hey, you answered that :)
<zyga> yep
<zyga> it's in my head
<jdstrand> zyga: thank you :)
<zyga> jdstrand: I was working on uid/gid restore but that's more of a maze than I wanted
<zyga> because of random places we raise/lower privs
<jdstrand> zyga: oh yes-- that is very deliberately setup
<zyga> yes
<zyga> but a bit mysterious where we drop permanently
<kjackal> jdstrand zyga: Thank you. I have to admit I kind of understand how profiles are used in the high level but I do not know how snapd manipulates them. Where should I go to learn more about the internals? Look at the snapd code?  Which snap would you consider the cleanest one?
<zyga> currently seccomp code does that
<zyga> anyway, you will surely review the patch
<zyga> kjackal: read snapd code
<zyga> kjackal: specifically interfaces/*
<zyga> kjackal: I'm happy to answer questions
<jdstrand> zyga: well, that is at the finish line :) note that my daemon user branch changes this a little
<kjackal> cool, thanks zyga
<ijohnson> hey zyga, any chance you or someone else could take another look at https://github.com/snapcore/snapd/pull/6697 ?
<mup> PR #6697: interfaces/daemon_notify: add {net,sys}_admin capabilities, update spread test <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6697>
<zyga> kjackal: the general idea is that snapd collects pieces of information in Specification objects, one for each security backend; each backend knows how to materialize a specification into a set of files that govern the sandbox
 * zyga afk for a sec, sorry
<zyga> ijohnson: queued
<jdstrand> ijohnson: fyi, that is in my queue. I have rather strong opinions on it
<ijohnson> zyga: thanks!
<jdstrand> ijohnson: but I have to dig up all the reasons why I dislike it so much
<jdstrand> zyga: fyi ^
<ijohnson> jdstrand: :-( but okay
<ijohnson> jdstrand: thanks for taking a look at it
<jdstrand> it isn't so much the PR as the feature in general
 * Chipaca looks forward to jdstrand's Sonnet 43
<jdstrand> I mean, the PR too, but the PR insofar as what systemd requires I don't like
<jdstrand> Chipaca: hehe. Sometimes I feel more Faulkner than Shakespeare
 * ijohnson returns the systemd-notify themed gift bask bought for jdstrand
<ijohnson> *basket
<jdstrand> ijohnson: :) I'm not going to get to it today, but I will get to it. I want to be able to provide a path forward which requires a bit of study and archaeology
<ijohnson> jdstrand: thanks for the due diligence
<jdstrand> kjackal: I suggest as a user, reading the forum 'doc' category for things interface related
<kjackal> thanks
<jdstrand> kjackal: eg https://forum.snapcraft.io/search?q=interfaces%20category%3A15
<jdstrand> kjackal: also, again, if you remove your hooks for now, you can proceed with your work. watch for zyga's PR and when it is committed, the fix should be in edge in the next day or so after. then you can 'snap refresh core --edge' and add back your hooks
<zyga> IRL interrupt
<zyga> looking after Lucy
<zyga> (baby)
<jdstrand> zyga: cute name :)
<Chipaca> jdstrand: it's short for Lucifer
<Chipaca> (probably)
<zyga> jdstrand: Åucja :)
<zyga> lol Chipaca
<zyga> back now, she's no longer crying :)
<zyga> back to that hook bug
<jdstrand> hehe
<mvo> pstolowski: want to join #ubuntu-desktop ? the topic of fc-cache came up
<pstolowski> mvo: sure
<mvo> Chipaca: the desktop team is asking if we can reply to queries while seeding like get the list of categories
<Chipaca> mvo: yes we can
<Chipaca> mvo: as long as they retry
<mvo> Chipaca: aha, so they try to early?
<Chipaca> mvo: the problem isn't their querying while seeding (although "list of installed snaps" when it's in the middle of installing will be racy)
<mvo> Chipaca: want to join #ubuntu-desktop as well :)
<Chipaca> sure
<mup> Bug #1823988 changed: CAP_NET_ADMIN not being provided with the recommended plugs <Snappy:Invalid> <https://launchpad.net/bugs/1823988>
<cachio> pedronis: PR updated
<zyga> kjackal: hey, would you mind reporting the bug please
<zyga> kjackal: I'm just working on the commit message and I'd love to reference a bug number
<kjackal> ok LP zyga?
<zyga> kjackal: please :-)
<zyga> on snapd
 * cachio lunch
<kyrofa> dot-tobias, I'm sorry for the delay. Indeed, as jdstrand mentions, they've changed from kill to errno. However, my understanding is that it depends on kernel features that aren't available everywhere, and the Nextcloud snap is used on a number of operating systems, so I chose not to rely on that behavior
<jdstrand> kyrofa: almost. the we do errno always. what is dependent on kernel features is logging with errno
<jdstrand> kyrofa: hi btw :)
<jdstrand> we don't kill anymore anywhere
<kyrofa> jdstrand, hey! So to clarify, the behavior should be consistent across distros, but the denial itself may not show up in the syslog?
<jdstrand> kyrofa: exactly
<kyrofa> That's good to know, I'm tired of maintaining that patch
<jdstrand> kyrofa: I didn't look at the patch. please note if they fail on errno != 0, a patch is still needed
<jdstrand> that seems pretty unusual with setpriority though
<zyga> kjackal: bug number? :)
<kyrofa> jdstrand, it just calls setpriority and then getpriority to see if the setting took. If not, it whines and moves on
<kyrofa> dot-tobias, note that it tries to use -20 as the priority
<roadmr> why is snap sign being a jerk to me :(
<roadmr> error: cannot sign assertion: cannot sign using GPG: /usr/bin/gpg --personal-digest-preferences SHA512 --default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0 --detach-sign failed: exit status 2 ("gpg: signing failed: No such file or directory\ngpg: signing failed: No such file or directory\n")
<roadmr> cat whatever.json | snap sign -k my-key-id
<Chipaca> roadmr: hmm
<Chipaca> roadmr: do you have /usr/bin/gpg?
<roadmr> $ which gpg
<roadmr> /usr/bin/gpg
<Chipaca> actually the 'gpg: signing failed' thing seems to be from gpg itself
<Chipaca> hm
<Chipaca> roadmr: do you have ~/.snap/gnupg/ ?
<kjackal> zyga: just came out of a meeting, opening the bug now
<roadmr> Chipaca: yes, there it is
<roadmr> Chipaca: funny part is - this worked like 30 minutes ago
<roadmr> a case of run it once, it works, run it again, it fails
<roadmr> ah but interestingly - that key (--default-key 0x65A81F29127BF1AC94AA1A4B735216CA804762D0) does NOT exist
<roadmr> oh I lie, there it is
<Chipaca> roadmr: you can poke into it by hand using gpg --homedir ~/.snap/gnupg
<Chipaca> roadmr: maybe it's expired or sth?
<roadmr> Chipaca: I did, I can see the key; not expired, just created it 1 hour ago
<Chipaca> roadmr: are you secretly time-traveling
<roadmr> busted :(
<Chipaca> roadmr: can you try strace'ing it?
<Chipaca> roadmr: 'snap sign' is client-side only, so just strace the snap process should give you results
<zyga> kjackal: even a small report, we can expand on it later
<roadmr> cat pi3.json | strace -o ouch snap sign -k what201904122
<kjackal> zyga: here it is https://bugs.launchpad.net/snapd/+bug/1824557
<mup> Bug #1824557: Apparmor "Multiple definitions for hat systemd_run" in kubernetes-support interface <snapd:New> <https://launchpad.net/bugs/1824557>
<zyga> thank you
<roadmr> Chipaca: http://paste.ubuntu.com/p/2nmbnJwDhW/ makes no sense to me
<zyga> kjackal, jdstrand: https://github.com/snapcore/snapd/pull/6717
<mup> PR #6717: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
<mup> PR snapd#6717 opened: snap: fix interface bindings on implicit hooks <Created by zyga> <https://github.com/snapcore/snapd/pull/6717>
<Chipaca> roadmr: is that with -f ?
<roadmr> Chipaca: nope; just ran with -f and it's stuck now haha
<Chipaca> roadmr: ah, yes it gets stuck unless you tell it not to trace select iirc
<Chipaca> roadmr: -e '!select,pselect6,_newselect,clock_gettime'
<roadmr> Chipaca: http://paste.ubuntu.com/p/dzsDWwRhw4/
<Chipaca> roadmr: i see something about pinentry telling gpg 'no such file or directory'
<roadmr> whats pinentry? :)
<Chipaca> roadmr: the thing gpg talks to to prompt you for keys
<roadmr> Chipaca: ah, let me try using --passphrase to bypass that
<roadmr> again, weird because it worked fine (tm) the first time
<roadmr> oh I can't use --passphrase when invoking snap sign :(
<Chipaca> roadmr: maybe seahorse went away?
<roadmr> whats seahorse :)
<Chipaca> roadmr: (it might be called something else now)
<Chipaca> roadmr: the gnome pinentry
<roadmr> that's the graphical key thingy, right?
<Chipaca> y
<roadmr> shouldn't, I'm SSHing into a headless box
<roadmr> let me try disabling x forwarding just in case
<roadmr> Chipaca: yay it worked with x forwarding disabled \o/
<Chipaca> roadmr: magic
<roadmr> Chipaca: sorry then, it appears it was my weird env :( mystified that it worked the first time
<roadmr> thanks so much Chipaca !
<Chipaca> roadmr: depending on how it worked the first time, maybe the remote agent broke, or maybe agent forwarding died
<Chipaca> maybe when you first connected you didn't have a remote agent and then you did
 * Chipaca is just pulling guesses out anatomically improbably places
<Chipaca> improbable*
<roadmr> all these things talking to each other can fail in intesting ways
<Chipaca> with non-obvious silent fallbacks
<pedronis> gpg could at least print the relevant file name :/
<roadmr> my thought exactly pedronis  :) having to strace to figure that out was interesting
<Chipaca> pedronis: but it wasn't a file name that failed; it's the agent saying "yes i launched pinentry" and then "nope"
<Chipaca> pedronis: lines 5713-5716 in http://paste.ubuntu.com/p/dzsDWwRhw4/
<Chipaca> (no i don't know that protocol well enough to know if that was even close to an accurate rendition of what went down)
<pedronis> Chipaca: didn't gpg print a ENOENT without the filename
<Chipaca> pedronis: it looked like it but wasn't
<Chipaca> (bad on gpg yes)
<jdstrand> kjackal: zyga's PR shows another workaround: you can define your hooks explicitly in the yaml instead of implicitly. this would also workaround the issue
<jdstrand> (according to the PR)
<zyga> jdstrand: good observation, correct!
<zyga> jdstrand: I'm reworking the PR a little, fixed the bug that pedronis showd, adding tests now
 * jdstrand nods
<zyga> pedronis: re, I pushed a fix and the updated test
<fluut> I'm trying to run a snap and I get "cannot move to directory with preserved namespaces: Permission denied" The only place that string exists, according to google, is in the code. Any ideas?
<xnox> Chipaca, was it you who asked about user sessions being allowed the other day? the unit is called systemd-user-sessions.service
<xnox> it was something about snapd
<kjackal> thanks zyga
<kjackal> thanks jdstrand
<zyga> re
<zyga> fluut: hey
<zyga> fluut: I can help, please tell me more
<zyga> fluut: start with snap version output, also if you can, run dmesg | grep DENIED and show me what it prints
<zyga> fluut: or if you can, report a bug with that information and hand me the URL, you can do that on https://bugs.launchpad.net/snapd/+filebug
 * cachio afk
<zyga> jdstrand: hey, if still around, could you please look at https://github.com/snapcore/snapd/pull/6714/files
<mup> PR #6714: cmd/snap-confine: reject crafted /tmp/snap.$SNAP_NAME <Created by zyga> <https://github.com/snapcore/snapd/pull/6714>
<zyga> it's +89,-64, mostly a test revamp but really crucial permission tweak
 * zyga EODs
<Chipaca> xnox: I didn't ask, per se, but yes it was me :-)
<Chipaca> xnox: thanks
#snappy 2019-04-13
<mup> Bug #1824607 opened: connection reset by peer <Snappy:New> <https://launchpad.net/bugs/1824607>
#snappy 2019-04-14
<sasaniak> hello, i'm trying out snap for the first time, and i installed prometheus successfully, but I have no idea how/where to configure it. can someone help me find out the configuration file please?
<sasaniak> alright then, i'll just use something else, bye
#snappy 2020-04-06
<mup> PR snapd#8429 opened: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429>
<mborzecki> morning
<mborzecki> mvo: hey
<zyga> Hey
<zyga> Please merge my last PR into master and merge master into your branches.
<mborzecki> zyga: hey
<jamesh> zyga: here's a simple one porting another job off Travis: https://github.com/snapcore/snapd/pull/8429
<mup> PR #8429: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429>
<mborzecki> zyga: which one is that? this one https://github.com/snapcore/snapd/pull/8428
<mup> PR #8428: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428>
<mborzecki> jamesh: thanks!
<jamesh> zyga: also, I'm not convinced that the use of actions/cache@v1 for the apt cache actually works
<jamesh> (the way it is written, I don't think it will ever get a cache hit)
<zyga> That one
<zyga> jamesh: I noticed
<zyga> Something is off
<zyga> Do you know what the issue is?
<mvo> hey mborzecki, good morning
<mborzecki> jamesh: quick question about gtk2, we have gtk2-common-themes snap, but one would still need the right theme engine to render those, isn't that right?
<mborzecki> jamesh: asking in the context of https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3 which looks like the snap plugs gtk2-common-themes, but when starting there's a log about missing pixbuf engine to render the adwaita-like theme with gtk2
<jamesh> zyga: ah.  you're doing the chown on /var/cache/apt after calling actions/cache, so the action does not have permission to write to that location
<zyga> Mmmmm
<zyga> So we need two chowns
<jamesh> zyga: It's not obvious that it is a good use of caching anyway: the cache key you're using doesn't specify exact revisions of packages, so each user could be testing against a different set of packages
<zyga> Or update the action to a version that fixed this and uses sudo
<zyga> We rarely rev our dependencies
<jamesh> mborzecki: gtk2-common-themes only contains theme engines.  We left the actual theme data files in gtk-common-themes, since most GTK 2 themes are distributed beside their GTK 3 counterpart these days
<zyga> So it is not a perfect set but a sufficient set
<mborzecki> jamesh: so gtk2-common-themes is effectively dead?
<jamesh> mborzecki: no.  You need theme data files plus any engines the theme uses
<jamesh> mborzecki: this is also a split between platform independent data files (gtk-common-themes), and platform dependent engines (gtk2-common-themes)
<jamesh> maybe we should have named the second package gtk2-common-engines
<jamesh> zyga: It might also be a good idea to combine some of the spread tests back into fewer jobs: it's nice not having mingled output, but we're obviously hitting Github's runner limits now
<zyga> jamesh: I will surely consider that but over weekend we also hit limits on our account in GCE
<zyga> now that we actually run spread when we push stuff
<zyga> we run out of capacity quickly
<zyga> we need to measure and count and decide
<mborzecki> jamesh: hmm so the gtk2-common-themes engines part content is connected, the snap sets GTK_PATH in meta/snap.yaml, but once the process runs GTK_PATH is set to a different path :/ looks like it's coming from desktop-launch
 * zyga breakfast
<mborzecki> jamesh: looks like GTK_PATH ends up without the location where the engines from gtk2-common-themes snap are, i added a note under https://forum.snapcraft.io/t/inkscape-snap-uses-a-windows-98-era-window-scheme/16432/3
<mvo> zyga: when you have a moment, a look/merge of https://salsa.debian.org/debian/snapd/-/merge_requests/5 would be great
<mborzecki> ehh 1080p is such a downgrade from 4k
<zyga> o/
<zyga> at my desk
<zyga> mvo: looking
<zyga> mborzecki: display change?
<pstolowski> morning
<mborzecki> zyga: yeah, had to rma the 4k one, so i'm using my old 1080p display now
<mvo> zyga: not ugent but it will bring the packaging git trees in sync again
<mborzecki> pstolowski: hey
<zyga> ta
<zyga> good morning pawel
<mborzecki> zyga: which is ironic, since it's also lg, 10+ years and not a single bad pixel
<zyga> hmm, salsa doesn't load for me, feels like none of the JS bits are getting loaded
<zyga> mvo: commits 8482? is this bundled with development history?
<zyga> (this explains why js is slow to load)
<mvo> zyga: yes, I think that's how we setup our branch
<mvo> zyga: it contains all the history
<zyga> ta
<mvo> zyga: TBH i have no idea why this style is popular, I think it's kinda useless
<zyga> maybe easier for cherry picking patches
<zyga> libzt uses separate history
<zyga> anyway
<zyga> approved
<mup> PR snapd#8430 opened: packaging: use debian/not-installed to ignore snap-preseed <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8430>
<zyga> mvo: I see you have two more extra PRs there
<zyga> but I guess they are obsolete now
<zyga> mvo: closed both, please shout at me if I was meant to land them instead
<mvo> zyga: probably fine, I forgot those
<mvo> zyga: that was when we were not directly involved I think
<zyga> aha
<zyga> looking at 8430
<zyga> do you know what's broken in our sid tests?
<zyga> mvo: can you review and land https://github.com/snapcore/snapd/pull/8428 please
<mup> PR #8428: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8428>
<zyga> it will prevent random failures on centos 7
<zyga> looking at this branch I also wonder if we should do a pass and review the timers and background services in our images
<zyga> who knows what else is randomly running
<mvo> zyga: yeah, I have a look soon, just need to finish my current task
<zyga> thanks
<mvo> zyga: is there anything like "skip-spread" in the new gh-actions world? just an idle thought
<zyga> mvo: not yet, we can certainly code it
<zyga> actions has enough logic for it
<zyga> https://github.community/t5/GitHub-Actions/Labeled-action-on-pull-request/m-p/37839#M3093 has some ideas
<zyga> we can just get the context as a json object, select the labels and skip the whole spread part if a particular one is set
<zyga> mvo: if it's not urgent I'll do it in the evening
<zyga> actually
<mvo> zyga: nice, not urgent at all
<zyga> https://stackoverflow.com/questions/59588605/how-to-check-for-a-label-in-a-github-action-condition
<zyga> is even easier
<zyga> if: contains( github.event.pull_request.labels.*.name, 'My Label')
<zyga> we could just do
<zyga> if: !contains( github.event.pull_request.labels.*.name, 'Skip Spread')
<mup> PR snapd#8428 closed: tests/session-tool: stop cron/anacron from meddling <Test Robustness> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8428>
<zyga> thanks for that mvo ^ !
<zyga> pstolowski, jamesh, mborzecki, mvo: gentle reminder to merge master into any branches you push or iterate on
<zyga> mainly to get the fail-fast: false part
<pstolowski> ack
<zyga> I will share details at the standup
<pedronis> mvo: pstolowski: hi,  I would appreciate reviews for https://github.com/snapcore/snapd/pull/8427  it's huge but is splitting files up basically, except for reorganizing things such that we can have mutiple store* test suites
<mup> PR #8427: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427>
<zyga> over weekend I noticed the ubuntu archive was failing again, I reported this to IS but they asked for more details. If this happens frequently we should cook a patch that prints the IP address of the node in case "apt-get *" fails
<pstolowski> pedronis: sure, will do
<mvo> pedronis: ok, thanks, I have a look. so this is no code change, just reorg?
<pedronis> mvo: yes
<pedronis> mvo: description and commit summary should hopefully be understandable
<mvo> ta
<mborzecki> mvo: can you take another look at https://github.com/snapcore/snapd/pull/8415 ?
<mup> PR #8415: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
<mvo> mborzecki: sure thing!
<mborzecki> mvo: thanks!
<mborzecki> hehe firefox chokes on the full diff in #8427
<mup> PR #8427: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <https://github.com/snapcore/snapd/pull/8427>
<zyga> brb
<mvo> fwiw, I updated the branch protection rules for master so that all stable gh actions need to be successful
<jamesh> The GH Actions workflow should probably also be updated to run on pushes to master and release branches.  At present, only the unit tests are being run for pushes to master
<zyga> re
<zyga> jamesh: we had something similar but I agree, we wanted not to test a push and a PR at the same time
<zyga> jamesh: but I think we should do tests on PRs for both master and release branches
<mup> PR snapd#8431 opened: github: give jobs shorter names <Created by zyga> <https://github.com/snapcore/snapd/pull/8431>
<mup> PR snapd#8427 closed: store: start splitting store.go and store_test.go into subtopic files <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8427>
<pedronis> mvo: mborzecki: thanks
<mup> PR snapd#8218 closed: [RFC] cmd/snapd, daemon/snapd: use multi call binary <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/8218>
<mup> Bug #1871058 opened: Tell how many bytes "install" will take <Snappy:New> <https://launchpad.net/bugs/1871058>
<mup> Bug #1871060 opened: Don't hide each step after it completes <Snappy:New> <https://launchpad.net/bugs/1871060>
<mup> PR snapd#8432 opened: travis.yml: disable unit tests on travis <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8432>
<pedronis> #8411 needs 2nd reviews
<mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
<zyga> jamesh: https://github.com/snapcore/snapd/pull/8429#issuecomment-609683448
<mup> PR #8429: github: port CLA check to Github Actions <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8429>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8432#pullrequestreview-388082166
<mup> PR #8432: travis.yml: disable unit tests on travis <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8432>
<mborzecki> hmm seems like ijohnson's standup notes were cut short or he didn't manage to publish the snapd branch of grub.cfg on friday
<mvo> zyga: thanks, replied
<zyga> mvo: I replied twice there, weird stuff
<zyga> I think we are leaking session from tests/main/snap-session-agent-service-control
<zyga> they break tests/main/snap-confine-undesired-mode-group
<mborzecki> pedronis: mvo: looking into adding 'recover' and 'run' modes into system actions, and actually i'm wondering a bit about run, it doesn't make sense to have run for other system than current, does it?
<pedronis> mborzecki: no, it's only for current
<pedronis> we discussed that in Frankfurt
<mborzecki> pedronis: ok, let me check the notes
<mvo> mborzecki: +1 - nly relevent for current
<mborzecki> mvo: pedronis: doesn't look like we put that down in the notes, nevertheless i take that recover applies to the current system only too
<jamesh> zyga: that seems like a good idea, especially since we can't use the job as a prereq for jobs that should run on pushes
<zyga> +1
<jamesh> zyga: the macos test should be fairly easy to move over  to GH Actions too.  At that point, the main thing the Travis job is doing is coverage
<zyga> yeah
<zyga> the test coverage provider we use has a dedicated action IIRC - we could adopt it
<jamesh> and codecov's first party action also downloads and executes a shell script...
<zyga> of course it does :)
<zyga> brb
<zyga> re
<mborzecki> zyga: hm that centos7 session-tool restore is still failing
<mborzecki> and travis is green fwiw
<zyga> mborzecki: same was as you showed me?
<mborzecki> yeah
<zyga> session that was running before the test closes during the test
<zyga> ok, I'll switch gears to that in a moment
<zyga> ta
<mborzecki> tbh making gh actions spread jobs as require feels a bit premature
<zyga> why?
<zyga> note that travis doesn't run spread anymore
<mborzecki> zyga: bc we cannot restart just one job
<zyga> I see
<zyga> I disagree but I wanted to understand
<zyga> note that we can collapse all spread runs into one big run
<zyga> and have that instea
<zyga> *instead
<mborzecki> zyga: that'd make it the same as it is now
<zyga> we've traded ability to restart half the workers for being able to get tests started faster
<zyga> (and having control over how many workers we can run)
<morphis> mvo: hey! do you guys saw issues with a not existing /run/snapd-snap.socket on configure hook execution recently? Running quite frequently into https://paste.ubuntu.com/p/qQGSQjRjM7/ with snapd 2.44.1
<morphis> to be precise, snapd isn't restart and was active all time.
<zyga> morphis: what is the status of the socket?
<zyga> I suspect it's in CI but perhaps you know
<morphis> I have a shell active so happy to debug
<zyga> please start with systemctl status snapd.socket
<morphis> zyga: socket is active and happy for >1h
<zyga> morphis: both?
<zyga>      Listen: /run/snapd.socket (Stream)
<zyga>              /run/snapd-snap.socket (Stream)
<zyga> ^ that's what I get on my box
<morphis> https://paste.ubuntu.com/p/phZ4H7SGXb/
<morphis> jepp, same here
<zyga> ok
<zyga> and is /run/snapd-snap.socket really there on disk?
<morphis> yes, touched an hour ago
<zyga> ok
<zyga> can you jump into the mount namespace of lxd
<zyga> and then check if the socket is there
<zyga> sudo nsenter -m/run/snapd/ns/lxd.mnt
<zyga> this will give you a shell in the mount namespace of lxd
<zyga> just check if the sockets are there as well
<morphis> yes, exists there too
<zyga> can you CURL to it?
<zyga> or maybe instead
<zyga> can you snapctl to it?
<morphis> ah, I think I know what happens here
<morphis> it's a race between `snap install lxd` and `snap set ..`
<morphis> something we should prevent from the charm side
<morphis> that matches with the dates the socket within the lxd ns is created and the snap got installed and the last time the error occurred in the juju output
<zyga> morphis: cool
<zyga> morphis: are you saying lxd doesn't really work after snap install lxd
<zyga> in the sense that snap set is invoked too early?
<mup> PR snapd#8433 opened: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433>
<morphis> it looks like we invoke `snap set` while performing `snap install`
<zyga> as in during?
<zyga> yeah that would not work
<morphis> jepp
<morphis> makes sense that it doesn't work
<morphis> zyga: is there a simple `snap wait-until-install lxd` thing?
<zyga> I don't think there is
<morphis> ok
<ogra> well, the configure hook runs after install
<ogra> perhaps move your stuff over to it ?
<mborzecki> morphis: hmm snap watch --last=install? could work
<morphis> mborzecki: interesting
<mborzecki> morphis: though it's still racy, since you'd expect the install to be started already to watch it
<zyga> morphis: may I ask how do you run the two operations concurrenctly?
<morphis> zyga: it's a problem in our charms I can fix on that level, was just looking for a hotfix
<zyga> I see
<zyga> ok
<zyga> mborzecki: testing a fix for what you found now
<mborzecki> zyga: cool thanks
<zyga> cachio: hey
<zyga> cachio: are you around?
<cachio> zyga, yes
<cachio> hi
<zyga> hey
<ijohnson> hey mborzecki sorry I didn't finish putting the snapd branch for grub.cfg things in the SU doc
<ijohnson> I just put it in there if you wanted to take a look, it's quite simple
<mborzecki> ijohnson: no biggie, i worked on adding the recovery/run modes to devicemgr
<mup> PR snapd#8431 closed: github: give jobs shorter names <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8431>
 * zyga breaks for a moment, 
<zyga> mborzecki: I've started reviewing 8433
<mborzecki> zyga: thanks
<ijohnson> hi pedronis did you have a chance to look at how I organized things in #8424 at all ?
<mup> PR #8424: cmd/snap-bootstrap/initramfs-mounts: cross-check partitions when mounting <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8424>
<mup> PR snapd#8434 opened: systemd: move the doc comments to the interface so their are visible <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8434>
<pedronis> pstolowski_: ^
<pedronis> ijohnson: I skimmed it, I didn't see anything unreasonable... but there's some comments about details from others
<ijohnson> pedronis: ok, sure I will continue on with it
<ijohnson> pedronis: I just didn't know if you would have opinions on having stuff in the boot package vs in the partition package of snap-bootstrap, etc.
<ijohnson> pedronis: I assume you will have opinions on the names of things and that's fine to rename later :-)
 * zyga breaks for lunch, see you soon
<mup> PR snapcraft#3013 closed: plugins: use v1 import path for all plugins <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3013>
<mup> PR snapcraft#3014 opened: meta: migrate get_build_base to Snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3014>
<ijohnson> hey ogra, is your zoom-client snap supposed to work with nvidia drivers? I tried it with 440 drivers on Sunday and it crashed on me
<mup> PR snapd#8430 closed: packaging: use debian/not-installed to ignore snap-preseed <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8430>
<mup> PR snapd#8432 closed: travis.yml: disable unit tests on travis <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8432>
<ogra> ijohnson, works gret with everything but nvidia-440
<ogra> *great even
<ogra> ijohnson, https://github.com/ogra1/zoom-snap/issues/2
<diddledan> is this an issue with the 440 drivers in general with snaps?
<ogra> due to the awful nature of the zoom binary (forcefully setting LD_LIBRARY_PATH to ./zoom (and ./zoom only) on app startup) i actually need to LD_PRELOAD the drivers ... and -440 somehow refuses to load libOpenGL.so for no apparent reason
<ogra> diddledan, there used to be one but zyga has fixed that ... i asked people to try snapd from edge but that didnt help
<ijohnson> ogra: ack I can try with 390 or 435 then instead
<ogra> -400 has a new directory structure and seemingly the linkage between the libs is differet
<ogra> err
<ogra> -440 indeed
<diddledan> aah, yeah, I see that message now on https://forum.snapcraft.io/t/nvidia-beta-drivers-completely-break-snaps/12392/15 - I must have overlooked it
<ogra> right ... but that is supposed to be fixed
<diddledan> gotcha :-)
 * diddledan goes snooping to see what the fix was
<ogra> and according to the logs users actually have the proper content in /var/lib/snapd/lib/gl ...
<ogra> so it is something with the LD_PRELOAD load order that i need to research to get t going (but for that i need a system that runs -440 ... my nvidia equipped desktop is still on 16.04 for which that driver doesnt exist)
<diddledan> I just took my nvidia card out to move it into my plex server
<diddledan> I now have reasonable transcoding on the fly for plex though, so WINNING
<ogra> but you cant use zoom-client on it !
<ogra> :D
<diddledan> I had to install the deb variant of plex though. something in the snap config is unable to do hardware transcoding
<zyga> mvo: so I guess this means you approve of my incoming valve index :D
<zyga> and on the upside - everyone can then test on their nvidia GPUs
<mvo> zyga: haha
<zyga> man, we will catch all the bugs this way
<ijohnson> the quality of nvidia support will skyrocket after this happens
<zyga> snapd: add half life alyx support
<zyga> snapd: fix level 3, achievement #42
<diddledan> I vote for leaving a few gotchas to keep the users on their toes
<zyga> snapd: fix 2nd playthrough ...
<zyga> ;-)
<mup> PR #42: rework filelock to make it less surprising wrt flock(2) semantics <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/42>
<mup> PR core20#35 opened: run-snapd-from-snap: log first snap watch better <Created by xnox> <https://github.com/snapcore/core20/pull/35>
<mup> Issue core20#36 opened: SSH login shell says the system was minimized and to run "unminimize", but should not <Created by anonymouse64> <https://github.com/snapcore/core20/issue/36>
<mup> PR pc-amd64-gadget#38 closed: grub.cfg-recovery: fix typo, filter vars when loading them <Created by anonymouse64> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/38>
<kenvandine> jdstrand: where's the trello card for the appstream-metadata inteface fixes?  I want to link it to mine card, but must be looking at the wrong board
<mup> Issue pc-amd64-gadget#41 opened: Hide the menu by default <Created by xnox> <https://github.com/snapcore/pc-amd64-gadget/issue/41>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8433#pullrequestreview-388194361
<mup> PR #8433: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433>
<zyga> mvo: I wonder if we should add some of my hosted workers to the pool
<zyga> to spread the load
<ogra> spread the spread ?
<zyga> exactly
<jdstrand> kenvandine: hey, I privmsg'd you
<zyga> jdstrand: hello :)
<zyga> jdstrand: thank you for the review from Friday
<jdstrand> sure, I need to finish and followup
<zyga> jdstrand: the tracking PR will be ready soon, there's a core20 issue still, where some packages related to dbus are missing, but it should be ready soon
<jdstrand> and hi
<jdstrand> ok
<zyga> jdstrand: not end of the story but looking like something we could look at merging soon
<zyga> jdstrand: I'll spend some more time on your feedback tomorrow, today I'm trying to wrap up that core20 problem first
<jdstrand> great! :)
 * cachio lunch
<mup> PR snapd#8435 opened: configcore,tests: fix setting watchdog options on UC18/20 <Created by pedronis> <https://github.com/snapcore/snapd/pull/8435>
<jdstrand> mvo: hey, so it sounds like you will roll another 2.44 point release for some policy updates?
<mvo> jdstrand: if it's just safe policy updates I can do that
<mvo> jdstrand: at this point I want to keep the risk minimal
<jdstrand> mvo: is later today ok?
<mvo> jdstrand: yeah
<jdstrand> ok, I'll do a couple low risk PRs then
<jdstrand> I'll target 2.44, 2.45 and master
<mvo> jdstrand: or in my morning tomorrow
<mvo> jdstrand: ok
<mvo> jdstrand: 2.44 and master is fine, 2.45 is not branched yet
<jdstrand> mvo: ah, ok, thanks
 * zyga runs an errand in the office
<roadmr> running in place, zyga? ð¤
<zyga> roadmr: mainly cleaning and that one box that's open because a cable went loose and I need to solder the power switch back on
<diddledan> just rebooted.. getting: `cannot change profile for the next exec call: No such file or directory \n  snap-update-ns failed with code 1: File exists` from running _any_ snaps
<zyga> diddledan: I think we debugged that recently
<zyga> diddledan: can you please collect your journal and pastebin it
<zyga> diddledan: to fix your machine restart apparmor.service
<zyga> diddledan: it's *not* fixed though
<zyga> popey: ^ can you recall if you reported that on launchpad?
<diddledan> is this enough journal, or more needed? https://paste.ubuntu.com/p/RBc2r4xqJY/
<mup> PR snapd#8436 opened: configcore,tests: use daemon-reexec to apply watchdog config <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
<diddledan> this is everything for this boot: https://paste.ubuntu.com/p/Jyx6gfFc3q/
<zyga> diddledan: looking
<zyga> diddledan: when you said "just rebooted", roughly what time was there for you?
<zyga> is that the start of your log?
<diddledan> I used journalctl --no-pager -b | pastebinit
<zyga> ok, so 16:32~~
<diddledan> yup
<mborzecki> /quit/quit
<zyga> so I see
<zyga> Apr 06 16:32:58 defiant lxd.activate[3329]: cannot perform operation: mount --rbind /dev /tmp/snap.rootfs_Iq23MU//dev: No such file or directory
<zyga> 16:32:58 - we use snaps already
<zyga> and then Apr 06 16:35:02 defiant audit[12031]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="snap.lxd.daemon" pid=12031 comm="apparmor_parser"
<zyga> at 16:35 we load the releated profile
<zyga> FYI: stgraber ^ (lxd runs before apparmor profiles of snapd are loaded)
<zyga> diddledan: please report a bug "services start before apparmor profiles are loaded"
<zyga> we have a race
<diddledan> ok
<zyga> include this journal if you don't mind, please highligh the two lines I mentioned above
<zyga> popey: ^ if you reported a bug this this is a dupe, if not please track the one diddledan will open
<zyga> mvo: ^ FYI
<zyga> mvo: system startup races startup of services and apparmor.service loading profiles
<zyga> mvo: observed for LXD here and for a lot of snaps (half of stuff IIRC) on popey's laptop
<zyga> FYI: ^ jdstrand
<zyga> though not a security issue, more a "it doesn't work" issue
<zyga> diddledan: can you confirm that restarting apparmor.service fixed the issue?
<diddledan> yes, restarting apprmor fixes it - I've put that info in the bug: #1871148
<mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:New> <https://launchpad.net/bugs/1871148>
<zyga> thank you
<pedronis> #8390 and #8411 need 2nd reviews
<mup> PR #8390: state: add state.CopyState() helper <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
<mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
<stgraber> zyga: oh, interesting, good that it's not something I have to fix for once ;)
<zyga> stgraber: yeah, in case someone comes along and says this is broken on their fast server, it's on ous
<zyga> *us
<diddledan> #blamepopey
 * zyga hugs popey 
<popey> sorry, been in meetings
 * popey confirmificates the bug
 * diddledan watching terminiser black inevitibility
<mup> PR core20#35 closed: run-snapd-from-snap: log first snap watch better <Created by xnox> <Closed by xnox> <https://github.com/snapcore/core20/pull/35>
<mup> PR snapd#8437 opened: tests/session-tool: collect information about services on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/8437>
<mup> PR snapd#8438 opened: tests/session-tool: stop anacron.service in prepare <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8438>
<mvo> zyga: uh, is this a new thing?
<zyga> mvo: no
<jdstrand> mvo, zyga: https://bugs.launchpad.net/snapd/+bug/1871148/comments/6
<mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148>
<zyga> jdstrand: isn't that the message that is printed from /etc/apparmor.d
<zyga> there's a separate one for /var/...
<zyga> IIRC
 * zyga checks
<jdstrand> zyga: what are you talking about?
<mvo> zyga: if it's not new I wonder why it's happening now?
<jdstrand> zyga: 'Finished loading...'?
<mvo> jdstrand: should we have an "After=apparmor" in all our snaps?
<zyga> please forgive me for being unclear, let me check and show
<jdstrand> mvo: please see my comment
<jdstrand> mvo: apparmor was already finished. something else seems to be going on
<mvo> oh, ok
<ijohnson> mvo will there be a 2.44.3 ?
<mvo> zyga: it can't be snapd rebuilding the profiles, right? we stop/disable services before we do that iirc
<ijohnson> $CUSTOMER would like https://github.com/snapcore/snapd/pull/8426 asap, but not like super asap
<mup> PR #8426: interfaces/docker-support: add overlayfs file access <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8426>
<mvo> ijohnson: yes, jdstrand needs some interface updates
<zyga> mvo: this is during system boot
<ijohnson> mvo: ack cool this is just an interface update too
<mvo> ijohnson: yeah
<ijohnson> thanks mvo!
<jdstrand> oh, that was in my list for today. thanks :)
<jdstrand> ijohnson: note, for the other policy updates, mvo asked me to target 2.44 too. can you do the same?
<ijohnson> jdstrand: mvo already milestonned 8426 to 2.44
<ijohnson> jdstrand: or did you mean to open a release/2.44 PR for 8426 ?
<jdstrand> ijohnson: the latter
 * ijohnson didn't open a 2.44 PR, but can if desired
<ijohnson> ok, I will open a 2.44 PR then
<mvo> ijohnson: if it's just a cherry pick I can do that, no need for a PR then
<ijohnson> zyga: we have to restart all github actions jobs, right? we can't just restart one ?
<zyga> correct
<ijohnson> mvo: ok I think a cherry pick should be fine it's literally 1 line change
<ijohnson> ok, thanks zyga
<mvo> ijohnson: ta, just let me know when i landed and I cherry pick (or feel free to just cherry-pick yourself)
<mvo> ijohnson: 8426?
<mvo> ijohnson: I think that is green, I can merge now
<ijohnson> mvo: oh
<ijohnson> mvo: it wasn't green there was a spread failure for nfs-support, which is unrelated
<mvo> ijohnson: yeah, I will merge anyway
<ijohnson> mvo: I just restarted them, but I suppose you could use your magic powers to merge anyways
<mvo> ijohnson: sorry, I meant "green" as in "green-enough"
<ijohnson> :-D
<zyga> diddledan: can you ls -ld /var/lib/snapd/apparmor/profiles/snap-update-ns.telegram-desktop
<mvo> ijohnson: and merged and cherry-picked, thank you!
<ijohnson> thanks mvo!
<mup> PR snapd#8426 closed: interfaces/docker-support: add overlayfs file access <Simple ð> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8426>
<diddledan> zyga: -rw-r--r-- 1 root root 53984 Apr  5 19:53 /var/lib/snapd/apparmor/profiles/snap-update-ns.telegram-desktop
<zyga> april 5 19:53
<zyga> thanks
<zyga> diddledan: do you have /var/lib/snapd mounted on external disk?
<zyga> or something of this kind
<diddledan> nopep
<zyga> k
<diddledan> it's on a fairly normal setup except 20.04.. I do have root-on-zfs as installed by ubiquity's new feature
<jdstrand> diddledan: what is the ls -l output for /var/lib/snapd/apparmor/profiles/snap.multipass.*
<jdstrand> popey: do you have root on zfs?
<zyga> diddledan: you you remember when you ran the command that restarted apparmor.service?
<popey> i do
<diddledan> https://paste.ubuntu.com/p/cJ8bxBjRjq/
<diddledan> zyga, not precisely, no
 * ijohnson remembers zyga asked us to setup tests to use zfs when 19.10 was released 
<zyga> indeed
<zyga> popey: are you using zfs on your machine that exhibited this problem?
<popey> yes
<zyga> (restarting apparmor.service)
<zyga> aha
<zyga> I feel a trend
<diddledan> rpool/ROOT/ubuntu_t60y5t/var/snap on /var/snap type zfs (rw,relatime,xattr,posixacl)
<zyga> diddledan: can  you provide your /etc/fstab
<diddledan>  /var/snap is a separate mount from the zfs
<diddledan> https://paste.ubuntu.com/p/Z7TJpV5TmT/
<jdstrand> diddledan: /var/snap is a separate thing
<jdstrand> diddledan: /var/lib/snapd is the thing
<diddledan> oops, sorry, misread
<jdstrand> diddledan: can you attach to the bug: sudo systemd-analyze plot > ./1871148.svg
<diddledan> rpool/ROOT/ubuntu_t60y5t/var/lib on /var/lib type zfs (rw,relatime,xattr,posixacl)
<zyga> jdstrand: great idea
<zyga> hmm
 * zyga also uses zfs on his 20.04 desktop but that machine sees very little use
<jdstrand> diddledan: can you also attach: sudo systemd-analyze dot snap.multipass.multipassd.service > ./1871148-multipass.dot
<diddledan> both added
<zyga> hmm
<zyga> no apparmor.service at all??
<zyga> WAT?
<jdstrand> zyga: which are you looking at?
<zyga> jdstrand: the .svg
<zyga> full system stuff
<zyga> diddledan: can you journalctl -u apparmor.service
<zyga> I wonder if it ran once or twice
<zyga> (during this boot)
<jdstrand> uh
<zyga> maybe I should boot that desktop
<jdstrand> that is real weird
<zyga> jdstrand: if you don't have ZFS I can try that
<diddledan> looks like it only ran once until I restarted it manually: https://paste.ubuntu.com/p/W8bzwDpcR3/
<jdstrand> I do not
<zyga> !!!
<zyga> diddledan: can you reboot
<zyga> diddledan: and see if it starts then
<zyga> diddledan: if no, do not start it please
<diddledan> roger. gimme a sec
<zyga> thank you
<zyga> jdstrand: I guess it didn't run and why is the whole mystery
<jdstrand> zyga: it did run
<jdstrand> Apr 06 16:32:56 defiant systemd[1]: Finished Load AppArmor profiles.
<zyga> jdstrand: yeah but it was invoked manually
<zyga> or could have been
<zyga> why is it not in the .svg file?
<jdstrand> zyga: the restarting apparmor was the manual one
<diddledan> ok. back. snaps are broken :-)
<jdstrand> zyga: the one I pointed at is from the paste in the bug that I mentioned
<jdstrand> but why isn't it in the svg file, indeed
<zyga> diddledan: ok
<zyga> please don't restart apparmor.service
<zyga> diddledan: systemctl status apparmor.service
<zyga> diddledan: I bet there's a reason it was not started
<zyga> and that's the big mystery
<jdstrand> yeah
<diddledan> https://paste.ubuntu.com/p/h69jvBV6Kd/
<zyga> huh
<zyga> jdstrand: is there some debug switch to get a list of things loaded?
<zyga> diddledan: can you edit /lib/apparmor/apparmor.systemd and add set -x up top
<zyga> and restart apparmor.service
<diddledan> that'll make everything start working, remember..
<zyga> yes but we will see that it works and the log of what happened
<zyga> if that log is useful
<zyga> then let's reboot again
<zyga> and see the early -boot log
<jdstrand> I still suspect the profiles weren't there at the time the service was start
<jdstrand> wait!!
<zyga> then we might know what to do
<jdstrand> don't reboot yet
<zyga> ok
<jdstrand> diddledan: can you update /lib/apparmor/rc.apparmor.functions to comment out:
<jdstrand>   if [ "${QUIET:-no}" = yes ] || [ "${quiet:-n}" = y ]; then
<jdstrand>           PARSER_OPTS="$PARSER_OPTS --quiet"
<jdstrand>   fi
<jdstrand> diddledan: then reboot
<diddledan> restarting apparmor with those changes BEFORE rebooting: https://paste.ubuntu.com/p/HHQsFPZpYP/
<jdstrand> diddledan: actually
 * diddledan holds
<jdstrand> diddledan: let's change that to be:
<jdstrand>   #if [ "${QUIET:-no}" = yes ] || [ "${quiet:-n}" = y ]; then
<jdstrand>   #        PARSER_OPTS="$PARSER_OPTS --quiet"
<jdstrand>   #fi
<jdstrand>   PARSER_OPTS="$PARSER_OPTS -k"
<jdstrand> that will show cache hits and misses
<zyga> mmm
<diddledan> ok. made the change. going for reboob
<zyga> jdstrand: like a good mystery novel
<zyga> the murderer is about to be revealed
<diddledan> here we go: https://paste.ubuntu.com/p/dMMdZRZBbN/
<zyga> Apr 06 18:03:26 defiant apparmor.systemd[2717]: + [ -d /var/lib/snapd/apparmor/profiles ]
<zyga> it didn't find snapd profiles
<zyga> PROFILE_DIRS is only assigned to once
<jdstrand> huh
<zyga> wow
<zyga> right/
<zyga> diddledan: can you pastebin /proc/self/mountinfo please
<zyga> maybe there's some zfs magic we didn't anticipate
<jdstrand> why isn't /var/lib/snapd/apparmor/profiles being looked at
<zyga> jdstrand: ^ because it's not there at the time
<diddledan> https://paste.ubuntu.com/p/7783bjqXNF/
<zyga> line 13 of the paste
<jdstrand> oh, yes
<jdstrand> ok, that part of the mystery is solved
<zyga> 143 31 0:53 / /var/lib rw,relatime shared:79 - zfs rpool/ROOT/ubuntu_t60y5t/var/lib rw,xattr,posixacl
<zyga> it's a separate volume
<zyga> we don't have requires mounts for
<zyga> so ... bummer
<zyga> we need to rev apparmor.service
<zyga> to have that
<jdstrand> that is probably not satisfied by local-fs
<zyga> diddledan: can you please create
<zyga> diddledan: /etc/systemd/system/apparmor.service.d
<zyga> diddledan: there create a file fixes.conf
<zyga> with contents:
<zyga> [Unit]
<zyga> RequiresMountsFor=/var/lib/snapd/apparmor/profiles
<zyga> then reboot
<zyga> that should be it
<zyga> I wonder what local fs thing is
<diddledan> ok. rebooting
<zyga> or what makes that zoo of pools
<zyga> do we know someone in foundations that works on zfs?
<zyga> I wonder why is everything in /var/* a separate pool
<zyga> and how does zfs interact with local-fs.target
<zyga> it feels like a bug that's deeper than RequiresMountsFor
<diddledan> dingdingding! we have a weiner!
<zyga> xnox: (sorry for pinging you, I just recall you as a foundations member that's very well connected), do you know who works on zfs on ubuntu?
<zyga> diddledan: cool!
<jdstrand> zyga: we definitely need foundations to advise
<zyga> jdstrand: agreed
<zyga> mvo: ^ it's a bug introduced by zfs
<zyga> popey: ^ a workaround for you is spelled out above
<jdstrand> fyi, I summarized in https://bugs.launchpad.net/snapd/+bug/1871148/comments/10
<mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148>
<zyga> super, thanks!
<jdstrand> I did not put in the workaround
<zyga> I read
<zyga> ok, I need to take the dog out
<zyga> it's been hours now
<zyga> but we should definitely ask foundations to help
<zyga> it's a RC blocker IMO
<jdstrand> RequiresMountsFor=/var/lib/snapd/apparmor/profiles is probably fine
<zyga> god knows what else is broken
<zyga> yeah, I think we should have that
<jdstrand> I can do a quick upload
<zyga> jdstrand: can you upload new apparmor package to add that?
<zyga> super ^ 2
<zyga> :D
<Saviq> zyga, jdstrand: didrocks / jibel are your zfs-on-root / zsys experts
<xnox> zyga:  we don't do zfs on ubuntu-core today, nor in cloud. the only place it's available is on ubuntu desktop => which is desktop team stuff, i.e. jibel and friends. Not foundations thing =)
<zyga> jibel: ^
<zyga> thanks guys!
<jdstrand> xnox: do you agree that RequiresMountsFor=/var/lib/snapd/apparmor/profiles is reasonable to upload?
<zyga> jibel: we may have a problem with zfs-on-root and local-fs.target
<Saviq> let's ping jibel again so he doesn't get a heart attack at all :D
<zyga> the details are in https://bugs.launchpad.net/snapd/+bug/1871148
<mup> Bug #1871148: services start before apparmor profiles are loaded <snapd:Confirmed> <https://launchpad.net/bugs/1871148>
<xnox> jdstrand:  complete context switch =) que? =)
<diddledan> should we ping jibel?
<zyga> diddledan: I did :) ^
<diddledan> :-p
<zyga> super
<zyga> I'll leave you guys to it
<diddledan> yeah I was trolly
<zyga> my dog is looking at me with those puppy eyes
<xnox> jdstrand:  you probably want rbalint
<diddledan> what idiot gave puppies puppyeyes?!
<jdstrand> xnox: so, zfs-on-root does different pools for /var such that local-fs.target is satisfied but /var/lib/snapd/apparmor/profiles does not exist at the time the service starts
<zyga> diddledan: puppy conspiracy :)
<zyga> jdstrand: I wonder if zfs mounts are done by systemd
<diddledan> it's the poopscoop industrial complex!
<zyga> I guess it must be
<zyga> because the requirement was enough to fix it
 * zyga afk
<zyga> o/
<jdstrand> xnox: ack
 * jdstrand -> ubuntu-devel
<xnox> jdstrand:  and AppArmorProfile= key doesn't synthesize such a dep already? it should?
<xnox> &> #ubuntu-devel
<Saviq> zyga: https://github.com/openzfs/zfs/tree/master/etc/systemd/system
<mup> PR snapd#8439 opened: [RFC] secboot: import secboot on ubuntu, provide dummy on !ubuntu <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8439>
<mvo> pedronis: I started looking into the tpm PR finally and the above is a first RFC to help moving it into master (cc cmatsuoka). hope this is vaguely the right direction, please let me know if you would like to see tags used differently or some totally different approach
<zyga> https://github.com/openzfs/zfs/blob/5a42ef04fd390dc96fbbf31bc9f3d05695998211/etc/systemd/system/zfs-mount.service.in#L8
<mvo> cmatsuoka: feel free to pickup/improve 8439, I have dinner now
<jdstrand> xnox: it might be able to synthesize it, but that is in the snapd units. by that time, the apparmor unit already ran and finished, ignoring the dir
<jdstrand> xnox: but, we aren't using AppArmorProfile in the units anyway (snap-confine handles it)
<cmatsuoka> mvo: ack
<pedronis> mvo: that looks painful once types enter the picture
<pedronis> but I'm probably missing something
<xnox> jdstrand:  hm, apparmor.service (or whatever it is) really should require mounts for dirs it uses, i.e /var/lib/foo/bar/baz/ which systemd will correctly resolve as to which ones are needed (i.e. /var, or /var/lib, or /varlib/foo, etc.)
<xnox> jdstrand:  and units that use ApparmorProfile should like synthese dep+after apparmor.service (whatever it is called)
<pedronis> cmatsuoka: I made some comments there
<cmatsuoka> pedronis: thanks, will check asap
<mup> PR snapd#8415 closed: cmd/snap-recovery-chooser: tweaks <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8415>
<jdstrand> xnox: ok, so it sounds like you answered my question about RequiresMountsFor=/var/lib/snapd/apparmor/profiles
 * zyga EODs and goes to set up some DNS at home
<pedronis> jdstrand: so this needs both an apparmor package fix and a snapd snap services fix?
<jdstrand> pedronis: no. snapd does not need a change. I am going to make a change to apparmor since it is the correct thing for it. it should address this issue. it sounds like jibel is going to perhaps adjust zsys in some manner
<mvo> pedronis: re 8439> it should be enough to get the current tpm PR in progress working everywhere but yes, will not scale well. I guess it all depends on how much of the secboot code will be used outside of cmd/snap-bootstrap (which is skipped entirely on !ubuntu)
<mvo> pedronis: anyway, totally happy about idea, just wanted to help unblock things
<cmatsuoka> mvo: ok, working on that. I refactored it a little bit to have CheckEncryptionAvailability() in different versions
<mup> PR pc-amd64-gadget#40 closed: gadget.yaml: reduce data partition size to 1G <Created by cmatsuoka> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/40>
<pedronis> jdstrand: don't we need this:  <xnox> jdstrand:  and units that use ApparmorProfile should like synthese dep+after apparmor.service (whatever it is called)
<mvo> cmatsuoka: sounds great
<mvo> cmatsuoka: fwiw, I'm not attached to this at all, just wanted to draft something to help us moving forward which can land in isolation to unblock the rest of the tpm work
<cmatsuoka> mvo: shall I push my version to the same PR so we can discuss it better?
<mvo> cmatsuoka: it looks also like my govendor changes are busted, sorry for that (https://travis-ci.org/github/snapcore/snapd/jobs/671744586?utm_medium=notification&utm_source=github_status) - I can look at it now unless you are already on this
<mvo> cmatsuoka: yeah, go for it!
<mvo> cmatsuoka: just push to the open PR or open a new one, like I said, no attachment to htis partical version :)
<cmatsuoka> mvo: pushed it, we can always revert it if necessary
<mvo> cmatsuoka: thanks! appreciated
<cmatsuoka> oops, I didn't read the last comment from pedronis before pushing it
<mvo> cmatsuoka: I ran "govendor remove +unused" just now
<mvo> cmatsuoka: it seems like you adressed his comment, no?
<cmatsuoka> I think it's in the same line
<cmatsuoka> I renamed the function but ok, it's not important now
<mvo> cmatsuoka: aha, I see
<ijohnson> mvo I see that google:ubuntu-core-20-64:tests/core/writablepaths failed because /etc/machine-id was not writable, do we need to port that patch to release/2.44 ?
<ijohnson> i.e. https://github.com/snapcore/snapd/pull/8422 might not have been applied to 2.44 iiuc
<mup> PR #8422: tests: skip "/etc/machine-id" in "writablepaths" test <Simple ð> <â  Critical> <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8422>
<mvo> ijohnson: in 2.44? yeah, I think there is a cherry pick missing
<ijohnson> mvo: yes
<ijohnson> I don't see that commit on 2.44
<ijohnson> and the 2.44 travis run failed on that
<mvo> ijohnson: just picked it
<mvo> ijohnson: *hopefully* that's enough
<ijohnson> cool :-)
<mvo> ijohnson: thanks for noticing!
 * ijohnson crosses fingers
<mup> PR snapd#8440 opened: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440>
<cmatsuoka> ijohnson: did you work with the microk8s snap recently?
<cmatsuoka> ijohnson: you may want to have a look at https://bugs.launchpad.net/snapd/+bug/1871189
<mup> Bug #1871189: Snapd `cannot update snap namespace` when connecting / disconnecting interfaces <snapd:New> <https://launchpad.net/bugs/1871189>
<ijohnson> cmatsuoka: yes I will add a reproducer there today, it is what was reported in #snappy-internal the other day
<cmatsuoka> ijohnson: ah ok, should I assign that to you then?
<ijohnson> sure
<cmatsuoka> thanks
<cmatsuoka> zyga: have you seen trap invalid opcode error messages in xdg-open invoked from a snap?
<mup> PR snapd#8441 opened: interfaces: add case for rootWritableOverlay + NFS <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8441>
<mup> PR snapd#8442 opened: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442>
<mup> PR snapcraft#3015 opened: [WIP] ros2 (colcon) extension preview <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3015>
<pedronis> ijohnson: I marked #8442 blocked, *util packages should really depend only on stdlib or other util packages (there might be counterexamples but we should fix them), so importing dirs into osutil is not a solution as is to your conundrum
<mup> PR #8442: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442>
<mup> PR snapd#8434 closed: systemd: move the doc comments to the interface so they are visible <Reviewed> <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8434>
<zyga> cmatsuoka: not that I recall
<mup> PR snapd#8443 opened: interfaces/many: miscellaneous policy updates xliv <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8443>
<mup> PR snapd#8444 opened: interfaces/many: miscellaneous policy updates xliv - 2.44 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8444>
<cmatsuoka> zyga: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1870861 shows some instances of that happening
<mup> Bug #1870861: chromium-browser is unable to open downloads <snapd (Ubuntu):New> <https://launchpad.net/bugs/1870861>
#snappy 2020-04-07
<mup> PR snapcraft#3014 closed: meta: migrate get_build_base to Snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3014>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey hey
<mborzecki> brb, new kernel
<mborzecki> and back
<mup> PR snapd#8413 closed: interfaces: don't use the owner modifier for files shared via document portal <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8413>
<mvo> mborzecki: welcome back!
<zyga> Hey
<zyga> Sleepy a bit
<mborzecki> zyga: hey
<mborzecki> mvo: the spread job on 19.10 didn't run here https://github.com/snapcore/snapd/pull/8443 but all the other jobs are green
<mup> PR #8443: interfaces/many: miscellaneous policy updates xliv <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8443>
<mborzecki> mvo: 2.44 port of that PR is green, so we could probably merge 8443
<jamesh> I also had a CI run pass on everything but 19.10 today: https://github.com/snapcore/snapd/pull/8356
<mup> PR #8356: cmd/snap: Implement a "snap routine file-access" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/8356>
<pedronis> mvo: hi, uc20-snap-recovery  has a failure, is searching for a 3G partition size but now we have 1G again
<mborzecki> so that 19.10 failure pops up in a number of PRs
<pedronis> mvo: also should we move those main/uc20-* tests to 20.04 ? (they are running on 19.10 atm)
<mborzecki> pedronis: do you have a log from that failure in uc20-snap-recovery?
<pedronis> mborzecki: yes, but I would expect anything to fail with it at this point
<pedronis> mborzecki: https://github.com/snapcore/snapd/pull/8435/checks?check_run_id=565884165
<mup> PR #8435: configcore,tests: fix setting watchdog options on UC18/20 <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8435>
<mvo> pedronis: I remember that there was a PR to shrink the size of the ubuntu-data partition down to 1G from claudio iirc, probably this is what is causing this failure :(
<mborzecki> pedronis: thanks, looking
<mup> PR snapd#8438 closed: tests/session-tool: stop anacron.service in prepare <Simple ð> <Created by zyga> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8438>
<mvo> pedronis: totally +1 for moving those from 19.10->20.04
<mvo> mborzecki: are you on this? that's great \o/
<pedronis> mvo: it landed
<pedronis> mborzecki: nothing deep, but I need to go have breakfast:
<pedronis> + MATCH '/dev/loop2p4 .* 3G\s* Linux filesystem'
<pedronis> + sfdisk -l /dev/loop2
<pedronis> that's what's failing afaict
 * mvo onds
 * mvo nods
<mborzecki> mvo: pedronis: isn't that because of https://github.com/snapcore/pc-amd64-gadget/commit/a0eb11c6f6945d9395a858aaf396f3f3c0c609cf#diff-3da8b5c9ab650c29257cf39fccfa8be7 ?
<mvo> mborzecki: I think so
<mvo> mborzecki: while you are in those tests, please also move them from 19.10 to 20.04 (sorry if this is redundant information, we mentioned it above already but I wanted to be explicit :)
<mborzecki> mvo: ack
<mvo> ta
<mborzecki> hmm that test should probably also check that the system-data was automatically expanded before it proceeeds to add that 110MB chunk in the next scenario
<pedronis> mborzecki: maybe two PRs ?  one to fix it and one to change/improve/move things?
<pedronis> they should also be called uc20-create-partions-* at this point
 * pedronis will not ask for a pony as well
 * mvo lols and wants a pony too
<mborzecki> :P
<pstolowski> morning
<mvo> good morning pstolowski
<pedronis> mvo: did a new pass on #8439
<mup> PR #8439: secboot: import secboot on ubuntu, provide dummy on !ubuntu <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8439>
<mup> PR snapd#8445 opened: tests/main/uc20-snap-recovery: unbreak, rename to uc20-create-partitions <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8445>
<mborzecki> mvo: pedronis: this should do it ^^
<zyga> o/
<zyga> mborzecki: can you review https://github.com/snapcore/snapd/pull/8437
<mup> PR #8437: tests/session-tool: collect information about services on startup <Created by zyga> <https://github.com/snapcore/snapd/pull/8437>
<zyga> it's just extra debug in case that service shows up again
<pedronis> mborzecki: thx, there's another couple of uc20-snap-recovery-* tests that need the renaming, ->20.04 change
<pedronis> mborzecki: maybe in the follow up?
<mborzecki> pedronis: yeah, i'll add the tweaks to check the auto grow there too
<pedronis> thank you
<pedronis> zyga: pstolowski: hi, #8390 needs a 2nd/re-review
<zyga> sure
<zyga> looking
<mup> PR #8390: state: add state.CopyState() helper <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
<pstolowski> looking
<zyga> it's interesting to look at test durations below
<zyga> some are >> 50minutes
<jamesh> https://github.com/snapcore/snapd/actions/runs/72216991 shows a run that was killed by the hard 5 hour timeout
<zyga> interesting
<mvo> thanks mborzecki !
<zyga> mvo: https://github.com/snapcore/snapd/pull/8390#pullrequestreview-388854965 is good to merge
<mup> PR #8390: state: add state.CopyState() helper <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8390>
<zyga> mvo: I think it's okay to override the test that failed due to session-tool
<pedronis> mborzecki: I made some comments in #8433
<mup> PR #8433: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8433>
<mborzecki> thanks
<mvo> zyga: thank you
<mup> PR snapd#8390 closed: state: add state.CopyState() helper <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8390>
<pedronis> #8411 needs 2nd reviews
<mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
 * zyga looks at 8411
<pedronis> zyga: are you familiar with bootstate20.go ? otherwise you probably should read it first
<zyga> yeah, I need to
<zyga> there's loads of new things in core 20 for me
<zyga> pedronis: what is modeenv?
<pedronis> zyga: boot related state and settings that are not needed before we open writable, so they can be kept there,  main stuff is really which base to use
<zyga> k
<mwhudson> mvo: hey would snapd be ok with having go 1.14 as default in focal?
<zyga> mwhudson: we test with master go
<zyga> mwhudson: so I suspect so
<mvo> mwhudson: pretty sure yes
<mvo> mwhudson: like zyga said, we do run all our unit tests on go-master already
<mvo> mwhudson: might be worthwhile to run a full spread run with 1.14 though, when do you want to change the default?
<mwhudson> zyga, mvo: thanks
<mwhudson> mvo: well about 3 weeks ago i guess
<mwhudson> mvo: before release
<mvo> mwhudson: *cough* sorry, I guess that was a dumb question
<mwhudson> i've kind of dropped the ball here really :/
<zyga> heh
<pedronis> mvo: it's there an easy way to do that, use 1.14 to build snapd in a full run?
<mup> PR snapd#8446 opened: tests/main/uc20-create-partitions-*: tweaks, renames, switch to 20.04 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8446>
<mborzecki> pedronis: mvo: arch, sid and fedora 32 tests probably run with 1.14 already
<zyga> yeah, I'm pretty sure we already test this variant for a while
<pedronis> zyga: have we lost the PR check in the github actions? spread fails on #8446 but not github
<mup> PR #8446: tests/main/uc20-create-partitions-*: tweaks, renames, switch to 20.04 <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8446>
<pedronis> sorry, I mean the PR title check
<zyga> pedronis: let me check
<zyga> pedronis: not removed but it doens't trigger, it loads TRAVIS_PULL_REQUEST for context
<zyga> pedronis: let me see if we can port that
<zyga> and what else is using TRAVIS_*
<mup> PR snapd#8447 opened: github: check pull request title <Created by zyga> <https://github.com/snapcore/snapd/pull/8447>
<zyga> pedronis: ^^
<zyga> oh boy
<zyga> almost
<zyga> maybe we should just host that as our own action
<zyga> (it's not marked as public)
<pedronis> zyga: also what permission does such an action get?
<jamesh> zyga: Note that you should have access to the event payload via the file $GITHUB_EVENT_PATH
<zyga> pedronis: it runs on the worker
<pedronis> what permissions has the worker?
<jamesh> put that through a json parser, and you can see pull request title, labels, etc
<zyga> pedronis: it gets a token from github to make API requests
<zyga> pedronis: but I don't know if it can make any write requests
<jamesh> and it can make arbitrary changes to the workspace before the rest of the job continues
<pedronis> I suppose there should be a way to control that, but if we don't want to dig
<pedronis> better not use 3rd party action on our stuff
<jamesh> and access anything left on the system by previous steps
<zyga> yeah, we can fork and host our own copy
<zyga> maybe that will actually make it work, I'm puzzled by the error
<mup> PR snapd#8447 closed: github: check pull request title <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8447>
<mup> PR snapd#8445 closed: tests/main/uc20-snap-recovery: unbreak, rename to uc20-create-partitions <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8445>
<mborzecki> yay
<mvo> mborzecki: does not cherry pick cleanly, we will need a 2.44 version as a PR :/
<mborzecki> mvo:  ok, will do
<mup> PR snapd#8437 closed: tests/session-tool: collect information about services on startup <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8437>
<jamesh> zyga: I think the release tag you picked is simply busted.  The file line 2 of https://github.com/DylanVann/check-pull-request-title/blob/v0.1.14/dist/index.js doesn't exist: it does in the v0.1.13 tag though
<zyga> yeah
<zyga> I looked at the forks
<zyga> there's a fork with better code and a status check that can be enforced
<zyga> I'll park this for now and resume in the evening, I think we need to fork it to our own org and manage it there
<jamesh> json.load(open(os.environ["GITHUB_EVENT_PATH"], "r")) might be a better option
<zyga> yeah
<jamesh> that's what github.context.payload in the action is
<mborzecki> mvo: hmm don't think we need that patch for 2.44 branch tho
<mvo> mborzecki: aha, cool
<mborzecki> mvo: running the test to make sure, but it looks like the test was never updated there in the first place
<mborzecki> (i mean updated to check gadget partitions sizes)
<mvo> mborzecki: even better, if so we can just remove the milestone
<mvo> mborzecki: might still be worthwhile to move from 19.10->20.04 in 2.44 so maybe cherrypick the other one
<mborzecki> yeah
<mvo> mborzecki: I will try to cherry-pick once 8446 landed
<mborzecki> mvo: c3019489d2 (19.10 -> 20.04) applies cleanly
<mvo> mborzecki: nice! and cherry-picked
<mup> PR snapd#8448 opened: tests/session-tool: add session-tool --dump <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8448>
 * pstolowski going to the grocery and other supplies, bb in 1h
<ijohnson> pedronis: does this make sense now? https://github.com/snapcore/snapd/pull/8442#issuecomment-610298206
<mup> PR #8442: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Test Robustness> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8442>
<ijohnson> pedronis: does this make sense now? https://github.com/snapcore/snapd/pull/8442#issuecomment-610298206
<pedronis> ijohnson: it still seems that there should be something simpler that can be done
<ijohnson> pedronis: do you mean a simpler way to mock proc/self/mountinfo all the places we need to?
<pedronis> first of all I notice that LoadMountInfo usage is a bit weird
<pedronis> it's always used with /proc/self/mountinfo except it takes a path afaict
<pedronis> for the benefit of its own tests
<ijohnson> pedronis: LoadMountInfo ends up getting used in many places outside of it's own tests
<pedronis> yes, so it's optimizing for the wrong thing
<ijohnson> pedronis: additionally, part of the issue I found with our current tests is that during the tests of other things, it will be used but on the go process's mountinfo, instead of a mocked one
<pedronis> ijohnson: so my suggestion is like this LoadMountInfo should take nothing or if that's annoying take "" to mean the default location, there should be no visible ProcSelfMountInfo afaict
<pedronis> ijohnson: MockProcSelfMountInfo(path, content string) should become just MockMountInfo(content)
<pedronis> and convince internall LoadMountInfo to use content instead of readin the file
<ijohnson> pedronis: what is most convenient for other tests, including the ones I have not yet proposed, is that all of the bits of the codebase that in effect read /proc/self/mountinfo should actually really be reading <testdir>/proc/self/mountinfo instead of the real one
<ijohnson> (for the tests only obviously)
<ijohnson> this means that LoadMountInfo needs a way to know the dirs.GlobalRootDir
<pedronis> ijohnson: see my suggestion, I don't want to even bother with files
<pedronis> unless we have a reason to
<pedronis> do we have a reason?
<ijohnson> hmm ok I can do that instead I suppose
<ijohnson> I don't think we have a reason to use files, other than it was slightly nicer to have a empty mountinfo by default when you just set RootDir to <testdir>, but now we also need to actually set an empty mountinfo too
<pedronis> ijohnson: does it affect a lot tests? the current PR looks very churny
 * pedronis needs to have lunch
<ijohnson> pedronis: there are many tests that end up triggering reads to /proc/self/mountinfo
<ijohnson> and there are also actually quite a few tests that need to mock a specific mountinfo
<zyga> hey ijohnson :)
<ijohnson> hey zyga
<zyga> we should get self-hosted workers from canonistack today so we will see much faster iteration
<ijohnson> that's great news
<pedronis> ijohnson: we are already detecting if we are in testing for snapdUnsafeIO, so maybe we can do something based on that, possibly panic if we are in tests and proc mountinfo is not mocked
<ijohnson> hmm good point I can look at that for inspiration
<pedronis> ijohnson: basically var inTesting := strings.HasSuffix(os.Args[0], ".test")
<pedronis> very blunt but simple
<pedronis> we don't have a lot of places, but we do have a couple that do things like that
 * ijohnson waits for many many tests to panic
 * zyga is puzzled by something
<ijohnson> $ go test ./... | grep PANICKED | grep -Po '[0-9]+ PANICKED' | awk '{print $1}' | paste -sd+ | bc
<ijohnson> 207
<ijohnson> hooray
<pedronis> zyga: session-tool failure here:  https://github.com/snapcore/snapd/pull/8435/checks?check_run_id=567093683 on centos ? now I need to re-run all the tests?
<mup> PR #8435: configcore,tests: fix setting watchdog options on UC18/20 <Reviewed> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8435>
<zyga> looking
<zyga> do you recall when you merged master into this?
<zyga> pedronis: technically yes but I think since nothing else failed, you can just ask mvo to merge
<pedronis> that doesn't scale a lot though
<zyga> ah, this is before the extra stop and debug patches
<mvo> merging now
<mvo> but yeah, does not really scale
<zyga> in travis we had to restart 50% of the tests, which was somewhat better
<mup> PR snapd#8435 closed: configcore,tests: fix setting watchdog options on UC18/20 <Reviewed> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8435>
<zyga> I will see if there'a programmatic way to do what we want
<zyga> maybe the GUI is missing but we can just handle that in other ways
<zyga> one thing we could do today is to just put those into separate workflows
<zyga> then we can restart each one
<zyga> in any way, point taken, I'll check
<mup> PR snapd#8443 closed: interfaces/many: miscellaneous policy updates xliv <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8443>
<mvo> zyga: thank you!
<mup> PR snapd#8444 closed: interfaces/many: miscellaneous policy updates xliv - 2.44 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8444>
<mup> PR snapd#8429 closed: github: port CLA check to Github Actions <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8429>
<ijohnson> pedronis: ok now 8442 is doing as requested
<pedronis> ijohnson: there's a bunch of place that SetRootDir where is a bit unclear if they needed at some stage, or also now.
<ijohnson> pedronis: probably leftover from prior commits, let me try to clean that up
<ijohnson> pedronis: I added squash merge since this PR is going through quite a bit of churn
<pedronis> ijohnson: it's also trying to do a quite a bit in one go, like the apparmor dirs move
<ijohnson> well since the goalpost for this PR has moved it can probably be split up now, moving apparmor can at least be split out too
<ijohnson> I wasn't able to split it up before since the apparmor dirs was causing an import loop
<pedronis> ijohnson: other question, is this related to the cross-checks ? or something else?
<ijohnson> pedronis: yes I need to mock mountinfo from the cross-checks PR
<pedronis> ok
<ijohnson> and I didn't want to add yet another instance of mocking it in that PR
<ijohnson> if this is really too much work I suppose I could it just makes me feel icky inside
<pedronis> I'm just trying to undetstand the context
<pedronis> ijohnson: I also thought we would use findmnt or something for the cross check
<pedronis> instead of doing using our own code
<ijohnson> pedronis: I mean we could, but I thought it would be better to use our own mountinfo parsing code rather than rely on parsing findmnt ?
<pedronis> ijohnson: findmnt has a json output
<pedronis> ijohnson: I'm ok using our own code if it's obvious
<ijohnson> ... but still if we already have code ?
<pedronis> my memory is that using mountinfo is not that trivial
<pedronis> but maybe I'm misremembering
<ijohnson> it's just LoadMountInfo() and then loop over looking for MountDir == the-thing-I-care-about
<ijohnson> and then the other place I need it will be to look for the efivars fs that is mounted to incorporate the suggestion from maciej and claudio in the efi vars code in boot pkg
<mup> PR snapd#8449 opened: dirs: don't depend on osutil anymore, mv apparmor vars to apparmor pkg <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8449>
<ijohnson> I broke out the apparmor stuff into this ^
<pedronis> ijohnson: there's a bug in that one, probably we don't have test that reveal it
<ijohnson> pedronis: you mean a bu in 8449 ?
<ijohnson> *bug
<pedronis> yes
<ijohnson> hmm okay, well now it's independent so we can just leave that open and deal with later when we have more time
<pedronis> it might fail in spread, I don't know
<pedronis> ijohnson: it's still shows up in the other diff? am I missing something?
<ijohnson> pedronis: do you have saved comments on the original big PR? I have broken out another PR now and rebased/rebased so it is simpler to understand the commit history
<ijohnson> pedronis: I would prefer just to close the big one and re-open at this point if you don't have saved comments there
<pedronis> no, just global comments
<pedronis> afaict
<mup> PR snapd#8450 opened: selinux: export MockIsEnforcing; systemd: use in tests <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8450>
<ijohnson> pedronis: so I'm okay to close 8442?
<pedronis> ijohnson: yes
<pstolowski> pedronis: what is your idea for hooking FilesystemOnlyApply into core16/18 firstboot and preseeding flows? core config hook run twice?
<pedronis> pstolowski: no for those we need to call it from image
<mup> PR snapd#8442 closed: tests/many: stop importing osutil from dirs, mock ProcSelfMountInfo more <Squash-merge> <Test Robustness> <â Blocked> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8442>
<pstolowski> pedronis: mind if i do this change?
<pedronis> pstolowski: no, we can chat quickly about it, I'm in another meeting atm
<pedronis> though
<pstolowski> pedronis: ok, sure, let me know when you have a moment
<mup> PR snapd#8446 closed: tests/main/uc20-create-partitions: tweaks, renames, switch to 20.04 <Simple ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8446>
<pstolowski> zyga: was this fixed https://bugs.launchpad.net/snapd/+bug/1870343 ?
<mup> Bug #1870343: Unit test failure on launchpad build <snapd:New> <https://launchpad.net/bugs/1870343>
<zyga> checking
<zyga> I don't know, I only reported it
<zyga> let me look deeper
<zyga> I doubt it was fixed
<zyga> it was a random failure but it is non the less interesting, that code is not full of timers and sleeps
<mvo> 8325 (recover mode) should be ready for a second review
<zyga> ack
<jdstrand> pedronis: hey, whenever you get a chance can you comment on: https://forum.snapcraft.io/t/support-for-daemon-dbus/8855/11 ?
<pedronis> jdstrand: yes, I'll try to get to it in the next couple of days
<jdstrand> pedronis: I'm going to add an UPDATE comment for the move away from bus-name, so please read that
<jdstrand> pedronis: thanks!
<ijohnson> mvo: what about 8010? are you going to close that one? iirc that one is blocked waiting for pedronis
<mvo> ijohnson: it's a subset of the other one, I don't mind either way
<ijohnson> ok, I reviewed 8010 but was waiting to review 8325 until 8010 was merged, if you like I can review 8325 now anyways?
<mvo> ijohnson: let's ask pedronis if we want to review 8010 first or juts do it all in one go in 8325
<ijohnson> mborzeck1: could I trouble you for a review on https://github.com/snapcore/snapd/pull/8411 ?
<mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
<ijohnson> degville: I know you worked on the hooks docs recently, have you seen this comment: https://forum.snapcraft.io/t/snap-common-looks-different-from-snap-shell/3056/5?u=ijohnson ?
<degville> ijohnson: no, I'd not seen that comment - thanks! I totally agree too. I'll try and make the hook docs a little more intuitive..
<ijohnson> thanks :-)
<mup> PR snapd#8451 opened: osutil: mock proc/self/mountinfo properly everywhere <Needs Samuele review> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8451>
<pedronis> mborzeck1: pstolowski: there's no way to make journald emit is current config right?  systemd has systemctl show ? but I don't think there is something for journald
<pedronis> #8411 still needs 2nd review (I think I said it before)
<mup> PR #8411: boot: cleanup more things, simplify code <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
<zyga> mvo: small review for https://github.com/snapcore/snapd/pull/8325#pullrequestreview-389162078
<mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<pedronis> mvo: I think closing 8010 is ok
<pstolowski> pedronis: i couldn't spot anyting in the man. only this: "By default, the configuration file in /etc/systemd/ contains commented out entries showing the defaults as a guide to the administrator."
<mup> PR snapcraft#3016 opened: cli: remove experimental config.yaml support <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3016>
<mup> PR snapd#8010 closed: snap-bootstrap: add support for "recover" mode <Needs Samuele review> <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8010>
<zyga> ijohnson: https://github.com/snapcore/snapd/pull/8451#pullrequestreview-389190974
<mup> PR #8451: osutil: mock proc/self/mountinfo properly everywhere <Needs Samuele review> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8451>
<ijohnson> zyga: did you see that the apparmor stuff is split out into a seprate PR?
<ijohnson> thanks for the review btw
<zyga> I saw the PR had prerequisites yeah
<zyga> sorry for dumping it all in one spot
<ijohnson> zyga: re adding a callback automatically invoking it, yes that seems like a useful thing to do
<zyga> I think it's okay, no need to change anything here IMO
<zyga> follow ups are +1
<zyga> I'm very happy to see this
<ijohnson> no prob, but if you also quick +1 the smaller PR's contained in the big one that would be awesome :-)
<zyga> mainly because we were going deeper into a world where everything had mocking helpers you had to know about
<ijohnson> zyga: yes the more I learned yesterday the more irritated I became that we weren't doing this
<zyga> or you would see failures in magic places
<ijohnson> yes
<zyga> the mock or panic idea is great
<ijohnson> I really like Samuele's suggestion to make it panic if not mocked
<zyga> a balance of convenience (no passing explicit state everywhere) but sound mind that you didn't miss anything
<zyga> pedronis: really nice idea!
<zyga> and we should adopt this for more mocking that is public
<ijohnson> yes
<zyga> it's just almost always wrong unless you are super careful
<zyga> but even if you are, it may break tomorrow
<zyga> so this is great
<zyga> I'll look at the prereqs now
<zyga> and taking pressure off dirs is great
<ijohnson> I've also thought about making exported Mock*() functions panic when run not in tests
<zyga> it's been such a dumpster of things
<ijohnson> dirs has gotten really big
<zyga> even if we get some duplication it's much easier to reason about it
<zyga> ijohnson: yeah, so they fail closed, not open
<zyga> +1
<pedronis> pstolowski: I reviewed #8414
<mup> PR #8414: o/configstate: core config handler for persistent journal <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
<pstolowski> pedronis: thank you, i like the marker idea
<pedronis> pstolowski: it's a bit tricky to implement atomatically, we probable need to use a rename somehow
<pedronis> heh, atomically
<pedronis> pstolowski: because the naive way we might end up we directory that we made but cannot remove
<pedronis> s/we directory/with a directory/
<zyga> pstolowski: I commented on that as well
<pstolowski> ty
<zyga> ah, wrong part
<zyga> sorry, let me revise
<zyga> commenting on the conversation page vs the diff
<pedronis> bit confused by that suggestion, we do want to remove that dir even if it's full
<pedronis> if it was created by us
<zyga> yes, I revised my comment
<pedronis> ijohnson: about adding the callback calling it, it seems interesting, that the current code is much more obvious, we would need a good name for the dirs helper and I don't have one to propose
<pedronis> s/that the/but the/
<ijohnson> pedronis sure I can just add a TODO there or something, not right now is totally fine
<pedronis> pstolowski: do you want to chat now about image and FsOnlyApply ? or tomorrow?
<pstolowski> pedronis: yes, today is fine
<pedronis> pstolowski: let's do it now then
<pstolowski> ok
<zyga> ijohnson: I think that's all of them
<ijohnson> thank you zyga !
<mborzeck1> ompf, finally done with https://github.com/CanonicalLtd/subiquity/pull/692
<mup> PR CanonicalLtd/subiquity#692: console_conf: various recover chooser tweaks <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/692>
<mborzeck1> degville: can you take a look at the wording of the user facing messages in the PR ^^
<zyga> mborzeck1: are you pythonic now? ;D
<mborzeck1> zyga: hopefully it's just temporary
<zyga> mborzeck1: I'm __sure__ it is
<zyga> mborzeck1: what's up with 1?
<zyga> network/power
<zyga> ?
<mborzecki> probably network
<degville> mborzecki: yep, of course. thanks!
<mborzecki> degville: thanks!
<the-mentor> hellow
<the-mentor> I wonder if anyone can help me with a snap issue
<the-mentor> https://forum.snapcraft.io/t/vulkan-is-broken-on-snaps-when-using-nvidia-proprietary-drivers/16378
<the-mentor> i opened this thread to try and help debug an issue with snaps and vulkan with nvidia gpus
<zyga> the-mentor: hey
<zyga> I can look tomorrow as I'm about to EOD
<zyga> I have the hardware and the means to check this
<zyga> but I suspect it may require more love to fix unless it's something trivial
<zyga> the-mentor: our nvidia support is not robust and needs changes :/
 * zyga EODs
<mvo> zyga: back now, looking at the queue now
<zyga> mvo: ta
<zyga> mvo: I'm in the office but not actively working now
<mup> PR snapd#8441 closed: interfaces: add case for rootWritableOverlay + NFS <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8441>
<ijohnson> zyga: do you know if there are maybe some spots in the queue taken up by just _branches_ that are pushed?
<ijohnson> I.e. I push a branch that I don't have an open PR for, will the tests run on that?
<zyga> ijohnson: IIRC no, only pull requests should be considered
<ijohnson> okay, cool just a bit odd some of the emails I got as the links they give you are just referencing a branch and not a PR, and the PR that was open for the branch was closed like 4-5 hours ago
<mup> PR snapd#8408 closed: snap/naming: add validator for snap security tag <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8408>
<zyga> it's going through a backlog
<zyga> tests for past commits to an open PR will be tested
<ijohnson> even if the PR is closed or merged it will keep running those?
<zyga> yes, actions is more of a "bring your own" system
<zyga> there's a way to encode the policy
<zyga> but we didn't do any yet
<zyga> there's a way to close those automatically
<zyga> we're just discovering that
<zyga> I made a remark about this in the internal channel
<zyga> ijohnson: though part of it is really the relative immaturity of the product
<ijohnson> ah I see it now
<mup> PR snapd#8433 closed: overlord/devicestate: support for recover and run modes <UC20> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8433>
<mvo> cmatsuoka: do you think you could review 8439? afaict it needs a second review
<mvo> zyga, ijohnson if it really tests all commits even if they are no longer "tip" I'm not sure we should continue using GH actions until this is fixed
<mvo> i.e. if there is no cancel feature yet
<zyga> mvo: there's a way to do that, perhaps I should integrate that ASAP
<ijohnson> iiuc zyga said there is, we just have to opt-in to it somehow
<zyga> yeah
<mvo> ijohnson, zyga ok, that sounds ok then, is it much work?
<zyga> let me check
<zyga> mvo: can you look at https://github.com/styfle/cancel-workflow-action
<zyga> it has to be someone who has repo access
<zyga> there are two things that need to be done there
<zyga> if this works we can fork that repo and run that action from snapcore/cancel-workflow-action
<zyga> so that we don't use 3rd party actions
<cmatsuoka> mvo: checking that...
<mvo> ta
<zyga> ijohnson, mvo: opened 8452
<mup> PR snapd#8452 opened: github: cancel previous builds <Created by zyga> <https://github.com/snapcore/snapd/pull/8452>
<zyga> this is also interesting: https://github.com/snapcore/snapd/actions?query=is%3Aqueued
<ijohnson> interesting you can manually cancel jobs too
<cmatsuoka> mvo: done
<zyga> ironically this has more visibility than travis before
<zyga> we see exactly what's queued and what's running
<ijohnson> yes this is much more useful imho
<zyga> as the queue drains I'd like to consider merging https://github.com/snapcore/snapd/pull/8440
<zyga> we could really ease the pain then
<mup> PR #8440: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440>
<zyga> and if cancel works that might be enough
<zyga> if this doesn't work we could go back to travis :/
<zyga> the goal was to improve
<zyga> not disrupt everything without improvement
<ijohnson> personally I think we're really close to having a much better workflow than we had on travis
<ijohnson> I think to go back to travis would be very sad now
<ijohnson> (apologies to anyone named traivs)
<zyga> it would only be better if we could re-oreder the queue
<ijohnson> that would be TOO good
<zyga> https://github.com/snapcore/snapd/actions?query=workflow%3ATests+actor%3Azyga <- stuff I'm waiting on
<zyga> that's actually cool, i didn't notice this before
<zyga> or maybe "blocked" on
<zyga> as those are queued
<ijohnson> haha I literally was looking at that view for me too
<ijohnson> there were a few jobs from like 2 weeks ago that stuck somehow so I just canceled them now
<ijohnson> seems to work good!
<zyga> I have a feeling that maybe we did jump prematurely
<zyga> but apart from the initial pain it's the better place to be
<zyga> I suspect way more innovation is going into actions than travis today
<zyga> (sorry travis, we really love what you gave the world)
<zyga> mvo: did you set the secret?
<zyga> ha
<zyga> so instead of soldering that power on switch
<zyga> I just enabled wake-on-lan
<zyga> :D
<mvo> zyga: I did
<zyga> hmm, ok,
<zyga> I'll check once the queue clear
<zyga> thanks!
<zyga> maybe a typo
<zyga> it failed with missing argument
<zyga> as if what we provided expanded to nothing
<mvo> zyga: definitely  GH_ACCESS_TOKEN there
<zyga> it could be a non-starter with a PR
<zyga> PR from a fork
<zyga> :/
<mvo> zyga: 8452 canceled the unit test it seems
<mvo> zyga: oh no
<zyga> I cancelled
<mvo> zyga: so this whole cancel thing will not work?
<zyga> not sure which PR is that
<zyga> I don't know yet
<mvo> zyga: the cancel pr
<zyga> ah, yeah, I cancelled a few things
<zyga> (my own)
<zyga> to explore what to do without wasting cycles
<mvo> zyga: pretty sure it won't work if the workflow is part of a fork
<mvo> zyga: as there won't be a token then, that's a bummer
<mup> PR snapd#8453 opened: [RFC] travis.yml: re-enable travis <Created by mvo5> <https://github.com/snapcore/snapd/pull/8453>
<mup> PR snapcraft#3016 closed: cli: remove experimental config.yaml support <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3016>
<mup> PR snapd#8452 closed: github: cancel previous builds <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/8452>
<zyga> store is wonky now
<zyga> noise][: the store is indeed wonky now
<zyga> https://www.irccloud.com/pastebin/vQoYjUDu/
<jdstrand> kenvandine: hey, I just noticed these denials in snap-store while looking at an unrelated bug: https://paste.ubuntu.com/p/vhGRmC8hyK/
<jdstrand> kenvandine: expected?
<jdstrand> kenvandine: a bit surprised it is looking at mime stuff in hostfs
<kenvandine> jdstrand:  which channel?
<cmatsuoka> zyga: is there a way to ask github to re-execute a test?
<zyga> cmatsuoka: yes
<zyga> cmatsuoka: click on checks
<zyga> cmatsuoka: then on the button on the right
<zyga> (starting from a PR page)
<jdstrand> kenvandine: it was in an unrelated bug report that just showed dmesg as an attachment. I don't have any other details
<cmatsuoka> zyga: the cancel workflow button?
<diddledan> jdstrand, kenvandine, I confirm that it is looking in those paths on my system, too.. also denied.
<diddledan> snappy-debug log: https://paste.ubuntu.com/p/h9pbYnWvs5/
<kenvandine> jdstrand, diddledan: it might be because of https://gitlab.gnome.org/Community/Ubuntu/gnome-software/-/blob/snap-store-3-36/plugins/core/gs-plugin-appstream.c#L519
<kenvandine> since the core snap has a /usr/share/applications we have to look via hostfs
<kenvandine> to find the installed desktop files
<kenvandine> i wonder if that load_desktop triggers something that tries to find the mime stuff
<diddledan> the two flatpak paths in my log are interesting, too
<kenvandine> that's related to XDG_DATA_DIRS
<kenvandine> probably
<kenvandine> flatpak modifies those
<diddledan> aah possibly because I've installed a flatpak then
<kenvandine> diddledan: yeah
<kenvandine> it'll do that
<zyga> cmatsuoka: there's a restart / cancel
<zyga> cmatsuoka: if it says cancel then it's still running
 * zyga is gone
<mup> PR snapcraft#3017 opened: pluginhandler: deterministic load depending on plugin and build-base <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3017>
<zyga> cmatsuoka: if around: https://github.com/snapcore/snapd/pull/8454
<mup> PR #8454: tests/session-tool: session ordering is non-deterministic <Created by zyga> <https://github.com/snapcore/snapd/pull/8454>
<mup> PR snapd#8454 opened: tests/session-tool: session ordering is non-deterministic <Created by zyga> <https://github.com/snapcore/snapd/pull/8454>
<zyga> session-tool is my worst thing ever
<zyga> like I want to strangle myself now
<cmatsuoka> ick
<zyga> ta
<cmatsuoka> zyga: so yeah, my PRs were stuck in a point where only the cancel button was available and it didn't do much, but I had to merge master anyway
<zyga> one thing that I find super confusin
<zyga> *confusing
<zyga> is that when you restart tests
<zyga> what happens is that you get unit tests
<zyga> but rest is still as-it-was before
<zyga> then once those run
<zyga> you get canary
<zyga> then rest
<zyga> so it's a wave
<zyga> not an immediate invalidation
<mup> PR snapcraft#3018 opened: Add prebuilt-wheel-dir to python plugin <Created by jimmylomro> <https://github.com/snapcore/snapcraft/pull/3018>
<mup> PR snapcraft#3019 opened: static: consolidate tooling setup to setup.cfg <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3019>
<mup> PR snapcraft#3020 opened: spread tests: default base for local plugin tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3020>
<stgraber> zyga: does "snap run" require a running snapd?
<stgraber> zyga: we've been trying to catch weird shutdown issues for a while now, where the system effectively gets stuck for 10min, until systemd gives up and kills everything
<stgraber> zyga: our own shutdown script has logic that should timeout after 9min so this has never made much sense
<stgraber> zyga: until I finally managed to keep a shell on a system where this is happening
<stgraber> zyga: that's what I'm seeing there: https://paste.ubuntu.com/p/jFdb9sTghF/
<stgraber> zyga: removing the snapd socket and manually starting snapd back up seems to fix the situation
<stgraber> in that the stop operation then unblocks, succeeds and systemd shuts down the system
<zyga> stgraber: tired, just one sentence - yes after some operations like kernel upgrade when system key indicates snapd needs to create new sandbox profiles
<zyga> Snap run detects this and pauses
<stgraber> probably should not do that on a stop operation though when snapd is already gone
<mup> PR snapcraft#2784 closed: [multipass] use stdio to get data in/out of Multipass <Created by Saviq> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2784>
<Saviq> ChrisTownsend: ^ FYI
<mup> PR snapcraft#3021 opened: remote-build: remove artifact sanity check <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3021>
<mup> PR snapcraft#3017 closed: pluginhandler: deterministic load depending on plugin and build-base <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3017>
#snappy 2020-04-08
<mborzecki> morning
<zyga> o/
<mborzecki> zyga: hey
<mborzecki> zyga: some trouble with the cla-check job
<zyga> uc20-snap-recovery failed
<mborzecki> zyga: where?
<zyga> but it ran on 19.10
<zyga> https://github.com/snapcore/snapd/pull/8440/checks?check_run_id=569193826
<mup> PR #8440: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440>
<mborzecki> zyga: uh, merge master
<zyga> is that even expected?
<zyga> known issue?
<mborzecki> zyga: yes, it's fixed already
<zyga> k
<zyga> how did cla check fail?
<zyga> it passed on my branch just now
<zyga> 38seconds
<zyga> meanwhile, travis is broken
<zyga> https://t.co/h3UEAleWVW?amp=1
<zyga> I think I can just go back to bed
<mborzecki> zyga: if you open a PR with a commit right on top of the master so that no merge commit is generated it will fail
<zyga> I see
<mup> PR snapd#8439 closed: secboot: import secboot on ubuntu, provide dummy on !ubuntu <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8439>
<pstolowski> morning
<mvo> good morning pstolowski
<mvo> zyga: quick question, do we have a 32bit machine in travis actions?
<zyga> mvo: travis actions?
<mvo> zyga: sorry, gh actions
<zyga> mvo: as I said yesterday I didn't add a 32bit xenial machine to github actions
<zyga> mvo: though it's a one-liner in the matrix, it slipped through the cracks in the initial PRs
<zyga> good morning :)
<zyga> last night store went belly up
<zyga> and everything running failed one way or another
<zyga> so I just called it quits and went to sleep (too late anyway)
<mborzecki> mvo: pstolowski: hey
<mup> PR snapd#8455 opened: tests/lib/cla_check: expect explicit commit range <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8455>
<mborzecki> zyga: can we skip the spread jobs?
<zyga> mborzecki: in principle yes but it's not something we coded, we should try that if: ... expression I pasted before
<zyga> one sec
<zyga> maybe add that to your PR
<mborzecki> contains(github.event.issue.labels.*.name, 'skip-spread') or somesuch?
<zyga> yes
<zyga> if: !contains ...
<mborzecki> idk tho, just copied and pasted from the docs :P
<zyga> :)
<zyga> I tried to get https://github.com/snapcore/snapd/pull/8440 green
<mup> PR #8440: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440>
<zyga> but each time something random failed
<mup> PR snapd#8456 opened: tests: add 32 bit machine to GH actions <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8456>
<zyga> some desktop service, some store bits, some reboot tests
<zyga> so tough luck
<zyga> mvo: could you please merge https://github.com/snapcore/snapd/pull/8454
<mup> PR #8454: tests/session-tool: session ordering is non-deterministic <Created by zyga> <https://github.com/snapcore/snapd/pull/8454>
<mborzecki> zyga: hm the docs are kinda meh
<mup> PR snapd#8457 opened: github: skip spread jobs when corresponding label is set <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8457>
<zyga> mborzecki: interesting, except that the status check is required
<zyga> mborzecki: perhaps instead wrap that in ${{  }}
<zyga> and have the worker essentially do nothing?
<zyga> mborzecki: ${{ .. }} is required in run blocks
<mborzecki> zyga: hm which pr?
<zyga> your pr
<mborzecki> there's 2 ;)
<zyga> 8457
<zyga> and there's a syntax error
<zyga> I would drop the first part
<zyga> as all events are pull reqeusts
<zyga> let me pull the docs
<zyga> if: contains(github.event.pull_request.labels.*.name, 'Skip spread')
<zyga> then just negate
<zyga> if: !contains(github.event.pull_request.labels.*.name, 'Skip spread')
<zyga> but as we learned, that should not go into if because then the status check wont report
<zyga> so maybe:
<zyga> run: | echo ${{ !contains(...) }}
<zyga> and see what that prints (probably true as that is just js)
<mborzecki> heh
<zyga> then wrap that into a shell
<zyga> and should be good
<mborzecki> i mean, wtf are the docs about labels?
<zyga> they are there
<zyga> hold on
<zyga> it's somewhat confusing because they are not in the action docs
<zyga> but in the bigger github docs
<zyga> the whole object model is documented
<zyga> https://developer.github.com/v3/issues/labels/
<zyga> by doing ${{ ... }} you're effectively tapping into that
<mborzecki> zyga: the pull request event is this: https://developer.github.com/v3/activity/events/types/#pullrequestevent  doesn't list the label there but it's in the example
<mborzecki> and it's an empty array
<mborzecki> however, there's actually an example in the issues event payload
<zyga> https://developer.github.com/v3/pulls/ has the labels listed
<mvo> zyga: re 8454 sure, I will merge once the spread tests finished, they are still running
<zyga> thanks
<zyga> one test already failed
<zyga> on portal info
<mvo> zyga: oh, ok. is james aware of the flakiness here?
<zyga> I don't know
<zyga> it's in spread-unstable so perhaps nobody noticed?
<zyga> jamesh: can you please check if this is expected
<mvo> aha, could be
<zyga> https://github.com/snapcore/snapd/pull/8454/checks?check_run_id=569207445#step:4:814
<mup> PR #8454: tests/session-tool: session ordering is non-deterministic <Created by zyga> <https://github.com/snapcore/snapd/pull/8454>
<zyga> fedora failed to prepare, network error
<mborzecki> zyga: idk, i think that the labels is not actually included there
<zyga> mborzecki: where specifically?
<mborzecki> zyga: is the pull_request object is the same as pull_request in https://developer.github.com/v3/activity/events/types/#pullrequestevent then the label is not htere
<mborzecki> but should be?
<mborzecki> idk
<zyga> pull request *event*
<jamesh> zyga: It isn't expected.  If you're seeing this error, then it can't map the process ID to a snap via cgroups
<zyga> refers to pull request
<zyga> that has labels
<zyga> jamesh: fun, I guess it is debug time then
<zyga> mvo: https://github.com/snapcore/snapd/pull/8456/files
<zyga> is the vendor change expected?
<mup> PR #8456: tests: add 32 bit machine to GH actions <Created by mvo5> <https://github.com/snapcore/snapd/pull/8456>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8440 is green
<mup> PR #8440: github: move spread to self-hosted workers <Created by zyga> <https://github.com/snapcore/snapd/pull/8440>
<zyga> but let's chat about that in the call
<mborzecki> zyga: don't think that check works https://github.com/snapcore/snapd/pull/8457 looks like the spread jobs are still schedule
<mup> PR #8457: github: skip spread jobs when corresponding label is set <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8457>
<mborzecki> d
<zyga> mborzecki: how do you determine that?
<zyga> mborzecki: they are required, so they are marked as expected
<zyga> mborzecki: note that normally you don't get any jobs until the previous pass is successful
<zyga> so I don't believe this is accurate as measurement
<mborzecki> ok, let's wait then
<mvo> zyga: yeah
<zyga> ah
<zyga> I see the 2nd commit now
<zyga> cool
<zyga> thanks
<mup> PR snapd#8440 closed: github: move spread to self-hosted workers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8440>
<jamesh> mborzecki: one option would be to move the if: clause down to the step level
<mborzecki> zyga: have you seen the 'cancel workflow' request to have any effect?
<mborzecki> jamesh: supposedly job level `if` is supported now https://github.blog/changelog/2019-10-01-github-actions-new-workflow-syntax-features/
<jamesh> mborzecki: it's not quite as efficient since a job would still be sent to a runner, but it would mean the job would be considered successful
<mborzecki> unless it isn't :/ idk, maybe i just need to wait
<jamesh> mborzecki: yes, but if the conditional causes the job not to run, then it isn't considered successful
<jamesh> if you want to get rid of the "Some checks havenât completed yet" message, the jobs need to at least do something
<zyga> mvo: there's a problem with the -32 bit build
<zyga> src/github.com/snapcore/snapd/vendor/github.com/chrisccoulson/go-tpm2/mu.go:267:17: constant 4294967295 overflows int
<zyga> chrisccoulson: ^ FYI
<zyga> mborzecki: IIRC cancelling works but spread doesn't cancel and the worker is killed
<mvo> zyga: I know, I updated the PR that adds 32bit works, it should have a fix
<zyga> maybe the hash is wrong?
<mvo> zyga: oh, let me double check :(
<mvo> zyga: could be that govendor confused me
<zyga> when you push again merge master please
<mvo> zyga: sorry, I'm an idiot, I updated go-tpm instead go-tpm2
 * zyga hugs mvo
<zyga> https://github.com/snapcore/snapd/pull/8403 needs a 2nd review
<mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
<zyga> it failed on store traffic: - Fetch and check assertions for snap "test-snapd-content-slot-no-content-attr" (1) (error reading assertion headers: read tcp 10.240.1.50:58298->91.189.92.20:443: use of closed network connection (Client.Timeout exceeded while reading body))
<mup> PR snapd#8458 opened: github: allow cached debian downloads to restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8458>
<zyga> jamesh: https://github.com/snapcore/snapd/pull/8458
<mup> PR #8458: github: allow cached debian downloads to restore <Created by zyga> <https://github.com/snapcore/snapd/pull/8458>
<zyga> this should fix the cache
<zyga> though I think it looks only in the scope of the PR, there's still more opportunity to cache things than we exploit
<zyga> (caches are associated with objects and are not global)
<zyga> brb
<jamesh> I suspect caches are probably scoped  to the (repo, user) pair
 * zyga monitors https://github.com/snapcore/snapd/actions?query=is%3Aqueued
<mup> PR snapd#8421 closed: tests: enable unit tests on debian-sid again <Simple ð> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8421>
<zyga> mvo: that seems to have fixed things
<zyga> oh, I spoke too soon
<zyga> mvo: src/github.com/snapcore/snapd/vendor/github.com/snapcore/secboot/utils.go:73:37: cannot call non-function he.TPMError.Code (type tpm2.ErrorCode)
<zyga> I think this commit is not good :/
<zyga> why didn't this get flagged by the unit test run?
<zyga> are we not building / testing secboot?
<zyga> ahh wait
<zyga> that's weird
<zyga> ah, snapcore/secboot is a different repository
<zyga> oh well
<zyga> (we don't seem to test anything there in CI)
<mvo> zyga: meh
<zyga> but at least the tests were quick now :)
<mvo> zyga: haha, yes. but that's slightly annoying that this fails
<mvo> zyga: one more try
<zyga> ok
<zyga> still 0 queued
<zyga> (which is good)
<zyga> mborzecki: thanks for the suggestion in https://github.com/snapcore/snapd/pull/7614
<zyga> updated
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<zyga> still 0 queued
<zyga> mvo: I also wonder if actions are more heavily used in US, making afternoon "harder"
<jamesh> I've always found CI runs faster before you Europeans wake up
<zyga> mborzecki: could you look at https://github.com/snapcore/snapd/pull/7825 and tell me if you think it's work splitting
<jamesh> I think it is more a case of two groups of users using CI at once
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> I could take the go bits that do cgroup scanning out and push separately
<zyga> jamesh: haha, yeah
<mborzecki> heh, as jamesh commented, https://github.com/snapcore/snapd/pull/8457 does appear to be stuck
<mup> PR #8457: github: skip spread jobs when corresponding label is set <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8457>
<mborzecki> the unit tests job should run though, but it hasn't yet
<mborzecki> wierd, i'll wait a little bit longer
<jamesh> could it have rejected the workflow entirely?
<mborzecki> idk, clearly something is off
<zyga> one job queued
<zyga> (all 32 spread workers are busy)
<zyga> mborzecki: werid
<zyga> mborzecki: can you rebase on master and push?
<zyga> at 32 spread runs I'm seeing roughly 1MB/s in and 1MB/s out
<zyga> that's not too terrible
<zyga> it spikes to 10MB/s
<zyga> especially when new jobs kick in and there's the initial sync
<mborzecki> zyga: where do you see that?
<zyga> spread has an inefficiency where the starting worker pushes the same tarball to each node
<zyga> mborzecki: on the machine running spread workers
<zyga> we could optimize that traffic down by just sending the tarball once and then fetching it from the cloud
<pstolowski> pedronis: hi. currently FilesystemOnlyApply skips core-only handlers if release is classic; i think this needs to be relaxed for image/setupSeed with a flag passed down to FilesystemOnlyApply; makes sense?
<pedronis> pstolowski: let me look
<pedronis> pstolowski: yes, the cleanest thing is probably for the package not use release.OnClassic at all, and get info through some options
<pstolowski> pedronis: k, thanks for confirming
<zyga> core 18 revert tests failed: https://github.com/snapcore/snapd/pull/8454/checks?check_run_id=570248002
<mup> PR #8454: tests/session-tool: session ordering is non-deterministic <Created by zyga> <https://github.com/snapcore/snapd/pull/8454>
<zyga> + snap list
<zyga> error: cannot list snaps: cannot communicate with server: timeout exceeded while waiting for response
<mup> PR snapd#8454 closed: tests/session-tool: session ordering is non-deterministic <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8454>
<popey> ogra where should bugs about ubuntu core images be filed?
<popey> actually, probably a bug in the installer, is that subiquity on core? (the first run thing)
 * popey starts a forum thread.
<zyga> mborzecki: TBH I really wish there were type annotations
<zyga> reading foreign python code is like "where are the types" :(
<zyga> mborzecki: did you try adding any annotations?
<mborzecki> zyga: not really, i've had enough fun with implementing the chooser ui
<mborzecki> zyga: anyways if you want to play with it, better talk to mwhudson first
<zyga> mborzecki: https://github.com/CanonicalLtd/subiquity/pull/692#pullrequestreview-389844549
 * zyga goes upstaris to make tea
<mup> PR CanonicalLtd/subiquity#692: console_conf: various recover chooser tweaks <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/692>
<zyga> we are running at 23/32 workers now
<zyga> we've reached saturation once for about 20 minutes
<pedronis> mvo: I made some comments in #8325, some are really general hindsight questions
<mup> PR #8325: snap-bootstrap: copy auth data from real ubuntu-data in recovery mode <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8325>
<mup> PR snapd#8458 closed: github: allow cached debian downloads to restore <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8458>
<mup> PR snapd#8448 closed: tests/session-tool: add session-tool --dump <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8448>
<zyga> thanks!
<mvo> pedronis: thanks, will look in a wee bit, looks like it is closed, I will try to get it to a landable point today :)
<ogra> popey, yeah, subiquity is correct
<ogra> popey, but the issue is indeed the clock ...
<pedronis> mvo: I don't know, there are some open questions
<zyga> mborzecki: https://github.com/CanonicalLtd/subiquity/pull/692#pullrequestreview-389870317
<mup> PR CanonicalLtd/subiquity#692: console_conf: various recover chooser tweaks <Created by bboozzoo> <https://github.com/CanonicalLtd/subiquity/pull/692>
<mborzecki> zyga: thanks!
<popey> ogra ok
<pedronis> mvo: can you merge #8449, it's all green but travis never came back or started, afaict ?
<mup> PR #8449: dirs: don't depend on osutil anymore, mv apparmor vars to apparmor pkg <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8449>
<mvo> pedronis: sure
<mup> PR snapd#8449 closed: dirs: don't depend on osutil anymore, mv apparmor vars to apparmor pkg <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8449>
<zyga> core 20 recovery design
<zyga> MAGA - make appliance good again
 * zyga hides
<zyga> we are at 3/32 workers
<zyga> though it will go back to ~20 once canary jobs are done
<ogra> MAGA ? so should we deny it exists until it hits us hard ? :)
<mborzecki> ogra: you mean another customs war?
<zyga> I started implementing snapctl refresh-available
<zyga> should have a simple version today
<zyga> but first, *hot* tea
<zyga> the office is horribly cold even today
<zyga> I need a 2nd review for https://github.com/snapcore/snapd/pull/8403
<mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
<mup> PR snapd#8459 opened: asserts: it should be possible to omit many snap-ids if allowed, fix <Created by pedronis> <https://github.com/snapcore/snapd/pull/8459>
<zyga> pedronis: ^ gofmt
<diddledan> no, you go fmt!
<mup> PR snapd#8460 opened: tests/session-tool: kill cron session, if any <Created by zyga> <https://github.com/snapcore/snapd/pull/8460>
<zyga> pedronis: ta
<pedronis> I'm seeing failures on core-16-64, that are not obviously bogus
<zyga> what kind of failures?
<zyga> I saw two kinds today:
<zyga> - reboot that went nowhere
<zyga> - snap rollback and timeout on "snap list"
<zyga> that felt really broken
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8457/checks?check_run_id=570718915 <- cache of debian deps worked!
<mup> PR #8457: github: skip spread jobs when corresponding label is set <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8457>
<pedronis> zyga: possibly, yes, reboot that went nowhere, but it seems new and real
<zyga> mborzecki: I wonder if we can set cache scope to "global" to make sure everyone benefits
<zyga> pedronis: I saw the reboot failure about twice last week as well
<zyga> but never when testing with -debug to see :/
<zyga> mborzecki: spread-canary started on your skip label PR
<zyga> mborzecki: and it works!!!
<zyga> mborzecki: cool
<zyga> mborzecki: with some extra love you could set a status label that shows it was skipped
<zyga> but the feature works :)
<mborzecki> zyga: uhh i don't like it though
<zyga> mborzecki: why?
<mborzecki> zyga: we still need to take as many workers as distros
<zyga> mborzecki: but not spread Vms
<zyga> mborzecki: that's nearly free
<zyga> mborzecki: they all passed now
<zyga> mborzecki: it adds ~30 seconds
<zyga> and it's green - except for "pending travis"
<mborzecki> hahah
<zyga> mvo: https://github.com/snapcore/snapd/pull/8457 <-
<mup> PR #8457: github: skip spread jobs when corresponding label is set <Skip spread> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8457>
<mborzecki> no surprises there
 * zyga hugs maciek
<zyga> thank you :)
<mborzecki> now, i still need to figure out that cla check
<mborzecki> looks like there's a difference in what gets merged where between gh and travis
<zyga> mvo: src/github.com/snapcore/snapd/vendor/github.com/chrisccoulson/go-tpm2/mu.go:267:17: constant 4294967295 overflows int
<zyga> mvo: this now breaks master .deb builds
<zyga> mborzecki: you can change how we check out things
<zyga> mborzecki: there's also plenty of 3rd party solutions for this but I didn't look deeper
<zyga> mborzecki: one was cool though, each CLA signature was a signed file in the repo
<zyga> mborzecki: so the check was entirely offline
<pedronis> zyga: it's because we are getting a pc-kernel update in the middle of the tests
<zyga> ohh
<zyga> pedronis: did you reproduce it
<mborzecki> zyga: there's an action ready for that, broought to you by SAP (?!)
<pedronis> zyga: no, but the log is obvious
<zyga> pedronis: we should probably hold refreshes for snaps that cause reboots
<pedronis> once you look at it and that the tests
<zyga> mborzecki: yes, SAP
<mborzecki> https://github.com/cla-assistant/github-action
<zyga> mborzecki: fun world :)
<pedronis> zyga: we don't have single snaps holding
<zyga> I read that one
<pedronis> but it's still strange
<zyga> pedronis: oh... right
<zyga> hmm
<zyga> but why doesn't it come back?
<pedronis> why would we try to refresh kernel anyway
<zyga> maybe really buggy?
<pedronis> something is off
<zyga> oh
<zyga> standup time
 * zyga needs to check one thing first
<pedronis> zyga: because we make reboot slow explicitly
<pedronis> the test don't really support unexplicit
<pedronis> reboots
<zyga> ah, indeed
<pedronis> these tests are not meant to reboot
<mup> PR snapd#8457 closed: github: skip spread jobs when corresponding label is set <Skip spread> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8457>
<pedronis> zyga: anyway I do think we want to add per-snap holding at some point, just not clear when
<rbasak> I just accidentally published a snap to beta, when nothing was published in beta before. Can I undo that?
<roadmr> rbasak: yes
<roadmr> rbasak: snapcraft close your-snap beta
<rbasak> Ah, I found a "close" option?
<rbasak> Got it. Thanks!
<roadmr> ð
<rbasak> While I'm on the topic, is there any way I can unpublish the i386 snaps (on a different snap)? We don't build those now, so the ones that are there are way behind and probably useless now.
<mvo> zyga: yeah, trying to fix it in 8456
<jdstrand> zyga: note, I re-read through PR 8408 yesterday (though after it was merged; it was fine)
<mup> PR #8408: snap/naming: add validator for snap security tag <Skip spread> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8408>
<zyga> jdstrand: thank you!
<jdstrand> zyga: PR 7614 and PR 7825 are very high on the list
<zyga> jdstrand: thanks
<mup> PR #7614: cmd/snap-confine: implement snap-device-helper internally <Created by zyga> <https://github.com/snapcore/snapd/pull/7614>
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<jdstrand> zyga: the apparmor upload and some training I gave set me back a bit, but I will be getting to them
<zyga> jdstrand: both fail in CI now, one on silly thing and one (f31 or f32) fails on something that seems real, I'll invesetigate soon
<zyga> jdstrand: but any feedback would be great
<zyga> jdstrand: in the branch about refresh-app-awareness please note if I should split up the cgroup scanning code to a separate PR, it could be reviewed faster and land, aiding further review
 * jdstrand nods
<zyga> uh
<zyga> my daughter's school friend is at a hospital
<zyga> he lives next door :/
<roadmr> ohnoes
<zyga> FYI we run at capacity now, saturated 32 workers
<zyga> but the queue is empty
<zyga> and we should see a drop to ~ half of that in a few minutes
<zyga> I will look at implementing the ideas we had today, that should reduce the queue load significantly
<zyga> well, worker load
<zyga> we're still not queueing because we manage to process everything (for now)
<zyga> and we are at 24/32
<pstolowski> zyga: oh
<mup> PR snapcraft#3019 closed: static: consolidate tooling setup to setup.cfg <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3019>
<mup> PR snapcraft#3020 closed: spread tests: default base for local plugin tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3020>
<mup> PR snapcraft#3022 opened: plugins: introduce v2.PluginV2 and v2.NilPlugin <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3022>
<zyga> pstolowski: yeah :/
 * zyga is hungry and breaks for lunch
<zyga> o/
<mup> PR snapd#8411 closed: boot: cleanup more things, simplify code <Reviewed> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8411>
<stgraber> zyga: back to what I asked you about yesterday, any reason why "snap run --command=stop" would block on snapd.socket?
<stgraber> zyga: if so, you need to find a way to make snapd keep running until the last snap has been stopped
<zyga> yes, it does so when system key is different to the one on disk
<zyga> it normally happens when you boot a new kernel
<zyga> we ask snapd to generate new profiles and wait until it does so
<stgraber> zyga: the current situation means LXD is never stopped properly, causes a 10min shutdown delay and data loss
<stgraber> *never stopped properly in those cases
<stgraber> I'm not sure it's just about kernel updates, I have a system that seems to reproduce it every time, let me try it again today
<zyga> stgraber: please raise a bug to mvo
 * zyga is at lunch
<zyga> (well almost)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8461
<mup> PR #8461: github: run non-canary if label is present <Created by zyga> <https://github.com/snapcore/snapd/pull/8461>
 * zyga is gone
<mup> PR snapd#8461 opened: github: run non-canary if label is present <Created by zyga> <https://github.com/snapcore/snapd/pull/8461>
<zyga> stgraber: FYI I experienced this issue but was unable to debug it at the time
<stgraber> yeah, got it easily reproducible on an arm64 system somehow, seems to happen at every single reboot
<stgraber> the new kernel thing would explain why other users only get it somewhat randomly though
<zyga> For me it was x86
<stgraber> filing a critical bug against snapd claiming data loss
<zyga> Perhaps system key is buggy
<zyga> Please!
<stgraber> mvo: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652
<mup> Bug #1871652: Daemon snaps not properly stopped in some cases <champagne> <snapd (Ubuntu):Triaged> <https://launchpad.net/bugs/1871652>
<stgraber> mvo: as you know, every single server and cloud instances of 20.04 will use the LXD snap and all upgrading users of 18.04 snap will upgrade to the snap too, so we really really need this resolved or we're in for a lot of data loss / corruption issues.
<mvo> stgraber: looking
<stgraber> mvo: thanks!
<stgraber> I'm creating a test VM on that arm64 system which can be played with as much as needed, should make fixing this easier
<mvo> stgraber: I think zyga is on to something here, snap run will wait for snapd to re-generate the profiles, if snapd is already stopped this of course won't work, I need to see why this happens/how to do fix it
<stgraber> mvo: I've updated the LP bug with my reproducer on arm64
<stgraber> mvo: I'm happy to sort out a way for someone from your team to access that system if that helps
 * cachio afk
 * cachio afk
<mvo> stgraber: in various meetings right now, need to find someone to look at this while I'm "off"
<zyga> re
<zyga> stgraber: I have plenty of arm64 boards
<zyga> I can look later today
<stgraber> zyga: VM capable?
<zyga> stgraber: hmmmm
<zyga> stgraber: good question
 * zyga checks
<stgraber> zyga: the system I'm testing this on is a 48 core, 128GB RAM, arm64 server :)
<zyga> stgraber: I think you win :)
<stgraber> (which Qualcomm kindly forgot in my basement before firing the entire team who designed it)
<zyga> GCE had a hiccup, restarted a job to see if it was temporary
<mup> PR snapd#8459 closed: asserts: it should be possible to omit many snap-ids if allowed, fix <UC20> <â  Critical> <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8459>
<mup> PR snapd#8460 closed: tests/session-tool: kill cron session, if any <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8460>
<cjwatson> that's one way to get hardware
<zyga> stgraber: if you _ever_ want to throw it out
<zyga> just remember
<zyga> bring it to europe on a plane and I can relieve you of it ;-)
<stgraber> :)
<zyga> stgraber: are there any arm servers available that don't require a datacenter contract?
<zyga> stgraber: looking at the bug now
<zyga> stgraber: would it be possible for me to get a shell on a machine where this can be reproduced?
<zyga> alternatively, I'd love to see the system key snapd writes
<stgraber> zyga: happen to have IPv6 on your side?
<zyga> stgraber: if is in /var/lib/snapd/system-key
<zyga> stgraber: unfortunately no :/
<zyga> maybe don't open access for now,
<zyga> system-key is ... well, the key
<mvo> zyga: thanks for looking, I'm a bit busy with meetings
<zyga> it may be revealing
<stgraber> {"version":10,"build-id":"799a88b406b245795da51b18f6224003020c6fb9","apparmor-features":["caps","dbus","domain","file","mount","namespaces","network","network_v8","policy","ptrace","query","rlimit","signal"],"apparmor-parser-mtime":1538072454,"apparmor-parser-features":["unsafe"],"nfs-home":false,"overlay-root":"","seccomp-features":["allow","errno","kill_process","kill_thread","log","trace","trap","user_noti
<stgraber> f"],"seccomp-compiler-version":"66988dd2c3fb0abf9b1fb29be212771d7c38ae85 2.4.1 8c73f36d3de1f71977107bf6687514f16787f639058b4db4c67b28dfdb2fd3af bpf-actlog","cgroup-version":"1"}
<zyga> thanks, let me inspect things now
<zyga> stgraber: so, why does lxd stop itself using snap run?
<zyga> this is not a bug on your side, I think, I'm just curious
<stgraber> that's how the systemd units are generated
<stgraber> all Commands in there wrap using snap run I think
<zyga> ah, I see,
<zyga> indeed
<zyga> stgraber: is it possible to reproduce this with SNAPD_DEBUG=1 set
<zyga> stgraber: if so please attach that
<zyga> I need to break now, my 1yo daughter just woke up
<zyga> but I have a hunch I know what it is
<zyga> having that will confirm
<pstolowski> so, fun fact about persistent journal; restarting systemd-journald triggers snapd restart (?) and since this is happening from config hook, bad things happen :/
<pedronis> pstolowski: that's a problem for sure :/
<pstolowski> pedronis: it's annoying, because core16 seems to need journald restart
<zyga> Whaaat?
<zyga> Why do we restart?
<zyga> Can we reload it instead?
<pstolowski> zyga: i need to try
<pedronis> pstolowski: core18 and 20 work without?
<pstolowski> pedronis: core18 - yes. i haven't checked 20
<pstolowski> Failed to reload systemd-journald.service: Job type reload is not applicable for unit systemd-journald.service.
<pstolowski> :}
<pstolowski> there you go
<pstolowski> only systemctl restart does it
<pedronis> pstolowski: if it works with 18 and 20 without, I would just go without, restarting the journal is kind of weird anyway
<pstolowski> pedronis: ok. i'll double check if i wasn't dreaming
<pedronis> pstolowski: anyway what you could try is kill USR1
<pedronis> pstolowski: see man systemd-journald
<pstolowski> pedronis: aaha, thanks!
<pedronis> pstolowski: as usual is not super clear what it does
<pedronis> from the man
<pedronis> zyga: mvo: I got again a bunch of allocation problems: https://github.com/snapcore/snapd/pull/8436/checks?check_run_id=570978994
<mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Reviewed> <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
<zyga> pedronis: looking
<zyga> pedronis: happened once today
<zyga> it looks like some permission issue
<zyga> it was mentioned on the internal channel
<zyga> please restart the workflow, it's not a capacity problem
<zyga> we don't know what caused it
<zyga> better yet, merge master for more fixes :)
<pedronis> zyga: I merged master many times
<pstolowski> pedronis: systemctl kill --signal=SIGUSR1 systemd-journald does the job on core16
<pedronis> pstolowski: good
<pedronis> pstolowski: that seems safe everywhere
<pedronis> systemd has Kill I think, right?
<pedronis> I mean systemd our package
<pstolowski> pedronis: yes, i'm just looking at it right now
<mvo> zyga: do you have anything to share about the lxd bug ? anything you figured out already that is worth for me to know?
<zyga> mvo: I'm still partially AFK but give me some more time
<zyga> mvo: I have conditions to reproduce it
<zyga> mvo: and I _suspect_ I know what the problem is
<mvo> zyga: nice, keep me updated please
<ijohnson> pedronis: did you want me to change to use a string pointer for mockedMountInfo in 8451 ?
<pedronis> ijohnson: yes, it's it not too annoying
<pedronis> heh
<pedronis> if it's not
<ijohnson> sure I mean I'll only have to re-start the workflows 1000 more times anyways so it's not a big deal
<pedronis> ijohnson: about the selinux tests, yes, that's fine, anyway is a different package, it was really testing two levels
<ijohnson> right
<zyga> let's merge https://github.com/snapcore/snapd/pull/8456#pullrequestreview-390189749
<zyga> it needs a 2nd review
<mup> PR #8456: tests: add 32 bit machine to GH actions <Created by mvo5> <https://github.com/snapcore/snapd/pull/8456>
<zyga> ijohnson: any issues?
<ijohnson> mm?
<ijohnson> oh the PR you just mentioned?
<zyga> with CI
<ijohnson> I haven't been looking at CI in the past hour or two, just seems annoying that every time I look at one of my PR's exactly one check out of the 17 failed and so I have to restart everything
<zyga> ijohnson: I'll prepare the quad workflows for tomorrow
<ijohnson> I reviewed 8456
<zyga> ijohnson: it's late and I'm looking at something else
<ijohnson> yes that would be much appreciated
<ijohnson> also did you see the mount ns bug I assigned to you last night ?
 * zyga needs coffee and checks
<ijohnson> I couldn't reproduce it with robust-mount-namespace-updates=true with a small reproducer snap, but with the full snap I can still reproduce the EBUSY
<ijohnson> anyways I can send you the snap when you have time to look at the issue
<mup> PR snapd#8456 closed: tests: add 32 bit machine to GH actions <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8456>
<zyga> ijohnson: cannot find it, let me check my mail
<pedronis> did we get a newer systemd recently in 20.04 ?
<mvo> ijohnson: I can override failures in merges fwiw
<mvo> ijohnson: we are a bit timezone challenged so not ideal but do ping me if you have such a case
<ijohnson> mvo ack maybe I'll send you an email at my EOD if needed
<mvo> ijohnson: sure thing!
<zyga> re, back to work
<zyga> pedronis: 244 was in Feburary
<zyga> February
<zyga> 245 was in March
<zyga> we are now on 245.2
<pedronis> ok, just confused because a test that I tried failed now, anyway it indeeds needs tweaking for systemd >=243
<zyga> mvo: I debugged the issue related to lxd and snapd
<zyga> cachio: 19.10 images also have GDM
<zyga> cachio: it would be good to regenerate them so that we don't have the desktop
<ijohnson> zyga: what was the issue with lxd and snapd ?
<ijohnson> I'm curious
<zyga> ijohnson: https://bugs.launchpad.net/snapd/+bug/1871652
<zyga> it's all there
<mup> Bug #1871652: Daemon snaps not properly stopped in some cases <champagne> <snapd:Confirmed for zyga> <snapd (Ubuntu):Confirmed for zyga> <https://launchpad.net/bugs/1871652>
<zyga> ijohnson: but tl;dr; is in the last comment
 * ijohnson reads
<zyga> ijohnson: it's pretty interesting actually
<zyga> stgraber: thank you for the debugging environment
<zyga> stgraber: it's late so unless it's very urgent I will fix it first thing  tomorrow after discussing with the team
<stgraber> zyga: it's been happening for a long long time, we can wait another day :)
<zyga> I hope one last day
<zyga> let me do one more test today
<stgraber> it's just that now that we understand it, we also understand the danger from it (containers aren't stopped at all, filesystem isn't unmounted, so data loss potential)
<stgraber> it actually explains why we've seen some odd db corruption in the past which we couldn't really explained based on logs
<zyga> yes, I think the bug is well marked as critical
<mvo> zyga: ohhhh, what did you find out?
<mvo> zyga: ok, how involved is the fix :) ?
<zyga> stgraber: as a small note, setting
<zyga> SNAPD_DEBUG_SYSTEM_KEY_RETRY=0
<zyga> should work around it
<zyga> mvo: it depends
<zyga> mvo: please read https://bugs.launchpad.net/snapd/+bug/1871652
<zyga> mvo: it's probably something we can fix tomorrow
<mup> Bug #1871652: Daemon snaps not properly stopped in some cases <champagne> <snapd:Confirmed for zyga> <snapd (Ubuntu):Confirmed for zyga> <https://launchpad.net/bugs/1871652>
<zyga> mvo: tl;dr; is https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652/comments/7
<mvo> zyga: nice
<mvo> zyga: but it does sounds like the fix will not be entirely easy
<zyga> mvo: it's actually very easy
<zyga> mvo: just the if ( ... ) part needs discussing
<mvo> I like the sound of that
<zyga> we cannot wait for system key on shutdown
<zyga> and we probably should depend on core/snapd
<zyga> and not let them go away / unmounted
<zyga> this was never expressed in systemd terms
<zyga> but let's discuss that tomorrow
<mvo> ok
<zyga> it's late and I'd love to get off my chair :)
<mvo> zyga: sounds great, thank you so much
<zyga> we know exactly how to reproduce this
<zyga> and we know what to change to fix it, we need to discuss how to introduce the changes
<zyga> mvo: I suspect we _can_ do a minimal fix tomorrow
<zyga> without ill effects
<zyga> and work on a more proper fix for +1
<zyga> the minimal fix will just detect the shutdown and ignore system key
<zyga> the proper fix will introduce dependencies
<zyga> so lxd will not stop after core is unmounted
<mvo> zyga: sounds good to me
<zyga> but that's more iffy for the reasons you probably know about (wrappers and ensure)
 * zyga waves and takes a break
<cachio> zyga, I'll run the update7
<zyga> cachio: let me know if you need mount-ns test changes for that
<mvo> zyga: thank again and good night
<zyga> cachio: it slipped from my radar but I will send the patches tomorrow
<cachio> zyga, sure
<zyga> stgraber: and I know why I cannot reproduce it, for development I disabled reexec on my main machine
<stgraber> ah, that'd do it
<cachio> zyga, job running
<cachio> zyga, https://travis-ci.org/github/snapcore/spread-cron/builds/672666095
<cachio> it would be ready in about 40 minutes
<mup> PR snapcraft#3021 closed: remote-build: remove artifact sanity check <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3021>
<zyga> stgraber: ^
<zyga> https://github.com/snapcore/snapd/pull/8462
<zyga> actually ^
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<zyga> it should do the job, we need to package it with tests and stuff
<mup> PR snapd#8462 opened: cmd/snap: don't wait for system key when stopping <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<zyga> that code didn't seem to have unit tests before so it will take me more
<zyga> now I'm really gone
<zyga> mvo: T
<zyga> ^
<stgraber> looks simple enough :)
<mup> PR snapcraft#3023 opened: pluginhandler: move attributes to PluginHandler <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3023>
<mup> PR snapd#8463 opened: secboot: key sealing also depends on secure boot enabled <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8463>
#snappy 2020-04-09
<mborzecki> morning
<zyga> Hey
<zyga> Taking the dog out
<mborzecki> zyga: found anything interesting about the lxd issue?
<mborzecki> zyga: reading through https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1871652 nice find!
<mup> Bug #1871652: snap run hangs on system-key mismatch due to reexec and shutdown <champagne> <snapd:In Progress by zyga> <snapd (Ubuntu):Confirmed for zyga> <https://launchpad.net/bugs/1871652>
<mborzecki> mvo: hey
<mvo> good morning mborzecki
<mborzecki> zyga: hm i was worried that maybe the client gets stuck, but looking at the backtrace the client timeout seems to work
<mborzecki> zyga: i think that the unfortunate part is that the client timeout (overall timeout for all retried requests) is 50s, then *12 retries in snap run, we're looking at 10 minutes after which snap run would fail eventually
<zyga> mborzecki: it's debugged
<zyga> :)
<zyga> mborzecki: if you are talking about the lxd issue
<zyga> mvo: good morning :)
 * zyga woke up in good mood and just returned from dog & bike ride
<mvo> zyga: good morning! you seem to be in a good mood :) ?
<zyga> indeed
<mborzecki> zyga: i know, just looking at the backtrace you posted there, https://github.com/snapcore/snapd/pull/8462 and the client.do() loop
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<zyga> yesterday surely ended on a high note
<zyga> I have some more thoughts about how this problem is annoying
<zyga> but I think the fix is valid
<mvo> mborzecki: yeah, a timeout of 10min seems a bit excessive
<mvo> zyga: yeah, I like hte idea to just check for shutdown
<mborzecki> mvo: there's this comment that isn't true anymore https://github.com/snapcore/snapd/pull/8462/files#diff-0ffbc404d8a8e3aaeca8cd9d066c3d71R160
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<mborzecki> uhh it's `// connect timeout for client is 5s on each try, so 12*5s = 60s`
<mvo> mborzecki: uh, so it looks like we try to accomodate thie situation already? is that check buggy?
<mvo> mborzecki: also if the retry timeout should be max 60s but in reality is 10min is there a different bug there too :( ?
<zyga> I can debug this further
<zyga> I wanted to check the solution in practice
<zyga> the socket is there
<zyga> but will never activate
<mborzecki> mvo: probably the client retry bits evolved separately
<zyga> maybe we just hang on connect?
<zyga> ahhh
<zyga> fiun
<zyga> hhe
<mborzecki> zyga: yeah
<zyga> ok, I'll get back to my coffee
<mvo> mborzecki: aha, yeah, that makes sense
<zyga> but I'm happy :)
<mvo> mborzecki: sorry, I see these lines are from an open PR
<mborzecki> if the socket wasn't there it would fail much earlier i believe
<mvo> zyga: woah, thanks so much for adding this PR so quickly
<zyga> :D
<zyga> after breakfast I'll verify this
<zyga> and write some tests
<mvo> zyga: yeah, having a test there would be great
<mborzecki> zyga: mvo: so actually a funny scenario, the socket we use to talk to snapd is there, but snapd may be inactive, how do you find out that the other end is inactive if poking th socket isn't reliable?
<zyga> any issues with spread?
<zyga> mborzecki: we should think about how to prevent the bug for real
<zyga> mborzecki: I realized it's much harder because the dependency is dynamic
<zyga> mborzecki: we depend on the active reexecution target that may be core or snapd and the revisions may change at runtime any number of times
<zyga> mborzecki: which is not great
<zyga> mvo: so 2.44... 4?
<mvo> zyga: 2.44.3
<zyga> perfect
<zyga> thank you
<mvo> zyga: I hope I can upload that today
<mvo> tonight
<mvo> something like this :)
<mborzecki> hmm preseed reset is failing in an intresting way
<mborzecki> saw the same rpoblem twice already
<zyga> yeah I noticed
<zyga> did you debug it more? I didn't look deeper
<mborzecki> the log https://paste.ubuntu.com/p/gTcdq4h8CF/
<pstolowski> morning
<zyga> good morning pawel
<mborzecki> pstolowski: hey
<mborzecki> pstolowski: preseed reset hangs on 20.04 https://paste.ubuntu.com/p/gTcdq4h8CF/
<mborzecki> pstolowski: but i'm not able to reproduce it manually
<mvo> pstolowski: good morning
<pstolowski> mborzecki: interesting, i'll take a look
<mborzecki> doing 'restart all jobs' in gh actions is actually very confusing
<mborzecki> looks like it's first restating the unit tests job, then the canary jobs, and then the stable ones
<mborzecki> and E: Failed to fetch http://pkg.jenkins.io/debian-stable/binary/jenkins_2.222.1_all.deb  Could not connect to pkg.jenkins.io:80 (52.202.51.185), connection timed out
<jamesh> presumably it is respecting the job dependencies: the stable jobs can't restart until the restarted canary jobs have completed, which can't restart until the restarted unit tests have completed
<zyga> jamesh: exactly
<zyga> mborzecki: yeah, they don't invalidate past results until such jobs actually start
<zyga> mborzecki: if it's a one off failure like that just ask mvo to override
<zyga> no use in burning money on this
<zyga> can I get a 2nd review on green https://github.com/snapcore/snapd/pull/8403
<mup> PR #8403: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <https://github.com/snapcore/snapd/pull/8403>
<zyga> it's not much and I'd like to get it in and have one less
<zyga> jdstrand: thank you for the reviews
<zyga> I'll break for breakfast and then get back to work
<mvo> zyga: which PR is that? I can override if needed
<pedronis> pstolowski: I reviewed #8414, thank you
<mup> PR #8414: o/configstate: core config handler for persistent journal <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
<pedronis> couple small comments
<pstolowski> pedronis: ty
<pstolowski> mborzecki: yeah, hangs for me too when run on gc. will try to add some debug
<mborzecki> pstolowski: oh, you manged to reproduce it?
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8462#pullrequestreview-390565291
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<pstolowski> mborzecki: it seems so.. it's hanging on < /mnt/cloudimg/var/lib/snapd/desktop/applications, i'm waiting for spread to timeout
<mborzecki> pstolowski: ha, interesting, i ran with -shell and executed the test line by line
<mborzecki> pstolowski: btw. diff -up is easier to read there
<pstolowski> mborzecki: also it's interesting it found a diff
<mup> PR snapd#8450 closed: selinux: export MockIsEnforcing; systemd: use in tests <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8450>
<zyga> mvo: not sure, it was pawel
<zyga> mborzecki: ta
 * mborzecki wonders why it's showing `degraded` here
<zyga> mborzecki: systemctl --failed
<mborzecki> zyga: yeah, that's the mystery, shadow.service apparenty failed :P
<zyga> shadow.service?
<zyga> what is that
<zyga> I don't have it
<zyga> is it related to homed?
<mborzecki> zyga: idk maybe https://paste.ubuntu.com/p/f7hkWx94vQ/
<zyga> which package ships that?
<mborzecki> zyga: surprise surprise.. `shadow` :P
<mborzecki> zyga: btw it runs the following /bin/sh -c '/usr/bin/pwck -r || r=1; /usr/bin/grpck -r && exit $r'
<zyga> pwck?
<zyga> wow
<zyga> I learned something today already
<zyga> YoU HaVe BeEn Hax0rEd
<zyga> re
<mborzecki> zyga: yeah, from what i managed to find it checks /etc/group against /etc/gshadow
<zyga> so is something corrupted on your system?
<mborzecki> zyga: nah, i had a `sudo` group at some point that was listed in gshadow, but got removed from /etc/group
<mborzecki> zyga: probably something went out of sync during one of my arch 'installs', that's actually rsyncing whole sysroot from another arch system, wouldn't be surprised since the actuall install from scratch was years ago
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/8462 again please
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<mvo> zyga: thanks for adding the test to 8462
<zyga> mvo: I'll verify this in the machine where it is easy to reproduce now
<mvo> zyga: \o/
<zyga> I believe I can write a spread test for this as well
<mvo> zyga: extra browny points if that is possible and not too much work
<zyga> mvo: I think so, just a moment to know
<mvo> zyga: \o/
<zyga> mvo: gotta justify a push to fix that silly typo :D
<zyga> test in progress
 * mvo hugs zyga
<ijohnson> morning folks
<ijohnson> hey zyga I saw this failure for session-tool on one of my PR's that is relatively up to date with master https://pastebin.ubuntu.com/p/tj9qTTN6Wf/
<ijohnson> looks like it's a gdm issue with 19.10?
<zyga> yeah
<zyga> I saw it, I asked sergio to remove gdm
<pstolowski> hi ijohnson !
<ijohnson> ok
<zyga> I'll send a patch to stop the gdm session
<ijohnson> o/ pstolowski
<zyga> though
<zyga> maybe I should remove that part of the test
<zyga> it's not like we are leaking our sessions
<zyga> it's just a goose chase
<zyga> ijohnson: what do you think?
<ijohnson> mmm it's a bit annoying, but in this instance also genuinely useful to have it tell us that something is on the image that is leaking state around
<ijohnson> I dunno
<pstolowski> is it related to the bug sergio raised recently? https://bugs.launchpad.net/snapd/+bug/1868857
<mup> Bug #1868857: Installing evolution-data-server on test images pulls in GDM and the desktop <snapd:Triaged> <https://launchpad.net/bugs/1868857>
<zyga> pstolowski: yes
<zyga> after checking and checking I managed to convince him we have GDM :)
<zyga> brb
<ijohnson> mmm okay another random failure from overnight about being unable to connect to the systemd user session: https://pastebin.ubuntu.com/p/QdyVGHHDrJ/
<pstolowski> mborzecki: this preseed-reset hang issue is misterious; i added debug that should show up right after the last diff line where it hangs , but it's quiet :/
<pedronis> pstolowski: core-persistent-journal is failing on core16
<pstolowski> pedronis: yeah, i've seen this, didn't happen when run locally, investigating
<mborzecki> pedronis: mvo: i'm looking into the mount point rename
<mvo> mborzecki: thank you
<mborzecki> mvo: pedronis: i'll split the /run/mnt/host bind mount till after we have the directory in the core snap
<mborzecki> i mean the /host directory
<mvo> +1
<zyga> afk for another moment, sorry :/
<ijohnson> mvo: could you use your magical powers to merge https://github.com/snapcore/snapd/pull/8451 ? It's been restarted numerous times and all the current failures there have either been reproduced and known by others, or have been reported
<mup> PR #8451: osutil: mock proc/self/mountinfo properly everywhere <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8451>
<mvo> ijohnson: sure
<mup> PR snapd#8451 closed: osutil: mock proc/self/mountinfo properly everywhere <Test Robustness> <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8451>
<ijohnson> thank you \/o
<ijohnson> oh whoops I was too excited
<ijohnson> \o/
<mvo> haha
<pedronis> pstolowski: now, it passed, it seems flakey somehow
<pstolowski> pedronis: yes, maybe there is something flaky. i'm running it in a loop locally now
<zyga> re
<mup> PR snapd#8464 opened: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mborzecki> mvo: pedronis: ^^
<mborzecki> i did not add the /run/mnt/data -> /run/mnt/ubuntu-data bind mount too, let's see if the tests pass
<pedronis> mborzecki: they won't, actually initramfs will need some changes
<mborzecki> hmm ah right, there's some hard coded names there too
<pedronis> mborzecki: https://paste.ubuntu.com/p/cF4NVBChbG/
<mborzecki> looks like the bind mount data -> ubuntu-data could make it work tho
<pedronis> yes, but we do want then to change the initrd
<pedronis> because otherwise is a bit too many level of mounts
<pedronis> mborzecki: also my pastebin has type -d (not sure why I did that), so there's a couple more things actually
<pstolowski> pedronis: just run it 10 times without failure. weird. will give it one more spin
<ijohnson> pedronis: mborzecki: suspicious that the initrd has things like this:
<ijohnson>     echo 'LABEL=ubuntu-boot /run/mnt/ubuntu-boot auto defaults 0 0' >> /run/image.fstab
<ijohnson> that seems like it would defeat the purpose of our cross-checking no?
<pedronis> ijohnson: it's optimizing some mounts
<pedronis> ijohnson: you'll have to discuss what that means
<ijohnson> mmm yes
<ijohnson> pedronis: is the results of the discussion this morning summarized somewhere ?
<pedronis> ijohnson: seems you got the doc
<ijohnson> yes mborzecki PM'd it to me
<pstolowski> zyga: btw i've re-requested your review of #8414 as it changed substantially
<mup> PR #8414: o/configstate: core config handler for persistent journal <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8414>
<zyga> ack
<zyga> I'll look in 10 minutes
<ijohnson> pedronis: I left a comment in the doc, so will we now have /run/mnt/boot instead of (or in addition to) /run/mnt/ubuntu-boot ?
<pedronis> ijohnson: no
<ijohnson> ok, so the changes are just for ubuntu-data really
<ijohnson> (and all alter egos of ubuntu-data)
<pedronis> ijohnson: yes, we'll have temporarely both data and ubuntu-data until initramfs is fixed
<ijohnson> sure
<zyga> pstolowski: looking
<diddledan> jdstrand: possibly I'm still broken? https://forum.snapcraft.io/t/snapcraft-and-strict-multipass-call-for-testing/16488/5
<Saviq> diddledan: yeah that's not something we're doing
<diddledan> strangely at least two snaps have started fine, but those are desktop apps and I spent some time cooking toast
<diddledan> ... after reboot, so I was well past apparmor starting when I logged-in
<diddledan> Saviq, yeah LXD is also dead
<zyga> pstolowski: +1
<Saviq> diddledan: have a look at https://github.com/ubuntu/zsys/issues/60#issuecomment-609729305 for what fixed things for me on zfs root - not snapd, but the overall problem may be the same - look in the journal for things refusing to mount due to target not being empty
<diddledan> it's not that.. I have a correct set of files in /etc/zfs-list.cache and there are no failed mounts in the journal
<zyga> mvo: sorry for the lag, i have a test
<zyga> I'm running a few more iterations to recheck if fails without the fix and to remove redundant parts
<zyga> I'll push the final version before the standup
<zyga> most likely in 20 minutes, after the next run
<pstolowski> pedronis: 100 runs and no failure; i wonder if we were seeing a failure from before USR1 commit
<pedronis> pstolowski: maybe, let's see if it gets green and can land
<pstolowski> pedronis: doh.. it failed on 20.04
<pstolowski> pedronis: on preseed-reset, which is the other issue i'm investigating
<pedronis> pstolowski: could you recheck quickly my #8436 , I had to change the spread test because I remember it passing on core20 but actually the systemd there now uses a different property name
<mup> PR #8436: configcore,tests: use daemon-reexec to apply watchdog config <Squash-merge> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8436>
<pedronis> pstolowski: maybe we need an explicit journalctl --flush ? or do some activity that is none to produce logs?
<pstolowski> pedronis: looking
<pedronis> s/none/known/
<pstolowski> pedronis: maybe, but it seems that enabling logging writes a single starting entry, so only question is if flush is needed
<pstolowski> pedronis: but the problem is now preseed-reset test which breaks with master
<jdstrand> diddledan: can you perform: sudo systemd-analyze plot > ./1871148-vm-no-varlib-mount_diddledan.svg' and attach it to https://bugs.launchpad.net/apparmor/+bug/1871148?
<mup> Bug #1871148: services start before apparmor profiles are loaded <AppArmor:Invalid> <apparmor (Ubuntu):Fix Released by jdstrand> <zsys (Ubuntu):Invalid by jibel> <apparmor (Ubuntu Focal):Fix Released by jdstrand> <zsys (Ubuntu Focal):Invalid by jibel> <https://launchpad.net/bugs/1871148>
<jdstrand> (without that trailing "'" of course
<jdstrand> )
<diddledan> jdstranddone :-)
<diddledan> jdstrand done :-)
<pstolowski> aaha, we started shipping var/lib/snapd/desktop/applications in the pkg, that's the primary reason of preseed-reset test failure
<jdstrand> diddledan: https://bugs.launchpad.net/snapd/+bug/1871148/comments/24
<mup> Bug #1871148: services start before apparmor profiles are loaded <AppArmor:Invalid> <snapd:New> <apparmor (Ubuntu):Fix Released by jdstrand> <zsys (Ubuntu):Invalid by jibel> <apparmor (Ubuntu Focal):Fix Released by jdstrand> <zsys (Ubuntu Focal):Invalid by jibel> <https://launchpad.net/bugs/1871148>
<jdstrand> mvo, zyga: ^ I added a snapd task. please see my comment. it seems that root on zfs is aggravating the condition that apparmor.service might start after snap services
<zyga> looking
<jdstrand> since we don't see it on non-root-on-zfs systems (even though the possibility is there)
<zyga> yeah, I think we need to think about how to handle this
<jdstrand> mvo: this is possibly another 2.44 point release. up to you to decide, but with focal making zfs an option in the installer, and that seems to push the system into this bug more than others, ...
<mup> PR snapd#8465 opened: tests: update snap-preseed --reset logic to acommodate for 2.44 change <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8465>
<cachio> pedronis, hey
<jdstrand> zyga: I need to step away, but maybe this is the time to align with non-Ubuntu-but-apparmor-enabled systems? I forget the details, but iirc, there is an additional snap-apparmor unit or similar that can be After apparmor, and then snapd can add After snap-apparmor to the units. I defer to you, mvo, etc on the design and am happy to review a PR
<cachio> I see this error on uc20 nested tests
<cachio> https://paste.ubuntu.com/p/sBWXC4VZyG/
<cachio> is it something new?
<cachio> first time I see this
<zyga> jdstrand: that's a brilliant idea
<zyga> jdstrand: we can just no-op if apparmor is of
<zyga> *off
<jdstrand> yeah
<zyga> and we can always put the dependency into the units
<jdstrand> yeah
<zyga> mvo: ^ that's a solution that's easy
<zyga> I can look at this after the current bug
<jdstrand> diddledan: thank you for your persistence :)
 * jdstrand -> steps away
<mvo> zyga, jdstrand works for me
<cachio> pstolowski, hey, I see also this error in nested test for uc20 Apr 09 12:08:53 ubuntu snapd[720]: hotplug.go:131: internal error: cannot get global device context: broken assertion storage, looking for model: broken assertion storage, cannot decode assertion: asser
<mup> PR #9: Added the travis config file <Created by elopio> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/9>
<cachio> pstolowski,  any idea?
<pstolowski> cachio: no, maybe core20 requires something new to be done in that area, i'll need to investigate
<cachio> pstolowski, thanks
<pstolowski> #8465 should unbreak master
<mup> PR #8465: tests: update snap-preseed --reset logic to acommodate for 2.44 change <Simple ð> <â  Critical> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8465>
<pedronis> it sounds like some code is running before seeding is done
<pstolowski> mborzecki: ^
<pedronis> I thought that code waiting on seeding
<zyga> today is sponsored by <critical> tag
<mborzecki> heh ;)
<mvo> zyga: yeah, it totally is
<mvo> it's the N-days before the release feeling
<pstolowski> pedronis: it doesn't wait
<pedronis> pstolowski: it waits for the system snap to be there at least
<pstolowski> pedronis: right, that's true
<pstolowski> mborzecki: for clarity, i pinged you about 8465
<mborzecki> pstolowski: figured ;)
<mborzecki> mvo: pedronis: added the compatibility bind mount, i can succesfuly go through the install mode, but it hangs in initramfs in run mode
<mvo> zyga: so you are suggesting all our snap unit have "After=apparmor.service", is that what you said earlier? are you on it? should I?
<mborzecki> mvo: pedronis: pushed a patch to #8464 anyway
<mup> PR #8464: cmd/snap-boostrap, boot: use /run/mnt/data instead of ubuntu-data <Skip spread> <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8464>
<mvo> mborzecki: please do, maybe something for dimitri
<mvo> pstolowski: do we need 8465 for 2.44 as well as a cherry pick?
<pedronis> mvo: we have no way to rewrite atm though
<pedronis> to rewrite units
<mborzecki> pstolowski: do you know what that blocked the test?
<mborzecki> pstolowski: it would actually hit the kill timeout
<mvo> pedronis: yeah, but at least all new focal install with zfs will not be affected if we have it now
<pedronis> pstolowski: that's really weird because 131 is definitely after we are getting events
<pedronis> something is very broken
<pstolowski> mborzecki: not yet, as i said in the comment and standup notes i'm investigating; maybe qemu-nbd hangs when we leave execute. if i re-arrange the test to first unmount and clean up and then fail on diffing, it fails as expected and doesn't hang
<pstolowski> mvo: probably yes
<zyga> mvo: I've verified that the spread test fails without the fix and passes with the fix
<zyga> mvo: I'll jump into the apparmor issue in a moment, after the call
<diddledan> zyga, I take it from that the fix doesn't work? I'm understanding how CI testing works, right?
<zyga> diddledan: ?
<diddledan> :-p
<zyga> diddledan: hopefully not :)
<diddledan> fail test == fix works; passing test == shruggy shoulders no idea
<diddledan> maybe it works?
<mvo> zyga: \o/ thank you
<diddledan> #shipit!
<zyga> mvo: I pushed the test now
<zyga> that was a nice bug
<zyga> jdstrand: I'm looking after apparmor now
<zyga> mvo: have a look at 8462 again please
<zyga> maybe mborzecki as well
<zyga> I'll get rid of my plate, grab coffee and jump into apparmor and zfs
<mvo> zyga: sure, will do
<ijohnson> pedronis: I merged master into 8424, the only thing missing there are tests for lsblk.go and the reimplementation of lsblk with sysfs + udev, which probably means we need to rename the file or maybe move it to it's own package somewhere
<ijohnson> but all the logic in boot and cmd_initramfs_mounts should be there and that is tested and ready to review
<pedronis> ijohnson: so I should focus on cmd_initramfs_mounts ?  and a bit on boot , if I understand correctly
<ijohnson> pedronis: yes
<pedronis> ok, having a break and then I will look
<ijohnson> thanks
<pedronis> zyga: btw, I didn't says this in the standup but I definitely prefer our snap services' units to be after something we control (or well defined from systemd) than a 3rd package service, we can control the dep on that one in one place at least
<zyga> +1
<zyga> yeah, I strongly agree
<zyga> this is so much cleaner than vague dependency on apparmor in each of the service files we write
<pstolowski> mvo: the script ijohnson linked requires greasemonkey which works on pretty much every browser
<mborzecki> zyga: hah, so when a workflow is successful, there's no way to restart it
<mvo> pedronis: should I cherry pick 8459 (omit many snap-ids) for 2.44.3 too?
<mvo> pstolowski: nice!
<zyga> mborzecki: yeah :)
<zyga> mborzecki: I have some ideas on that though
<mborzecki> omg, close/reopen didn't trigger anything
<mborzecki> oh w8, it did
<zyga> really?
<zyga> oh
<zyga> odd
<zyga> there's a way to trigger on more
<zyga> anyway
<zyga> ENOTIME
<mup> PR snapd#8466 opened: tests: backport partition fixes to 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8466>
<pstolowski> oh, preseed-reset fix failed on 19.10
<pstolowski> cachio: did you update 20.04 images but not 19.10?
<cachio> pstolowski, I updated all of them
<cachio> pstolowski, https://travis-ci.org/github/snapcore/spread-cron/builds/672701787
<mvo> pstolowski: hm, 8465 failed in 19.10 in preseed-reset it seems, can you please have a look?
<mvo> pstolowski: it's strange as it seems like the only place where it fails
<pstolowski> mvo: yeah, i just noted this above
<mvo> pstolowski: aha, sorry
<pstolowski> mvo: i'm confused
<pstolowski> mvo: did our deb packaging change made it to all ubuntu versions?
<mvo> pstolowski: maybe not, the SRUs are notoriously slow :/
<mvo> pstolowski: https://paste.ubuntu.com/p/SzwVMqT9GX/
<pstolowski> mvo: yes, plus it needs to be on the image we download. oh well, i need to relax this test check then
<mvo> ok
<mvo> pstolowski: or just limit it to 20.04 for now?
<pstolowski> mvo: good idea
<cachio> pstolowski, do you need another update?
<pstolowski> cachio: no, not for now, afaiu we need to snapd deb 2.44 to make it through
<pstolowski> *to wait
<cachio> mvo, I found that the nested machine is locked because it reaches 100% of cpu
<cachio> and it has 1 cpu
<cachio> most of the cases is when snapd is installing or removing
<zyga> re
<zyga> am I online?
<pstolowski> zyga: no
<zyga> haha :)
<zyga> I managed to connect from my thinkpad
<cachio> mvo, I'll try some qemu configuration to avoide this
<jdstrand> zyga: fyi, I answered your question about offline and unknown in https://github.com/snapcore/snapd/pull/8462#discussion_r406269208
<zyga> thank you, looking
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<zyga> jdstrand: I'm wrapping up the fix for apparmor now
<jdstrand> zyga: but, then that got me thinking about: https://github.com/snapcore/snapd/pull/8462#discussion_r406270147
<zyga> jdstrand: hmmm
<jdstrand> zyga: these are not blockers imo
<zyga> jdstrand: maybe
<jdstrand> I have to step into a meeting
<zyga> I need to go AFK for 10 minutes now
<jdstrand> zyga: or maybe return nil (I mentioned that in a followup comment)
 * jdstrand fully attends meeting
<mborzecki> guys, i'm taking a day off tomorrow as well, ping me if there's anything urgent
<mvo> cachio: nice, thank you
<pedronis> ijohnson: I did a high-level pass on 8424,  let me know if you have questions
<pstolowski> mvo: ok, i pushed a fix. tested manually on 19.10 & 20.04, should work. fingers crossed
<mvo> pstolowski: cool, thank you
<ijohnson> thanks pedronis looking now
<zyga> I'm home now
<zyga> mvo: testing apparmor fix now
<zyga> it's so annoying we build depend on gcc-multilib
<zyga> it clashes with cross compiler stack I use
<mvo> zyga: thanks, looking forward to the PR
<mup> PR snapd#8403 closed: sandbox/cgroup: avoid making arrays we don't use <Skip spread> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8403>
<zyga> mvo: https://github.com/snapcore/snapd/pull/8462 is green, except for preseed-reset on ubuntu 20.04
<mup> PR #8462: cmd/snap: don't wait for system key when stopping <Security-High> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8462>
<zyga> mvo: shall I merge it?
<zyga> it's one patch
<mvo> zyga: yes, sounds good
<zyga> k
<mvo> zyga: I will cherry pick then
<zyga> mvo: release branch CI overflows 50minutes in travis
<zyga> mvo: actually, you must merge it
<zyga> required status check
<mvo> zyga: just noticed but I think it also hang in the preseed
<zyga> aha
<zyga> I didn't look deeper
<mvo> zyga: so hopefully once the preseed fix lnaded this is good again :)
<zyga> focusing on apparmor
<mvo> zyga: no worries
<zyga> hmm
<zyga> but
<zyga> ah ok
<mvo> zyga: yeah, looking forward to this fix
<mup> PR snapd#8462 closed: cmd/snap: don't wait for system key when stopping <Security-High> <â  Critical> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8462>
<zyga> thanks!
<mvo> zyga: I backed the system-key lxd fix to 2.44 (cc stgraber) - I still plan an upload tonight/in the morning
<mvo> zyga: *thank you*
<zyga> pleasure :)
<stgraber> excellent, thanks zyga and mvo
<zyga> stgraber: thank you for providing the perfect laboratory environment :)
<ijohnson> mborzecki: how did you manage to duplicate the number of tests on 8464 ? o_O
<ijohnson> > 37 successful and 3 failing checks
<mborzecki> ijohnson: clearly gh wanted to test that PR thoroughly
<ijohnson> it wanted to be double extra sure
<mborzecki> each +1 doubles the tests
<ijohnson> that would be kinda funny if gh just kept adding to the list, so if you have to restart tests like 4 times it would say "89 successful and 4 failing checks"
<mup> PR snapd#8467 opened: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Created by zyga> <https://github.com/snapcore/snapd/pull/8467>
<zyga> mvo, jdstrand: ^
<zyga> tested locally on my focal install
<zyga> with lxd and systemd-analyze
<zyga> I'll break for coffee and be back later (mvo: tg to summon me please)
<pstolowski> 8465 failed on google:ubuntu-20.04-64:tests/main/interfaces-timeserver-control
<alvesadrian> hello, there is something similar for after: on app: , I know after is only for parts but there is something like that in app:
<pstolowski> Failed to restart systemd-timesyncd.service: Unit systemd-timesyncd.service is masked.
<alvesadrian> I mean apps:
<zyga> pstolowski: check what masks that service
<alvesadrian> zyga, hello why after: is not accespted by snapcraft in apps: ?
<alvesadrian> zyga there is something like after: from parts: in apps:?
<zyga> I don't understand
<alvesadrian> $ snapcraft
<alvesadrian> Issues while validating snapcraft.yaml: The 'apps/ovs-vswitchd' property does not match the required schema: Additional properties are not allowed ('after' was unexpected)
<zyga> I still don't understand
<zyga> what do you mean after for parts?
<alvesadrian> zyga parts: accept after:
<alvesadrian> but it looks like u can use after: on apps:
<zyga> yes but the meaning is different
<zyga> what do you want to do?
<alvesadrian> service or command orders after this do this
<zyga> alvesadrian: https://snapcraft.io/docs/snap-format documents "after" for apps
<zyga> alvesadrian: which version of snapcraft are you using?
<alvesadrian> 2.44
<ijohnson> alvesadrian: are your apps meant to be services/daemons ?
<alvesadrian> ijohnson yes
<zyga> alvesadrian: are you building in docker?
<zyga> alvesadrian: snapcraft is at 3.11
<zyga> alvesadrian: that version surely supports this construct
<ijohnson> alvesadrian: you probably need to add `daemon: simple` or something to make sure your apps are daemons and not CLI/GUI "apps"
<zyga> alvesadrian: snapcraft or snapd?
<zyga> (I mean 2.44)
<alvesadrian> snapcraft
<ijohnson> alvesadrian: what's `snapcraft version` ?
<alvesadrian>  snapcraft version
<alvesadrian> snapcraft, version 2.43.1+18.4
<ijohnson> alvesadrian: you should install snapcraft via the snap not the debian package
<alvesadrian> bionic
<ijohnson> alvesadrian: `apt remove snapcraft && snap install snapcraft`
<jdstrand> is there a way with the new spread tests to re-run a specific job? it seems like twice now I only have 're-run all jobs'?
<jdstrand> I'm talking about the github interface
<zyga> jdstrand: not at present, ask mvo to override if this is a well-known failure that is fixed elsewhere
<zyga> jdstrand: we discussed github actions vs travis and while there are some shortcomings as compared to travis we decided to keep the experiment alive for now
<jdstrand> zyga: ok, so long as I'm not missing something. it seems that fedora is failing a lot.
<jdstrand> something about reboot iirc
<zyga> jdstrand: it's more that a specific test is failing,
<jdstrand> I'll keep an eye on it
<zyga> jdstrand: aha
<zyga> thanks, maybe it's something new
<zyga> there are a few fixes in flight that should get rid of most of those
<zyga> jdstrand: on the upside actions lets us really run those tests as soon as possible, much faster than travis offered
<jdstrand> zyga: it was a specific spread test related to core reboot *I *think*, don't jump on it now ;)
<zyga> I won't, my goal is to focus on your feedback for udev PR
<zyga> but I think tomorrow, today I just want to get the fixes ready
<jdstrand> zyga: I also commented on the apparmor pr
<jdstrand> (but only a comment at this point since you were still testing)
<zyga> I noticed, going through that now! :)
<Eighth_Doctor> popey: hey, I just noticed that the instructions for rhel are wrong: https://snapcraft.io/install/icq-im/rhel
<Eighth_Doctor> snapd has been available in EPEL 8 for a while now
<zyga> hey Eighth_Doctor :)
<zyga> good to see you again
<Eighth_Doctor> The CentOS instructions were updated, but apparently not the RHEL ones
<Eighth_Doctor> zyga: hello :D
<popey> hello Eighth_Doctor
<Eighth_Doctor> how are you surviving?
<zyga> Eighth_Doctor: with three kids at home
<popey> they're editable on the forum now, which makes life easier
<Eighth_Doctor> popey: hey
<zyga> Eighth_Doctor: and parents-in-law
<Eighth_Doctor> woo
<popey> oh, or are they, no they are not
<zyga> Eighth_Doctor: and overeager police that fines you for taking your dog out on a bike
<popey> not *those* ones
<zyga> Eighth_Doctor: splendind :)
<zyga> Eighth_Doctor: we are lucky I have a job
<jdstrand> zyga: I think I was wrong about suggesting ConditionPathExists: https://github.com/snapcore/snapd/pull/8467#discussion_r406351235
<mup> PR #8467: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8467>
<Eighth_Doctor> I'm lucky I still have a job
<Eighth_Doctor> living alone and not being able to meet people regularly has sucked
<zyga> jdstrand: ack
<popey> Eighth_Doctor is this correct? https://snapcraft.io/docs/installing-snap-on-red-hat
<Eighth_Doctor> popey: yes
<popey> oh look https://github.com/canonical-web-and-design/snapcraft.io/issues/2646
<popey> :D
<Eighth_Doctor> that's why I didn't notice for months :D
<popey> thanks for noticing now, anyway :D
<Eighth_Doctor> I only noticed today when somebody asked me about adding snapd for EPEL 8, which I distinctly remember doing this last year
<Eighth_Doctor> popey: no problem :)
<zyga> jdstrand: maybe we should not change the cache for the point release
<zyga> jdstrand: I'm happy to do this for +1
<zyga> not sure
<zyga> mvo: ^
<Eighth_Doctor> zyga: the loneliness and the fear of getting sick gets to me
<Eighth_Doctor> but I've been doing fine so far for the past month
<mvo> zyga: reading
<mvo> Eighth_Doctor: hey, great to hear that you are fine (but yeah, the loneliness part is depressing :(
<Eighth_Doctor> mvo: and my "community energy" is draining with nothing to refill it these days
<Eighth_Doctor> no SUSECON, no CentOS Dojo, no Red Hat Summit, etc.
 * mvo nods
<Eighth_Doctor> I'm just begging for Flock and oSC to not get canceled in the fall
<jdstrand> zyga: it is up to you
<jdstrand> zyga: your snapd-apparmor already assumes /var/cache/apparmor, so it is fine to just add /var/cache/apparmor to RequiresMountsFOr
<cachio> zyga, #8468
<mup> PR snapd#8468 opened: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
<mup> PR #8468: tests: adding option --no-install-recommends option also when install all the deps <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8468>
<cachio> pleas could you take a quick look?
<jdstrand> (ie, today, you aren't worrying about alternate locations and presumably not suffering bugs for it, so there is no need to change in the dot release)
<mvo> zyga: just to double check - the unit in 8467 does nothing if both are available? there will be no races or apparmor compiling the same profile in parallel or something (cc jdstrand)
<zyga> mvo: no because our service depends on the system service
<zyga> mvo: so in practice, if the system service loaded snapd profiles nothing new happens
<zyga> mvo: if it didn't we load the profiles
<zyga> mvo: *but* the new dependency from snap.foo.bar.service to snapd.apparmor.service means the boot race is over
<zyga> mvo: snapd.apparmor.service has After=apparmor.service, so they will be serialized
<mup> PR snapd#8469 opened: snap: do not use os.Environ() in 2.44 <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8469>
<zyga> mvo: I'll adjust the PR once to get the cache recommendation from jamie and remove the changelog
<zyga> mvo: ah, thanks for that
<zyga> I wasn't sure
<mvo> zyga: nice
<zyga> mvo: fix your PR please
<mvo> zyga: which one?
<zyga> https://github.com/snapcore/snapd/pull/8469#pullrequestreview-391010494
<mup> PR #8469: snap: do not use os.Environ() in 2.44 <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8469>
<zyga> =
<mvo> zyga: fixing now, sorry
<ijohnson> wow zyga you beat me to that by 10 seconds
<zyga> :D
 * zyga refrains from joking about stuff now
 * mvo hugs ijohnson and zyga - awesome team!
<ijohnson> :-)
<mup> PR snapcraft#3023 closed: pluginhandler: move attributes to PluginHandler <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3023>
 * mvo vanishes a bit while 2.44 builds are churning along
<jdstrand> mvo: today, apparmor is looking at /var/lib/snapd/apparmor/profiles. if you can do a focal upload of snapd that makes you control it, I can do a focal apparmor upload that undoes it. Also, the snap-apparmor service is After=apparmor so there is no race. running one after the other is 'ok' because the speed at which the parser will load the cache into the kernel is essentially as fast as it can read from
<jdstrand> the disk, unless it recompiles policy. the 2nd run will never recompile policy since it is After=apparmor
<zyga> we are *burning* through spread jobs today!
<jdstrand> mvo: we can consider an apparmor SRU to stop looking at /var/lib/snapd/apparmor/profiles at some future point if desired
<jdstrand> mvo: we would probably wait for a bigger SRU bug and piggyback on it though
<jdstrand> mvo: it would be good if you could ping me on when you are going to do a focal upload so I can do the apparmor one after
<ijohnson> zyga: indeed, it is pretty responsive, and I even made the cardinal mistake of pushing an open PR branch 3 times in 5 minutes :-P
<zyga> re
<zyga> ok, back to branches
<mvo> jdstrand: I will do a focal upload tonight or tomorrow with the .3 fixes
<zyga> jdstrand, mvo: can we decide on the cache directory
<zyga> shall I change it from /var/cache/apparmor?
<jdstrand> zyga: I agree to not change in this PR
<zyga> OK
<zyga> I'll adjust the RequiresMountsFor
<zyga> to add /var/cache/apparmor
<zyga> and nothing else
<jdstrand> yeah, just add /var/cache/apparmor to that
<zyga> is that ok? (I want to do only one push)
<zyga> OK
<jdstrand> zyga: actually
<zyga> yes?
<zyga> (I won't push for a few more minutes so I'm open to changes :)
<jdstrand> zyga: this will hit other releases of Ubuntu eventually. we should verify the cache locations of all of them
<jdstrand> zyga: otherwise snapd-apparmor will fail on those where the cache isn't in /var/cache/apparmor
<zyga> jdstrand: snapd.apparmor.service is a .deb only feature so we can correct anything we want at the time we choose to dput to the archive
<jdstrand> zyga: so, snapd hardcodes /var/cache/apparmor when compiling policy, no?
<zyga> jdstrand: having said that, you are right,
<zyga> jdstrand: can we use the location?
 * zyga checks
<zyga> yes
<jdstrand> zyga: I think that is accurate (though, yes, please check :). if so, I think the only question would be if a release doesn't have /var/cache/apparmor, then we create it in the deb packaging rather than have snapd create it
<zyga> we hard-code /var/cache/apparmor
<jdstrand> ok, good
<zyga> jdstrand: given that we use this location in 14.04 already I _think_ we are safe
<zyga> jdstrand: or are you saying we should mkdir the directory from the service to be safe?
<jdstrand> ok, then yes, don't change it cause like you said, deb only item and we can verify the other deb uploads
<jdstrand> zyga: no, for focal, that is the location that apparmor creates
<zyga> jdstrand: oh, one thing before I forget: "systemd-analyze security"
<zyga> I dind't know this before, perhaps it's new
<jdstrand> zyga: I can look at the packaging real quick for all the releases
<zyga> thank you
<zyga> mvo, jdstrand: I pushed the updates to https://github.com/snapcore/snapd/pull/8467
<mup> PR #8467: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8467>
<jdstrand> zyga: that is interesting. I wonder if it considers AppArmorProfile=.... today, it seems to primarily (understandably) care about its own nspawn/etc directives
<zyga> jdstrand: I didn't look at what it checks but it's true that systemd has grown considerable vocabulary of sandboxing features over the years
<mvo> zyga: ta
<zyga> jdstrand: I would say it rivals snapd in some ways so it's a nice selection
<zyga> Lucy has fever, oh buy
<zyga> boy*
<zyga> :/
<jdstrand> zyga: ok, the apparmor package creates /var/cache/apparmor all the way back to trusty
<zyga> good
<zyga> so we're good
<zyga> I think it's safe to keep this as-is for 2.44.3
<jdstrand> yeah. just normal QA
<zyga> we can do more in 2.45 without a time pressure
 * jdstrand nods
<zyga> we are at 25/32 workers so the changes should proces quickly
<zyga> but I anticipate a small queue for about an hour while we go through the stuff that will spawn stable and unstable tests
<zyga> mvo: I think we should aim for tomorrow morning
<zyga> mvo: unless you want to dput at ~ 22
<zyga> and I'll just get back to work to work on the feedback from jdstrand
<zyga> btw, jdstrand are you available tomorrow?
<jdstrand> zyga: I am working tomorrow, yes
<zyga> ok
<zyga> mvo: shall I stick around or are you OK for today?
<mvo> zyga: all good for today
<zyga> OK, signing off :)
 * zyga EODs
<mup> PR snapd#8465 closed: tests: update snap-preseed --reset logic to acommodate for 2.44 change <Simple ð> <â  Critical> <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8465>
<mup> PR snapd#8470 opened: tests: update snap-preseed --reset logic to acommodate for 2.44 change (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8470>
<mup> PR snapd#8466 closed: tests: backport partition fixes to 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8466>
<pstolowski> mvo: thanks for merging my test fix!
<pstolowski> mvo: and for the herry pick! huh, what are those all failures there
<pstolowski> ah, i see another PR
<mvo> pstolowski: yeah, some fallout from the divergence of 2.44 and master
<mvo> pstolowski: I will wait for the tests and do the release tomorrow, I think its getting a bit too late
<mup> PR snapcraft#3024 opened: tests: remove usage of FakeApt fixtures in lifecycle <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3024>
<mup> PR snapcraft#3025 opened: tests: move FakeApt fixtures into deb tests <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3025>
<mup> PR snapd#8469 closed: snap: do use os.Environ() in 2.44 <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8469>
<mup> PR snapd#8471 opened: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS (2.44) <Created by mvo5> <https://github.com/snapcore/snapd/pull/8471>
<mup> PR snapd#8470 closed: tests: update snap-preseed --reset logic to acommodate for 2.44 change (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8470>
<mup> PR snapd#8472 opened: tests: disable some problematic tests for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8472>
<mup> PR snapd#8467 closed: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8467>
<mup> PR snapcraft#3024 closed: tests: remove usage of FakeApt fixtures in lifecycle <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3024>
#snappy 2020-04-10
<mup> PR snapcraft#3025 closed: tests: move FakeApt fixtures into deb tests <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3025>
<zyga> o/
<mup> PR snapd#8471 closed: many: fix loading apparmor profiles on Ubuntu 20.04 with ZFS (2.44) <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8471>
<pstolowski> morning
<zyga> Hey PaweÅ :-)
<zyga> Maybe a slow day for a change
<pstolowski> zyga: hey! we will see, mvo had issues with finalizing 2.44 yesterday evening
<pstolowski> i hope to progress with nested vm test for early core config today
<zyga> pstolowski: what kind of issues?
<zyga> pstolowski: 2.44 backports not working?
<pstolowski> zyga: just tests afaiu, plus something slightly diverged and needed a small fix
<zyga> I see
<zyga> pstolowski: I see mvo mentioned that master is broken
<pstolowski> zyga: i don't know about that, maybe missed something
<zyga> it's in the standup doc, it seems to be that service that gets masked somehow
<zyga> so tests don't pass
<pstolowski> zyga: #8472 fixes it for 2.44
<mup> PR #8472: tests: disable some problematic tests for 2.44 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8472>
<pstolowski> (well, disables the test)
<pstolowski> so yes we need a fix for master
<pstolowski> i'll look at it
<pstolowski> tests/main/interfaces-time-control passed on 20.04 for me
<pstolowski> perhaps 20.04 was fixed since yesterday
<zyga> pstolowski: I suspect it's something earlier that breaks it
<zyga> re
<pstolowski> zyga: aah, i didn't think about it. running entire suite then
<mup> PR snapd#8473 opened: tests: when restoring chrony do not restart systemd-timesyncd <Test Robustness> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8473>
<zyga> MVO
<zyga> BEHAVE :)
<zyga> it's your day off
<zyga> pstolowski: ^
<pstolowski> +1
<mup> PR snapcraft#3026 opened: spread tests: add core20 and cleanup systems <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3026>
 * zyga is drained today
<zyga> echo ....
<pstolowski> ....
<zyga> ho ho ho
<pstolowski> i'm running entire suite from mvo's PR locally to check this ntp issue
<zyga> it's like we have a quarantine on the channel too
<zyga> :D
<zyga> thanks!
<zyga> thank you for chasing reliablilty
<pstolowski> zyga: so the test fails on test-snapd-timedate-control-consumer.timedatectl-timeserver set-ntp yes
<zyga> mmm
<zyga> yes
<pstolowski> zyga: but i'm dropped in the shell, and manually it works
<pstolowski> zyga: perhaps there is a race with ntp being synchronized?
<zyga> oh that's curious
<zyga> when it failed, how did it fail?
<zyga> what was the error message?
<pstolowski> sorry, not synchronized; i mean 'available' or some such
<pstolowski> + test-snapd-timedate-control-consumer.timedatectl-timeserver set-ntp yes
<pstolowski> Failed to set ntp: NTP not supported
<pstolowski> zyga: ^
<pstolowski> same command now works manually on that system
<zyga> r45d09i-o
<zyga> that was not my password :)
<zyga> just cleaning the keyboard
<zyga> pstolowski: not sure if that helps, I sometimes run a spread with -shell, instead of debug, and then play through the "execute" part interactively
<pstolowski> zyga: hmm we do check test-snapd-timedate-control-consumer.timedatectl-timeserver status before we carry on with the rest of the test
<pstolowski> but maybe it's still racy
<pstolowski> i'll try a retry around set
<zyga> ah
<pstolowski> ah, no, ignore me, i misunderstood it
<pstolowski> ok, still digging in ;)
<pstolowski> i think i have a tentative workaround, waiting for tests to finish. it involves retries in two places though and i'm unclear about the root cause
<zyga> mmm
<zyga> I was wondering if https://shop.3mdeb.com/product/tpm2/ is worth buying for desktops that don't have TPM support
<mup> PR snapcraft#3027 opened: static: mypy requires __init__.py <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3027>
<mup> PR snapd#8474 opened: [WIP] tests: retry timedatectl set ops <Created by stolowski> <https://github.com/snapcore/snapd/pull/8474>
<zyga> looking
<pstolowski> let's see how it goes across systems
<zyga> pstolowski: is the move of the first block relevant?
<zyga> I'm asking because there's a install of chrony that now now happens *after*
<zyga> ah
<zyga> that's the restore section
<zyga> ok, makes sense
<zyga> let's see how it works :)
<diddledan> looks like the mount namespace is failing to be set-up before running the install hook in this forum post: https://forum.snapcraft.io/t/sudo-snap-install-gimp-fails/16526/5
<zyga> it seems so
<zyga> diddledan: thanks for raising this, I replied
<diddledan> thank you :-)
 * diddledan huggle zyga
<diddledan> funny gif of the day to keep everyone smiling: https://i.redd.it/h9hr7wo8hxq41.gif
<pstolowski> zyga: yeah i think the order of restore was a bit weird/suspect
<zyga> mvo messaged me,
<zyga> there's a failure in pulseaudio test in the release branch
<zyga> he asked us to look
<zyga> do you know which test we have for pulse?
<pstolowski> interfaces-pulseaudio?
<zyga> let's try it
<zyga> running
<zyga> running SPREAD_DEBUG_EACH=0 spread -debug google:tests/main/{interfaces-pulseaudio,interfaces-audio-playback-record}
<ijohnson> morning zyga pstolowski
<zyga> hey ijohnson
<zyga> good morning
<pstolowski> hi!
<zyga> happy friday (indoors)
<ijohnson> indeed!
<ijohnson> is it just the 3 of us today then?
<zyga> I think so
<zyga> jdstrand: is around as well I think
<ijohnson> nice, SU?
<zyga> I'm looking into this failure by request from mvo https://www.irccloud.com/pastebin/H0N9IpA9/
<zyga> oh
 * diddledan waves
<diddledan> I'm lurking :-p
<roadmr> you lurker you
<diddledan> https://youtu.be/mFfQQYsamqM
<zyga> ijohnson: do you think sending a patch that moves a single test over to session tool is useful?
<zyga> ijohnson: I have a few of those that I could just send
<zyga> not sure that it helps for 2.44 though
<ijohnson> zyga: I think it is useful in general maybe, but I don't think we should do it for the release branch yet
<zyga> I was only thinking about master now
<ijohnson> sure for master yes I think we should try to use session-tool as much as possible
<zyga> ok, I'll send what I have then
<ijohnson> ack
<ijohnson> I've got the interfaces-audio-playback-record test running now off 2.44 branch to see if I can reproduce the failure
<zyga> same here
<zyga> ijohnson: I've sent a patch with tree tests
<zyga> https://github.com/snapcore/snapd/pull/8475
<mup> PR #8475: tests: port snap-session-agent-* to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8475>
<ijohnson> cool, I'll take a look in a little bit, gonna finish porting the interfaces-pulseaudio test changes to audio-playback-record first
<mup> PR snapd#8475 opened: tests: port snap-session-agent-* to session-tool <Created by zyga> <https://github.com/snapcore/snapd/pull/8475>
<zyga> thank you
<zyga> ijohnson: reproduced!
<ijohnson> nice
<ijohnson> logs?
<zyga> https://www.irccloud.com/pastebin/CXofm8kK/
<zyga> google:ubuntu-19.10-64 .../tests/main/interfaces-pulseaudio# ls -ld /run/user/12345/pulse/native
<zyga> srw-rw-rw- 1 test test 0 Apr 10 13:25 /run/user/12345/pulse/native
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<zyga> processes
<zyga> https://www.irccloud.com/pastebin/0oP0R6j2/
<zyga> journal
<zyga> https://paste.ubuntu.com/p/yYKS3Rv2JC/
<zyga> weird
<zyga> pulse doesn't start
<zyga> because it's running
<zyga> Apr 10 13:25:17 apr101317-837037 dbus-daemon[612]: Unknown username "pulse" in message bus configuration file
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<zyga> Apr 10 13:25:17 apr101317-837037 groupadd[19712]: group added to /etc/group: name=pulse, GID=125
<zyga> Apr 10 13:25:17 apr101317-837037 groupadd[19712]: group added to /etc/gshadow: name=pulse
<zyga> Apr 10 13:25:17 apr101317-837037 groupadd[19712]: new group: name=pulse, GID=125
<zyga> Apr 10 13:25:17 apr101317-837037 useradd[19716]: new user: name=pulse, UID=116, GID=125, home=/var/run/pulse, shell=/usr/sbin/nologin
<zyga> Apr 10 13:25:17 apr101317-837037 usermod[19722]: change user 'pulse' password
<zyga> are we installing pulse?
 * zyga checks the test
<ijohnson> oh
<ijohnson> zyga you are running interfaces-pulseaudio
<zyga> yes
<zyga> well, both but here this one failed
<ijohnson> hmm so that's failing again too ?
<ijohnson> hmm, well fwiw I just ran audio-playback-record via spread and it didn't fail for me
 * ijohnson tries again with interfaces-pulseaudio too
<ijohnson> also sorry I forgot is the failure we see on the release branch just 19.10, or is it 20.04 too?
<zyga> 19.10 often, 20.04 once - according to mvo
<ijohnson> ok
<zyga> interesting
<zyga> so we start pulse
<zyga> it gets pid 20042
<zyga> that pid is gone now btw
<zyga> then we wait for it to respond
<zyga> but then another pulse runs
<zyga> I'll look for the 20042 pid in the journal
<zyga> nothing
<zyga> ah, wait
<zyga> the pid is useless
<zyga> it's the pid of the shell :/
<zyga> actual pulse is 20080
<zyga> https://www.irccloud.com/pastebin/vFqZLjvh/
<zyga> ^ I was trying to run the failing command myself
<ijohnson> right so this matches what happened last time, in that the daemon seemed to be around but wouldn't respond to anything
<zyga> https://www.irccloud.com/pastebin/lUWR3zfO/
<zyga> pulseaudio log file
<zyga> E: [pulseaudio] socket-server.c: bind(): Address already in use
<zyga> because there's a socket
<zyga> that's there
<mup> PR snapd#8476 opened: secboot: add tpm support helpers <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8476>
<zyga> and it cannot get it
<zyga> :D
<zyga> google:ubuntu-19.10-64 .../tests/main/interfaces-pulseaudio# ls -ld //run/user/12345/pulse/native
<zyga> srw-rw-rw- 1 test test 0 Apr 10 13:25 //run/user/12345/pulse/native
<zyga> google:ubuntu-19.10-64 .../tests/main/interfaces-pulseaudio# date
<zyga> Fri Apr 10 13:43:48 UTC 2020
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<zyga> 2020-04-10 15:28:22 Debug output for google:ubuntu-19.10-64:tests/main/interfaces-pulseaudio :
<zyga> ah wait, that last timestamp is my local time
<ijohnson> zyga: so the socket is there, but nothing is holding on to it?
<zyga> yes
<zyga> and bind fails
<zyga> because it's there
<zyga> one sec
<zyga> let me correlate pulse startup timestamps
<zyga> with the date of that socket
<zyga> Apr 10 13:25:22 apr101317-837037 dbus-daemon[612]: [system] Activating via systemd: service name='org.freedesktop.RealtimeKit1' unit='rtkit-daemon.service' requested by ':1.89' (uid=12345 pid=20080 comm="pulseaudio --exit-idle-time=300 -n -F /home/test/p" label="unconfined")
<zyga> this is the only proof I have
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<zyga> pulse requests realtime scheduling on startup
<zyga> this is at 13:25:22
<zyga> the socket is ... roughly the same
<zyga> let's get more precise timestamp
<ijohnson> yay I reproduced it too on 19.10
<ijohnson> let's have a look
<zyga> srw-rw-rw- 1 test test 0 2020-04-10 13:25:21.799833281 +0000 native
<zyga> this is definitely younger
<zyga> but
<zyga> but only by a second
<zyga> I doubt it wasn't pulse who made it
<ijohnson> ah no actually I had an error in my test changes porting over, wrong variable name
 * ijohnson tries again
<zyga> I'm so inclined to port this to session tool and see if it fails
<zyga> also half of the prepare goes away with it
<ijohnson> true, I'd say give it a shot, I mean if it makes the test more reliable then it's got to be better than the current situation
<zyga> I cannot explain why socket bind failed
<zyga> let me read the man page
<zyga>        EADDRINUSE
<zyga>               The specified local address is already in use or the filesystem socket object already exists.
<zyga> so
<zyga> ijohnson: I'll start by not rewriting this
<zyga> but by adding an assert up top
<zyga> that that socket file is gone
<zyga> maybe it will fail early on that
<zyga> any other ideas
<zyga> to look in this session?
<ijohnson> zyga: so in your session right now you cannot use paplay ?
<zyga> correct
<zyga> I tried
<zyga> I get...
<ijohnson> zyga: can you try restarting pulseaudio the way the test does ?
<zyga> https://www.irccloud.com/pastebin/UcKlvZqR/
<zyga> as in?
<zyga> kill the current process
<zyga> and start it the way it was started?
<ijohnson> yes pulseaudio --kill or something like that
<zyga> ok
<ijohnson> then do
<ijohnson> as_user "pulseaudio --exit-idle-time=300 -n -F /home/test/pulse-test.pa --log-level=4 --verbose 2>&1 | tee $PA_TEST_LOG >/dev/null" &
<zyga> (some of the variables are not defined in the debug shell)
<zyga> so it's not as easy
<zyga> one moment
<ijohnson> ah yeah right
<pstolowski> doh, my fix for timeserver failed after all :(. "Failed to restart systemd-timesyncd.service: Unit systemd-timesyncd.service is masked."
<zyga> google:ubuntu-19.10-64 /run# su -l -c "HOME=/home/test XDG_RUNTIME_DIR=/run/user/12345 pulseaudio --exit-idle-time=300 -n -F /home/test/pulse-test.pa --log-level=4 --verbose 2>&1 | tee $PA_TEST_LOG >/dev/null" test
<zyga> pstolowski: check the maintainer script of chrony
<zyga> pstolowski: it must be doing that
<zyga> ijohnson: weird, I think the shell is stuck now?
<ijohnson> hmmm
<zyga> ok, managed to kill that
<zyga> https://www.irccloud.com/pastebin/V0D8IOLf/
<zyga> paplay failed again
<ijohnson> hmm is the pid file for pulseaudio there?
<pstolowski> zyga: hmm indeed, it;s restore section that failed because of this
<ijohnson> zyga: it's like in /run/pulse dir I think
<zyga> I killed pulse, let me try again
<zyga> weird
<zyga> killing pulse yanked *all* of /run/user/12345
<zyga> it's empty
<zyga> restarted pulse, again socket already in use
<ijohnson> mmm
<zyga> the pid file is correct
<zyga> https://www.irccloud.com/pastebin/WdaDZDVw/
<zyga> that's weird
<zyga> look at this
<zyga> srw-rw-rw- 1 test test   0 Apr 10 14:01 native
<mup> PR #10: Update README.md <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/10>
<zyga> I'm sure the permissions were 600 before
<zyga> nah, they were the same
<zyga> so...
<zyga> is it connected
<zyga> I'll check if that socket is really open
<ijohnson> there is a pulseaudio running
<ijohnson> and there is a socket
<ijohnson> clients try to connect to that socket
<ijohnson> and then pulseaudio just refuses
<zyga> https://www.irccloud.com/pastebin/rI9Th6Dn/
<zyga> I don't know how to correlate the fd 9 there to the socket on disk
<zyga> any ideas?
<ijohnson> mmm lsof ?
<zyga> empty
<zyga> as in
<zyga> lsof of tthe "native" socket is empty
<zyga> nobody has that open
<zyga> I'll try stracing pulse
<ijohnson> well the test passed for me again so I'm just gonna keep running it
<zyga> https://paste.ubuntu.com/p/4wSSB2mBcV/
<zyga> it immediately died though
<zyga> this one worked
<zyga> https://paste.ubuntu.com/p/HjsnJgqy9x/
<zyga> 21195 bind(14, {sa_family=AF_UNIX, sun_path="/run/user/12345/pulse/native"}, 30) = -1 EADDRINUSE (Address already in use)
<zyga> HUH
<zyga> are on disk unix sockets like TCP sockets
<pstolowski> zyga: ok, reproduced outside of our tests by switching between systemd-timesyncd and chrony packages and restarting
<ijohnson> wait, what do you mean when you say this one worked ?
<zyga> ijohnson: this one is still running
<zyga> ijohnson: the previous run (identical) failed quickly and quit
<zyga> look at the end of each strace
<ijohnson> ah, can you get another shell to try playing ?
 * ijohnson looks
<zyga> no, same shell
<zyga> in both cases I ran this command:
<zyga> su -l -c "HOME=/home/test XDG_RUNTIME_DIR=/run/user/12345 strace -f -o /tmp/pulse.strace pulseaudio --exit-idle-time=300 -n -F /home/test/pulse-test.pa --log-level=4 --verbose 2>&1 | tee $PA_TEST_LOG >/dev/null" test  &
<zyga> the one that failed didn't get to bind
<zyga> in the second log something weird happens
<zyga> pulse makes a socket (fd 14)
<ijohnson> hmm it's unclear why the strace that failed immediately didn't get to bind
<zyga> and then connects!
<zyga> 21195 connect(14, {sa_family=AF_UNIX, sun_path="/run/user/12345/pulse/native"}, 110) = 0
<zyga> which works
<zyga> so it closes the socket (14)
<zyga> makes a new socket (well also 14 now)
<zyga> and then binds
<zyga> which fails
 * zyga reads unix(7)
<roadmr> ð±
<zyga> so
<zyga> I think I know
<zyga> well
<zyga> maybe :)
<zyga> one sec
<zyga> yeah
<zyga> hehehe
<zyga> ijohnson: do you want to know what the problem is :DDD
<ijohnson> .........
<ijohnson> what happens if I say no
<ijohnson> :-D
<roadmr> I WANT TO KNOW
<zyga> ijohnson: I just go out, get hit by a bus
<ijohnson> okay fine, I can't live with myself denying roadmr the conclusion to this suspense
<roadmr> thanks ð
<ijohnson> <3
<zyga> heh
<zyga> ok
<zyga> so the bug is really in the test code
<zyga> we use su and shit to run as test
<zyga> and guess what
<zyga> systemd running in the user session starts pulseaudio.socket and .service
<zyga> and we race and lose
<zyga> it's really incorrect
<zyga> if we were using session tool
<zyga> we could really not start pulse at all
<zyga> because just starting session for the test user gives us one already
<zyga> without the race
<ijohnson> hahahahahahahahahahaha
<ijohnson> oh man
<zyga> the socket is there because systemd took it
<ijohnson> of course systemd is racing with us
<zyga> for socket activation
<roadmr> hehe ;)
<ijohnson> well in this case zyga let's just port the whole thing to use session-tool
<zyga> https://paste.ubuntu.com/p/3HCqGzXrv2/
<zyga> this is strace after masking pulseaudio.{session,socket} for the user
<zyga> systemctl --user --global mask pulseaudio.{session,socket}
<zyga> 21597 bind(14, {sa_family=AF_UNIX, sun_path="/run/user/12345/pulse/native"}, 30) = 0
<zyga> bind now worked
<zyga> paplay now worked
<zyga> https://www.irccloud.com/pastebin/QPrlRzPI/
<zyga> problem solved
<ijohnson> I guess if we didn't want to jump ship to session-tool for the release branch we could just mask pulseaudio at the start of the test
<zyga> can I get a cookie :D
<zyga> ijohnson: yes
<ijohnson> yes you can get all the cookies you want
<zyga> my thoughts exactly
<zyga> haha
<zyga> I'll prepare a patch
<ijohnson> you just need to get find them without leaving the house
<zyga> and we really need to burn user.sh with fire
<ijohnson> thanks zyga, good detective work
<zyga> and remove all the hacks
<zyga> it's working against us
<roadmr> zyga: ðª
<mup> PR snapcraft#3027 closed: static: mypy requires __init__.py <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3027>
<zyga> ijohnson: just two tests, right?
<zyga> I cannot grep any more
<ijohnson> zyga: just interfaces-pulseaudio and interfaces-audio-playback-record
<zyga> rm: cannot remove '/run/user/12345': Device or resource busy
<zyga> this is also related
<zyga> man this is a good day
<roadmr> \o/
<zyga> https://github.com/snapcore/snapd/pull/8477
<mup> PR #8477: tests: fix racy pulseaudio tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8477>
<mup> PR snapd#8477 opened: tests: fix racy pulseaudio tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8477>
<zyga> ijohnson: I'm happy I didn't port this test
<zyga> yes, porting it would have fix things but would we know why?
<mup> PR snapd#8472 closed: tests: disable some problematic tests for 2.44 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8472>
<ijohnson> very true
<ijohnson> but to be honest, do we really need to know all the reasons why all our user session tests are broken
<ijohnson> haha
<zyga> I rebased and force pushed as requested by mvo
<ijohnson> also in other news, I fixed the uboot script and have a booting uc20 on the pi \o/
<zyga> wooot!
<zyga> ijohnson: I plan to buy one more rpi4
<zyga> maybe next week you could show me how to get it working
<zyga> I'll break for lunch now :)
<ijohnson> sounds good
<mup> PR snapcraft#3028 opened: static: add codespell excludes for .direnv <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3028>
<zyga> pstolowski: so what about that ntp test?
<zyga> do we know what the problem is?
<pstolowski> zyga: i found another revelation :)
<pstolowski> testing atm
<zyga> super :)
<mup> PR snapd#8478 opened: tests: fix racy pulseaudio tests <Created by zyga> <https://github.com/snapcore/snapd/pull/8478>
<pstolowski> zyga: pushed 1 more change to ntp test
<zyga> pstolowski: looking
<ijohnson> zyga: approved
<zyga> ijohnson: thank you :)
<zyga> LOL
<zyga> pstolowski: nice
<zyga> pstolowski: that's the bug? :D
<zyga> how did we missit before
<pstolowski> zyga: i have *no idea* how did it work before. maybe packaging changed. i reproduced on my local box outside of tests. systemd one gets masked when chrony gets installed. but chrony doesn't even provide systemd-timesyncd, it provides chrony[d].service
<ijohnson> pstolowski: zyga which PR is the ntp test ?
<zyga> 8484
<zyga> pstolowski: I think it's sensible that chrony masks systemd feature it replaces
<zyga> so that's a good find
<zyga> please polish the PR, provide one patch and check if you can get a 2.44 version as well
<zyga> jdstrand: I think I won't do much today
<zyga> jdstrand: we're getting ready for my fathers-in-law 70th birthday
<zyga> jdstrand: and people look at me to EOW now
<zyga> jdstrand: I'll get through all your comments for Monday though
<zyga> jdstrand: I'll be off on Monday but if you are round, try looking at the two PRs then
<jdstrand> zyga: sounds good! there is a chance I'll be off monday
<zyga> that's great, I won't stres for Monday then
<zyga> just for Tuesday :)
<jdstrand> zyga: enjoy your long weeked :)
<zyga> ditto :)
<jdstrand> zyga: try not to stress for either ;)
<zyga> I feel happy anyway, this was a 2.44 firefighting day
<zyga> jdstrand: if you have a second over weekend
<zyga> can I interest you in libzt-doc in debian? :)
<zyga> I wrote some manual pages,
<zyga> lots of text
<zyga> if you want to see how I did, I'd be honored to get any feedback :)
<zyga> it's not work related at all so feel free to just stay indoors and read books :)
 * zyga needs to EOW now
<jdstrand> nice! :)
<jdstrand> take care
<zyga> cake is on the table
<zyga> see you next week everyone!
<zyga> I'll circle back to read PRs in the evening
<ijohnson> have a good weekend zyga
<cwayne> Wait I want cake
<roadmr> ð
<cmatsuoka> who said cake?
<cwayne> You did
<cmatsuoka> oh
<cmatsuoka> ok then, I thought it was someone else
 * cmatsuoka goes back to sleep
<roadmr> zzz :)
<mup> PR snapd#8477 closed: tests: fix racy pulseaudio tests (2.44) <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8477>
<mup> PR snapcraft#3028 closed: static: add codespell excludes for .direnv <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3028>
<mup> PR snapd#8479 opened: release: 2.44.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8479>
<mup> PR snapcraft#3026 closed: spread tests: add core20 and cleanup systems <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3026>
<mup> PR snapcraft#3029 opened: tests: speed up clean command unit tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3029>
<zyga> ijohnson: do you have a reproducer for https://bugs.launchpad.net/snapd/+bug/1871189 ?
<zyga> or should I go for the full snaps?
<mup> Bug #1871189: Snapd `cannot update snap namespace` when connecting / disconnecting interfaces <snapd:Triaged by zyga> <https://launchpad.net/bugs/1871189>
<mup> PR snapd#8480 opened: [WIP] tests: fix timeserver-control-test for 2.44 <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8480>
<pstolowski> zyga: there?
<zyga> sure
<pstolowski> zyga: my fix for ntp failed on pulseaudio on 19.10, everything else passed
<zyga> hahaha
<zyga> I guess we need mvo to merge all the fixes :)
<pstolowski> zyga: i just force pushed to clean the history, so re-running the tests
<zyga> pstolowski: can you force push 8484 with a description of what is broken and how you fixed it
<pstolowski> zyga: prepared 2.44 cherry-pick just in case
<zyga> or is that ready as-is?
<zyga> spread tests are churning
<zyga> I think we can only EOD and wait now :)
<pstolowski> zyga: dang, i think i lost mvo's original commit in the battle :/
<zyga> pstolowski: git reflog
<pstolowski> zyga: i'm too tired already
<zyga> you still have it
<zyga> can salvage
<pstolowski> zyga: yeah, it's one line, not a problem. but i was testing without it before
<pstolowski> anyway... eod
<pstolowski> see you, and happy easter!
<zyga> :)
<zyga> you too :)
<zyga> have a good evening and the rest of the weekend!
<pstolowski> likewise! bye
<mup> PR snapd#8478 closed: tests: fix racy pulseaudio tests <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8478>
<mup> PR snapcraft#3030 opened: [WIP] repo: drop _AptCache and add migrate to install_stage_packages() <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/3030>
<mup> PR snapcraft#3022 closed: plugins: introduce v2.PluginV2 and v2.NilPlugin <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/3022>
<mup> PR snapcraft#2966 closed: build providers: move to buildd images <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2966>
#snappy 2020-04-11
<Gargoyle> Mornin. o7
<Gargoyle> Whoever sets up the webserver/forums needs to properly configure hostnames for sending emails:- https://files.paulcourt.co.uk/randoms/snapcraft-mail.png
<mup> PR snapcraft#3031 opened: build_providers: pass through SNAPCRAFT_{BUILD,IMAGE}_INFO to container or VM <Created by jhenstridge> <https://github.com/snapcore/snapcraft/pull/3031>
<zyga> Gargoyle: I'll relay the message
<Gargoyle> Thanks, zyga.
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134, core18#144, core18#146, core18#148, core18#149
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134, core18#144, core18#146, core18#148, core18#149
<mup> PR snapcraft#3032 opened: plugins: introduce v2.MakePlugin with rebuilding <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/3032>
<mup> Bug #1872232 opened: Snaps that use LibGL fail on NVIDIA 440.64 <Snappy:New> <https://launchpad.net/bugs/1872232>
<mup> PR snapd#8481 opened: cmd/snap-update-ns: handle EBUSY when unlinking files <Created by zyga> <https://github.com/snapcore/snapd/pull/8481>
#snappy 2020-04-12
<the-mentor> hi zyga maybe you can help me with my issue
<the-mentor> https://forum.snapcraft.io/t/vulkan-is-broken-on-snaps-when-using-nvidia-proprietary-drivers/16378
<mup> Bug #1872232 changed: Snaps that use LibGL fail on NVIDIA 440.64 <snapd:New> <https://launchpad.net/bugs/1872232>
<the-mentor> mup i think your bug is related to mine
<the-mentor> seems like nvidia drivers and snapd are not playing nice
<mup> PR snapd#8482 opened: tests: rewrite timeserver-control test <Created by zyga> <https://github.com/snapcore/snapd/pull/8482>
