#snappy 2016-02-15
<pitti> elopio: where are you running this? --flavor autopkgtest is a custom flavor that only exists in scalingstack
<pitti> elopio: in principle that looks like a correct invocation, yes; add some -d after adt-run and ssh to see what happens
<fgimenez> good morning
<dholbach> good morning
<zyga> good morning :)
<didrocks> good morning dholbach, fgimenez and zyga!
<dholbach> salut didrocks
<fgimenez> hey hey didrocks, dholbach and zyga :)
<dholbach> hola fgimenez :)
<fgimenez> zyga, quick question for you (i guess), what is the minimum yaml for a snap to provide a skill, is this enough http://paste.ubuntu.com/15072870/ ?
<zyga> looking
<zyga> fgimenez: I think you can abbreviate that further to offsers: [bool-file]
 * zyga checks the spec
<zyga> type defaults to name
<zyga> unless changed explicitly
<zyga> fgimenez: are you building a snap that provides the bool file skill?
<fgimenez> zyga, i'm beginning with integration tests for skills, i'm using the branch you pointed out last friday as a base
<fgimenez> yep, thanks already looked at that, but was having problems after building the snap, let me try again and paste you the results
<zyga> nice
<zyga> fgimenez: sure, let's work together on this
<fgimenez> zyga, great :)
<clobrano> hello everybody, I assume that it's possible to install different version of the same snap, but I'm getting an error like this "failed to install: a package by that name is already installed". I'm installing a snap file in my filesystem, it's version is 0.7, while the version installed is 0.6. Any Idea? Thanks!
<fgimenez> zyga, ok for the provider, the problems are with the consumer, probably uses: [bool-file] doesn't work there? http://paste.ubuntu.com/15072941/
<zyga> fgimenez: hmm, yes, it seems that snappy-side parsing is not correct yet
<zyga> fgimenez: note that we haven't enabled bool-file (or any other non-migration skill) -- we are trying to do that since last week but we need to do it in the state engine desing and that's not trivial
<zyga> fgimenez: so even if all my branches today would land, you would still not be able to use bool file in practice
<fgimenez> zyga, ok np, i'll try to keep an eye on the development and update the tests accordingly, bool-file is the first skill type that is going to be available, right?
<zyga> yes
<fgimenez> zyga, ok thanks, could we write something about the migration-skill or is this going to go away shortly?
<fgimenez> zyga, write some integration tests i mean :)
<zyga> fgimenez: I think not shortly
<zyga> fgimenez: but that's not exercising anything new (though the test will stay valid)
<zyga> fgimenez: migration skill is not using the skills system yet
<zyga> fgimenez: I think a lot will become clearer this week
<zyga> fgimenez: then we can plan which tests to invest in
<fgimenez> zyga, great thanks
<clobrano> uhm, I just read this https://developer.ubuntu.com/en/snappy/guides/packages-names/, at which Phase are we now? Is it already possible to install more version of the same snap? Thanks
 * zyga writes a small piglow demo
<ysionneau> asac: Hi! I just managed to get snappy boot correctly in qemu (with cloud-init working and therefore the ubuntu/ubuntu login working)
<ysionneau> I had indeed to merge a bit of kernel config + extract the initrd from the rpi2 snappy .img
<ysionneau> I still need to figure out why I don't have any network interface (apart from lo) :o
<zyga> ysionneau: out of curiosity, how do you run qemu?
<ysionneau> ./arm-softmmu/qemu-system-arm -M raspi2 -smp 4 -kernel ~/dev/kernel-rpi2/linux/arch/arm/boot/zImage -sd ~/Downloads/ubuntu-15.04-snappy-armhf-raspi2.img -append "rw earlyprintk loglevel=8 console=ttyAMA0,115200 dwc_otg.lpm_enable=0 root=/dev/mmcblk0p2" -dtb ~/dev/kernel-rpi2/linux/arch/arm/boot/dts/bcm2709-rpi-2-b.dtb -usbdevice mouse -usbdevice keyboard -net nic,model=smc91c111 -net user -nographic -redir :8090::80 -redir :8022::22 -initrd ~/initr
<ysionneau> something like that
<ysionneau> maybe I should extract snappy dtb and use that instead of my own vanilla dtb
<ysionneau> let's try that.
<ysionneau> Warning: requested NIC (anonymous, model unspecified) was not created (not supported by this machine?)
<ysionneau> hmmm I guess the raspi2 qemu port just does not support NIC
<ysionneau> :/
<ysionneau> what's weird is that even with a usb network device it does not work (-usbdevice net). The kernel detects the USB NIC, but no usb0 is created
<asac> ysionneau: nice!
<asac> ysionneau: is raspi2 in standard qemu?
<asac> ysionneau: have you tried with our default kernel etc.?
<ysionneau> 13:12 < asac> ysionneau: is raspi2 in standard qemu? < nop, I used this: https://github.com/0xabu/qemu
<ysionneau> 13:13 < asac> ysionneau: have you tried with our default kernel etc.? < hmm no, lemme try
<asac> ysionneau: right. so afaik the NIC is a USB nic on the raspi2
<asac> :)
<asac> so think you are on right track and just need to get the right kernel that supports the usb device you "plug in"
<ogra_> thats quite fiddly with qemu (bot doable)
<ogra_> *but
<ysionneau> hmm interesting, at least with the snappy kernel, I get an eth0 iface
<ysionneau> but I still get some errors and I don't have network
<ogra_> it has the driver builtin iirc
<ysionneau> http://paste.ubuntu.com/15073838/
<ogra_> you probably need some tun/tap device setup the VM attaches to
<ogra_> (i'm just widly guessing here though)
<ysionneau> in theory, in -net user mode, I should not need that, but let's try in bridge mode
<ysionneau> I often think of finding correct qemu args as black magic
<ysionneau> like ffmpeg cmdline
<ysionneau> when you find the correct line, you keep it preciously
<ogra_> hah
<asac> yeah i agree
<asac> qemu arguments to do what you want and still work together is like ffmpeg :)
<asac> but think you are close :_)
<ysionneau> hmmm cannot get an ip address
<ysionneau> I think the usb nic is buggy somehow
<ysionneau> either in qemu or in the linux kernel I use
<ysionneau> maybe I should rebase the qemu port onto qemu master
<asac> ysionneau: did you try our kernel?
<ysionneau> asac: yes, with your kernel it improves the situation a bit, I can get an eth0 iface
<ysionneau> but it is not usable
<Tomer> hi there, i'm trying to compile bluez5 for an RPi 2 running snappy core 15.04, but the generated snap package is for amd64, is it possible to compile for ARMv7?
<ogra_> yes, if you do it on an armv7 system
<ogra_> (i.e. on the rpi)
<Tomer> how do I install tools like git on the snappy core (apt-get not available...)? I'm a total noob regarding snappy core
<ysionneau> asac: hmmm you said I should not use arm64 version on 15.04 because it's not very well tested and not stable. What about having an arm64 kernel but using the arm32 15.04 system? Does this work?
<ysionneau> an arm64 kernel should be able to run an arm32 user space
<opny> ysionneau, asac I've spent a bit of time on snappy vs qemu too. On 15.04 eth0 never get an ip and cloud-init failed
<ysionneau> I'm asking because we have a drone on Tegra X1 (arm64)
<ogra_> well, in 16.04 there is the classic dimension, that gives you a full apt environment on demand for such stuff ... in 15.04 you can use a container (lxc or docker) or you can use a chroot
<ysionneau> and it would be cool for me to be able to test 15.04 on Tegra X1 board
<asac> ysionneau: interesting idea :)
<asac> ricmm: what do you think? guess could work to use a arm64 kernel and make it work with our 15.04 image
<asac> ?
<ysionneau> arm64 kernel + your arm32 images
<ysionneau> opny: which -M were you using? (which board were you emulating?)
<opny> ysionneau, vexpress-a9
<ogra_> asac, i think 15.04 is still a bit risky wrt arm64, i'D go straight to 16.04 for that
<asac> nah
<asac> ogra_: we are talkinga bout using 32-bit image
<ricmm> you can try armhf userland sure
<asac> with 64-bit kernel
<ogra_> (and actually use arm64 for the rootfs too)
<asac> no
<asac> its not ready enough :)
<ogra_> why not ?
<asac> not ready enough
<ogra_> nonsense :P
<ogra_> i'm just running it here ... rock solid :)
<ogra_> (and i compiled some quite heavy stuff on the weekend (webkit and qtwebkit) on it ... i have seen no issues)
<opny> ysionneau, I was trying to emulate armhf/ armv7 https://github.com/muka/qemu-snappy-experiments/blob/master/run-snappy.sh
<ysionneau> opny: have you tried with a usb NIC? maybe you will be luckier than me
<ysionneau> ogra_: I'm a bit lost, you are saying 15.04 is risky for arm64 (kernel ? or user space?) and then afterward you say it's rock solid? Maybe I misunderstood something
<ogra_> ysionneau, i'm not sure how ready 15.04 is ... we just added arm64 to 16.04 though, this is what i'm using here and it is rock solid
<ysionneau> ah ok arm64 with 16.04 is rock solid, got it
<ogra_> (15.04 will be droped when 16.04 goes stable so all dev focus is on 16.04 currently)
<zyga> ogra_: hey
<ysionneau> but, what about having the arm32 userland on 15.04 but with an arm64 kernel?
<ysionneau> should be "ok", right?
<ogra_> technically, yes
<ogra_> practically i have no experience with that :)
<ysionneau> only thing that bothers me with 16.04 is 1Â°) it's not released yet 2Â°) it's not much documented like 15.04
<ogra_> yeah, and constantly moving
<ysionneau> 15.04 dev/support will be dropped as soon as 16.04 is released?
<ysionneau> meaning all the ubuntu website documentation will turn into 16.04 compatible tutorials?
<ogra_> (its a bit of a pain to make snaps if your floor changes underneath you all the time ... but the worst changes should have landed by now)
<ogra_> yeah
<ysionneau> if the snappy release cycle is like normal ubuntu, 16.04 release is pretty soon :o
<ysionneau> but I would have finished my evaluation long before the release anyway
<ogra_> well, snappy is a rolling release, so they are not really synced up (156.04 will see fixes and changes after release for sure) ... but the stable channel will switch to it by 16.04 release or shortly after
<ogra_> s/156.04/16.04/
<ysionneau> hmmm doesn't rolling release mean there is "no" release?
<ysionneau> like a 15.04 will become automatically a 16.04?
<ogra_> it isnt that easy since the image design changed in an incompatible way
<ogra_> so you have to re-flash for 16.04 ...
<ysionneau> ok
<ogra_> (there is no easy way to migrate to the new partitioning for example)
<ysionneau> right got it
<elopio> fgimenez: do you know why I can't ssh into an scalingstack ubuntu-server instance created from jenkins?
<fgimenez> elopio, mm no idea, are you adding the user's keypair in the create command?
<elopio> fgimenez: there is one keypair for RegionOne in the slaves. I'm passing it's name to the create command.
<fgimenez> elopio, and then you try to ssh from a canonistack instance passing as -i the private key, right?
<dpm> davidcalle, dholbach, popey mentions that on the getting started snappy page the rpi2 image link is out of date - could perhaps one you update it to the 16.04 image? Either popey or ogra should have the right link
<ogra_> dpm, no
<ogra_> dpm, 16.-04 isnt released, we only point to stable images
<ogra_> (the links will be updated once we release 16.04 as stable)
<elopio> fgimenez: where is the private key of the RegionOne keypair?
<ogra_> we could perhaps link to dev images additionally, once we actually have the all-snaps one coming from the build system
<ogra_> but thats still a bit away
<fgimenez> elopio, i think it must be in the tarmac server, let me check
<ogra_> (the only "proper" 16.04 image is atm the one that mvo builds by hand ... nothing we should promote yet)
<fgimenez> elopio, yes, there it is, ~/credentials/scalingstack/ues-snappy-integration_RegionOne.key
<elopio> fgimenez: yes, I tried with that one.
<elopio> no luck.
<fgimenez> elopio, no idea, the snappy instances used in the tests doesn't use this keypair, anyway you can always create a new one
<elopio> fgimenez: should I create a new keypair as part of the deploy?
<fgimenez> elopio, sure that way it won't need any secret management, if the deploy and the keypair have short live it's a good solution. if the deployed instances are expected to last longer maybe you could use an existing keypair
<opny> Hi, in a snap (xenial) I've used printenv to have  a clue of avail vars but I'm a bit confused now ..  $SNAP is where the executable is. What is the difference of $SNAP_APP_DATA_PATH and $SNAP_USER_DATA ?
<opny> http://paste.ubuntu.com/15075093/
<ogra_> opny, there used to be a wikipage but i cant find it anymore
<opny> ok thanks
<ogra_> the USER stuff is all for actual executables a user can manually run though
<ogra_> SNAP_APP_DATA_PATH is just the writable area of the snap ... used by services etc
<opny> Do you think there is a sane way to have like a `ln -s` at build time paths that are hardcoded in the app runninig in a snap?
<ogra_> i would do that from a startup wrapper
<opny> ogra_, oh that's right.. I have a read call like /run/resolvconf/resolv.conf I cannot see a way to solve that..
<opny> or read from  something like /proc/2368/net/ipv6_route (read)
<ogra_> opny, yeah, i dubt confinement will allow you
<ogra_> probably tyhicks or jdstrand have some hint if/how thats possible
<opny> ogra_, I've noticed. Shouldn't the app see the fs as root (/) ?
<ogra_> nope
<ogra_> it sees its real path ... but cant access anything outside
<olli_> hey
<olli_> morning
<opny> ouch, so bad...
<opny> and let's add either a  "only a single skill is supported, 2 found"
<opny> to the soup
 * ogra_ isnt much familiar with skills yet ... i had just started to understand caps ... then they were replaced :)
<opny> ogra_, well being aware that I am not alone is a good start :)
<opny> ogra_, *IRC101* how do you do that chat reflection thingy?
<ogra_> "chat reflection thingy"?
<opny> * ogra_ isnt much familiar with skills yet ..
<ogra_> /me isnt much familiar ....
 * opny is learning IRC
<ogra_> :)
<opny> that's has been a productive day
<opny> :)
<zyga> opny: skills are not live yet
<zyga> opny: except for migration-skill
<opny> zyga, oh that's good
<opny> zyga, thanks, do you know if they will be avail ? (I found them in snapcraft json/yaml schema)
<ysionneau> when using arm64 kernel with rpi2 (arm32) image it boots but I get cloud-init issues (url_helper.py) when not using any initrd.
<ysionneau> if I use the initrd from the rpi2 snappy img I get this : http://paste.ubuntu.com/15075934/
<ysionneau> boot freezes at this point
<ogra_> you *need* to use the initrd, else you wont get the proper mount farm ...
<ysionneau> that's what I understood
<ysionneau> ah, if I wait long enough I get some timeout and it told me it's a rootfs name issue ("could not find fe02 root partition")
<ysionneau> I'll try other names
<ogra_> Kernel command line: rw earlyprintk loglevel=8 console=ttyAMA0,115200 root=fe02
<ogra_> this cant work at all
<ogra_> u-boot has a huge scriptery that assembles an actual cmdline
<ogra_> try mimicing one from a booted system instead
<ogra_> (i.e. boot snappy once and copy the cmdline into your qemu call)
<ogra_> since you are not using uboot
<wigleworm> I used the java "hello-world" example in snapcraft and the resulting snap was 130MB - is that correct?
<wigleworm> why so large
<ogra_> because it includes hjava i'd guess :)
<ogra_> *java
<ysionneau> 17:12 < ogra_> try mimicing one from a booted system instead  < ok :)
<wigleworm> any clue where to look for a method to pair that down?
<ogra_> i dont think there is one ... apart from making java itself smaller or some such
<ogra_> if you want your snap to run java bits the jvm needs to be shipped along
<wigleworm> also, from the example I could not see where the script was pulling JAVA from - anyone know?
<wigleworm> ogra - thank you
<ogra_> that would be a quaesion for the snapcraft guys ... but sergiuens isnt arund and i dont know if kyrofa is familiar with the java bits
<ogra_> you should be able to dig though the snapcraft plugin code though ...
<wigleworm> is there another channel for snapcraft or is this it?
<wigleworm> irc channel that is
<ogra_> this is it ...
<ogra_> there is a sprint at the US westcoast that many are attending, so catching people from the team might be hard this week
<wigleworm> -orga_- thank you, I will dig into the snapcraft docs
<fgimenez> elopio, i'm getting lots of errors like this http://paste.ubuntu.com/15076159/, can you please try to reproduce when you have time?
<elopio> fgimenez: sure.
<fgimenez> elopio, the image used by jenkins was built a few weeks ago and we still don't have the automation in place with the new sources, maybe something has changed somewhere that make the new one fail, if you confirm the error i can manually trigger the build to make it visible in the PRs
<fgimenez> elopio, we can also put the build job in cron mode and create a new image every day, the cleanup jobs are working now
<elopio> fgimenez: I updated my snappy image and I can install hello world.
<elopio> it's using ubuntu-core 2016-02-12.
<ogra_> crazy stuff !
<elopio> fgimenez: ah, the error is running it.
<elopio> fgimenez: yes, confirmed. Pleaes report the bug.
<ogra_> elopio, did you guys already start testing with all-snap images ?
<fgimenez> elopio, sure, i'll fire up also a new image build
<ogra_> or are you wating til they come from the official build system
<elopio> ogra_: jenkins is testing the pull requests with all-snaps.
<ogra_> cool !
<elopio> fgimenez: also confirmed that it doesn't happen with ubuntu-core from 2016-02-03
<ysionneau> with root=/dev/vda2 now it boots, and cloud-init works (I also added a few parameters from a /proc/cmdline of a live snappy system=
<ysionneau> and I also have a network iface ... "sit0" but it only gets ipv6 address upon dhcp :o
<ogra_> ysionneau, still wrong
<ogra_> ysionneau, root=/dev/disk/by-label/writable net.ifnames=0 init=/lib/systemd/systemd ro panic=-1 fixrtc
<ogra_> thats the least you want in the kernel cmdline ...
<elopio> wigleworm: it is installing the default-jdk package from the archive.
<ysionneau> yes I've put the panic=-1 and init stuff
<ysionneau> I'll try with the remaining parts
<ysionneau> are you sure I'm supposed to boot on the writable rootfs ? :o seems weird
<ysionneau> others seem to boot from the system-a or system-b fs
<ogra_> ysionneau, you want the init= and the root=
<ogra_> panic and fixrtc arent that important
<ysionneau> if I do root=/dev/disk/by-label/system-a it works way better than writable
<ogra_> lol
<ogra_> yeah, sorry
<ogra_> i'm running the all-snaps image ... you indeed want system-a on older images
<ogra_> sorry
<ogra_> (in all-snaps system-a is actually a loop device living in /writable which is why thats the rootfs device)
<fgimenez> elopio, the new image is uploaded and it's already showing the error http://162.213.35.179:8080/job/snappy-daily-rolling-openstack/103/console
<elopio> fgimenez: great. I set the bug priority as critical.
<wigleworm> elopio: :) I wish I knew - do you know how I find out?
<elopio> wigleworm: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/jdk.py#L24
<fgimenez> elopio, thx, i'll prepare the changes for reacting to modifications in the snaps from the store and build the images accordingly, hopefully it won't take too long
<elopio> fgimenez: have you decided on a name for the images?
 * ogra_ votes for "fred"
<ogra_> (unless they are female indeed)
<fgimenez> elopio, i think that your idea of the timestamps is great, we can sort and select them without modifying the existing tools, -tests-job and -cloud-image
<elopio> elsa for female.
<ogra_> +1
<elopio> fgimenez: but then the -1 trick wouldn't work. Because it won't necessarily be ubuntu-core -1. It could be kernel -1.
<wigleworm> elopio: from the file that you linked me to, I am guessing it is installing whatevere I have installed - is that correct
<elopio> I think we need to modify the tools.
<ogra_> wigleworm, it is running "apt-get install default-jdk"
<ogra_> inmside the snapcraft dir
<elopio> wigleworm: https://github.com/ubuntu-core/snapcraft/blob/master/docs/snapcraft-parts.md
<ogra_> ogra@styx:~$ apt-cache show default-jdk|grep Depends
<ogra_> Depends: default-jre (= 2:1.7-52), openjdk-7-jdk (>= 7~u3-2.1.1)
<ogra_> (thats what i get on 15.10)
<elopio> take a look at stage-packages in that link.
<wigleworm> ok, I see default-jdk :) - understand that
<wigleworm> where does default-jdk get defined - i.e. is it set to 1.7.x. or 1.8.x?
<fgimenez> elopio, ok, i'll submit a PR and we can discuss there, the alternative could be 3 separate padded version numbers of our own, so that we can sort and compare
<ogra_> wigleworm, in the ubuntu archive
<elopio> fgimenez: maybe we extend snappy-cloud-client to receive optional versions for the three snaps. If there's no image, it will create one and upload it to glance.
<elopio> fgimenez: then we don't care about the name, we'll just use whatever ip it returns.
<wigleworm> ogra_ - thanks, can you point me in the direction of the ubuntu archive or tell what I am searching for exaclty?
<ogra_> wigleworm, like the gcc package depends on a specific gcc-$version package ... it is selected during a release
<fgimenez> elopio, but how do we know if we have available an image for the requested versions, if the versions are not stored in the name? and it can be ugly, only ubuntu-core's version looks like 2016-02-12 16.04.0-14... well, we can discuss in the PR
<ogra_> wigleworm, just run "apt-cache show default-jdk|grep Depends" on your machine and it will tell you which open jdk version it would install
<wigleworm> so is it looking at the dev system and saying "which version is the default java?" and then down loading that version?
<wigleworm> ok, so basically the default jdk for the development system that was used to create the snap
<ogra_> yeah
<elopio> fgimenez: yes, I mean that the name will only be important for the tool that returns the ip, not for the jobs. But of course we need a way to identify the versions in the image. It's late for you, let's talk later.
<wigleworm> ok, thank you
<fgimenez> elopio, ok nice evening everyone o/
<longsleep> hey folks it has been a while since i had time to work with snappy, to get up to speed is there a vagrant box to get a 16.04 snappy running quickly?
<elopio> longsleep: we are finishing the details of the new all-snaps images for 16.04. In the meantime you can get images from https://people.canonical.com/~mvo/all-snaps/
<longsleep> elopio: great thanks
<ogra_> elopio, not sure thats suitable for vagrant without converting it though
<ogra_> there are currenly no all-snap cloud images afaik
<longsleep> well i can upgrade my odroidc stuff but i guess i have to learn some new stuff first then
<longsleep> so i would need something which runs in kvm or virtualbox
<ogra_> the amd64 one runs fine in kvm
<longsleep> ogra_: ah ok great - i will use that one for now then - thanks!
<ogra_> but iirc vagrant needs a special image format you need to convert to
<longsleep> no problem - i can boot a plain disk image
<ogra_> longsleep, good to have you back btw :)
<longsleep> ogra_: yeah - i am still very busy and not much snappy time unfortunately :/
<ogra_> sad ... but busy means you guys are getting forward, thats good :)
<wigleworm> ok, new issue with java-hello-world. I installed the snap and ran it - error - no java found. Then I did some searchs on the system and I found that java is on the system, under the snap I just install but it seems like my program (snap) does not know where to look. Should I be setting a "path" somewhere in the hello sample or somewhere else?
<ogra_> dont you need JAVA_HOME in java ?
<ogra_> or some such
<ogra_> the wrapper script that runs the app should set this to your snap dir
<ogra_> (or respectively to the path underneath the snap dir actually)
<longsleep> ogra_: amd64-all-snap.img.xz booted just fine thanks!
<ogra_> awesome
<longsleep> some grub migration service failed, thats normal?
<ogra_> longsleep, sudo snappy enable-classic; snappy shell classic
<ogra_> thats one of the new awesome things ;)
<ogra_> longsleep, yeah, we need to look into that
<ogra_> should be harmless though
<longsleep> yeah i follow the maillinglist - will try that for sure
<longsleep> ogra_: no more snappy search?
<ogra_> snap find
<longsleep> cool thanks
<ogra_> (but snapy install ..., yay consistency)
<longsleep> well - once you know it :)
<longsleep> ogra_: ok, maybe last question for today - how do i sideload a snap quickly now?
<ogra_> same as before
<longsleep> mhm getting some wild error
<longsleep> /tmp/spreed-webrtc_0.24.10-1_amd64.snap failed to install: can not open /tmp/spreed-webrtc_0.24.10-1_amd64.snap: cannot open snap: unknown header: "!<arch>\ndebian-binar"
<ogra_> suo snappy install --allow-unauthenticated /peth/to/snap
<ogra_> yeah ... it should rather say "unsupported snap version"
<longsleep> ah
<ogra_> 16.04 requires squashfs snaps without the click package legacy (which is dpkg based)
<longsleep> good, i guess then i have something to work on for tomorrow
<longsleep> i assume snapcraft has the gear to build those snaps?
 * ogra_ looks forward to 16.04 release ... all that "floor moves underneath you all the time" is really painful 
<ogra_> yeah
<ogra_> you need xenial though
<ogra_> (a chroot or what not)
<longsleep> ok, xenial vagrant already somewhere?
<ogra_> dunno ... you mean normal server ?
<longsleep> yes to run snapcraft
<ogra_> there surely is ... but dont ask me where :)
<longsleep> guess i can use those https://cloud-images.ubuntu.com/xenial/
<ogra_> yeah
 * zyga hacks on i2c skills
<elopio> kyrofa: are you here today?
<zyga> ogra_: hey, still around? would you mind telling me where the gadget snaps live (sources?)
<wigleworm> back again looking for java and snapcraft help
<wigleworm> I have now twice used the example code
<wigleworm> and both times snapcraft completes and creates a snap (java-hello-word exaple)
<wigleworm> install the snap and run the wrapper <-- I think thats what I am suposed to do
<wigleworm> I get "./wrapper: 2: ./wrapper: java: not found
<wigleworm> Comments on what I should do to debug this would be welcome
<barty> hi! just a fast question. I've discovered today snappy and installed it in a RPI2. I'm from Spain and I'm unable to change the default keyboard layout to spanish. I've search a lot over the web and found nothing. Anyone there know how to do it?
<wigleworm> barty: are you familiar with desktop ubuntu "dpkg" program?
<wigleworm> more than likely you can use that and install the "consol-common" deb pkg on the system - you will need to make sure that you get the dependencies that are needed though
<barty> ok :)
<barty> I thought there will be a command already installed like locale-get or something
<barty> thank you very much!!!!
<wigleworm> @bar(input):button2
<nothal> wigleworm: No such command!
<wigleworm> huh?
<wigleworm> nothal: are you saying dpkg wont work?
<wigleworm> I just used it the other day
<barty> I'm using dpkg right now. I think nothal says no such command like locale-gen
<longsleep> bug #1458866
<ubottu> bug 1458866 in Snappy "hangs in uboot boot prompt if dtbs dir is missing" [Critical,Triaged] https://launchpad.net/bugs/1458866
#snappy 2016-02-16
<wigleworm> anyone online
<elopio> wigleworm: more or less. About to leave
<elopio> pitti: I think I found my problem. I'm creating a keypair for scalingstack, and then I need to pass the private key to ssh -i. But the nova script tries to connect to ssh without specifying the private key, so it times out.
<elopio> I have solved it for now putting the private key in ~/.ssh/config.
<elopio> now I need tons of squid exceptions, but it's running the whole suite.
<pitti> elopio: right, you need to upload your ssh key to nova with keypair-create
<pitti> elopio: if you only have one key in "nova keypair-list", then the setup script will use that, otherwise you have to add a --keyname option to chose the one you want
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks
<fgimenez> good morning
<ysionneau> any idea why I'm not able to ping anything from snappy? name resolution works, and I was able to snappy install nethack-armhf.ogra so network seems approximately ok
<ysionneau> is there some telnet client that I can install?
<didrocks> ogra_: hey! stupid question, but how is the grub.cfg taken from the gadget snap in 16.04? I don't see any bindmount or anything to it
<longsleep> Hey snappy, so what is the best strategy to convert a snap for 15.04 to one for 16.04?
<JamesTait> Good morning all; happy Tuesday, and happy Innovation Day! ð
<popey> hELLO!
<popey> Do I need to jump through hoops to make wifi work on the Pi2 snappy images or will it "just work"?
<didrocks> popey: depends on the version :)
<didrocks> popey: which one are you trying?
<popey> the one from mvo's home
<popey> built 4/2/16
<didrocks> ok, so 16.04, you just need to create the wlan0 file then
<didrocks> uno momento
<didrocks> popey: http://www.marinus.nu/2015/02/enabling-wifi-on-snappy-ubuntu-core.html
<didrocks> popey: from "Create a config file for your wlan0 interface:
<didrocks> "
<didrocks> (ignore the above)
<didrocks> popey: I don't have a wifi module, so didn't test myself
<popey> hm, okay
 * popey plugs into ethernet for now (I assume that works OOTB)?
<didrocks> popey: yeah, it does
<didrocks> popey: I even share my laptop wifi connection through ethernet here
<popey> didrocks: on wired, does it do dhcp by default or do I need to plug a physical kb/screen in before I can use it?
<popey> (I don't see it listed on my dhcp server)
<didrocks> popey: it does dhcp client by default
<popey> hmmm
<didrocks> popey: tried rebooting (unsure it has hotplug support though, even if it's auto eth0)?
<popey> had to plug it into a telly and ifconfig to find out the ip
<popey> for some reason it's not showing up on my dhcp server, but it has an ip
<popey> most strange
<popey> ubuntu@localhost:~$
<popey> \o/
<didrocks> good! :)
<didrocks> (and phew, "just" have to blame your dhcp server :p)
<popey> this command requires root access. Please re-run using 'sudo'
<popey> that should have a capital letter at the start
<popey> #justsaying
<popey>  ð
<popey> ugh, all messages in errors.go are badly capitalised. My eyes!
<didrocks> popey: yeah, I was looking at the same. I'm unsure this is on purpose (like combining with "Error:") or something else
<popey> it can't be intentional, or if it is, it's inconsistent
<popey> "this command requires root access. Please re-run using 'sudo'" - "this" lowercase "t", "Please" uppercase "P".
<didrocks> well, you have a full stop in between
<didrocks> the consistency is in all sentences are starting in this file with no capital
<didrocks> like if they wanted to prepend "Error: {}"
<didrocks> so the result would be: "Error: this command requires root access. Please re-run using 'sudo'"
<didrocks> (which is consistent)
<popey> okay. still looks odd (and is inconsistent with other things like the kernel). I'll not worry about that  ð
<popey> :( failed in my first step in the guide. trying to "snappy install docker hello-world"
<popey> docker failed to install: can not open /tmp/docker963014042: cannot open snap: unknown header: "!<arch>\ndebian-binar"
<didrocks> popey: yeah, that's the current issue with 16.04â¦
<didrocks> popey: it's all moving right now, and the store isn't yet snap-all compatible (it shows you old snaps that are still ar-based)
<popey> ah, okay.
<popey> Living life on the edge :)
<ogra_> didrocks, i think u-d-f puts it in place
<didrocks> ogra_: ah, so it's a copy when generating the image, but what if you update the gadget snap thus?
<popey> What's the replacement for "snappy search"?
<ogra_> popey, snap find
<ogra_> didrocks, you have to ask mvo if he added cod to copy it then (i havent seen any)
<ogra_> *code
<popey> that's not listed in the --help :(
<popey> and snappy find doesn't work
<didrocks> popey: *snap*
<popey> oh, snap?
<didrocks> new snappy name from what I know
<ogra_> yeah, because we like to be intuitive ;)
<didrocks> even if I never saw anything written down
<popey> so snappy -> apt-get, snap -> click/pkcon?
<popey> kinda
<didrocks> no, I think snappy will move to snap, right?
<didrocks> and commands will transition one after another?
<didrocks> (ogra_ probably knows more than I here, I just saw this command being mentioned once)
<ogra_> i have no idea ... it might be documented in some google doc though
 * ogra_ also only picked it up from IRC conversations
<ogra_> i assume we want to put all operations you can do directly to a snap into that command ... though looking at the --help output "find" somehow doesnt fit there
<didrocks> zyga: you probably know more than us there then ^
<didrocks> zyga: snap vs snappy command (will they eventually merge into one?)
<popey> dholbach: https://developer.ubuntu.com/en/snappy/build-apps/get-started/ says i should install snappy-tools to get snapcraft, I had to manually install snapcraft itself, it wasn't pulled in by snappy-tools
<popey> dholbach: want me to file a bug?
<zyga> popey: hey
<zyga> er
<zyga> didrocks: hey :)
<zyga> didrocks: snap is the new version of snappy command
<zyga> didrocks: snap works over the REST api and talks to snapd
<zyga> didrocks: snappy is the old command that has everything inside
<zyga> didrocks: snappy will be removed before 16.04
<zyga> didrocks: and we'll just have one
<didrocks> I was right \o/
<didrocks> thanks for confirming zyga :)
<ogra_> ah, good to see a proper summary, thanks zyga
<zyga> ogra_: lots of things are in snap today
<zyga> ogra_: but daily builds are broken so we don't see that
<ogra_> ?
<ogra_> daily builds of what ?
<zyga> ogra_: and daily builds are broken because of launchpad git model choking on gpg signed git commits
<zyga> ogra_: of snappy itself
 * ogra_ didnt see any build failures
<zyga> ogra_: mvo found this yesterday or last week
<ogra_> oh, it fails before it even attempts to build ?
<zyga> ogra_: we have a backup plan to just do manual git pull github; git push launchpad
<zyga> ogra_: yes, the import is stuck now
<ogra_> ah, that explains why i see no failures :)
<zyga> ogra_: I'm sure we'll untangle this as the sprint develop
<ogra_> right
<popey> when's that?
<ogra_> this week
<zyga> popey: well, this week
<popey> heh
<zyga> popey: ask mvo for details
<popey> no need, just wondered :)
<zyga> popey: we could do a plan-B in 30 minutes or so
 * popey sets expectations accordingly :)
<zyga> popey: but I wanted to sync with mvo to see who's going to do that
 * ogra_ actually prefers outdated but working over landed but broken (and nobody there to fix it) state
<zyga> ogra_: daily is broken too :)
<zyga> ogra_: but differently, no executable seems to run today
<ogra_> i can use it here
<zyga> ogra_: as in real master, not the outdated build from lp
<ogra_> right, so just leave LP as is until everyone is back ;)
<zyga> ogra_: do you have any updates on dragon kernel/gadget?
<ogra_> zyga, done, i just need to roll an image and push it up
<zyga> ogra_: nice, I can offer simple testing on my board to iron our works-for-me issues :)
<ogra_> it doesnt resize yet, and systemd spills a few rfkill messages on boot ... the rest should be all fixed
<ogra_> (i ripped resize out completely for now so it doesnt break on big SD cards anymore)
<ogra_> sudo ./ubuntu-device-flash --verbose core rolling --channel edge -o dragon-all-snap-test.img --gadget canonical-dragon.canonical --kernel canonical-dragon-linux --os ubuntu-core.canonical
<zyga> ogra_: yeah I've seen those
<zyga> ogra_: oh that a nice touch, thanks
<ogra_> (with mvo's u-d-f binary)
<zyga> ogra_: so essentially, ubuntu-image dragon :-)
 * zyga rebuilds
<zyga> ogra_: building now, I'll let you know when it boot
<ogra_> good
<zyga> flashing
<zyga> I should write the flash tool
<zyga> all I want is a freeling progress bar
<zyga> ogra_: for the first time I can also measure power usage of my dragon board, if you ever want to experiment with some tweaks to the kernel, I can give that a go
<ogra_> zyga, there is godd, that has a progressbar
<zyga> oh, thanks, I'll give it a try next
 * ogra_ doesnt want no shitty progressbar ... i just want it to flash 10x as fast instead :P
<zyga> ogra_: booting now
<zyga> ogra_: flash over usb3.0
<zyga> ogra_: on a speedy card
<ogra_> i do ... still takes ages
<davmor2> ogra_: b.....b....but without progress bars you wouldn't have a break to go make coffee
<ogra_> davmor2, true indeed :)
<zyga> ogra_: boot done
<zyga> ogra_: is the mac address stable now?
<ogra_> yep
<zyga> ogra_: perfect, let's update my mac tables
<zyga> ogra_: wifi operates too
<ogra_> i still need to make the code a bit more generic, but the function is fine
<zyga> ogra_: so +1 from me, works like a charm
 * zyga posted https://github.com/ubuntu-core/snappy/pull/490 and https://github.com/ubuntu-core/snappy/pull/489
<popey> Is there any prospect of snapcraft 2.x being backported to trusty?
<popey> the ppa still has snapcraft 1.x
<ogra_> no, 2.x is solely for xenial
<ogra_> use a xenial chroot, container or use the classic dimension on your xenial snappy install
<popey> thats what i am doing
<popey> but my laptop is 14.04
<popey> so i have a difference between them
<ogra_> between the chroots ?
<popey> will create a xenial chroot on my laptop, ta
<ogra_> ah
<popey> no, between 14.04 on my laptop and xenial on my pi
<ogra_> yeah
<popey> nvm, it's cool :)
<ogra_> well, there is no cross building ... so after all you want to use the classic dimension on your pi to get armhf packages
<popey> yeah, i was building on my laptop then copied the yaml over to the pi in classic and found the syntax differed
<popey> of both the yaml and snapcraft itself
<popey> which is what made me look at the versions
<popey> woot, made a snap
<ogra_> yay
<ogra_> ooooh !
 * ogra_ found his next snap 
<ogra_> https://github.com/coolwanglu/BrowserHack
<ogra_> (i already packaged nethack, but this is even cooler)
<popey> bah, can't find some perl libs
<ogra_> add them to stage-packages
<popey> is it a comma separated list? stage-packages: [foo,bar,baz] ?
<ogra_> http://paste.ubuntu.com/15090658/
<ogra_> thats a snapcraft 2.1 file though ... the security stuff is different now
<popey> ok
 * popey will play
<kyrofa> Good morning
 * zyga finds classic dimension fantastic and uses it for daily work
 * ogra_ misses it on arm64 :P
<didrocks> hey kyrofa!
<kyrofa> Hey didrocks, how's your week so far?
<didrocks> kyrofa: it's quite good, thanks! Working on the developer website, but can't wait to be able to dive into the more technical aspect of snappy once 16.04 settles down :)
<didrocks> (and be able to work more closely with you guys)
<kyrofa> didrocks, awesome! Well we look forward to that, too :)
<kyrofa> didrocks, how many times have you looked at a Snappy question on, say, stack overflow, become completely confused, only to realize that it's Google's snappy compression lib?
<noizer> Hi the system variable for the snaps path?
<didrocks> kyrofa: ah, that didn't happen yet (sorry, was on a meeting) :p
<didrocks> kyrofa: for me, it was more snappy ubuntu core vs ubuntu core ;)
<didrocks> (like our old named ubuntu core)
<kyrofa> didrocks, ah, right
<kyrofa> didrocks, well, keep an eye out if your subscriptions span more than askubuntu
<didrocks> kyrofa: will do, even just for the sake of fun :p
<kyrofa> didrocks, :D
<dholbach> popey, I'll file a bug
<ogra_> kyrofa, pfft ... compression lib ....
<ogra_> ogra@styx:~/Devel/mycroft$ apt-cache show snappy|grep Description
<ogra_> Description-en: Powerful media player with a minimalistic interface
<ogra_> :P
<kyrofa> ogra_, wait... :P
<ogra_> hmm, we dont ship hdparm in the rootfs ... i wonder if we should
<popey> dholbach: okay
<popey> hm, adding the perl-modules package to my stage-packages: has no effect, it doesn't get bundled into the snap
<ogra_> in a copy plugin ?
<popey> ah
<ogra_> (not sure how stage-packages behave in other plugins, i always ever used them in that context )
<popey> is the "files" section documented somewhere?
<ogra_> well, "source: destination"
<ogra_> (relative paths)
<popey> does it not assume same path
<popey> ?
<ogra_> only for the toplevel
<ogra_> aha, found the issue with rfkill .... systemd wants a dir /var/lib/systemd/rfkill and wants that writable
<ogra_> werid though, i thought we had added that to /etc/system-image/writable-paths before ... but seems we didnt
<zyga> ogra_: nice
<zyga> ogra_: that's going to fix rfkill for all systems, right?
<ogra_> well, it is going to quieten the systemd error .... not sure thats enough to fix the low level
<elopio> pitti: yes, I create the keypair and pass it with --keyname. The thing is that if the keypair I create doesn't have the same private key as the entry in ~/.ssh/config there's no way to tell nova which private key it should use.
<elopio> ogra_: happy birthday!!!!
<ogra_> elopio, thanks !
<popey> Oooh! Congratulations ogra_ for clinging to this rock for another solar orbit. Well done you!
<ogra_> haha, thansk :)
<ogra_> *thanks even
<pitti> hey ogra_, happy birthday! *hug*
<ogra_> thanks !
<kyrofa> Ah, happy birthday ogra_!
<ogra_> thanks !
<asac> ppisati: so i chatted to the linaro qemu guy
<asac> ppisati: he said we could try to build the u-boot as the bios image
<asac> to get a qemu that boots with u-boot
<asac> 15:48 < pm215> build it to expect to start at address 0 with the usual ARM interrupt/exception vector table
<asac> 15:48 < pm215> ie as if you were going to burn the thing into rom
<asac> ppisati: ^^ means anything?
<ogra_> sound like "dd it to the start of your img file"
<elopio> fgimenez: I might be 10 minutes late to our meeting. I'm running to get back on time. bbs.
<asac> ogra_: right, but guess thats not all
<asac> probably needs more tweaking of init values etc.?
<ogra_> depends
<ogra_> hmm ... i wonder if all-snaps supports me sideloading ubuntu-core on a running image (i.e. manual upgrade)
<ogra_> Installing ubuntu-core_16.04.0-4.arm64_arm64.snap
<ogra_> ubuntu-core_16.04.0-4.arm64_arm64.snap failed to install: package "ubuntu-core" is already installed with origin "canonical" your origin is "sideload"
<ogra_> ah, sad
<ogra_> would have been nice for testing
<ppisati> asac: never faffled with uboot internals, so i don't know
<ppisati> asac: qemu versatile / vexpress?
<fgimenez> elopio, ok, no problem
<asac> ppisati: he says we should use "virt" unless we have special requirements
<asac> not sure what virt means
<Dikkekip> hi there, i'm new to the whole docker infrastructure. but i'm looking for a way to make a docker webserver. but i see there are a lot off options out there. what is to be preferred?
<Dikkekip> coreos
<Dikkekip> vs ubuntu
<Dikkekip> kubernetes vs shipyard
<Dikkekip> who wins?
<ogra_> are you sure you are in the right channel ?
<Dikkekip> nope
<ogra_> :)
<Dikkekip> but i'm asking the guys who use ubuntu
<ogra_> sounds like you want to be in #cloud-battle :)
<davmor2> ogra_: man it seem like only yesterday you were a year younger, Congrats and Happy Birthday dude :)
<ogra_> davmor2, thanks a lot dude !
<asac> pitti: so i see a huge number of .service files in /lib/systemd/system/
<asac> are all those run ?
<didrocks> asac: you need to look at the *.requires/ or *.wants/ ones
<asac> didrocks: so in /lib/systemd/system is the superset of all you can use
<didrocks> asac: right!
<asac> and then in .wants and requires is the actual stuff linked?
<asac> like mods-available and -enabled for apache?
<asac> kk
<didrocks> systems ones that you can't disable are in /lib/systemd/system/*.{wants,requires}
<didrocks> the ones you are enabling/disabling manually are in /etc/systemd/system/
<didrocks> (and you can also creates services there)
<asac> yeah. so i guess we could remove all those that we dont want/require on a snappy system from /lib/system/  and noone would notice?
<didrocks> ofc, you have the socket activated ones in addition to this (and timer, but we don't use them much)
<asac> e.g. cruft?
<didrocks> asac: yeah, if they are enabled on a system level (in /lib) and we want to mask them, we can symlink with the same file name to /dev/null
<didrocks> (again, same with path/socket/timer activation)
<asac> i am not sure
<asac> i thought everythign not .wants or .requires is not used at all
<asac> from /lib/systemd/system/
<asac> can we not remove all of those then?
<didrocks> normal services not in .wants or .requires are not activated the regular way (and will never be activated normally)
<didrocks> unless a socket/path/timer activates them
<didrocks> asac: if you have docker install, look at /lib/systemd/system/docker.socket
<didrocks> you see PartOf=docker.service
<didrocks> so docker.service can be activated by the docker.socket
<didrocks> and /etc/systemd/system/sockets.target.wants/ has a link to docker.socket
<didrocks> (so the socket service is activated via the sockets.target, which in turn, can activate docker.service when it receives something in the socket)
<didrocks> on*
<asac> didrocks: do socket activated services get killed if the socket client closes or dies?
<didrocks> asac: with PartOf= yeah
<didrocks> (it's double linked IIRC)
<didrocks> but the service should exit after a timeout anyway
<didrocks> it's the upstream recommendation
<didrocks> some like docker doesn't do it IIRC though)
<asac> didrocks: so systemd passes you the socket fd on startup rigth? i read it can also pass you many sockets at the same time
<asac> how do you know which is for what purpose?
<didrocks> asac: libsystemd pass an array, let me check back
<didrocks> asac: yep: http://0pointer.de/blog/projects/socket-activation.html
<didrocks> n = sd_listen_fds(0);
<didrocks> so you get the number of fds (generally 1)
<asac> right i read that doc
<asac> and it tells it can pass you multiple
<asac> but cant figure how someone might then guess which socket is what
<asac> so think > 1 is just not working
<asac> like in the exampleL:
<asac>         fprintf(stderr, "Too many file descriptors received.\n");
<didrocks> well, it's just because he expected one, what is blocking you?
<asac> wonder why it even tries to pass multiple ones... i think there must be some determinism defined what goes to which array bucket
<asac> i just try to understand that feature :)
<asac> because the doc says youy can get multiple ones
<asac> but it doesnt tell me how to ensrue that i alway sget the FD i want at position 9
<didrocks> so, what happens, imagine a service which can take multiple sockets as input/output
<didrocks> oh, it does
<didrocks> fd = SD_LISTEN_FDS_START + 8
<didrocks> for instance :)
<didrocks> to get position 9
<didrocks> I'm unsure the name of the socket is determinist though, you just get a fd
<didrocks> so between 2 boots, it may changes as being in position 0 or position 5, or position 8 (if you have 9 of them)
<asac> i know i can just ask for socket 8
<asac> but i cant see how that socket 8 will always be the socket i expect it to be
<asac> like i can imagine client A talks to socket 1 and client B talks to socket 2 ... how does systemd ensure that its not suddenly the other way around?
<didrocks> I think it's part of the protocol rather
<asac> guess some annotations that can be looked up
<asac> would help
<didrocks> like announcing their name
<asac> part of the protocol?
<didrocks> the protocol you set between your client and services
<asac> ok so you say all need to be of same protocol?
<didrocks> service*
<didrocks> at least in the first bytes
<didrocks> (that's just a guess)
<asac> ok so restriction is that all sockets are on same port for INET and hence have the same server
<didrocks> asac: TBH, for systemd-fskd, I just use one socket
<asac> that makes more sense
<didrocks> then this socket is getting client connection request
<asac> right. i see
<didrocks> and depending on this, I create more connections :)
<asac> its for being able to buffer if multiple requests come in
<asac> not to enable activation through different protocols
<didrocks> so all clients use the same socket to initiate a request
<asac> yeah
<didrocks> then, their are connected through their own sockets that have been given back
<didrocks> (by the service)
<asac> didrocks: and you said that once all sockets are closed the service gets killed by systemd?
<didrocks> no, sorry, I was unclear, it's when the .socket systemd service is stopped (manually)
<didrocks> thanks to PartOf=
<asac> ah
<asac> so there is no deactivation
<didrocks> I implemented a service timeout when having 0 connection
<didrocks> and that's what is recommended
<asac> i guess socket activated services wont get restarted thouygh until there is a client again?
<asac> e.g. its the servers responsibilty to just die if all clients are gone
<asac> and if a new cient comes systemd will activate again?
<didrocks> exactly, another client connexion to the socket reactive the service
<didrocks> right
<didrocks> (and this is working well)
<didrocks> also, the service status is correctly reflected
<asac> what is the service status if i exit a process that got socket activated?
<didrocks> depending on the exit return code
<didrocks> so, basically 0, if you don't set to restart it in the .service file, you are considered as being oneshot
<asac> didrocks: does systemd have an API you can use to create nbew services etc. or is the interface "put a unit file there and run reload" ?
<didrocks> and so, everything is good
<didrocks> asac: yeah, you need to run systemctl daemon-reload
<asac> ok so no api
<didrocks> that way systemd is aware of the new unit files
<didrocks> well, systemctl is using systemd API
<didrocks> so, there is one
<didrocks> unsure how stable it is though
<asac> right. nothing anyone ever said would be something for use not through CLI
 * didrocks needs to run to the bank
<didrocks> yeah
<didrocks> see you tomorrow guys :)
<asac> thansk for giving me inducation didrocks :)
<didrocks> yw asac ;)
<kyrofa> elopio, excellent fix on the catkin thing-- I know exactly what the issue is
<kyrofa> elopio, and I'm sad I didn't catch it in review, I'm sorry :(
<elopio> kyrofa: well, nobody of us caught it. Tell me more...
<kyrofa> elopio, so initially the env() function set the PYTHONPATH explicitly using the in-snap python version, and then added more items to it via ROS's setup.sh. However, in the recent refactor for the python version globbing, that explicit set line was moved AFTER the ROS setup.sh call, which wiped out the ROS environment :P
<kyrofa> elopio, I have no idea how this ever passed. And indeed, I see the failure now on my dev machine. Really odd
<kyrofa> elopio, anyway, so your change keeps the ROS environment, which makes it work
<kyrofa> elopio, I suspect now that my working tree wasn't up to date
<elopio> kyrofa: is there a nicer way to solve it?
<kyrofa> elopio, no I think your solution is perfect
<elopio> lucky shot.
<kyrofa> elopio, all skill ;)
<elopio> ah, yeah, that too ;)
<elopio> kyrofa: hey, the problem with this autopkgtest job in jenkins is that it will take like an hour to run.
<elopio> do you think that's too much?
<kyrofa> elopio, per PR?
<elopio> yes.
<kyrofa> elopio, that's certainly long, and I can see it being frustrating if we really want to crank something out, but can we honestly say that ensuring quality takes too much time?
<pcoca> Hi everyone, Is there any way to deploy snaps to many devices at the same time? (with snappy remote or other tool) or needs to be done with the store?
<elopio> kyrofa: we can make the rule to wait for it only on the changelog PR. Ignore it for other pull requests we want to merge faster.
<elopio> and I think I can run the integration and the examples tests in parallel, somehow. I'll look into it.
<sergiusens> pcoca, snappy remote with a "store" name should just work
<pcoca> sergiusens, then all the devices pointing at that store will get the snap?
<sergiusens> pcoca, real features for multi deploys will come with landscape integrating with the rest api
<sergiusens> pcoca, yes to your question
<pcoca> sergiusens, thanks! :)
<kyrofa> elopio, honestly most PRs sit for an hour or so anyway, I'm fine with it. sergiusens may have an opinion (morning sergiusens!)
<sergiusens> morning
<sergiusens> I don't mind PRs taking an hour
<sergiusens> but do we have to use the main upstream or will it work in our forks?
<kyrofa> sergiusens, good question
<kyrofa> Oh elopio, I accepted your PR but I suppose the ROS test should have been enabled in debian/tests/exampletests
<elopio> kyrofa: maybe. Let me first confirm it runs in jenkins.
<elopio> we are still missing some squid rules
<kyrofa> elopio, alright
<jerryG> ogra: can you answer a question about coredumps ?
<kyrofa> jerryG, were you ever able to enable them?
<ogra_> jerryG, not sure, try it :)
<kyrofa> jerryG, https://github.com/ubuntu-core/snapcraft/blob/master/docs/debug.md if you haven't seen it
<jerryG> kyrofa: ogra_: I'm having trouble getting coredumps to work.... it's creating folders... but it's not creating any coredump files
<jerryG> kyrofa: thanks. that's what I was using as a guide
<ogra_> jerryG, well, we dont do anything special despite using the kernel defaults ... perhaps you need to tweak something
<kyrofa> jerryG, I just did it the other day doing that (though using "snaps" instead of "apps" for all-snaps)
<jerryG> kyrofa: so /home/ubuntu/snaps ?
<ogra_> there is also nothing in userspace that should touch the defaults either
<kyrofa> jerryG, indeed. Were you using apps?
<kyrofa> jerryG, that's a bug in the documentation
<jerryG> kyrofa: ok thanks.  ill try that
<zyga> kyrofa: hey, have you seen pad.lv/1545786 by any chance?
<kyrofa> (carry-over from 15.04)
<zyga> kyrofa: elopio tells me you touched the launcher lately
<zyga> kyrofa: I'm trying to see what's causing that error to happen
<kyrofa> zyga, no I haven't, thanks for the heads up!
<zyga> kyrofa: I'm running raspberry pi with latest snappy master spliced into an image I built yesterday
<zyga> kyrofa: nothing I install runs
<zyga> kyrofa: I cannot find any matches on the error message so far
<kyrofa> zyga, is the user data directory owned by root or anything?
<kyrofa> zyga, it's an errno
<zyga> kyrofa: which directory is that? I did see root owned directories in /var/lib/snap
<zyga> kyrofa: older (prebuilt) were root:ubuntu
<zyga> kyrofa: post-install changed were root:root
<zyga> kyrofa: chgrp on that doens't help
<kyrofa> zyga, no, user data directory ($SNAP_USER_DATA)
<zyga> kyrofa: no, those are all ubuntu:ubuntu
<kyrofa> zyga, if you can walk me through how to get on edge I can look into this. I tried the other day but it seemed that channel-changing was broken
<zyga> kyrofa: (in fact, nothing in $HOME is owned by root)
<zyga> kyrofa: I built an image using my small tool: https://github.com/zyga/devtools
<zyga> kyrofa: https://github.com/zyga/devtools/blob/master/ubuntu-image
<zyga> kyrofa: essentially ubuntu-device-flash from mvo and some defaults for pi2
<kyrofa> zyga, alright, let me check it out :)
<zyga> kyrofa: cool, I'll try to strace the error in the meantime
 * zyga has a bunch of straces to look at
<zyga> kyrofa: got it:
<zyga> open("/", O_RDONLY|O_DIRECTORY|O_NOFOLLOW|O_CLOEXEC) = -1 EACCES (Permission denied)
<zyga> write(2, "failed to create user data direc"..., 36) = 36
<zyga> write(2, ". errmsg: Permission denied\n", 28) = 28
<zyga> kyrofa: that is ubuntu-core-launcher
<zyga> elopio: ^^
<kyrofa> zyga, huh... why would that be permission denied?
<zyga> jdstrand: ^^
<zyga> tyhicks: ^^
<zyga> no idea
<ogra_> / is readonly ...
<kyrofa> ogra_, it's not trying to write to it. It's trying to get the fd
 * ogra_ guesses thats just fallout 
<ogra_> oh
<zyga> ogra_: no, I don't think you'd get EACCES for O_RDONLY open on /
<ogra_> is it ?
<kyrofa> ogra_, it uses that fd with a series of openat/mkdirat calls
<jdstrand> zyga: read on '/' isn't allowed by the policy
<ogra_> and it doesnt use the actual path ?
<kyrofa> jdstrand, but it's done before the app is confined
<zyga> ogra_: I guess using openat means it has to get the fd for / first
<zyga> jdstrand, tyhicks: for context, we're trying to understand https://bugs.launchpad.net/snappy/+bug/1545786
<ubottu> Launchpad bug 1545786 in Snappy "error trying to execute snap binary" [Critical,Triaged]
<jdstrand> kyrofa: did '/' get wrong permissions? is the mount wrong?
<ogra_> it is readonly
<kyrofa> jdstrand, good question. zyga ?
<ogra_> since it is a squashfs
<jdstrand> 'failed to create user data directory. errmsg: Permission denied'
<ogra_> but that shouldnt get you a permission denied i guess
<jdstrand> 'user data directory'
<zyga> ubuntu@localhost:~$ mount | grep '/ '
<zyga> /dev/loop0 on / type squashfs (ro,relatime)
<zyga> is a loop-mounted squashfs from the os snap
<zyga> (well, it is the os snap)
<ogra_> right
<zyga> jdstrand: I straced that to ubuntu-core-launcher
<jdstrand> 'ubuntu@localhost:~$ hello-world.echo'
<jdstrand> zyga: yes
<jdstrand> it tries to create the user data directory
<jdstrand> as of recent commits (I guess they landed)
<zyga> jdstrand: hello-world.echo behaves the same way (just installed it and tried the command)
<jdstrand> tyhicks: might be able to provide some more insight on openat, but the security team is currently working on a critical update
<jdstrand> zyga: I get that. what I'm saying is that if run as a user, it is possible that $HOME/snaps is already there with root permissions. that is a different bug
<jdstrand> so checks the perms of that
<zyga> jdstrand: $HOME/snaps and inside has nothing owned by root (checked now)
<jdstrand> ok, good (it isn't that bug)
<zyga> jdstrand: everything is ug+rwX,o=rX
<jdstrand> zyga: I would guess it has something to do with the mount options
<zyga> jdstrand: mount optionon /writable or / ?
<zyga> *optioins
<zyga> *options
<jdstrand> I'm not sure
<jdstrand> are there apparmor denials in syslog?
<jdstrand> the launcher runs under its own profile. I wonder if it needs an update with the recent changes
<tyhicks> I can't think of what would cause that failed open()
<tyhicks> that is really odd
<jdstrand> zyga: grep DEN /var/log/syslog
<kyrofa> tyhicks, indeed
<tyhicks> ah, I guess it could be the ubuntu-core-launcher AppArmor profile blocking it
<zyga> http://pastebin.ubuntu.com/15094280/
<zyga> jdstrand: ^^
<jdstrand> ok, there you go
<tyhicks> yeah
<jdstrand> let me look at the rest of the profile and I'll commit something to the tree
<zyga> jdstrand: thanks, if there is something I can tweak in my image in the end to unblock on this that would help me a lot; if not I'll just wait for the bugfix to be available and if needed, update/rebuild the image
<kyrofa> jdstrand, tyhicks I'm sorry guys, I'm not sure how I didn't discover that in testing
<jdstrand> zyga: so, to work around this, you'll have to add '/ r,' to the profile
<zyga> jdstrand: I assume the new os snap is needed to fix this?
<zyga> jdstrand: ah, easy enough, I'll try
<jdstrand> zyga: well, you can't tweak in the image since it is read only, but we can test what is needed without that
<jdstrand> zyga: it is
<zyga> hmmm, right
<jdstrand> zyga: do this: cp /etc/apparmor.d/usr.bin.ubuntu-core-launcher /tmp
<jdstrand> zyga: then modify /tmp/usr.bin.ubuntu-core-launcher to have:
<jdstrand> r,
<jdstrand> err
<jdstrand>  / r,
<zyga> done
<jdstrand> then do:
<zyga> bind mount over?
<jdstrand> sudo apparmor_parser -r /tmp/usr.bin.ubuntu-core-launcher
<jdstrand> no don't worry about that
<zyga> ah
<zyga> right, this is in-kernel
<jdstrand> we can load the profile into the kernel from anywhere
<kyrofa> jdstrand, ah, and that profile is path-specific? If the launcher was run from elsewhere it wouldn't be applied?
<jdstrand> kyrofa: in the profile there is '/usr/bin/ubuntu-core-launcher ... {'
<kyrofa> jdstrand, argh, that was my testing gap
<jdstrand> kyrofa: that gives what we call binary attach
<jdstrand> kyrofa: I can actually test this here
<zyga> jdstrand: done, still same error, inspecting new set of strace logs
<jdstrand> zyga: if you'd like to go back to sprinting, I'll assign this to myself
<jdstrand> zyga: I suspect there are other similar accesses that are required
<jdstrand> so I can work through those
<zyga> openat(3, "home", O_RDONLY|O_DIRECTORY|O_NOFOLLOW|O_CLOEXEC) = -1 EACCES (Permission denied)
<jdstrand> yep
<zyga> it seems to need to go all the way down to $HOME/snaps
<jdstrand> I'll take it from here
 * jdstrand nods
<zyga> jdstrand: actually, I'm not sprinting (no remote sprinting this time)
<zyga> jdstrand: so I can focus on this issue to unblock myself from skill security work
<zyga> jdstrand: I'll make a coffee and be back soon,
<kyrofa> zyga, trying to use ubuntu-image for the pc I get "expected 3 partitons but found 0"
<jdstrand> zyga: to unblock yourself, in addition to '/ r,', add '/**/ r,'
<jdstrand> zyga: I'm going to do something more specific, but that should unblock you
<zyga> kyrofa: oh? weird, maybe you are affected by kpartx bug? (I assume that's at the very end when it builds the image)
<zyga> kyrofa: I'm running xenial daily and it works okay
<kyrofa> jdstrand, I suppose /, /home/ and /root
<zyga> jdstrand: perfect, thanks
<zyga> kyrofa: and $HOME/snaps too in the end
<jdstrand> kyrofa: yes, but I wanted to sprinkle some 'owner' matches in there too
 * zyga starts to grok all the security parts involved even if they are still complex
<kyrofa> jdstrand, ah right
<kyrofa> zyga, hmm... I'm on xenial, though I haven't updated for a while
<elopio> jdstrand: kyrofa: zyga: we are working on a process to release ubuntu-core to edge, and run the full suite there before moving it to other channels. That should find this type of errors earlier.
<kyrofa> elopio, very cool!
<jdstrand> elopio: sounds excellent :)
<zyga> great elopio
<zyga> jdstrand: the workaround works, thank you :)
<jdstrand> zyga: cool :)
<zyga> wooooot, my demo works :)
<zyga> very close to i2c through skills
<zyga> no longer running as root :D
<zyga> whee :D
<elopio> zyga: \o/
<sergiusens> utlemming, https://bugs.launchpad.net/cloud-init/+bug/1546230
<ubottu> Launchpad bug 1546230 in cloud-init "change the default to the nocloud data source" [Undecided,New]
<jdstrand> zyga: what are you testing this on? I don't seem to have any updates for my os snap in kvm
<kyrofa> jdstrand, edge
<jdstrand> zyga: hmm, I'm on core/rolling with ubuntu-core 16.04.0-11. how did you install 'edge'
<popey> If I am using snapcraft and want to wrap my executable thing in a shell script to add environment variables like setting PERL5LIB to SNAP_APP_DATA_PATH etc, how do I tell snapcraft to "install" my shell script?
<kyrofa> jdstrand:
<kyrofa> kyrofa> zyga, if you can walk me through how to get on edge I can look into this. I tried the other day but it seemed that channel-changing was broken
<kyrofa> <zyga> kyrofa: (in fact, nothing in $HOME is owned by root)
<kyrofa> <zyga> kyrofa: I built an image using my small tool: https://github.com/zyga/devtools
<kyrofa> <zyga> kyrofa: https://github.com/zyga/devtools/blob/master/ubuntu-image
<kyrofa> <zyga> kyrofa: essentially ubuntu-device-flash from mvo and some defaults for pi2
<zyga> jdstrand: using ^^
<zyga> jdstrand: it's magic
<zyga> nobody knows how to use ubuntu-device-flash :D
<kyrofa> popey, using the copy plugin
<popey> ah
<kyrofa> zyga, indeed! That tool got super confusing
<zyga> I'm sure we'll see real ubuntu-image sometime soon but before that happens, I've just do what I do
<zyga> done, well anyway
 * zyga sleepy
<kyrofa> zyga, seems my kpartx is up-to-date... so I don't know what's going on with my lack of image creation abilities
<jdstrand> zyga: well, there are so many different versions of udf :)
<ogra_> there is only one true one !
<ogra_> (the latest local binary on people.u.c from the person that implemented the last feature indeed !!!)
 * kyrofa hears ogra_ now: "The one that creates dragonboard images!"
<kyrofa> ogra_, hahaha
<zyga> jdstrand: yeah, I'm using the build mvo makes
<ogra_> :)
<zyga> kyrofa: hmm, if you want I can make an image for you
<zyga> kyrofa: but otherwise no idea
<kyrofa> zyga, it sounds like jdstrand is on it, but I may take you up on that offer next time I need to test something on edge if that's okay ;)
<kyrofa> zyga, hopefully the channel-switching bug will be fixed at some point as well
<jdstrand> I'm running ubuntu-image now. I'm expecting I'm fine
 * zyga wonders if the security team is busy with http://people.canonical.com/~ubuntu-security/cve/2015/CVE-2015-7547.html
<ubottu> ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2015-7547)
<jdstrand> its fun that the kernel snap is like 2/3 bigger than the os snap
<jdstrand> zyga: yes
<ogra_> jdstrand, all that firmware ...
<zyga> ah, man, security is hard work! thanks for working on this
<ogra_> kernel and modules alone would be smaller
<jdstrand> I'll say "you're welcome" on behalf of the security team (/me hasn't yet done his part for that update)
<jdstrand> zyga (and kyrofa): ok, have an edge image working. thanks
<kyrofa> jdstrand, ah, so it worked for you? /me pouts
<jdstrand> kyrofa: all I did was ./ubuntu-image
<jdstrand> then it asked me some stuff and out popped a pc.img that worked
<kyrofa> zyga, I'm running it in an lxc. Think that would break things?
<jdstrand> kyrofa: I've occasionally found that rebooting helps
<jdstrand> kyrofa: eg, if you've used udf a few times in a row, etc
<jdstrand> I think I opened a bug on that
<zyga> kyrofa: perhaps yes
<zyga> kyrofa: actually qemu is pretty nice
 * jdstrand did not run it under lxc
<zyga> kyrofa: just run xenial in qemu to build the image
<ogra_> yay
 * ogra_ has a working resize script for the dragonboard ... now i just need to pull that into the initrd
<ogra_> and since i'll have to touch the initrd package for that i'll make asac happy tomorrow and simply also add the code for a generic binary build :)
<ogra_> zyga, do you have random USB devices you could try on the dragonboard to see if they work (i tried the three USB ethernet adapters i have here but lack more stuff)
<ogra_> would be good to know they load their respective modules at least and dont throw errors in dmesg
<zyga> ogra_: yes, sure
<ogra_> thanks
<zyga> ogra_: trying now
<zyga> ogra_: tried wifi dongle, eth dongle
<zyga> ogra_: (eth dongle flaky but that's the dongle)
<zyga> ogra_: trying more
<ogra_> both load modules and all ?
<zyga> ogra_: yes (both work as network interfaces)
<jdstrand> zyga: fyi, uploaded ubuntu-core-launcher to xenial and the image ppa for the fix
<ogra_> awesome !
<zyga> ogra_: just FYI, I still see this while bootinh
<ogra_> zyga, "this" ?
<zyga> [FAILED] Failed to start Load/Save RF Kill Switch Status.
<zyga> (had to reboot to see it, damn serial)
<zyga> minicom over screen over classic mode pi over ssh over ssh
<zyga> don't ask ;)
<zyga> https://xkcd.com/908/
<zyga> applies
<ogra_> zyga, yeah, that wont be fixed before tomorrow ... needs the fix uploaded first (i havent yet) ... then a cdimage build ... and then manually snapping that and uploading to the store
<ogra_> (the rfkill stuff)
<ogra_> i was planning to do a full set of ubuntu-core snap updates tomorrow anyway
<ogra_> also to test the arm64 update (mvo claimed it should work, but nobody has tested it yet :) )
<zyga> cool
<zyga> I'll gladly update tomorrow
<ogra_> it should even do that itself :)
<ogra_> (unless you disabled autoupgrade)
<sergiusens> kyrofa, elopio how are things progressing on your side?
<kyrofa> sergiusens, not too bad here. How's the sprint so far?
<svij> ogra_: hÃ¤ppy bÃ¶rsday!
<sergiusens> kyrofa, good; looking into ubuntu image more than anything else
<kyrofa> sergiusens, ah good, that will be super useful :)
<sergiusens> and trying to wrap up cleanbuild a bit during spare time
<kyrofa> sergiusens, you have spare time? Not 8-8 meetings eh?
<mvo> ogra_: sure it will work ;)
<sergiusens> kyrofa, 8-8 meetings; spare time is me getting distracted or during the night ;-)
<kyrofa> sergiusens, hahaha
<kyrofa> ogra_, were you ever able to fix the dragonboard partition-resize-eating-itself issue?
<popey> How long to snap reviews take in the store?
 * popey is used to clicks being reviewed in about a minute
<zyga> popey: I may be wrong but reviews might be manual until squashfs is supported by review scripts
<popey> ah okay
<popey> well, I successfully uploaded my first snap to the store, so that's a milestone for me  ð
<sergiusens> stgraber, hey about https://bugs.launchpad.net/snappy/+bug/1543764 do you have implementation details on how you plan to do this?
<ubottu> Launchpad bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New]
#snappy 2016-02-17
<zyga> jdstrand: hey
<zyga> jdstrand: it works :)
<zyga> jdstrand: all skills based, I'll bug you with details tomorrow :)
<zyga> https://github.com/zyga/snappy/tree/skills-demo-i2c <- somewhat hacky, to a small degree
<encryptedchicken> howdy
<encryptedchicken>  i'm trying to install snappy core on i386 and the file is .img and i've tried converting to .iso but it's failing. What gives?
<aatchison> X86 as in 32bit?
<encryptedchicken> 64
<zyga> good morning
 * zyga has made great progress towards adding lots of more, complex skills
<didrocks> hey zyga
<dholbach> good morning
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<JamesTait> Good morning all!  Happy Wednesday, and happy World Human Spirit Day! ð
<ogra_> kyrofa, resize is fixed with the latest kernel snap in the store, yes (you can use mvo's u-d-f to build one or wait til later today when i release a new image)
<msvb-out> No snappy images for 15.10, is there a roadmap that states if a 16.04 release will appear?
<ogra_> msvb-out, snappy is a rolling release, after release of the "normal" 16.04 ubuntu the stable channel will switch to it
<Tomer> Hi
<Tomer> I'm running 16.04 snappy core on an RPi2
<Tomer> I want to build an app using snapcraft but my laptop outputs an arm64 package, which is not copatible with the RPi2 (ARMv7)
<Tomer> What can I do?
<ogra_> you should use the classic dimension on your rpi to build it
<ogra_> sudo snappy enable-classic
<ogra_> snappy shell classic
<ogra_> then install snapcraft with apt-get, pull your snapcraft.yaml in and build it
<Tomer> ok ill try it, thanks!
<asac> zyga: do we have a list of skills that we will do yet?
<asac> or skill types rather
<asac> wow, my desktop just locks itself after 10 seconds without me touching anything :/
<asac> wonder if that means i need to restart X :)?
<zyga> asac: I don't know anything more than last week, sorry
<zyga> asac: maybe something will be decided at the sprint
<zyga> asac: I'm not there, I don't know
<zyga> asac: I explored adding a new skill type this week (i2c) to iron out issues with the security layer
<ogra_> geez .... will that netsplit ever stop today ?
<ogra_> asac, you should reboot after the libc bug anyway
<asac> hmm. ok :)
 * asac turns down productivity
<asac> and goes for reboot
 * zyga needs to reboot as well, thanks for the tip ogra_ 
<ogra_> :)
<ogra_> hmm, seems to not have landed in xenial yet http://people.canonical.com/~ogra/core-image-stats/20160217.changes
<zyga> ogra_: I see it in my apt-get changelog
<ogra_> yeah, but it landed after the daily image build
<zyga> glibc (2.21-0ubuntu6) xenial; urgency=medium
<popey> hm, what does this mean when I run "snapcraft snap" on a very simple package (figlet):- http://paste.ubuntu.com/15099808/ is the yaml, here's the 'error message' "Command '['/bin/sh', '/tmp/tmpom31_khu', '/bin/sh', '/tmp/tmp6lhcweja']' returned non-zero exit status 1"
<popey> it clears up after itself so i can't even tell what /tmp/tmpom31_khu & /tmp/tmp6lhcweja were.
 * ogra_ has never used the nil plugin ... 
<popey> i used it in my cowsay one and it worked fine
<popey> don't understand it
<ogra_> where would figlet.sh come from ?
<ogra_> i dotn see it being copied or anything
<popey> ah
<popey> balls, i missed that out
<popey> good spot, thanks  ð
<ogra_> :)
<msvb-out> ogra_: Ah, a rolling release. But why didn't the snappy stable channel follow the 15.10 release, was it not 'normal'?
<ogra_> it was a snapshot of 15.04 to have a non-moving base but has a lot of additional updates from an additional repo
<ogra_> all new development is in 16.04 though, 15.04 was kind if a "stable pre-release"
<ogra_> *of
<ogra_> but we arent really tied to the normal release schedules after all
<msvb-out> ogra_: Okay, that's what I gathered. It would be easier for users if a intuitive release schedule and regular image filenames exist.
<msvb-out> ogra_: But maybe that will follow once a larger userbase is established.
<ogra_> the release process is totally different for snappy
<ogra_> a schedule wouldnt make sense
<ogra_> fixes go in if they are ready and will always show up in the daily rolling builds ...
<ogra_> also, since you can update apps and os completely independently the os isnt really that important (apart from feature completeness)
<ogra_> there is some raw schedule though ...
<ogra_> http://www.olli-ries.com/t-242d/
<msvb-out> ogra_: interesting, hadn't thought of the release philosophy being different. What you say makes sense.
<noizer> Hi guys, I'm trying to install nginx. I do that with deb packages but when it tries to start it killed itself again :s
<msvb-out> I guess this was more relevant when snappy on ARM builds had no implementation of snappy update.
<ogra_> yeah, the switch to the all-snaps model in 16.04 will chnage that
<ogra_> noizer, via stage-packages in your snapcraft.yaml ?
<ogra_> you most likely need a wrapper script to adjust config and paths etc
<kyrofa> Ah, ogra_ thanks for getting back to me regarding the resize thing :)
<kyrofa> Good morning #snappy, by the way
<ogra_> kyrofa, if you want to resize it on your PC http://paste.ubuntu.com/15099918/ might help (adjust DISK to point to your SD reader and run with sudo)
<noizer> yea with stage packages ogra_
<ogra_> i'm working that snippet into the initrd today (and clean it up a bit)
<ogra_> noizer, so if you take a look at the startup script i use for lighttpd ... http://bazaar.launchpad.net/~ogra/+junk/upnp-server/view/head:/run-lighthttpd between line 12 and 44 i create/update the config (you probably dont need that if you have a fixed config pointing to the right dirs) and in line 50 i run lighttpd with adjusted options to run from the snap dir
<ogra_> you likely want something similar for ngnix fi you use the deb, since the deb defaults wont work for snappy
<ogra_> (note this is for 15.04 though ... the env vars have changed in 16.04 and you should use the new ones)
 * ogra_ triggers a xenial build to get the fixed app-launcher and libc before rolling new ubuntu-core snaps 
<noizer> hmmmm strange i think i do that
<noizer> when the service is running can you see it with ps -A
<noizer> ?
<ogra_> yes
<kyrofa> ogra_, yeah good idea
<ogra_> (RaspberryPi2)ubuntu@localhost:~$ ps ax|grep lighttpd
<ogra_>  5373 ?        S      0:00 /apps/upnp-server-armhf.ogra/0.1.0/usr/sbin/lighttpd -D -f /var/lib/apps/upnp-server-armhf.ogra/0.1.0/lighttpd.conf -m /apps/upnp-server-armhf.ogra/0.1.0/usr/lib/lighttpd
<ogra_> noizer, ^^^
<noizer> ogra_ dammed xD stupid nginx xD
<noizer> ogra_ But kyrofa told me to compile it myself nginx. But i think that would be overkill
<zyga> noizer: why, this is the best way to integrate
<zyga> noizer: and if you really care about it, you can have a branch with extra snappy integration features that tracks upstream
<zyga> noizer: it really is sensible IMHO
<ogra_> noizer, well, you have twoo options, eiter use the deb and invest all the work to adjust the paths via wrapper or you compile from source and set the right prefixes and paths in there ... either will be fine and both will likely be equally much work
<zyga> ogra_: note; there is no valid value for the prefix as $SNAP_APP_foo is not fixed in stone
<zyga> ogra_: you really have to load and re-loate at runtime
<zyga> (load environment variables and use them to find stuff)
<ogra_> well, luckily we still have backwards compatibility
<ogra_> the old values should all still work afaik
<zyga> ogra_: yeah but I mean that stuff like configure --prefix=/snaps/something is not going to work naively, there is no really good way to configure application that uses prefix to load its data
<ogra_> well ... --prefix=./ might work though :)
<zyga> heh :) maybe but I doubt autotools will respect that
<ogra_> heh
<zyga> the good news is that patching it is usually quite easy
<zyga> the bad news is that then you have to carry a patch
 * ogra_ is in the deb camp though ... 
<kyrofa> Right, Snappy is a bit odd in that you need to build in one place, tell it it'll run in another place, and actually run in yet another place :P
<ogra_> but thats just because i love shell
<ogra_> i still have to hit my first package where a wrapper doesnt work (there are surely a lot though)
<noizer> ogra_ when he tries to start now my nginx i got following error: Failed with result 'start-limit'.
<ogra_> well, no idea what that means ... i never used ngnix
<asac> kyrofa: master static tests are currently failing?
<kyrofa> asac, hmm... looks like an lxd error. Restarting
<asac> zyga: think for the time being you could use an x-plugin to have a hacked autotolls one?
<kyrofa> asac, to take care of the patching?
<asac> the other thing could be to have variable expansion in configflags
<asac> kyrofa: to not require to patch the buggy upstream build system that relies on --prefix for data install instead of also honouring DESTDIR
<asac> better than adding a patch to autotools plugin imo that will auto add prefix to install dir... but thats just my feel
<zyga> asac: yeah, that works too
<zyga> asac: I think now you can fake most with a makefile
<zyga> jdstrand: hey, I have a security question for you
<asac> you can also make a makefile wrapper for sure
<asac> but then thats a bit nasty to do too as you need multiple parts i guess
<jdstrand> zyga: shoot
<zyga> jdstrand: old hw-assign world ran a chmod so that "granted" file can be world/group read/writable
<asac> one with local source and one with remote source and then the local one needs to build the one from remote
<jdstrand> it did?
<zyga> jdstrand: this made sense since those files were off-limits anyway
<zyga> jdstrand: yep,
<zyga> jdstrand: so that at the end of the day a non-root process can open the file
<jdstrand> I don't think I remember that
<zyga> jdstrand: I can find that, one sec
<jdstrand> I imagine this was done for something like /dev/video where udev is setting up strict groups and permissions that the non-root user was not part of
<jdstrand> but, I don't really like just making the device world writable
<ogra_> coundnt we hook into udev-acl here ?
<ogra_> groups are pretty dead everywhere anyway
<zyga> hmmmmmm
<jdstrand> I don't know what that is, but it sounds promising
<zyga> I cannot find that yet, that's not rightr
<zyga> so actually this is quite related
<zyga> I wrote a hacky i2c skill
<zyga> it allows ioctl (though it's on by default) via seccomp
<jdstrand> actually, if udev-acl is doing what I think it is, I don't think I like that either
<zyga> it allows open via apparmor on the affected /dev/i2c-1 file
<zyga> now the last thing I want to understand
<zyga> is systemd /dev namespace and udev
<zyga> (without the final chmod my demo app didn't have right to open the i2c controller)
<ogra_> jdstrand, well, afaik it hooks into logind and manages acls based on polkit ( pitti may correct me here, i'm only a consumer usually)
<zyga> note - this is not a service/framework
<zyga> jdstrand: are we on the same page or am I missing something with regards to things in /dve?
<zyga> in /dev
<jdstrand> ogra_: right, but what I was getting at is that while it might (arguably) be fine to grant the device access to the non-root user within the context of a confined process, either method gives the non-root user access to the devices when it starts processes that aren't confined
<ogra_> why would anything from a snap start something thats non confined ?
<jdstrand> zyga: with hw-assign we didn't use a systemd /dev namespace
<ogra_> (beyond the granted skills)
<jdstrand> ogra_: nothing from a snap would. a login starts an unconfined shell
<ogra_> but a login also gets me sudo access anyway :)
<ogra_> (at least currently)
<pitti> ogra_, jdstrand: not polkit, it really adds ACLs to the device node (you can't control file acess with polkit)
<zyga> jdstrand: https://github.com/zyga/snappy/blob/skills-demo-i2c/skills/types/i2c.go
<jdstrand> ogra_: but sudo doesn't equal root. if the login account is hacked, the password is unknown
<zyga> pitti: oh, where do we do that?
<ogra_> jdstrand, ah, indeed
<pitti> zyga: /lib/udev/rules.d/70-uaccess.rules
<jdstrand> zyga: so, remember, the way hw-assign works is that isn't just apparmor
<ogra_> pitti, oh, right, i'm living in the past ... i remember it hooked into consolekit once
<pitti> ogra_: right, that part got replaced with logind which tracks the foreground console, but the ACL part is still the saem
<jdstrand> zyga: because we didn't want to have to recompile apparmor policy for ever changing device names (until our profile composition feature is finished (not 16.04)
<zyga> pitti: uaccess? is it something like this: https://github.com/zyga/snappy/blob/skills-demo-i2c/skills/types/i2c.go#L98
<ogra_> ah, k
<jdstrand> )
<pitti> zyga: they are both tags, yes; snappy-assign was meant for a different purpose, though
<jdstrand> zyga: so we tag devices via the file pitti mentioned and then the launcher adds any devices that are tagged into a device cgroup for the app
<pitti> zyga: IIRC we do that via apparmor
<pitti> uaccess means "accessible to the current foreground console"
<pitti> right, devices cgroup, not apparmor, sorry
<pitti> it's been a while
<jdstrand> it *should* be apparmor
<jdstrand> but, aforementioned unimplemented feature
<zyga> jdstrand: okay, I actually asked the wrong question up front; I don't want to design the security system; let me re-state the question differently: how should I implement access to files in /dev (e.g.g /dev/i2c-1 here) for snappy skills for 16.04?
<jdstrand> zyga: the same general method. add them to a device cgroup
<jdstrand> zyga: via the udev tagging
<zyga> jdstrand: how?
<zyga> jdstrand: like what I linked to?
<zyga> https://github.com/zyga/snappy/blob/skills-demo-i2c/skills/types/i2c.go#L98
<zyga> or something else
<jdstrand> zyga: something like that, yes
<jdstrand> zyga: ie, just port the old hw-assign technique to skills
<zyga> jdstrand: that gets written to https://github.com/zyga/snappy/blob/skills-demo-i2c/skills/security.go#L176
<jdstrand> yes
<zyga> jdstrand: yeah, I'm trying to ensure I didn't miss anything, that old code is somewhat convoluted
<zyga> hmm, so with this i still had to chmod /dev/i2c-1
<jdstrand> zyga: two things need to happen: *if* there is a /dev assignment, create a udev rules file in /etc/udev/rules.d *and* add a /dev/** rwk rule to the apparmor profile if it isn't already there
<jdstrand> zyga: if there is not a /dev assignment, make sure there are no /etc/udev/rules.d files for the snap and remove the /dev/** rwk apparmor rule
<jdstrand> zyga: what this is doing is transferring control from apparmor to the devices cgroup for /dev assignement
<jdstrand> zyga: and giving it back with unassignment
<jdstrand> zyga: this has nothing to do with device ownership btw
<jdstrand> in the sense of UNIX perms
<zyga> jdstrand: hmmm, so currently I do both
<zyga> jdstrand: I have the apparmor rule and the /dev "assignment" via udev file
<jdstrand> zyga: you don't want to do the apparmor part when we release, but it is ok for now
<zyga> jdstrand: so what happens when I drop that today?
<jdstrand> zyga: this is a boot time optimization
<zyga> jdstrand: I mean, just use /dev assignment
<zyga> jdstrand: (don't worry about boot time, everything will change before 16.04)
<jdstrand> zyga: which are you dropping?
<zyga> jdstrand: I'm trying to see what to do to make it right, out of the three security systems (seccomp, apparmor, "udev") I can give any kind of security configuration for the i2c skill
<zyga> jdstrand: you just said I should not do apparmor
<jdstrand> it might be more than boot time-- the point is, that if we assign a usb camera to the snap, every time the camera device name changes, we don't want to have to recompile apparmor policy
<davmor2> ogra_, dholbach: I've seen this a bunch now but it only just dawned on me to ask, why in snap do you have to do in popey's example cowsay.cowsay to make the command actually run?
<zyga> jdstrand: let's not worry about that, I'm pretty sure we will do a full transition at that time
<zyga> jdstrand: I want to focus on the simple mechanics, optimize later if we can (I suspect we won't)
<ogra_> davmor2, because there could be a cowsay.ogra and a cowsay.davmor2 too
<zyga> jdstrand: the state engine in snappy will change how many things happe
<zyga> *happen
<jdstrand> zyga: if assigning something to a snap from /dev, use the udev method and add a blanket /dev/** rwk apparmor rule. hw-assign does that apparmor rule via an .additional file
<ogra_> davmor2, snaps actually replace PPAs on a very subtle level ;)
<jdstrand> zyga: you should do the same
<zyga> jdstrand: ok
<davmor2> ogra_: so the second is just hte dev namespace right?
<ogra_> yeah
<ogra_> or company or whatever
<zyga> jdstrand: we're switching to skills controlling all of the security files, the .additional file doesn't exist in this world tw
<zyga> btw
<jdstrand> why not?
<ogra_> davmor2, like: libreoffice.microsoft ;)
<zyga> jdstrand: each app has one apparmor profile, we don't write anything to disk ourselves
<popey> lulz ogra_
<jdstrand> zyga: that file makes it so you don't have to recompile the policy all the time
<davmor2> ogra_: that's evil dude seriously get ready for the letters ;)
<zyga> jdstrand: how does that work if we still have to load the updated profile into the kernel?
<jdstrand> zyga: you do write out to disk-- or are you saying that you removed /var/lib/snappy/{apparmir,seccomp}/profiles?
<zyga> jdstrand: I kept that but I write fewer files:
<zyga> https://github.com/zyga/snappy/blob/skills-demo-i2c/skills/security.go#L59
<jdstrand> so, to be clear, hw-assign was doing exactly what it needed to wrt /dev files
<zyga> https://github.com/zyga/snappy/blob/skills-demo-i2c/skills/security.go#L138
<jdstrand> no more, no less
<davmor2> ogra_: so say for example libreoffice.libreoffice is the official snap and then libreoffice.davmor2 is mine with all the QA report templates added right
<jdstrand> if you are removing a bunch of stuff, we need to discuss that, cause there are some pretty major implications
<zyga> jdstrand: don't assume that what hw-assign did stays the same, snappy is changing in interesting ways, we cannot keep some of the old stuff around
<ogra_> davmor2, the point is that you can have the same app/binary multiple times installed and compare them, or use feature a from one and b from the other
<jdstrand> zyga: I don't care about the high level. I'm talking about the lowest level security enforcement
<ogra_> davmor2, right
<zyga> jdstrand: I can write to other files but it's not exactly clear that we want to; IMHO we'll start with empty security on boot (nothing has extra permissions) and build a fully dynamic changing system as things happen (snaps get activated, skills get granted)
<davmor2> ogra_: okay cool thanks for that makes a lot more sense now :)
<ogra_> :)
<jdstrand> zyga: at the highest level, that may make sense, but if you are dynamically generating apparmor policy all the time, you'll find boot will be slow, assignements will be slow, etc
<zyga> jdstrand: I think this is unavoidable given that the system has to be fully dynamic (skill hooks)
<jdstrand> zyga: we have to utilize caching and be smart about updating the apparmor policy otherwise the system will feel slow
<jdstrand> no it doesn't
<jdstrand> we can avoid the slowness
<jdstrand> if you listen to me :)
<zyga> jdstrand: please tell me :)
<jdstrand> initial boot from factory, there is nothing
<jdstrand> (fine)
<zyga> jdstrand: generating the policy is cheap, compiling one is slow but I hope we can cache *that*
<jdstrand> write
<jdstrand> right*
<jdstrand> think of it like this:
<jdstrand> write the policy to /var/lib/snappy/apparmor/profiles, then compile from that and write a cache file from that to that on next load, /var/lib/snappy/apparmor/profiles is used. ok, now you can
<jdstrand> when the skills change or anything else, create a temporary policy generation somewhere
<jdstrand> then compare that to what is in /var/lib/snappy/apparmor/profiles
<jdstrand> if they are the same, do nothing
<jdstrand> if different, copy to /var/lib/snappy/apparmor/profiles, recompile and update the cache
<jdstrand> that is how you can be fully dynamic
<zyga> that's somewhat similar to what I'm trying to build, I'll maintain a set of compiled policies
<jdstrand> without losing caching benefits
<zyga> probably hashed by contents
<jdstrand> that does not cover device names that change all the time though (which is where the cgroups come in)
<zyga> my point was that on boot we'll still do the dynamic bring-up (nothing stays granted after boot as a hook has to decide that), if the decisions are the same we just get cached binaries
<jdstrand> hashed is fine, point is, just don't overwrite /var/lib/snappy/apparmor/profiles unless things actually change
<zyga> that's another thing
<zyga> we may end up changing the directory sturcutre
<jdstrand> so, if you are regenerating the profile all the time and comparing it, then yes, you don't need an .additional file
<zyga> for better transactionality, right now it is not transactional at all
<jdstrand> the .additional file was just a technique to maintain a few additions rather than snappy having to maintain the profile itself
<zyga> for apparmor the actual file is not interesting much, just the loaded profile in the kernel, we can keep cache on disk and actual profiles in temporary files that exist just long enough to load the profile into the kernl
<zyga> *kernel
<jdstrand> zyga: not quite
<zyga> no?
<zyga> please tell
<jdstrand> no, because what if apparmor itself changes?
<zyga> apparmor itself?
<zyga> os-snap update?
<jdstrand> yes, we add features to it
<zyga> we reboot
<jdstrand> yes
<jdstrand> rules change, etc
<zyga> start form scratch
<zyga> cache won't be used because binary content will differ
<zyga> all of security files are ephemeral
<zyga> we re-construct them (we can) on boot
<zyga> right?
<jdstrand> I think that you should maintain the files in /var/lib/snappy/apparmor/profiles
<jdstrand> the reason why is you won't know if the cache file changed without recompiled the policy
<jdstrand> put more simply
<zyga> hmm?
<zyga> you mean things like <include> ?
<jdstrand> when you generate a cache file, its mtime is later than the policy file it was generated from
<jdstrand> (and abstractions it includes)
<jdstrand> only if the mtime of the profile is later than the cache will the policy be recompiled and the cache updated
<jdstrand> (or the abstractions it includes)
<zyga> hmmm
<zyga> I see
<jdstrand> so if always regenerate dynamically, then your mtime is always newer than the cache and you always recompile
<zyga> I'll think about it
<jdstrand> so you must have the files in /var/lib/snappy/apparmor/profiles
<zyga> does apparmor have a preprocessor?
<jdstrand> yes
<zyga> so that we can just get the full raw output that we want to compile and stick into the kernel
<jdstrand> and that is what you need to be using with my technique of seeing if the tmp profile and the one in /var/lib/snappy/apparmor/profiles are different
<zyga> the reason I'm leaning that way is that all of security blobs seem to migrate to tmpfs in the world we're going to
<zyga> is the perprocessor also slow?
<zyga> or just the compiler?
<jdstrand> no
<jdstrand> it doesn't matter though
<jdstrand> it is the same problem
<zyga> I'd much rather compute the full output of the preprocesosr and manage just the perprocessed src -> binary cache
<zyga> then it is independent of mtime
<zyga> (time is generally pesky)
<jdstrand> can you explain how you will do that?
<jdstrand> basically, you are taking control away from apparmor on when and how to use its cache
<zyga> jdstrand: perhaps I'm missing something, I'd like to treat apparmor profiles as preprocessed .c files
<zyga> jdstrand: and use the cache as a ccache
<jdstrand> and this is an area of intense thought and evolution over the years
<zyga> jdstrand: the reason for all of this is that we need to make snappy able to recover from various things, to make it more transactional so to speak
<jdstrand> zyga: the preprocessor doesn't have everything though. it has the rules, but not what the kernel or the parser supports
<zyga> jdstrand: and the numer of things that can fail in applying a new set of security permissions is large, we'd like to be able to "go back" to a known consistent state
<jdstrand> zyga: I don't see how having a profile in /var/lib can't be made to work with transactions
<jdstrand> if you "go back" simply invalidate the cache and remove the profiles
<zyga> jdstrand: we need to be able to keep arbitrairly many good states around
<zyga> jdstrand: and pick the one we want to be in at will
<jdstrand> not for this
<zyga> jdstrand: today that's involving rewriting many separate files
<jdstrand> you yourself said it is dynamic
<zyga> yes, but the application process can fail
<jdstrand> then remove the file
<jdstrand> you are going to have to write out stuff regardless
<zyga> so going from state A to state B can fail and we want to be able to go to A (if possible) or to a new state C with as few error paths as possible
<jdstrand> ie, maintain your preprocessor cache
<jdstrand> easy, always invalidate
<jdstrand> you have to anyway
<jdstrand> you are just moving the problem around
<zyga> in ephermeral mode it's easier, nothing stays behind
<zyga> not quite
<jdstrand> by the nature of using a cache, you have to do certain things
<zyga> I'd like to make "switch" operation impossible to fail
<zyga> jdstrand: so I can have two entire sets of security files
<zyga> jdstrand: and switch between them with a very primitive operation that has minimal chance of failure
<zyga> we can do that for seccomp easily
<jdstrand> I fail to see how that can't be done with using profiles in /var
<jdstrand> sure, there is no compilation for seccomp
<zyga> well, we can keep them in /var but that just needs more gardening
<jdstrand> (well, sorta-- the launcher is doing the compile)
<zyga> perhaps I'm trying to avoid the inevitable
<zyga> right
<zyga> udev is more complex, we cannot switch that atomicall
<zyga> atomically*
<zyga> same with dbus
<jdstrand> zyga: I think this is a really thorny problem that needs very careful thought and there are more pressing matters to attend to
<zyga> apparmor we sort of can, we can have 2 profiles loaded and use the launcher to pick the one we want
<zyga> jdstrand: but that's the matter we are attending, that's the state engine
<jdstrand> zyga: if you want atomicity, in case of any error, blash everything from /var and the cache files and regenerate everything
<zyga> jdstrand: we have to solve this, now
<jdstrand> blast*
<zyga> (now as in before 16.04)
<jdstrand> zyga: I fail to see how pushing the problem into the launcher makes the system better
<zyga> I don't think that I'm pushing the problem into the launcher
<jdstrand> if the launcher is picking which one, I don't think that is necessarily better
<zyga> the fact today is that security changes are not atomic and failure leaves the system in inconsistent state, I'm trying to build something that has better properties
<jdstrand> plus, remember, the profile names are already versioned
<zyga> well, the launcher just makes it happen, currently we _tell_ it which to pick
<zyga> no
<zyga> they are not
<zyga> only by snap name
<jdstrand> and app name and revision
<zyga> not by grant/revoke iteration count
<zyga> so if I'm building state for "after grant" it clobbers some of the state "before grant"
<jdstrand> it seems like I've been out of a few conversations here and that I probably shouldn't have been
<zyga> those are just my observations, there are no background conversations on this
<jdstrand> the files in /var are versioned
<zyga> the state engine is the big thing that is changing
<jdstrand> currently
<zyga> can you tell my what is the version key?
<zyga> they are not versioned by things that matter to skills (snap version is not important here)
<jdstrand> pkgname_appname_revision
<noizer> ogra_ can i see the yaml file of you application with lighthttpd?
<zyga> that's not important here, that's my point
<jdstrand> we aren't talking about skills
<zyga> jdstrand: when I say "snap grant foo bar"
<ogra_> noizer, just go one level up
<jdstrand> we are talking about apparmor caching
<ogra_> same tree
<jdstrand> zyga: this is why we had .additional files
<zyga> that will clobber some of the state, perhaps even before the process is finished (because something failed) we already overwrote the state of that snap-version-app
<zyga> jdstrand: how do .additional files improve that?
<jdstrand> zyga: there are other ways to do it without additional files, but they were unversioned and the profile was versioned. the profiles was versioned precisely to cover moving from one state to another
<jdstrand> ie, rollbacks, forwards, whatever
<zyga> please differentiate snap updates from changes to granted skills
<zyga> in a state where snaps don't change
<zyga> skill grants can change
<zyga> and that is currently not transactional in any way
<jdstrand> zyga: the additional file was the only thing snappy managed wrt hw-assign
<zyga> correct?
<jdstrand> zyga: like I said, that could be changed
<zyga> right, okay, sorry if I seem confused sometimes, I'm trying to ensure I still grok the picture as it exists today
<zyga> hw-assign is going away
<zyga> skills replace it entirely
<jdstrand> yes
<zyga> I'm just looking for the best way to do that
 * jdstrand understands that
<zyga> and transactionality is big part of that
<zyga> (to the extent that snappy is transactional in general)
<jdstrand> zyga: perhaps it would help me if you said exactly what qualities you want for your transactionality
<zyga> right, that's a good question
<zyga> right now it's somewhat open as a sprint is under way and perhaps new things will happen there
<zyga> jdstrand: but what I believe to be true is a world where snappy has a set of compoentns internally
<zyga> jdstrand: each component having a way to veto an arbitrary examined state
<zyga> jdstrand: one state is effective (as in true on disk and in memory as observed by other processes)
<zyga> jdstrand: snappy can try to transition from one state to another by computing a new state
<zyga> jdstrand: asking each of the components (managers) to sanitize that state
<zyga> jdstrand: perhaps veto it
<zyga> jdstrand: or perhaps sanitize it with some modifiations
<zyga> jdstrand: then if all of the managers agree, we can apply that state to make it effective
<zyga> jdstrand: that can fail as well so we need a way to roll back
<zyga> jdstrand: each manager has a different notion of a rollback
<zyga> jdstrand: (snaps, assertions and skills)
<zyga> jdstrand: but in general it is to return to a state that is consistent, that all managers agree on
<jdstrand> it sounds like the security system may be a manager as well
<zyga> yes
<zyga> jdstrand: I think so
<jdstrand> let me know when you are done with your synopsis
<zyga> jdstrand: currently skills are one such manager but it's just being built so perhaps it will grow
<zyga> jdstrand: (ok) for skills my "state" is the set of intents-to-grant
<zyga> jdstrand: so set of tuples (snap-skill-name, skill-name, snap-slot-name, slot-name)
<zyga> jdstrand: that state is persistent
<zyga> jdstrand: at runtime, the manager will try to satisfy those intents by handing out appropriate permissionto apps, running skill hooks
<zyga> jdstrand: inspecting hook output and iterating until the system is stable
<zyga> jdstrand: the effective state of the system is comprised of the state of the launcher files, systemd units, udev rules, seccomp and apparmor profiles and dbus filters
<noizer> are there here people that installed nginx succesfully into a snap?
<jdstrand> (are dbus filters the same as dbus bus policy?)
<zyga> jdstrand: I'd like to be able to "apply" and "recover" from a state / to state with little surface for failure as possible
<zyga> jdstrand: yes, I'm sorry, I didn't know the right name
<zyga> jdstrand: so that's the picture we're trying to build
<jdstrand> ok
<jdstrand> that's all fine
<jdstrand> 09:24 < zyga> jdstrand: then if all of the managers agree, we can apply that state to  make it effective
<jdstrand> all you need to do wrt apparmor is before making it 'effective', generate a preprocessed profile, then compare it to /var/lib/snappy/apparmor/profiles (after running it through a preprocessor
<jdstrand> )
<jdstrand> if they are the same, do nothing (ie, it is effective)
<jdstrand> if they are different, create the new profile in /var/lib/snappy/apparmor/profiles and apply the cache
<jdstrand> you also have to manage the file in /etc/udev and /etc/dbus/system.d (but those are the same as with seccomp, just a file, no cache)
<zyga> jdstrand: yes but those are a bit harder to work with, we're racing with things using them, right?
<ogra_> ubuntu@localhost:~$ sudo snappy update
<ogra_> Updating ubuntu-core (16.04.0-4.arm64)
<ogra_> ...
<zyga> jdstrand: udev monitors /etc/udev/rules.d/ ?
<jdstrand> which those are you referring to?
<ogra_> :D
<zyga> jdstrand: udev and dbus
<zyga> ogra_: wow, so it does work after all :)
<ogra_> zyga, rebooting ... lets see
<jdstrand> well, that is a different discussion point, but, ideally these things would happen before the service started
<zyga> ogra_: same here, updating now
<jdstrand> if it changes while the service is running, the service needs to be notified
<zyga> jdstrand: ah, that's a very good observation
<zyga> jdstrand: notified how? I was thinking that we really should restart the service after revoke affecting it, perhaps also after grant that fiddled with udev
<zyga> ogra_: magic
<ogra_> geez, shutdown takes half a century
<jdstrand> zyga: a restart would be an excellent default choice
<zyga> ogra_: update uses nearly 2W
<zyga> jdstrand: that's good to hear, I think that's the best we can do for 16.04
<jdstrand> zyga: perhaps someday we an app could opt into being notified with a HUP signal (for example)
<jdstrand> s/we an/an/
<ogra_> zyga, well, wifi download i guess
<zyga> jdstrand: there are two concerns, notifying cooperating services and ensuring that malicious service is not abusing permissins
<zyga> *permission
<zyga> *permissions
<zyga> geez, my keyboard
<ogra_> yay, update worked
<ogra_> ha ! and arm64 is the first one to have the libc fix !
<ogra_> http://people.canonical.com/~ogra/core-image-stats/20160217.1.changes
<jdstrand> zyga: I'd also like to point out that if an apparmor profile isn't already loaded, you can't apply it to a running process (you can update the profile for a running process). This is part of why we have cache files as well-- the cache files are loaded before any services so they are guaranteed to be running under confinement
<jdstrand> zyga: 'ensuring that malicious service is not abusing permissions' - how are you planning on ensuring that?
<zyga> jdstrand: restarting it after changing the profile
<jdstrand> zyga: you mean revocation?
<zyga> jdstrand: as for sequencing things in right order I'd have to talk to mvo first, there are some simple things about snaps (activated/deactivated) but activated snaps have systemd units that are more complicated to control, I'd like to ensure that we correctly shut down all the services around transition points
<zyga> jdstrand: yes, revocation
<jdstrand> zyga: cause yes if you want revocation of a device to happen, you are going to have to kill the process and have it restart, otherwise an open file handle won't be closed
<zyga> jdstrand: but as I said above, perhaps also on grant if a new /dev namespace entry is needed and systemd manages that
<zyga> jdstrand: right, that's why I mentioned that
<jdstrand> we aren't using /dev namespaces with systemd
<zyga> jdstrand: no revoke()
<jdstrand> to be clear
<zyga> sorry, I keep confusing that
<jdstrand> that is something different from what we are currently doing
<zyga> so the udev rule does what?
<jdstrand> tags the device
<zyga> is that for foreground apps only?
<zyga> right, but the launcher is interpreting those tags
<jdstrand> the udev rule tags the device to be used with a particular snap
<jdstrand> the launcher looks up the tags for that snap and if it finds any, adds them to an app-specific device cgroup
<jdstrand> zyga: it is for anything that runs under the launcher
<jdstrand> so all 'apps' (ie, formerly services and binaries)
<zyga> jdstrand: ah, so cgroup that's managed by the launcher, I see
<jdstrand> yes
<zyga> jdstrand: I haven't looked at background apps yet, are they also using the launcher?
<jdstrand> yes
<zyga> ah, great
<jdstrand> look in /etc/systemd/system
<zyga> hmm, one concern, can we tag one device to more than one snap?
<jdstrand> all of them use ubuntu-core-launcher as part of the Exec
<zyga> that's great, my demo snap (https://github.com/zyga/snappy-pi2-piglow) is not using services yet
<jdstrand> zyga: I believe the launcher can handle that. if it can't today, it could be made to
<zyga> jdstrand: ok
<jdstrand> correction, ExecStart
<zyga> jdstrand: I think we mostly agree, I have to handle apparmor pre-processor, cache and delta computations
<jdstrand> but yes, all services and commands use the launcher
<zyga> jdstrand: but mostly integrate into the state engine being built
<jdstrand> zyga: I'd like to review those changes. I think all this will work fine and we can continue to use caching effectively and avoid slowness
<zyga> jdstrand: I will ask you to review all the patches affecting skills
<jdstrand> cool
<zyga> jdstrand: and I think we should cooperate more daily
<jdstrand> yes, I'm getting to the point where I think I can do that
<jdstrand> beuno and I went through the backlog of cards and I'm finishing up review tools and store things and then it is skills
<zyga> jdstrand: that sounds great, I think we'll have a storm of skills-under-development as soon as the foundations are in place
<zyga> jdstrand: it took me ~24 hours to build the i2c skill from scratch plus another 24 hours to build demo snaps
<zyga> jdstrand: I expect to see a lot of similar new skills sprout
<jdstrand> zyga: I'm going to have a bunch of stuff to talk about for existing frameworks moving to only skills (which among other things gets into dbus bus policy and what I'll refer to as native security skills)
<zyga> jdstrand: we can have a call at any time, I'd love to know what you are building so that we are aligned
<beuno> also
<beuno> we're discussing a lot of that at the sprint
<beuno> so we'll have some updates on what we think the default skills should look like
<jdstrand> zyga: well, not building anything yet. I'm collecting frameworks (ie, helping others use the old system so I can see what we have to deal with on the new)
<beuno> more on that soon
<zyga> beuno: hey!
<beuno> :)
<jdstrand> beuno: hi!
<beuno> heya jdstrand!
<beuno> o/ zyga
<zyga> beuno: tell us, I'm dying of curiosity
<beuno> zyga, oh, no (incomplete) spoilers
<popey> beuno: who reviews / approves snaps in the store, and what's the process? Is it something that needs more eyeballs ?
<beuno> more importantly, I don't actually have the details
<beuno> it's all Gustavo
<jdstrand> beuno: fyi, mvo asked a bunch of questions after I was eod. I have answers. the most important is that it seems you guys were looking at 15.04 caps. 16.04 has the caps that were enumerated in brazil already on the device
<zyga> beuno: sure, I understand
<beuno> popey, it's usually me or jdstrand, hoping we don't need eyeballs and instead keep automating
<jdstrand> ie, in Brazil we said what security skills should be present. I implemented those as caps
 * beuno nods
<beuno> that's great
<zyga> jdstrand: I'd like to implement the migration skill as an actuall skill this week
<jdstrand> and what zyga and I were discussing at the end was converting those to skills (among other things)
<zyga> jdstrand: so that it's not a special case using the old code
<jdstrand> zyga: it will still look the same to developers? you are just talking about under the hood
<jdstrand> ?
<opny> Hello, on xenial for Pi2  I should enable I2C and SPI support. In raspbian should be like `modprobe i2c-dev / i2c-bcm2708` What's the corresponding in snappy?
<zyga> jdstrand: under the hood
<zyga> jdstrand: nothing on the outside should change
<jdstrand> beuno: fyi, 'snappy-debug.security list -i' on 16.04 system will show you what is there
<jdstrand> zyga: ack
<zyga> jdstrand: but in the end we'll be able to drop code from snappy/ (the package)
<jdstrand> beuno: but I'm going to talk to mvo when he comes online
<jdstrand> (just fyi)
<popey> beuno: ah okay. i put a couple of stupid snaps up, wondered if they'd pass.
<beuno> popey, atm, anything targeted at 16.04 will get stuck
<beuno> for a brief time, I think we'll fix that really soon
<jdstrand> popey: I've been furiously working on getting 16.04 snaps reviewable by the store. if you update the review tools in trunk, you can have all but security checks
<popey> cool.
<beuno> popey, reviewing now
<popey> oh, thanks :)
<jdstrand> there is another branch for those, but don't use it until tomorrow-- it isn't ready yet
<jdstrand> popey: once this lands in the store, 15.04 *and* 16.04 snaps can be reviewed just like clicks
<jdstrand> ie, by any of the reviewers
<beuno> popey, so
<beuno> https://myapps.developer.ubuntu.com/dev/click-apps/4540/rev/1/
<beuno> + signs in version numbers break our system atm
<beuno> cc/ matiasb ^
<beuno> popey, so, I'll need you to re-upload with a non +'s version
<beuno> sorry
<beuno> we're fixing it, etc
<matiasb> beuno, ack
<popey> heh, okay
<matiasb> beuno, fwiw the fix is expected to be deployed during today
<beuno> zyga, you have piglow2 waiting to be published
<beuno> zyga, are you aware
 * beuno hugs matiasb 
<matiasb> you should thank pindonga, really
<beuno> one hug per day, sorry
<beuno> you have to hug him now
<matiasb> heh
<zyga> beuno: yep
<zyga> beuno: I pushed it to see if I can start having more complete demos working from the store later
<zyga> beuno: I'm not blocked by it though
<beuno> zyga, it's approved, but not published
<beuno> so it won't be accessible
<beuno> just an FYI
<zyga> beuno: ah, I'll have to check that
<zyga> thanks
<popey> beuno: ok, uploaded a new package with no + sign
<plars> elopio: sorry, I have this weird thing where my hangout always seems to crash at the end of a call... which is good timing I guess, but it looks like I cut off at the end
<ogra_> popey, yeah, beuno's store only supports subtraction, not addition :P
<opny> How can I do a modprobe on snappy ?
<ogra_> opny, have a look at "sudo snappy config ubuntu-core"
<ogra_> it supports setting modules to be loaded
<opny> ogra_, oh thanks!
<opny> ogra_, does modprobe expects a yaml list or spaced list? How to R/W config?   ...   Is there any docs?
<popey> ogra_: that's good, I subtracted loads from those packages :)
<ogra_> opny, you can just "sudo snappy config ubuntu-core >core.yaml" ... edit the modprobe line and then call: sudo snappy config ubuntu-core core.yaml
<ogra_> (edit in the core.xaml file it produced indeed)
<ogra_> *yaml
<opny> ogra_, ok, hope there is some kind validation :)
<ogra_> ubuntu@localhost:~$ sudo snappy config ubuntu-core |grep modprobe
<ogra_>     modprobe: foo
<ogra_> not for the content
<ogra_> :)
<ogra_> (but there is syntax checking i think)
<opny> ogra_,  I put modprobe: "i2c-dev i2c-bcm2708" let's see waht happens
<ogra_> opny, take a look at /etc/modprobe.d/ubuntu-core.conf afer you ran snappy config with the new yaml
<ogra_> thats the file where they end up
 * zyga has published his first snap into the store!
<zyga> with a vimeo video no less :)
<noizer> where can I find information about docker in snappy?
<kyrofa> Hey elopio, you around?
<elopio> kyrofa: yes.
<kyrofa> elopio, can you sanity check me and tell me if I'm being stupid?
<zyga> kyrofa: :)
<elopio> kyrofa: what's your problem?
<kyrofa> elopio, I've been operating under the assumption that, if I ask snapcraft.repo to fetch the same package twice, it'll just say "yup" the second time
<kyrofa> elopio, however, that doesn't seem to be the case. But it doesn't seem to be the case in a very weird way: http://pastebin.ubuntu.com/15101603/
<kyrofa> Notice first get() call, stuff is fetched. Second get() call, failure. Third get() call, it says "yup"
<kyrofa> (fourth get() call, failure, fifth get() call success, you get the idea)
<kyrofa> I don't understand what's happening there
<elopio> kyrofa: hum, I can't reproduce it because there's a hash sum mismatch in the archive.
<elopio> let me try in a different machine.
<elopio> I think Daniel was the one who touched the cache. But he's away. Let me try to debug and see if I find something useful.
<kyrofa> I just can't explain the success/failure flip-flop
<kyrofa> elopio, ah, I got it
<kyrofa> elopio, it's the consistency check. Since we unmark some packages, the consistency check fails. Since we know it'll fail, I figure disabling the consistency check is probably fine
<elopio> kyrofa: makes sense.
<kyrofa> elopio, thanks for taking a look :)
<magizian> hey.
<jerryG> kgunn: are u there?
<kgunn> jerryG: yes
<alex_wri> Hi all, can someone direct me to any resource that explains how to change the default size of the System-A/B partitions in a snappy appliance (if this is possible)?
<beuno> alex_wri, hi. asac, ricmm or ogra might be able to help
<jerryG> kgunn: any way to hide MIR cursor?
<alex_wri> beuno: Thank you.
<alex_wri> ricmm: Is there a way to change the default partition size of the System-A/B partitions?
<ricmm> alex_wri: no, its hardcoded
<ricmm> why?
<alex_wri> ricmm: Well, maybe it's a conceptual issue. I want to deploy a large software package as part of my appliance. This makes the system larger than 1 GB. Can this be deployed through the oem snap?
<kgunn> jerryG: yes, there is...do you mean the server itself?
<kgunn> jerryG: might ask in #ubuntun-mir
<kgunn> jerryG: i'm kinda assuming you mean in the context that you are using mir_demo_server ?
<kgunn> or something else?
<kgunn> the server used in the recent snap posts i made, is not the demo server, but a simple server very much like it
<ogra_> alex_wri, note that the system-a/b partitioning is already obsolete, with 16.04 this has been moved to squashfs images (signed and with 0 free byte) ... you need to package your project as a snap, then you can define the inclusion of this snap in your gadget
<alex_wri> ogra_: Where can I find up to date documentation or information on the new architecture?
<ogra_> sadly i'm not sue this is properly documented yet ... (it will be once we release 16.04)
<ogra_> there are images at http://people.canonical.com/~mvo/all-snaps/ in case you want to inspect it though
<ogra_> in these images everything is a snap ...
<qengho> Har har. Btw, those images are getting stale.
<qengho> Two weeks old.
<ogra_> qengho, i'll push new rootfs snaps to the store tomorrow (only updated arm64 today)
<ogra_> the images auto-update already ;)
 * ogra_ goes back afk
<alex_wri> ogra_: Is there a concept of a snap that has unfettered access to the system by default, or do all permissions need to be explicitly stated and whitelisted?
<sergiusens> wgrant, hey, beuno mentioned you wanted to speak/write to me
<qengho> sergiusens: Hi hi. I'm interested in working on a snap for classic. What can you tell me about classic progress, dependencies, etc?
<sergiusens> qengho, classic is totally under mvo's wing; but maybe robert_ancell can provide more insight than myself
<jerryG> kgunn: yes, that's correct
<kgunn> jerryG: yeah, so first you can check mir_demo_server --help there might be some args to look at there
<kgunn> otherwise as in #ubuntu-mir
<kgunn> duflu will be coming on in a bit...and he's pretty good with that sort of thing
<jerryG> kgunn: kk thx
<ricmm> kgunn: hey, while I have you here
<ricmm> do you have any pointers to that dragonboard demo you mentioned?
<noizer_> Hi guys are there some people available here?
<jerryG> idk
<jerryG> noizer:  u might want to try in the morning
<noizer_> jerryG ok xD
<noizer_> jerryG see you tomorrow
#snappy 2016-02-18
<dhallett> i am new to snappy ubuntu and wondering if i can setup my own snappy repo to host updates and also snappy images for raspberry pi 2?
<dhallett> i am currently using snappy ubuntu core 16.04 on my rpi2 right now. just to let you know.
<dhallett> i have been a ubuntu user since Ubuntu 9.04 came out.
<dhallett> any help is appreciated
<dhallett> i would like to start contributing back to the ubuntu community as both as a dev and a fellow ubuntu user.
<dhallett> anyone able to help me with my problem? i also have a webdm on snappy ubuntu problem as when i go to my localip of my raspberry pi 2 it doesn't show on 16.04LTS snappy core
<dhallett> i  thought using this irc channel would provide faster answers after searching the internet for approx 24 hours i find the forums are a tad bit slow at answering than on irc
<dholbach> good morning
<didrocks> good morning dholbach!
<dholbach> salut didrocks
<JamesTait> Good morning all!  Happy Thursday, and happy Battery Day! ð
<popey> When I upload a snap to the store, I have to add a release. rolling-personal, rolling-core and 15.04-core. i made the snap on 16.04. which is that?
<longsleep> Good morning snappy, what is the best way to get snapcraft and start building a snap for 16.04?
<longsleep> is there a ppa or should i clone from Git?
<popey> there's a ppa longsleep
<longsleep> popey: that one looks good: https://launchpad.net/~snappy-dev/+archive/ubuntu/snapcraft-daily
<zyga> longsleep: get xenial or the snapcraft ppa
<zyga> longsleep: install snapcraft and look at snapcraft examples
<ogra_> i think you need xenial in any case, dont you ?
<zyga> longsleep: the examples are in snapcraft source tree, you can just clone that from github as a start
<zyga> ogra_: oh, good point
<zyga> longsleep: so you do want to use xenial for 16.04, 16.04 requires 16.04 to develop
<ogra_> so use a chroot (or the traditional ubuntu-core tarball)
<longsleep> ogra_: well i got the vagrant image but ran into bug #1546108
<ubottu> bug 1546108 in livecd-rootfs (Ubuntu) "Latest Vagrant box for Ubuntu Xenial is failing to boot" [Undecided,Confirmed] https://launchpad.net/bugs/1546108
<longsleep> i can chroot as well but that requires root which i would like to avoid
<noizer> ogra_ HI i will use your application to start with lighttpd but do you have an conf file?
<ogra_> noizer, i use a script to generate both configs (config.sh) out of the default.yaml file
<ogra_> and indeed the startup wrapper script
<longsleep> zyga: All right, i have 16.04 now gbarbieru/xenial Vagrant box seems to work
<longsleep> ogra_: can i still rely that python3 and openssl binaries are available in 16.04 base snappy system?
<longsleep> ok ready to go root@vagrant:~# snapcraft -v
<longsleep> 2.2.2
<noizer> ogra_ is it possible to use an conf file?
<ogra_> noizer, sure, just ship it and point the binary to it
<ogra_> longsleep, you could never rely on that .... though the new snapcraft makes it trivial to ship your interpreter
<noizer> ok I will first make my conf file and then try it.
<longsleep> ogra_: ok thanks - i will check it out
<noizer> thx ogra_
<ogra_> longsleep, thats for snapcraft 2.1 (so, outdated atm) http://paste.ubuntu.com/15106152/ but that should give you an idea
<ogra_> the last three lines simply pull in the py2 interpreter
<ogra_> (it allows indeed more complex things too)
<longsleep> yeah i guess it does
<longsleep> thanks - i need to find a suitable version of Go first - is it in the repositories nowadays?
<ogra_> not a go user, so i dont know :)
<ogra_> https://launchpad.net/ubuntu/+source/golang/2:1.6~rc2-0ubuntu1
<ogra_> looks like that is in the archive
 * longsleep looks
<longsleep> well apt-cache search golang-go-linux-amd64 gave nothing, lets try golang-go and see what that installs
<ogra_> https://launchpad.net/ubuntu/+source/golang/2:1.6~rc2-0ubuntu1/+build/8984117
<ogra_> looks like it is just "golang"
<longsleep> probably packaging has changed, does not look too bad
<longsleep> ogra_: looks really good vagrant@vagrant:/vagrant/Dev/spreed-webrtc$ file bin/spreed-webrtc-server
<longsleep> bin/spreed-webrtc-server: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), statically linked, not stripped
<longsleep> hooray!
<ogra_> yay
<ogra_> ricmm, ^^^ !
<ricmm> longsleep: excellent :)
<zyga> 19:41 -!- magizian [pan@162-202-67-158.lightspeed.livnmi.sbcglobal.net] has quit [Client Quit]
<zyga> 19:41 -!- magizian [pan@162-202-67-158.lightspeed.livnmi.sbcglobal.net] has quit [Client Quit]
<zyga> hmm
<zyga> sorry :)
<ogra_> zyga, yes ?
<ogra_> hah
 * ogra_ was wondering what you wanted to tell us :)
<zyga> "where has my focus gone to"
 * zyga digs into cgroups
<zyga> whee
<longsleep> mhm snapcraft does not work when used on the /vagrant mount - not really a problem but it would be nice if it would work :)
<longsleep> [Errno 1] Operation not permitted: '/vagrant/Dev/spreed-webrtc-snap/parts/glue/install/ssleay.cnf' -> '/vagrant/Dev/spreed-webrtc-snap/stage/ssleay.cnf'
<longsleep> ogra_: do you know if the make plugin for snapcraft can run a script after clone? like ./autogen.sh
<zyga> jdstrand: I'd like to make some modification to ubuntu-core-launcher, I'll ping you later about that
<longsleep> ogra_: ah seems i have to ue the autotools plugin
<zyga> jdstrand: I'd like to sync with you as soon as you are around, it's important and related to the sprint
<longsleep> ricmm: Are you there? I got the problem that snapcraft passes a bunch of LDFLAGS in a format which seems to be wrong for the go toolchain
<ogra_> did you use the go plugin actually ?
<longsleep> ogra_: no, the autotools plugin, but i can fix it in the Makefile.am
<longsleep> ogra_: i guess it is our fault and not snapcraft to blame :)
<ogra_> or sergiuens ;)
<longsleep> Staging spreed worked now
<zyga> jdstrand: so (in case you read the backlog), hw-assign doesn't work with /dev/i2c-1 for the same reason it didn't work with skills, still no permission to /dev/i2c-1 -- it's in the control group, but it's just not writable and the app doesn't run as root
<zyga> jdstrand: unless there's a logic hole somewhere I think we have to accept to chmod devices
<zyga> jdstrand: what confuses me is that other people make similar stuff and for them it works but they were always background commands, running as root, so getting the permission
<longsleep> ogra_: btw, snappy-tools where do i get it from for xenial?
<longsleep> (i have ppa:snappy-dev/tools)
<ogra_> longsleep, hmm, they should be in the archive ... if not, they are definitely in https://launchpad.net/~snappy-dev/+archive/ubuntu/image
<ogra_> oh, wait ... -tools isnt in there
<ogra_> i guess the above is correct
<longsleep> what exactly? /tools has not much builds for xenial yet
<longsleep> and /image does not seem to have it either
 * ogra_ has honsetly not used -tools since he switched to xenial and snapcraft 2.x )
<longsleep> how do you sideload?
<longsleep> manually?
<longsleep> i wanted to use snappy-remote or something
<kyrofa> Good morning
<longsleep> ogra_: seems i accidently created an app instead of a service :/
 * longsleep searches for a service example
<ogra_> longsleep, see my mycroft examplle from above
<longsleep> ah just add the daemon key?
<ogra_> yeah, services are dead .... they are all apps now
<ogra_> binary vs daemon is the difference
<longsleep> ok got it
<longsleep> ogra_: what about the caps? Seems like snapcraft 2.2 does not like it like it is in your example
<longsleep> probably the uses key from the examples
<longsleep> i think i get it from the example
 * longsleep tries it
<ogra_> longsleep, thats the new skills system i'm completely unfamiliar with
<ogra_> zyga might be able to point you to something perhaps
<longsleep> https://github.com/ubuntu-core/snapcraft/blob/master/examples/mosquitto/snapcraft.yaml
<longsleep> using that example
<ogra_> (caps are gone with 2.2+ )
<ogra_> yeah, that looks about right
<zyga> longsleep: no caps
<zyga> longsleep: use the migration-skill please
<zyga> longsleep: and tell me about the permissions your snap needs please
 * zyga -> lunch
<longsleep> zyga: i now use [network-listener, network-service], as the snap only listens in a bunch of ports and reads/writes to its own directories
<longsleep> ogra_: ok i have a service now, only the config hook needs fixing and then i think i might have it
<ogra_> wow, that was fast
<ogra_> you rock :)
<longsleep> well, KeyError app in the config hook still to resolve :)
<longsleep> ah it is not even a problem in the config hook, i am just missing the config.in file in the snap
<zyga> longsleep: nice!
<ogra_> hmm
<ogra_> does anyone have an idea why we ship Qt libs in our rootfs ? http://people.canonical.com/~ogra/core-image-stats/20160218.changes
<asac> hehe
<asac> ogra_: yes i know
<asac> i lokoed it it just yesterday
<asac> i think it can be fixed by seed
<asac> we have the ubuntu-download-manager still in
<asac> or somethign along that line used qt
<ogra_> eek
<ogra_> yeah, that shoul drally go
<asac> just unseed it and see if world explodes :)
<zyga> hmm, how do I start a background service in a snappy way?
<ogra_> *should really
<asac> sure it should
<asac> dont think we want to remove it though before next week :)
<ogra_> does snappy do the download on its own for snaps ?
<asac> yes i think thats all old
<zyga> ogra_: yes
<ogra_> cool then
<asac> just leftover from old world
<asac> feel free to double check if you find any other rdepend
<asac> so we are safe
<ogra_> yeah, there is more system-image stuff still seeded i think
<ogra_> (and hacks in the build system to set that up)
<ogra_> sudo reboot
<ogra_> damn ... EFOCUS :P
 * ogra_ blames zyga ... he started that :P
<zyga> Feb 18 13:40:23 localhost.localdomain ubuntu-core-launcher[3888]: failed to create user data directory. errmsg: Permission denied
<zyga> hehe
<zyga> so it seems we still have the permission denied issue, this time for services
<zyga> so yay, more stuff to debug
<zyga> (this is with the applied workaround)
<zyga> kyrofa: ^^ any chance you know how to work around this?
 * kyrofa reads scrollback
<longsleep> ogra_: after i have fixed a bug in the config hook totally unrelated to snappy it actually works on 16.04
<kyrofa> zyga, did jdstrand get that new profile out?
<ogra_> longsleep, whee, awesome !
<kyrofa> zyga, as for working around it, the same workaround he suggested before should work
<kyrofa> Oh wait.. you said you're using that workaround
<kyrofa> zyga, it was /** r or something, wasn't it?
<kyrofa> zyga, check for apparmor denials?
<kyrofa> (make sure this is the same issue)
<kyrofa> zyga, also, you haven't rebooted since loading in that temporary profile, right? Or you've loaded it again?
<kyrofa> zyga, alright, I will now take you up on making an edge image for me, if you have a minute. Let me take it for a spin, see what's going on
<zyga> kyrofa: yes (I don't know if new image was built) but note I did apply the same workaround myself
<zyga> kyrofa: how do I check apparmor denials?
<kyrofa> zyga, either with snappy-debug or just the syslog
<zyga> kyrofa: previously I manually straced everything, I don't know how to do that when systemd does activation
<zyga> ok, I'll check
<kyrofa> zyga, yeah you don't need to-- it's not that complicated
<noizer> ogra_ how does I make some rewrite in lighttpd. it does not work from me
<zyga> noizer: rewrite/
<noizer> zyga do you know something about nginx on snappy?
<zyga> noizer: no, I was just wondering what you were asking about
<zyga> Feb 18 13:57:55 localhost.localdomain ubuntu-core-launcher[4831]: failed to create user data directory. errmsg: Permission denied
<zyga> Feb 18 13:57:55 localhost.localdomain kernel: audit: type=1400 audit(1455803875.084:81): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/root/snaps/" pid=4831 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<zyga> kyrofa: ^^
<zyga> seems like the same old problem
<zyga> just root instead of $HOME
<zyga> I'll apply the same workaround
<zyga> kyrofa: it'd be good to check if jdstrand fixed both root and $HOME
<noizer> lighttpd is a webserver but ogra_ worked with it before and i thought he could help me out with some problems
<ogra_> noizer, you likely need to enable the module first
<kyrofa> zyga, I thought the workaround was /** r though, no?
<ogra_> somewhere in the config
<kyrofa> zyga, oh, the write though
<kyrofa> zyga, yeah you can take a peek inside the profile real quick if you want
<zyga> kyrofa: I only have the workaround
 * zyga looks at vanilla profiles
<noizer> mod_rewrite is enabled ogra_
<ogra_> http://redmine.lighttpd.net/projects/1/wiki/Docs_ModRewrite#Description
<kyrofa> zyga, /etc/apparmor.d/usr.bin.ubuntu-core-launcher
 * ogra_ grumbles about systemd log output 
<ogra_> ..."Failed with result 'exit-code'."
<kyrofa> zyga, though have you built another image since that was released? (or is it included in the OS snap...)
<ogra_> why cant it actually write the exit code in there
 * ogra_ shakes head
<kyrofa> zyga, yeah the apparmor profile uses HOME, which should be set correctly to /root. So I suspect you simply don't have the update
<zyga> kyrofa: I have the workaround for sure so something else might be broken
 * zyga returns to checking what
<kyrofa> zyga, if you can upload an image somewhere I'd be happy to check it out
<zyga> kyrofa: it's the stock image I built before, I don't want to re-flash it because I use classic dimension heavly for skill development
<zyga> kyrofa: looking at u-c-l profile, where does it have access to $HOME/snaps?
<kyrofa> zyga, makes sense
<zyga> 14:58 < zyga> Feb 18 13:57:55 localhost.localdomain kernel: audit: type=1400 audit(1455803875.084:81): apparmor="DENIED" operation="mkdir" profile="/usr/bin/ubuntu-core-launcher" name="/root/snaps/" pid=4831 comm="ubuntu-core-lau" requested_mask="c" denied_mask="c" fsuid=0 ouid=0
<kyrofa> zyga, check the last few lines of the profile (83 and on)
<zyga> kyrofa: I don't see anything that affects $HOME in the profile
<zyga> kyrofa: http://paste.ubuntu.com/15109503/
<zyga> kyrofa: that's my hacked copy
<kyrofa> zyga, yeah you don't have the update then. Here, use this:
<zyga> kyrofa: ah, perfect, thanks
 * zyga wonders if he can just update snappy then
<zyga> update is not released?
<zyga> ubuntu-core         2016-02-12 16.04.0-8.armhf canonical
<kyrofa> zyga, http://paste.ubuntu.com/15109578/
<zyga> trying
<kyrofa> zyga, I think that's the OS snap... right? Which needs it needs to be rebuilt before the update is actually distributed?
<ogra_> i'll try to get to that today and bump all os snaps ...
<kyrofa> which means it needs*
<ogra_> (prob iis that mvo didnt pick the same version for all of them so its all manual hackery )
 * kyrofa is still a little fuzzy on the kernel/os/magic snaps
<zyga> kyrofa: all good, thanks
<kyrofa> zyga, yeah? Working now?
<zyga> kyrofa: I found unrelated bugs in snappy (it seems that "snappy service" blindly tries to run crazy stuff that's not a service
<zyga> kyrofa: ) but starting the systemd unit manually makes things go
<zyga> kyrofa: so I have a skill-based service in operation :-)
<kyrofa> zyga, ooo, that's fun. What type of crazy stuff?
<zyga> kyrofa: background piglow
<kyrofa> (make sure you log those!)
<zyga> kyrofa: Feb 18 14:14:07 localhost.localdomain ./snappy[5012]: main.go:50: DEBUG: [./snappy service start] failed: unable to start pi2-piglow's service foreground: [start pi2-piglow_foreground_INANbBEQgddX.service] failed with exit status 6: Failed to start pi2-piglow_foreground_INANbBEQgddX.service: Unit pi2-piglow_foreground_INANbBEQgddX.service failed to load: No such file or directory.
<zyga> kyrofa: note: foreground is _not_ a background command/service
<zyga> kyrofa: the source for this snap is at github.com/zyga/snappy-pi2-piglow
 * zyga pushes new stuff
<zyga> done
<zyga> (now done)
<kyrofa> zyga, haha, I was gonna say...
<zyga> Feb 18 14:14:07 localhost.localdomain ./snappy[5012]: main.go:50: DEBUG: [./snappy service start] failed: unable to start pi2-piglow's service foreground: [start pi2-piglow_foreground_INANbBEQgddX.service] failed with exit status 6: Failed to start pi2-piglow_foreground_INANbBEQgddX.service: Unit pi2-piglow_foreground_INANbBEQgddX.service failed to load: No such file or directory.
<kyrofa> zyga, yeah, how does foreground turn into a service?
<zyga> er, damn paste
<zyga> kyrofa: it doesn't-- there is no .service file for it
<zyga> I don't know the service generation code by heart, maybe something is wrong there
<kyrofa> zyga, huh... but the snap.yaml looks okay?
<zyga> kyrofa: let's see
<zyga> kyrofa: yes
<zyga> kyrofa: I wouldn't worry yet, this might be some old/new snappy combination
<zyga> I may have used old (non trunk) version of snappy to instal the snap perhaps
<kyrofa> zyga, probably-- I was through all that code recently and it seemed okay
<zyga> kyrofa: if it happens after clean reproduction I'll start chasing it
<kyrofa> zyga, sounds good!
<zyga> who can I poke to review / approve squashfs app in the store?
<zyga> pi2-piglow.zygoon revision 2
<longsleep> ricmm, ogra_ https://github.com/strukturag/spreed-webrtc-snap - works fine for me and should build fine on arm64 as well if you run snapcraft there
<longsleep> ricmm, ogra_ it currently get the code from develop branch as i had to fix a variable conflict in the Makefile
 * zyga must say that the piglow executable, stripped, is comparable in size to the side of .yaml/changelog ;)
 * jdstrand reads backscroll and sees it is resolved
<jdstrand> yes, ubuntu-core-launcher is part of the os snap. if an os snap hasn't been generated in a while, the fix won't be there
<jdstrand> kyrofa: and the workaround rule was '/**/ rw,' - the trailing '/' is important :) ( though /** rw certainly would've worked too, but basically invalidated confinement :)
<jdstrand> as workarounds go, it would've been effective though :)
<kyrofa> jdstrand, heh. Yeah, all resolved :)
<kyrofa> jdstrand, good morning by the way!
<jdstrand> zyga: as for chmod-- this needs architects input. sure, a chmod will make it 'just work' for the ubuntu user, but there are a lot of implications in that
<jdstrand> kyrofa: hi!
<jdstrand> zyga: my gut feeling is that a chmod for the device for the user and a skills assignment to the snap are conflating two different things
<jdstrand> we don't have a strong story of users and groups on snappy yet and that probably needs to be discussed
<zyga> jdstrand: yep, I think this needs proper design
<jdstrand> cool
<zyga> jdstrand: hmm, perhaps in this case we could cheat by putting that device in the cgroup (as we do) and chmodding it *there*
<zyga> so the user doesn't get it
<zyga> but the app does
<jdstrand> I'm happy to be part of that conversation, but I think tyhicks should also be a part of it
<zyga> jdstrand: ok, let's do it
<jdstrand> zyga: I think we want pitti to have input too
<zyga> jdstrand: shall I open a bug on this to track it?
<jdstrand> I think that makes sense. something about requiring sudo for certain devices after skills assignment
<ogra_> longsleep, thanks, i'll try it out before EOD
<longsleep> ogra_: For comparison, this is the full output for snapcraft snap for me: http://paste.ubuntu.com/15111240/
<ogra_> thx
<longsleep> ogra_: i am not sure about the dependencies, i added some but might have missed autoconf or something else
<ogra_> k
<zyga> kyrofa: can you do a sanity check please
<zyga> kyrofa: install v2 of the p2-piglow.zygoon snap from the github url I mentined earlier
<zyga> kyrofa: and see what services you have
<zyga> ubuntu@localhost:~$ sudo ./snappy service status
<zyga> Snap            Service         State
<zyga> pi2-piglow      background      enabled; loaded; failed (failed)
<zyga> pi2-piglow      foreground      ; not-found; inactive (dead)
<zyga> !?
<kyrofa> zyga, I don't actually have an image where that stuff will work :P
<zyga> kyrofa: looking at the service code
<zyga> kyrofa: the condition to see if something is a service is bogus IMHO
<zyga>             if serviceName != "" && serviceName != name {
<zyga>                 continue
<zyga>             }
<zyga> everything else is a service
<zyga> what?
<kyrofa> zyga, wait... shouldn't that be using the daemon keyword?
<zyga> in other words _everything_ is a service
<zyga> kyrofa: exactly
<zyga> kyrofa: I'll fix that
<zyga> https://github.com/ubuntu-core/snappy/pull/495/files
<zyga> revoke works
<longsleep> ogra_: What would i select to upload a snap to the store for 16.04? rolling-core?
<zyga> now I only want to know which signal does systemd send to stop an app
<zyga> (a service)
<zyga> so that piglow can react to it by shutting down the lights before it goes
<ogra_> longsleep, yeah
<zyga> ah, that's SIGTERM
<zyga> nice
<longsleep> ogra_: mhm automated review failed, (NEEDS REVIEW) squashfs pkg lint_is_squashfs
<longsleep> and one warning: unknown entries in package.yaml: 'apps,description,summary,uses' lint_snappy_unknown
<ogra_> longsleep, sounds like a false positive ... beuno ^^^ ?
<ogra_> Snapping spreed-webrtc_0.24.11-1_arm64.snap
<ogra_> FATAL ERROR:Mksquashfs requires more physical memory than is available!
 * ogra_ cries
<longsleep> lol
<longsleep> how much memory did you give that box?
 * ogra_ hopes a swapfile will be respected
<kyrofa> ogra_, it will
<ogra_> cool !
<ogra_> longsleep, its real HW with 1GB
<longsleep> ah
<kyrofa> ogra_, it's the only way my snaps build on the arms I have here-- a 16GB swapfile :P
<ogra_> wow, thats bad
<longsleep> my vagrant box has 758352 memory and the same as swap and it worked to build
<kyrofa> ogra_, and that's a slight lie. I could make with no -j parameter and it would need less, but then it would take days
<longsleep> ogra_: what hardware do you actually use?
<ogra_> longsleep, dragonboard
<longsleep> ah ok cool
<beuno> ogra_, longsleep, it is false positives, will ve fixed soon
<beuno> kyrofa, ogra_, you can build snaps on Launchpad!
<kyrofa> beuno, indeed, and I plan on figuring that all out very soon
<kyrofa> beuno, but we're doing arm64
<kyrofa> beuno, launchpad only has 32-bit arms, no?
<ogra_> kyrofa, hmm, do you use chroots when building ?
<kyrofa> ogra_, no, why?
<ogra_> kyrofa, no, LP builds our rootfses :)
<ogra_> so there are also arm64 machines
<kyrofa> ogra_, ah, excellent!
<ogra_> kyrofa, because i just noticed 1GB is fine ... i just forgot to mount /proc and /sys
<kyrofa> Ah!
<beuno> kyrofa, it as arm64 for snaps  :)
<ogra_> longsleep, works great !
<longsleep> ogra_: fantastic!
<longsleep> ogra_: thans for testing
<longsleep> +k
<ogra_> thansk for building !
<ogra_> so sad the ubuntu phone browser doesnt work with it :(
<longsleep> what html/javascript engine does that browser use?
<ogra_> not sure ... popey ^^^ do you know ?
<ogra_> not v8 afaik
<popey> it's chromium, so blink.
<ogra_> blink is the renderer
<ogra_> and that all we use from chromium afaik ... the js engine was something different
<longsleep> if its chromium including v8 and the media enginges in the back then it could work with if recent enough
<ogra_> i'm pretty sure it is neither
<longsleep> currently we support Chromium 38 or newer
<longsleep> it might somewhat down to Chromium 30
<longsleep> work somewhat
 * ogra_ asked in #ubuntu-touch 
<ogra_> we onyl use blink (and even re-work it for Qt)
<popey> "Mozilla/5.0 (Linux; Ubuntu 14.04 like Android 4.4) AppleWebKit/537.36 Chromium/35.0.1870.2 Mobile Safari/537.36"
<popey> thats OTA-9
<popey> so chromium 35
<ogra_> right, doesnt talk about js
<longsleep> well, Chromium 35 would be too old in any case to connect to any recent browser
<ogra_> nor is it chromium beyond the renderer ... thats like using gecko with all your own stiff and showing firefox in the UA :P
<ogra_> ok, seems i was wrong, it is actually v8
<longsleep> question is if all the media extensions are compiled in including the capture code
<longsleep> webrtc for that matter
<ogra_> no
<longsleep> dtls
<longsleep> srtp :)
<ogra_> neither of them because they would have to be hooked into the toolkit
<ogra_> whicfh isnt dont yet
<ogra_> (my webrtc bug is open since 2.5y ... eventually it will come though :) )
<ogra_> *isnt done
<ogra_> we have basic camera and mic access working i think ... just no webrtc integration yet
<ogra_> i wonder how much would work if we cheated inthe UA though
<longsleep> ogra_: what do you mean cheating in the UA?
<longsleep> ogra_: we are doing feature detection for pretty much everything, so the UA would not help
<ogra_> longsleep, telling the server it is chromium 38
<ogra_> ah, k
<gregburd> I just tried Snappy for the first time on a NUC.  I like where the project is headed, the integration of a stable upgrade image A->B (and back) is a great step forward.  It takes the best part of CoreOS and grafts it into a Ubuntu world.  Thanks!  The "snappy" package manager is headed in the right direction as well, but I have to wonder (and I'm sure I'm
<gregburd> not the first to ask this) why not simply adopt the Nix package manager format?  Why invent yet another thing when Nix seems to have all the bases covered that snappy would like to address (and more)?
<ogra_> does nic integrate with apparmor and seccomp ?
<ogra_> *nix
<ogra_> does it use squashfs files as readonly filesystems of its packages ?
<ogra_> (i never heard of Nix, just curious)
<gregburd> http://nixos.org/nix/
<ogra_> seems to onyl be a package manager though ... you should take a look at snapcraft too if you look at snappy :)
<gregburd> http://sandervanderburg.blogspot.com/2015/04/an-evaluation-and-comparison-of-snappy.html is a good evaluation by a Nix maintainer of Snappy
<ogra_> snappy (the package manager) is very deeply integrated with the OS too ... it was essentially built around all the things we learned from the phone OS
<gregburd> So, I'm not saying "ditch all of Snappy" I'm saying "steal liberally the ideas from Nix and integrate them into Snappy" especially the way that Nix versions and inter-relates package dependencies (sim-link tree with a hash rather than version number used to separate packages).
<gregburd> I used to work at Amazon/AWS and there we had a similar (to Nix) way of managing package dependencies in deployment (called Brazil) with versioned trees of inter-dependent packages.
<gregburd> I like that deep integration ogra_ that makes sense.
<gregburd> If my mom or some other non-technical person is ever going to experience Ubuntu Desktop then we'll need that level of integration.
<gregburd> I'm sure that the phone project pushed the developers hard in the direction of super simple/reliable package distribution.
<ogra_> well, snappy does effectivbely not have any dependencies
<ogra_> you bundle everything
<ogra_> (you can have library snaps, but only within your own namespace)
<gregburd> ogra_ isn't that going to hammer memory as each different process brings its own copy of glibc along with it?
<ogra_> well, glibc is on the system. as long as you dont differ too much you dont really need to ship it (but you can indeed)
<ogra_> but yeah, there is surely some duplication that will eat some diskspce at least
<gregburd> my point is more generally related to shared libraries that will, in a snappy world, be duplicated and not shared
<gregburd> and RAM and cache lines
<gregburd> and that's power and performance lost
<gregburd> no?
<ogra_> right, yxou should just build static binaries if you can :)
<gregburd> er, I disagree
<ogra_> you prefer shared libs that arent shared ?
<gregburd> how is that not going to introduce the same problem?
<gregburd> no :)
<ogra_> either way, the confinement wont allow apps to share resources on that level
<ogra_> (unless the libs come from your own namespace ... i.e. libreoffice.ogra wouldnt have to ship boost but could consume libboost.ogra)
<gregburd> In the Nix (and Brazil) world a shared lib can indeed be shared by many other packages iff those packages all required the same version/config/build/dependencies that went into building glibc
<gregburd> So, where there is overlap the shared libraries are indeed shared
<ogra_> right, then we are back at dpkg :)
<gregburd> not really.
<ogra_> you ahve deps ... you have the same old probs
<ogra_> while bundling works just fine in the Mac and Windows world since ages
<ogra_> and yes, there might be some penalty ... but obviously neither of the other systems is hit by that to hard
<gregburd> So, here again we'll disagree (and as a former NeXT engineer I might have some knowledge on this topic)
<ogra_> (well, for some value of "fine" regarding windows :P )
<gregburd> But hey, I'm not here to start a fight
<gregburd> Please just consider reviewing the differences between Nix and Snappy with an open mind.
<ogra_> the point is that theoretically the snap should be completely independent from the OS
<ogra_> and be used standalone
<gregburd> Okay, fair point and I'm certain I don't fully get how Snappy is supposed to work as yet.
<ogra_> so that you can upgrade/rolback both of them completely independent ...
<ogra_> if you have deps you will hit massive probs with that rollback mechanism for example
<gregburd> Nix can do that as well (if "them" means "various applications and their package dependencies")
<ogra_> the typical focus is your home router where you install a NAS snap and attch disks, plug in a WLAN stick and can install an AP snap to manage your WIFI ... etc ... also robots where you can install different types of autopilots ...
<ogra_> while the vision of snappy doesnt stop there and will go towards desktops and phones over time, IoT, small devices, cloud instances and such are the current focus
<ogra_> i.e. at the current state it is rather unlikely you will see firefox or libreoffice snaps for such devices :)
<gregburd> So, here's the thing.  I would have put Ubuntu into deployment today for a rollout of a large number of NUCs that have to be managed as remote Kiosks if it had: 1) an opensource Omaha-esque centralized management setup, 2) a more Nix-like structure for inter-package dependency management and 3) a way to bridge the apt/dpkg world into the Snappy world until
<gregburd> the Snappy world is as rich as the existing apt/dpkg world is today (so a way to deal with the practicalities of an incomplete new system).
<ogra_> but rather the small samba server with a web interface ... or a upnp server or some such
<ogra_> while you cant bridge it, you can use snappy in classic mode
<gregburd> I get that, but don't preclude the future use cases with decisions that focus on today.
<ogra_> (in 16.04 that is)
<ogra_> snappy enable-classic: snappy shell classic ... and you are in an environment with full apt support ...
<ogra_> you will not be able to run services in there (they wouldnt survive a reboot) but you can use snapcraft in there to just rapidly snap up wnat you need and turn it into a snap package immediately
<gregburd> so that's the model for moving existing packages forward?
<ogra_> that the model for ... well, enabling you to turn anything into a snap quickly
<ogra_> so there is no need to use dpkg/apt ... its just a small yaml file away to turn anything you need into a snap
<gregburd> ok, that's promising
<gregburd> anything like the Omaha server/service available yet?
<ogra_> if you invest a bit more you can also write a config hook for any deb you use that can be accessed through snappys REST api
<ogra_> never heard of omaha ... is that like puppet/chef ?
 * longsleep has heard of Omaha beach
<ogra_> drinks and sun !
<gregburd> https://github.com/google/omaha
<gregburd> https://omaha.googlecode.com/svn/wiki/OmahaOverview.html
<ogra_> ah, no need for that :)
<ogra_> snappy cares
<gregburd> https://coreos.com/docs/coreupdate/custom-apps/coreupdate-protocol/
<ogra_> there is a builtin auto-update service that queries the sotre regulary
<ogra_> *store
<gregburd> so, that's great but sometimes services will need to have centralized control of the rollout of new software - limit the damage, etc.
<ogra_> if you update your snap in the store it gets pushed out
<ogra_> the store has staging areas
<gregburd> how are end devices assigned to various channels?
<ogra_> so you can push stuff to the edge channel and have your QA people pull that first ... once they give green light you can switchj it over to stable
<ogra_> thats a good question someone from the architects needs to answer :)
<ogra_> i havent played with that yet beyond ... well snappy install <packagename>/edge  ... which is the manual variant
<ogra_> i assume you can define it image wide via your gadget snap (which effectively defines the whole system of an image)
<gregburd> I'll have to review that part of Snappy, but I'm not sure it provides the level of control and flexibility I needed for a service that I used to run at Amazon/AWS.
<gregburd> interesting discussion, thanks for the time
 * gregburd back to work!
<ogra_> :)
<popey> ogra_: do you have an example of a snap that needs network access?
<popey> (I assume network is blocked by default unless specified)
<ogra_> i think client is always allowed ... (not sure about the snapcraft 2.0 world though)
<popey> yeah, 2.x
<ogra_> popey, https://github.com/strukturag/spreed-webrtc-snap/blob/master/snapcraft.yaml  see the "uses" thing between line 13 and 16 ... then see line 11 how the binary/service  uses it
<popey> I'm getting odd network errors so assume not
<popey> thanks
<zyga> ogra_: there ware some back and forth but I think we'll see snaps *not* getting network access in 16.04 unless they asked for it
<zyga> popey: ^^
<zyga> popey: so do ask for the migration-skill and for the network-client cap
<zyga> or something
 * zyga really EODs
<kyrofa> ogra_, hey does classic dimension not work on the dragon image?
<kyrofa> zyga, ah, good to know!
<kyrofa> zyga, I think that's smart
<kyrofa> zyga, oh you're gone
<kyrofa> ogra_, I get 'needle "ubuntu;xenial;arm64;default;" not found
<kyrofa> elopio, you may know something about that ^^  too, perhaps?
<elopio> needle? no, I don't know about that. I still have to find some time to resume my dragonboard testing.
<plars> elopio: some output from the checkbox-ized version of the tests... there are a few permission problems, possibly because we are running them from a snap? http://paste.ubuntu.com/15122636/
<robert_ancell> elopio, can you give me some pointers on a user test for https://github.com/ubuntu-core/snappy/pull/409?
<elopio> robert_ancell: from your comment, I suppose we could write a test that installs and remove a snap without sudo. I know nothing about polkit, so I'm not sure how we could set up the configuration for that user.
<robert_ancell> elopio, You'd probably want to to run a mock polkit service, but there's no mocked d-bus services in snappy currently are there?
<elopio> robert_ancell: basically this: https://github.com/ubuntu-core/snappy/blob/master/integration-tests/tests/installApp_test.go#L58
<elopio> without sudo with polkit.
<elopio> robert_ancell: no, there is not. But running the tests we have sudo, so we could get it working, I guess.
<elopio> but before exploring the mock option, is there a reason we can't use the real service?
<robert_ancell> elopio, I'm just don't know what environment you are running in. You probably want to test the two cases with PolicyKit (accepted / declined)
<elopio> robert_ancell: We are running this in a snappy system in scalingstack, bbb and raspberry pi. In my ignorance, I imagine that there's a way to tell polkit that the ubuntu user can install apps. And then there's a way to tell it to revoke that permission.
<elopio> then we just run snappy install and check the result.
<robert_ancell> elopio, is that ubuntu-core?
<robert_ancell> Because then we wont have polkit
<robert_ancell> If we can write the polkit config, we can configure both cases
<elopio> robert_ancell: so, how are you going to install polkit on your system?
<robert_ancell> That's a challenge...
<elopio> robert_ancell: ok, I would say that's the first step. In the ideal scenario, we will be able to install it just as you install it, and then we can run a test to make sure that we will never break your system.
#snappy 2016-02-19
<robert_ancell> elopio, did lots of talking here, it looks like we might be able to use macaroons to validate the user thus avoiding the need for PolicyKit (at least initially). So it may be possible to avoid adding these tests.
<robert_ancell> elopio, thanks for the info
<elopio> robert_ancell: cool.
<elopio> now we need to figure out how to test macaroons authentication :)
<robert_ancell> elopio, yeah, hopefully that wont be my problem! ;)
<sergiusens> elopio, kyrofa in case you get bored https://github.com/ubuntu-core/snapcraft/pull/328
<dholbach> good morning
<didrocks> hey dholbach!
<dholbach> salut didrocks
<zyga> good morning :)
<zyga> fgimenez: hey :)o/
<fgimenez> good morning zyga :)
<zyga> friday, I cannot believe how quick this week was
<shuduo_> hello, i'm working on a snappy lights-on on a rockchip board. i'm reading the doc from https://developer.ubuntu.com/en/snappy/guides/porting/. the first step in "Getting started" section but wonder if there is an official document regarding how to build oem snap. i can read code by referring to https://github.com/longsleep/snappy-odroidc but would like to know if official/internal doc exist. Thanks.
<shuduo> ogra_: ping
<longsleep> Good morning snappy, so my snap for 16.04 from yesterday was reviewed and accepted, but the new version shows as "unpublished" while the top of the myapps page says it is published. Any suggestions?
<longsleep> ah just found the Publish button at the very bottom of the page after all the history :)
<ogra_> shuduo, http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files has our official gadgets, note that trhis is for 16.04 and already uses the all-snaps setup for images though
<shuduo> ogra_: i'm reading on it too. i tried to build them but only pi2.moved be made successfully. i can refer to pi2.moved too but wonder why others don't work. Or should I need switch to 16.04? Another question is where i can download 16.04's decice.tar.xz armhf version? I tried u-d-f query but can't get it as I don't know what 16.04 channel exactly is.
<ogra_> shuduo, http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/current/
<shuduo> ogra_: got it. thanks.
<zyga> hmm, my pi updated last night
<zyga> but crashed (didn't reboot successfully)
<ogra_> capture the serial log (if you can)
<ogra_> thats not the all-snaps one i assume ?
<longsleep> ogra_: when i start with getting 16.04 on the odroidc1 should i look for that all-snap thing you are talking about?
 * longsleep might have some time on the weekend
<ogra_> longsleep, yeah, the old system-image stuff is dead, we'll default to all-snaps in 16.04 very soon
<longsleep> ogra_: ok cool, and what tool would i use to create a device snap or whatever it is called :)
<ogra_> longsleep, http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/files
<longsleep> ogra_: awesome thanks!
<ogra_> longsleep, you need xeinal for this (for the --squashfs support in snappy)
<ogra_> *xenial
<ogra_> longsleep, also: http://people.canonical.com/~ogra/snappy/all-snaps/dragonboard/ you need this u-d-f
<ogra_> (see the README for the options, --gadget, --kernel and --os all also take a local path to a snap)
<longsleep> great, i will have a look tomorrow. I also have the Pine64 and might try that one first
<popey> Still can't quite figure out how to do network client (not server) from my snappy app. examples seem to mostly be services/servers... any clues?
<ogra_> you'd do it the exactly same way
<ogra_> i.e. define the skill under "apps:" and just dont set "daemon:" for the app
<popey> got an example of something that's a client?
<didrocks> popey: 16.04?
<ogra_> popey, http://paste.ubuntu.com/15130014/
<ogra_> try something like this
<popey> didrocks: yes
<didrocks> yeah, ogra beats me to it :)
<ogra_> well, untested :)
<didrocks> looks like typo free :)
 * popey tries this
<ysionneau> any idea what could be the origin of this error? http://paste.ubuntu.com/15130024/
<popey> hm. "Bad system call" from the application ð
<ogra_> popey, check syslog, i bet there is a seccomp error
<popey> [262021.832942] audit: type=1326 audit(1455878770.782:89): auid=1000 uid=1000 gid=1000 ses=30 pid=32171 comm="whois" exe="/snaps/whois.sideload/INCRgCAKgHXE/usr/bin/whois" sig=31 arch=40000028 syscall=282 compat=0 ip=0x76ed2348 code=0x0
<ogra_> sig=31
<popey> wonder if it's trying to write to /tmp or something
<ogra_> scmp_sys_resolver 31
<ogra_> check that
<ogra_> (tells you the syscall)
<ogra_> all apps can write to /tmp ... the yhave a transparently mounted one that they own
<popey> oh
<ogra_> oh, wait
<popey> scmp_sys_resolver 31 returns UNKNOWN
<ogra_> scmp_sys_resolver 282
<ogra_> yeah
<ogra_> i picked the wrong thing from your line
<ogra_> not sig ... buts syscall= (obviously)
<ogra_> ysionneau, never seen that
<ogra_> but data.tar.gz sounds like a debian package somehow
<ysionneau> I've built a .snap package with snapcraft, it contains data.tar.gz inside
<ysionneau> the .snap seems to be pretty close from a .deb
<ogra_> that might not be allowed
<ysionneau> why would snapcraft generate something not allowed? :o
<ogra_> (not sure though)
<didrocks> ysionneau: that's the case in 15.04, it's using the same format (ar)
<ysionneau> yes
<didrocks> which has the control and data.tar.gz
<ogra_> ah, 15.04
<ysionneau> yes 15.04
<ysionneau> ok, let me explain what I'm doing, I'm adding support for cross compilation to snapcraft
<ysionneau> but in the control/manifest it still shows "amd64" instead of "armhf"
<ysionneau> so I modified the ar archive (extracted control.tar.gz, modified the amd64 to armhf, put back control.tar.gz in the .snap)
<ysionneau> but now I get this error
<popey> ogra_: scmp_sys_resolver 282 returns "bind"
<popey> it's whois, so it's doing a dns lookup I imagine
<ogra_> popey, hmm, then you might need more network- skills ...
<popey> I need more skills for sure ã
<popey> are they listed somewhere?
<ogra_> try adding "network-listener, network-service" to the caps line
<ogra_> servuice might be a bit much though, since you dont run a server
<ogra_> ysionneau, i'm pretty sure snappy creates checksums of the files it carries internally ...
<popey> hmmm
<popey> $ whois.whois 8.8.8.8
<popey> getaddrinfo(whois.arin.net): Servname not supported for ai_socktype
<ogra_> well, check syslog, there might be more
<popey> nothing
<popey> only the profile replace when it was installed
<ogra_> well, whois surely tries to access a socket it isnt allowed to (yet)
<popey> I guess.
<popey> is there no "give it all network access" like we do with clicks?
<ogra_> dunno, i'm still learning about skills
<ricmm> longsleep: hey simon
<ricmm> longsleep: I'm trying to run the webrtc client running on the arm64 device
<ricmm> works fine in local lan, over internet it cant stablish the call
<ricmm> "peer connection failed" but we can chat just fine
<ricmm> I'm exposing 8443 over the internet through a reverse ssh tunnel to a VPS of mine
<ricmm> could that be getting in the way? does spreed attempt to open other ports on demand for the peers?
<ogra_> you probably need other ports for the webrtc
<ricmm> hmm I cant reach it from my phone
<ogra_> weird
<ogra_> i did a call from laptop to desktop yesterday
<ricmm> oh, jesus
<ogra_> can you ping it from your phone ?
<ricmm> longsleep: yea I guess it opens more ports on demand
<kyrofa> ogra_, classic dimension doesn't seem to work for me on the dragonboard. Is that a known issue?
<ogra_> yes
<ogra_> bug 1543764
<ubottu> bug 1543764 in Snappy "snappy classic must use officially supported lxd images from simplestream; not unsupported ones from linux-containers.org" [High,New] https://launchpad.net/bugs/1543764
<kyrofa> ogra_, ahh, right I remember that one now
<kyrofa> ogra_, no known workaround?
<ysionneau> ogra_: would you know where those checksums are stored?
<ysionneau> ogra_: I found hashes.yaml which contains sha512 of the files in data.tar.gz , but nothing for files in control.tar.gz
<kyrofa> ogra_, I seem to remember you mentioning setting up a chroot?
<ogra_> kyrofa, scp http://cdimage.ubuntu.com/ubuntu-core/daily/current/xenial-core-amd64.tar.gz to the board ... create a dir under /home/ubuntu and extract it there ... then copy /etc/resolv.conf to etc/ and you can chroot ...
<ogra_> ysionneau, no, i have no idea, but i doubt you can safely hack an already assembled snap like you try to
<ysionneau> hmm too bad :/
<ysionneau> is snapcraft doing the .snap? or is it calling snappy?
<kyrofa> ogra_, sweet, okay. Hopefully this kernel doesn't have the swap deadlock bug that the linaro image had :P
<kyrofa> ysionneau, depends on the version of snapcraft
<ogra_> kyrofa, i have been using a 2G swapfile here, worked fine
<kyrofa> ysionneau, Version > 2, snapcraft does it. < 2, snappy
<kyrofa> ogra_, awesome :)
<kyrofa> ogra_, that should unblock the owncloud snap
<ogra_> yay
<kyrofa> ogra_, and I'm crossing my fingers for ROS
<ogra_> haha, yeah
<ysionneau> ok I'm using snapcraft 1.0.2 so it's snappy doing it...
<ysionneau> thanks kyrofa !
<ysionneau> cool now I can see in snappy code where is the error message "Can not handle"
<ysionneau> I had to checkout the 15.04 branch!
<ysionneau> it means it does not understand which kind of compression algorithm to use...
<zyga> good afternoon :)
<zyga> (lovely day here today)
<ysionneau> ok, it seems that when I use ar rD to replace control.tar.gz in the .snap by another one, it changes data.tar.gz name to data.tar.gz/ (at least that's what the sappy code sees, even if ar tv does not show the '/' suffix)
<ysionneau> this extra / makes the code fail to recognize a tar.gz
<ysionneau> by hexdumping I can indeed see extra / in the ar file header ...
<ysionneau> so that would be a bug in the ar tool? :o
<nessita> kyrofa, hi! I'm looking for a specific information and perhaps you can help. You know how snaps for 15.04 are totally incompatible with snaps for rolling-core, right? I wanted to know if there is such a clear difference between snaps targetting rolling-core and rolling-personal
<kyrofa> nessita, great question
<kyrofa> nessita, as of now, I don't believe so. Snappy (and snapcraft) don't do anything special for Personal right now. For example, there are no .desktop files, etc
<nessita> kyrofa, we are improving the Store UI and we are gonna restrict the releases a developer can choose for his uploads
<nessita> kyrofa, so you are saying that targetting both -personal and -core is safe, correct?
<kyrofa> nessita, right now I'd say yes, but it's important to point out that there isn't even a personal image right now
<nessita> kyrofa, I understand, so you are implying we should remove the rolling-personal release (or disable)?
<kyrofa> nessita, while there will be eventually, I'm not sure hiding that option would be a bad thing right now
<nessita> understood, thank you!
<kyrofa> nessita, though you probably want to check that with someone who knows more than I do
<nessita> kyrofa, yes, no worries, you will not be blamed :-)
<kyrofa> nessita, ha! I just mean I don't want you to do any work only to find out I was wrong and you have to put it back :P .
<ysionneau> ok I found the origin of the issue
<ysionneau> trailing slashes are legal in ar format : https://en.wikipedia.org/wiki/Ar_%28Unix%29#System_V_.28or_GNU.29_variant
<ysionneau> but the deb.go part of snappy does not handle them
<noizer> HI guys, just a short question. Is it the same when how I can communicate with gpio's from my raspberry pi with ubuntu-snappy
<noizer> ?
<zyga> noizer: hmm, can you ask that again please>?
<zyga> noizer: I've implemented a skill that allows to expose gpio's as "bool-file"
<zyga> noizer: but this is not the full GPIO, no way to set direction, etc
<ogra_> most likely via the skills system ... in 15.04 hw-assign worked for that, but this got moved into skills now
<zyga> noizer: (though that's east to add, bool-file was just the very first skill I made)
<zyga> noizer: easy* not east :)
<zyga> noizer: this week I also created an i2c skill and a demo snap that uses it
<zyga> noizer: I plan to expose subsequent hardware feature of the pi as we progress
<zyga> noizer: some things are not ready so you cannot still use skills for real, with released version of snappy
<zyga> noizer: if you want you can try my development branch that allows you to do more
<ogra_> zyga, the question is if the store already knows about these new skills, i guess noizer would like to upload his snap at some point
<zyga> noizer: have a look at http://github.com/zyga/snappy-pi2-piglow and https://github.com/zyga/snappy/tree/skills-demo-i2c
<zyga> ogra_: no, the store doesn't currently know but at the same time, it never will know about particular skill types, just what snaps declare and what devices declare
<zyga> noizer: so if you tell me more about what you need then perhaps I might be able to help you, perhaps not immediately but still
<noizer> ogra_ zyga when will the store know this skills?
<ogra_> perhaps it already lets them through ... i was just asking too :)
<noizer> I need i2c for an sensor and other gpio just for settings things
<noizer> zyga
<zyga> noizer: cool, stay in touch and we can talk
<zyga> noizer: I can create a simple gpio skill that exposes both the value and direction of a particular pin
<noizer> zyga So its not possible at this moment to use the gpio's
<noizer> zyga ok
<noizer> zyga how long does it takes to make this skill?
<zyga> noizer: no, skills are not "glued" to the rest of snappy, that's our focus
<zyga> noizer: depends on what you mean, it takes minutes to create a new skill but it will be a while before you can really use them with stuff in vanilla images
<noizer> zyga but it this snap won't be in the store. So I think
<zyga> noizer: if you develop it now with me
<zyga> noizer: you can be ready for skills in 16.04
<zyga> noizer: and you can help us iron out issues
<zyga> noizer: there's nothing better that I can think of, all of this will be live soon, just not today
<noizer> Zyga So when I'm developing it and pushes to the git it will be in 16.04
<zyga> noizer: but you can get the skill side to work, starting now, by working with me
<kyrofa> elopio, gah, I'm sorry, I lost track of the time
<kyrofa> elopio, oh wait, you're off
<zyga> noizer: I'm not sure I understand what you just said about git
<zyga> noizer: if you can, please tell me about your devleopment setup
<zyga> noizer: and about your needs for i2c and gpio
<zyga> noizer: I can also show you how to run my branch to see if your snap will work with what I'm building
<noizer> zyga Ok, I am making a device with many Sensors . On my OS there is Ubuntu Snappy with a snap that needs to connect with the gpio's of my raspberry pi
<noizer> These sensors need to interact with some status leds
<noizer> I know there needs to be I2C but for what. Thats now a mistery because my colleague knows that and is not at the office at the moment
<noizer> Zyga maybe that we can talk in a private conversation how we can make this
<longsleep> ricmm: Hey, did you ping me?
<ogra_> longsleep, yeah, he tried to run a spreed install behind a NAT ... and while we could see each others users we couldnt really establish a call
<ogra_> (i assume just opening 8443 wasnt enough)
<longsleep> ogra_: well you need a TURN server somewhere outside
<longsleep> or at least STUN
<longsleep> so the peer to peer connections can work
<ogra_> well, it works fine doing it in my LAN
<longsleep> yes peer to peer in LAN works
<longsleep> but to bridge the NAT some external help is required
<ogra_> i assume P2P on two realy internet IPs too ...
<ogra_> *real
<ogra_> right ... but our usecase is LAN only anyway ... so we're fine
<longsleep> the browsers have real internet addresses?
<ogra_> hah, no, the server does :P
<ogra_> anyway, we'Ãll only use it in LAN setups anyway
<ogra_> so all is fine
<longsleep> ok in LAN its easy. It depends on the firewall for the browsers if and what external help is needed. Most of the time STUN is good enough if the firewall allows UDP
<longsleep> if not, a TURN server is required (which is essentially a proxy) where all peers connect to
<longsleep> You could set this up easily on the server as well
<ricmm> longsleep: how can I set one of these servers up?
<ricmm> if I'd like to try
<longsleep> ogra_: https://github.com/coturn/rfc5766-turn-server/
<longsleep> ricmm: ^^^
<ricmm> cool
<longsleep> let me check if we have some instructions
<ricmm> spreed exposes config to point it to the server?
<ricmm> thanks
<longsleep> might have a miss in the config hook
<longsleep> but the server.conf has it
<longsleep> ricmm: the repository for the TURN server moved here it seems: https://github.com/coturn/coturn
<longsleep> for our public services we provide this (configured with shared secret authentication)
<ricmm> got it
<ricmm> ok, we'll keep demos to LAN only then
<longsleep> ricmm: we have this ticket to get better docs how to set up TURN :) https://github.com/strukturag/spreed-webrtc/issues/199
<ricmm> if we run into issues at setup at least I know how to set one up ;)
<longsleep> yeah - i can certainly also help if there are issues
<longsleep> ricmm: we recommend 2 public IP addresses for the TURN server and at least one of the listeners to use port 443
<kyrofa> nessita, the name collisions apply to 15.04 as well?
<kyrofa> (just got your email)
 * zyga -> tea
<nessita> kyrofa, yeah, otherwise the store-side implementation gets super more complex and, as per my talk with martin, we prefer to apply this to 15.04 as well
<kyrofa> nessita, ah okay. I ended up responding to that email, so sorry for the redundancy
<kyrofa> zyga, I just built a new vanilla edge image, and ubuntu/ubuntu isn't letting me in. Any clues?
<zyga> kyrofa: o_O?
<zyga> kyrofa: any serial ports to see what's going on
<zyga> kyrofa: does it boot
<zyga> kyrofa: can you ping it
<zyga> kyrofa: do you have a screen attached to it?
<ogra_> kyrofa, that happens if cloud-init didnt run properly
<kyrofa> zyga, it's virtualbox. Yeah, it boots and I have the ability to login, it's just not accepted ubuntu/ubuntu as valid
<kyrofa> zyga, ah, okay
<kyrofa> zyga, I'll toast it and run again, see if I can spot any errors
<zyga> kyrofa: man, why virtualbox
<zyga> kyrofa: just use kvm
<ogra_> did you build it with u-d-f ? check if it was properly built actually
<kyrofa> zyga, because you can't do both and I already have vbox machines
<zyga> kyrofa: ah
<kyrofa> zyga, long story :P
<kyrofa> ogra_, yeah. How would I check that it was properly built?
<ogra_> first of all by seeing no errors during building :)
<kyrofa> ogra_, ahh
<kyrofa> ogra_, the uber-technical way
<ogra_> kpartx is a constant source of pain ...
<ogra_> (i cant build any all-snaps image on any of my trusty systems ... they all fall over when loop mounting for example)
<ogra_> (they still produce an image though ... but with only half the content)
<kyrofa> ogra_, yeah I'm using a xenial VM. Can't make an image in an lxc container either... weird partition errors
<ogra_> yeah, needs an actual /dev for kpartx i guess
<ogra_> the worst part is that if you screwed that up once you *have* to reboot
<ogra_> and indeed my trusty machines run tons of scripts ... rebooting my desktop is 1h of work to get everything back in order
<ogra_> super annoying
<kyrofa> ogra_, you would die with my flaky multi-monitor setup, then :P
<kyrofa> ogra_, I have to reboot multiple times a day because my mouse pointer decides to go on vacation until I do
<zyga> kyrofa: man, why do you use stuff like that
<kyrofa> zyga, haha, two monitors?
<zyga> no, stuff not working
 * ogra_ has three on his desktop 
 * zyga has one, and two children with their own computers now ^_^
<ogra_> but a proper nvidia card :)
<zyga> ogra_: I was super surprised how stable amd has gotten lately
<kyrofa> zyga, I'd love to solve those problems, but then I wouldn't get my job done
<nessita> kyrofa, do you confirm I can remove your owncloud?
<ogra_> zyga, nah ... i like to play a game occasionally ... no more amd for me
<zyga> ogra_: on windows or ubuntu? he uses xenial and plays games all day
<zyga> ogra_: I have a wintendo for my games :(
<kyrofa> nessita, sure. Though do you know the answer to my question? Who's in charge of that Canonical ownCloud snap?
<ogra_> i use trusty for playing
<ogra_> but i honestly didnt manage to play anything since november or so
<zyga> ogra_: though I use ubuntu for playing casual games with my son :)
<kyrofa> zyga, ogra_ huh, regenerated the image and it works fine
<ogra_> well, good then :)
<nessita> kyrofa, you mean the owncloud from the canonical shared account?
<kyrofa> nessita, yes
<nessita> kyrofa, the account is generic, and I think many have access: snappy-canonical-storeaccount@canonical.com
<nessita> kyrofa, I can't not identify an individual
<nessita> kyrofa, is whoever can access that account in myapps
<kyrofa> nessita, very good, thank you!
<nessita> you are welcome!
<zyga> kyrofa: magic
<zyga> and I tell my children everything is rational
<zyga> while we deal with magic all day
<nessita> kyrofa, all reldeted! :-)
<nessita> deleted*
 * zyga feels sleepy
<dholbach> elopio, is there anything blocking landing https://github.com/ubuntu-core/snapcraft/pull/318?
<kyrofa> dholbach, I'm afraid he's out today and Monday
<dholbach> oh ok, no worries
<dholbach> thanks kyrofa
<kyrofa> dholbach, it looks good, but since he's been looking at it I'd like to wait for him to review one last time
<dholbach> right, makes sense
<didrocks> balloons: all good on the Ubuntu Core front for gsoc?
<balloons> didrocks, I think everything looks good.
<didrocks> \o/
<didrocks> thanks :)
<balloons> Thank you. We'll see what the students think soon enough :-)
<didrocks> yeah! ;)
<kyrofa> ogra_, what's with the dragonboard wifi driver and its handling of broadcasts?
<ogra_> kyrofa, working on that
<tbr> kyrofa: there have been claims that it was fixed on the linaro side
<tbr> kyrofa: it used to be horribly b0rken
<tbr> one reason why my board is collecting dust
<kyrofa> tbr, still seems kinda horribly broken :P
<tbr> no doubt
<tbr> the RE'd driver doesn't seem to be getting much love
<kyrofa> ogra_, alright cool. I've been reading blog post after blog post about yucky workarounds, and not one person discussed fixing the thing.
<tbr> linaro has other priorities
<ogra_> kyrofa, well, no idea yet how much the patch we have fixes it ... thanks to squashfs my turnaround time for doing tests did massively increase ... so its a very slow process now
<kyrofa> ogra_, yeah I feel ya
<kyrofa> ogra_, glad you're working on it though, thanks for your efforts :)
<zyga> kyrofa: what is the issue? wonky driver?
<ysionneau> allright I can now install my cross compiled .snap o/
<kyrofa> zyga, I assume so. It doesn't respond to ARP requests, so you can't reach it unless, say, it pings you first :P
<zyga> ahhh
<zyga> that explains some stuff :D
<kyrofa> zyga, so people are writing startup scripts to nmap the entire network
<zyga> well, non mainline kernel
<zyga> could be worse
<zyga> could be another blob
<kyrofa> zyga, true enough
<tbr> that only works in case of IPv4, IPv6 remains pretty much broken
<kyrofa> tbr, ah, I hadn't thought of that
<ogra_> who uses that anyway :P
<tbr> I've been complaining about this b0rkenness since last summer to the linaroooo people
<kyrofa> ogra_, haha, my lack of knowledge of ipv6 is staggering
<tbr> in the beginning they were blissfully unaware as everyone used usb-ethernet
<zyga> tbr: https://xkcd.com/865/
<tbr> hehe
<tbr> btw: if you urgently need it to work, you can probably just transplant the closed source module from the android images
<ogra_> heh, i'm working on an official image ... cant really do that :)
<tbr> yeah, but someone else might not
<tbr> the whole 96boards thing seems like dead on announcement anyway. there are two official boards, none of them compliant with official specifications. no enterprise boards. Meh, I'm starting to rant again.
<ogra_> tbr, i must admit i really like the dragonboard
<tbr> ogra_: if you successfully ignore all the closed source boot-loaders that it requires, the missing software support for a lot of the hardware, ...
<sergiusens> jdstrand, snappy dimmension problem [jue feb 18 20:33:58 2016] audit: type=1400 audit(1455912316.447:48): apparmor="DENIED" operation="open" profile="shout.sergiusens_server_0.52.0-1" name="/run/resolvconf/resolv.conf" pid=13224 comm="node" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<sergiusens> Chipaca`, https://github.com/ubuntu-core/snapcraft/pull/328
<jdstrand> sergiusens: are you using the network-client cap?
<sergiusens> jdstrand, I think I am; this works fine on ubuntu-core proper
<sergiusens> jdstrand, it fails with the snappy dimmension on classic
<jdstrand> sergiusens: can you file a bug with steps to reproduce?
<sommar> Hi, have a quick snappy question. How can I oweride the : failed to install: Signature verification failed, at installation of a package?
<sommar> I have seen som switches on a vid-clip on youtube, but cant remember it.
<jdstrand> --allow-unauthenticated
<sommar> Ahhh..
<sommar> Where can I find information about this switches?
<sommar> Thanks..
<jdstrand> snappy install --help
<jdstrand> there is also https://developer.ubuntu.com/en/snappy/
<jdstrand> I'm not sure if all of the switches are documented outside of the help system
<sommar> I feeling a litlebit stupid, why dident i try that one (snappy install --help).
<sommar> Thanks..
<sommar> I manage to install the package.
<jdstrand> cool :)
<jdstrand> np
<jdstrand> and no need to feel stupid. this is a whole new system :)
<qengho> I'm worried about differing behavior on identical runs of snapcraft. I can get an error message once, and run snapcraft again and get a different result.
<qengho> It could be related to another problem I'm working on, I suppose. I'll solve other first.
<qengho> Oh man. That's ugly. Found it.
<qengho> So, should parts be used as a kind of flow-control between discrete stages of building one thing? download and unpack tarball, then configure source, then build source and package?
<qengho> Or, are parts supposed to be discrete sources of code that are used to create a package?
<qengho> I see a "copy" that makes me think the source of one part could be the output of another part.
<qengho> :q
<qengho> :q
<qengho> Ah, I guess they are all discrete units of code. Dang.
#snappy 2016-02-20
<ogra_> ricmm, or beuno, can one of you approve four snaps ? (namely: https://myapps.developer.ubuntu.com/dev/click-apps/4573/ https://myapps.developer.ubuntu.com/dev/click-apps/4574/ https://myapps.developer.ubuntu.com/dev/click-apps/4575/ and https://myapps.developer.ubuntu.com/dev/click-apps/4576/ )
<ogra_> some basic packages to fill the arm64 store :)
 * asac wonders if awe committed the bluez5 snapcraft fixes
<asac> jdstrand: ?
<ogra_> asac, i think he did
<asac> ogra_: he didnt
<ogra_> (he talked about doing it in the other channel)
<asac> at least not in his branch
<asac> no commits
<ogra_> oh
<asac> ogra_: see other chan
<ogra_> can't i'm on the wrong machine
#snappy 2016-02-21
<qengho> Ugh, in building, I have a sub-sub-sub-process that calls pkg-config and it sets the "prefix" internally to something nuts. From my custom plugin extending BaseHandler, self.run([pkg-config --cflags gio-2.0]) is "-pthread -I/home/foo/snap/stage/usr/include/glib-2.0 -I/home/foo/snap/stage/usr/lib/x86_64-linux-gnu/glib-2.0/include"
<qengho> from subprocess.run(same), it's properly "-pthread -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include".
<qengho> That took a while to decipher.
<ricmm> ogra_: 4576 seems aproved
<ogra_> ricmm, nope, neither of the four is
<ogra_> oh, wrong ... the first three are "ready to publish"
<ogra_> 4576 actually has an issue with an external symlink it seem
<ogra_> s
 * ogra_ will check that later today
<ogra_> ok, fixed
#snappy 2017-02-13
<olympionex> in my snapcraft project folder, I have a src dir.  After I run snapcraft, the contents of this folder gets copied to the src dir of every single part.  Is there a way to control this behavior? Organize or something?
<olympionex> actually, for every single part in project/parts its in the build, src, and install dir
<olympionex> scratch that, it happens for parts that use my custom plugin as well as the dump plugin
<knight__> yeah i need to figure that out too
<olympionex> knight__: are you referring to the question I asked?
<knight__> olympionex, yep
<knight__> this channel is pretty sleepy... been asking questions the last 3 days with basically no answers :)
<olympionex> knight__: I believe I made some progress just now.  When you create a custom plugin it inherits from snapcraft.BasePlugin which has a member called 'source'
<olympionex> by default, it seems to copy whatever is in source to the project/parts/src dir
<olympionex> and by default that source parameter is the project directory itself
<knight__> Oh I see, that's for custom plugin.
<knight__> I have a src dir in my snapcraft project folder
<olympionex> well it works the same with dump I believe, testing it out
<knight__> Then a subdir, and a script, that i'm trying to use dump to move into destination app command
<olympionex> if you don't specify the source option for the plugin, it appears to copy the entire project directory to that part's source dir
<knight__> my source is defined as "src/"
<olympionex> i'm still verifying.  I suspect what you want to do is create a project/src/script_dir
<olympionex> and set the source for the dump plugin to src/script_dir
<olympionex> then use organize to decide exactly where to copy it
<knight__> yeah
<knight__> i did source: src/ and then organize with item: item_dir/item
<knight__> but maybe that's wrong?
<olympionex> well previously I was using this:
<olympionex> http://pastebin.com/LxRDzRUz
<olympionex> i'm currently working on modifying / testing to make a specific directory project/src/netconf that only has the file netconf.py
<olympionex> so that it doesn't copy everything in the whole project/src directory to src of that part
<knight__> yeah that's similar to what i want
<olympionex> yeah, that appears to work for me
<olympionex> you just need to create subdirs for each part under src
<olympionex> and be careful that for any part which you don't specify source, it will probably copy the whole project dir in
<knight__> maybe we need to do:
<knight__> organize:    item_dir:    item
<olympionex> thats not what I'm doing
<olympionex> the key should be the filename relative to the source dir
<olympionex> and the value should be the full path where it will end up in a fileset
<knight__> Yes, that's what I'm saying
<olympionex> whether that is stage or prime
<knight__> We can add another level to represent the subdir
<knight__> i.e. source + subdir + item
<knight__> organize:    item_dir:    item: item.py
<olympionex> ah, you mean a suggestion to modify the snapcraft source itself?
<knight__> the yaml
<knight__> organize statement
<olympionex> all I had to do to fix it was this:
<olympionex> http://pastebin.com/F2ar752n
<olympionex> basically just change src to src/netconf
<olympionex> and move netconf.py from src to src/netconf
<knight__> yep
<knight__> my suggestion is if you have other files in src/ with other subdirs and don't want to isolate the source to that
<olympionex> ah, we were just talking past each other.  Thats what I meant by modifying the snapcraft source -- would require changing the operation of snapcraft
<knight__> ?
<knight__> i guess dump copies all
<knight__> you can't cherrypick
<olympionex> yeah, as far as I can tell, the default behavior of possibly all plugins is to copy everything from source
<olympionex> I haven't looked yet, but it must be in BasePlugin
<knight__> there's got to be a way to be able to pull something down from a dir or remote, and cherrypick
<olympionex> I think it would require something like having filesets for the pull operation
<knight__> need to figure out how to cross-build armhf support
<ffox> is there any way to force snapd to skip a task in a changeset?
<ffox> I'm trying to bring up a board and it keeps hanging on "Run configure hook of "core" snap if present"
<olympionex> knight__: I just noticed that you have to do the same for the nil plugin, which is kind of annoying -- otherwise it will copy the whole project directory to the part source
<mup> PR snapd#2834 opened: release: add galliumos support <Created by mvo5> <https://github.com/snapcore/snapd/pull/2834>
<zyga> good morning
<mup> PR snapd#2835 opened: strutil: support version compare with empty strings <Created by mvo5> <https://github.com/snapcore/snapd/pull/2835>
<mup> PR snapd#2836 opened: release: assume higher version of supported distros will still work <Created by mvo5> <https://github.com/snapcore/snapd/pull/2836>
<zyga> popey: thank you for the bug reports on distro support sir!
<sborovkov> jdstrand: Hi! So I tried to declare plugs and slots as you described. Ended up with this. https://hastebin.com/rijasoyoxo.pl But when uploading to the store automatic review fails with this now human review required due to 'deny-connection' constraint for 'slot-attributes' from base declaration
<sborovkov> jdstrand: did I do something wrong?
<popey> zyga: no worries, thanks for fixing them :)
<zyga> popey: mvo did all the work with a fantastic future-proof branch
<popey> \o/
<davmor2> zyga: pfff /me sets up linux from scratch to test the wild claims I'll be back in two whole years with reports ;)
<zyga> davmor2: I expect nothing less than utter success :)
<mvo> jibel: quick question about #1663666 - do you run zesty as well? the bugreport is originally on a zesty system, I tried various things to reproduce but no luck so far
<mup> Bug #1663666: max-format is not a positive integer assertion installing unity8-session snap <snapd:New> <Snap Store:New> <Unity8 Session Snap:Confirmed> <https://launchpad.net/bugs/1663666>
<jibel> mvo, yes on zesty too
<mvo> jibel: excellent, let me test it there
<jibel> mvo, I wondering if it happens after a package or snap upgrade. After a reboot the problem was gone
<mvo> jibel: ohhh, that is super useful information
<mvo> jibel: let me try with that
<mup> PR snapcraft#1138 closed: python plugin: exclude the RECORD files <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1138>
<joedborg> hello all!  quick question; is it possible to change the user running the app inside the snap?
<mup> PR snapd#2837 opened: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<zyga> joedborg: not at this time
<joedborg> zyga: thanks, do you know what user the application inside sees?
<joedborg> i assumed it was the user who initiated it, but doesn't seem to be the case
<joedborg> even though if i run with --shell and do a `whoami` it does say the same
<zyga> joedborg: yes, when it is a normal command it runs as the user who started it
<zyga> joedborg: when it is a service/daemon it runs as root
<joedborg> zyga: aaaah, thanks, that makes sense (i'm running a daemon)
<brunch875> I just noticed hexchat uses ~/snap/hexchat/17/.config instead of ~/.config
<zyga> brunch875: that's correct
<zyga> brunch875: for snaps that are not using confinement:classic the HOME environment variable is changed
<zyga> brunch875: since most apps correctly derive $XDG_CONFIG_DIR from $HOME you end up with what you said
<brunch875> aaah, so I shouldn't worry about the application defaults
<zyga> brunch875: note that snaps don't normally have access to your home directory
<zyga> brunch875: no, that's fine
<brunch875> ah thank you, didn't really know how to ask the question but you read my mind :)
<zyga> I know ;)
<deanman> ogra_, thanks for the answer to my question the other day. In fact, it was mentioned in a different document on developer.ubuntu.com that the first install should take place with a wired connection.
<ogra_> yeah, i hope we nail that bug some day
<deanman> ogra_, some day? It can't be that huge, can it ? By the way, is it worth filing a change request on "https://developer.ubuntu.com/core/get-started/raspberry-pi-2-3"?
<ogra_> does that point to wlan stuff ?
<deanman> It can be frustrating for first time users when they are following that guide and somehow stumble on that configuration step.
<deanman> It's step #3, i guess we could add a note saying that first setup should be wired ?
<deanman> I found a similar note on this https://developer.ubuntu.com/en/snappy/start/installation-tips/ but no reference to the first user-guide
<mup> PR snapd#2838 opened: allow core_support interface to modify /etc/hostname using hostnamectl <Created by ogra1> <https://github.com/snapcore/snapd/pull/2838>
<ogra_> davidcalle, ^^^ should we have a known issues castegory on these pages ?
<jamespage> hi all
<deanman> ogra_, is there a dedicated launchpad group that is working to polish things out with snappy ?
<jamespage> I've been comparing performance of commands provided as snaps vs debs
<ogra_> deanman, depends ... there is a github team for the snapd related bits and there is snappy-dev on launchpad for the image builds
<jamespage> even a classic confinement snap appears to have some overhead that I don't see with a deb - would the use of squashfs have some impact here or am i looking at something else?
<jamespage> 1.6 s vs 0.5 seconds for example - thats just to run neutron --version
<jamespage> so no network ops in the way
<zyga> joedborg: can you say what you are measuring exactly?
<zyga> er
<zyga> jamespage: ^^
<jamespage> zyga, my tests are
<zyga> joedborg: I'm sorry, irssi confusion
<jamespage> time /snap/bin/neutron --version
<joedborg> zyga: no worries :)
<jamespage> vs
<ogra_> jamespage, i doubt it is the filesystems fault but rather the way of executing
<jamespage> time /usr/bin/neutron --version
<ogra_> there is surely some extra overhead in that bit
<zyga> jamespage: snap adds three execs along the way: snap-run -> snap-confine -> snap-exec
<zyga> jamespage: two go and one C executables
<zyga> jamespage: there's bound to be some overhead but typically it is hard to even measure
<zyga> jamespage: I'd be interested to know more
<jamespage> zyga, me to
<zyga> jamespage: can you run a /bin/true test?
<zyga> install a snap that just runs /bin/true)
<zyga> jamespage: e.g. snapd-hacker-toolbelt
<zyga> jamespage: it ships snapd-hacker-toolbelt.busybox
<zyga> jamespage: then you can just say snapd-hacker-toolbelt.busybox true
<zyga> jamespage: and see how "fast" that is
<ogra_> and have a local busybox to compare ?
<zyga> jamespage: that should be a good ballkpart number for the overhead itself
<zyga> ogra_: well, true just takes 0.00 seconds I bet :)
<ogra_> dont we have a bash in the hacker toolbelt for direct comparison ?
<zyga> jamespage: do a 100 runs and see what you get
<zyga> ogra_: I think there's bash as well
<zyga> ogra_: because snapcraft :/
 * ogra_ wouldnt trust busyboax and bash "true" to be the same
<deanman> ogra_, is this for the image builds ? https://launchpad.net/~snappy-dev
<zyga> ogra_: but that does run busybox "true" applet
<ogra_> deanman, thats the team managing the builds ...
<zyga> ogra_: it's the busybox true
<jamespage> zyga, looks like about 0.033s vs 0.001s (snap vs /bin/true)
<ogra_> zyga, right, and to compare with a std true you would have to have the busybox classic deb installed
<zyga> jamespage: how many runs did you measure?
<jamespage> zyga, ~20 on each
<jamespage> zyga, first hit on snap was a bit more expensive
<zyga> ogra_: I'd say that std true is "0.00" in this case
<jamespage> 0.485s
<zyga> jamespage: yes, the first run of snap-confine does way more
<zyga> jamespage: can you stick this in a repository
<zyga> jamespage: we could benchmark this periodically
<zyga> jamespage: and try to come up with a way to lower those numbers
<jamespage> zyga, I'm pondering whether the fact its python is making a diff there
<zyga> jamespage: is the app shipping .pyc files?
<zyga> jamespage: maybe that is a factor?
<jamespage> zyga, that was my thinking
<jamespage> there are no pyc's in the snap itself
<zyga> jamespage: or the pyc files it ships are for different interpreter and python recompiles everything anyway
<zyga> jamespage: there you go
<zyga> jamespage: my idea: ship python _and_ just pyc files, skip .py
<zyga> jamespage: small and faster
<jamespage> zyga, well we should make that the default for the snapcraft python plugin then
<deanman> ogra_, on that team's page there are no bugs for the wlan. Are they reporting them elsewhere? github ?
<ogra_> deanman, in launchpad, but it is a kernel bug ...
<zyga> jamespage: would be nice to have this as an option
<zyga> jamespage: anyway, just an idea
<ogra_> deanman, https://bugs.launchpad.net/ubuntu/+source/linux-raspi2
<deanman> ogra_, thanks
<jamespage> sergiusens, ^^ any thoughts on the conversation above re perf of python apps in snaps?
<davidcalle> deanman: indeed, for the record, the source of the raspi setup page is here https://github.com/ubuntudesign/developer.ubuntu.com/blob/master/templates/pages/core/get-started/raspberry-pi-2-3.md, if you want to file a bug/make a PR
<deanman> davidcalle, got it, thanks!
<deanman> davidcalle, PR filled, added small description with that as well. Feel free to rephrase as English is not my native tongue.
<davidcalle> deanman: thanks a lot, I'll have a look!
<sergiusens> jamespage: .pyc? You should be able to force add them through filesets. We don't by default because many people complained about conflicts when using N python parts as all the pyc files (coming from the same py) would be different
<jamespage> sergiusens, what happens if they are not shipped? does the python in the snap compile them with every invocation?
<zyga> jamespage: yes
<zyga> jamespage: and discards them
<zyga> sergiusens: you could set a variable for python to store .pyc files in $SNAP_DATA/$SNAP_USER_DATA
<zyga> (or just .cache)
<zyga> sergiusens: could be a nice compromise
<jamespage> zyga, sergiusens: I wsa digging to see if that was possible
<zyga> jamespage: I bet it is
<zyga> it's just software :)
<sergiusens> zyga: given classic we are removing env vars as a default in our plugins, but people are welcome to do so if they want
<mup> PR snapd#2828 closed: tests: increase service retries <Created by fgimenez> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2828>
<mup> PR snapd#2831 closed: interfaces: add missing recvfrom syscall to dbus interface <Created by mvo5> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2831>
<didrocks> sergiusens: hey! do you know if the parts importer will check as well for snap/snapcraft.yaml?
 * didrocks creates a new parts and would like to know
<didrocks> (for cloud parts)
<mup> PR snapd#2839 opened: debian/tests: map snapd deb pockets to core snap channels for autopkgtest <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2839>
<elopio> jdstrand: there was a bug to let me write in /dev/shm/envoy_shared_memory_0, right? I find similar things, but I'm not sure which one that was.
<jdstrand> elopio: I'm strugging to parse that question, but you can write to:
<jdstrand> /{dev,run}/shm/snap.@{SNAP_NAME}.**
<jdstrand> /{dev,run}/shm/sem.snap.@{SNAP_NAME}.*
<jdstrand> /{dev,run}/user/[0-9]*/snap.@{SNAP_NAME}/**
<jdstrand> elopio: so if you follow any of those naming schemes, it is allowed
<ogra_> /dev/user ??
<jdstrand> ogra_: yeah, that is wrong
 * jdstrand will fix
<ogra_> :)
<elopio> jdstrand: so, I need to patch upstream? We are never going to let a snap write to /dev/shm/envoy_shared_memory_0 ?
<jdstrand> I shouldn't have pasted that anyway cause it wasn't in shm, but glad I did :)
<ogra_> on linux everything is a file ... even the user ;)
<sergiusens> didrocks: about that, josepht would know for sure
<sergiusens> but iirc, it uses the general mechanics we have for part loading
<jdstrand> elopio: I don't know what /dev/shm/envoy_shared_memory_0 is, but it is not snap-specific so we won't add a rule to the default template or a plugs side interface for that. if this is for a particular slot implementation, we could. you probably want to look at https://github.com/sergiusens/snapcraft-preload if you want to avoid patching
<elopio> jdstrand: I thought I read a discussion about this, but it's all too fuzzy. I think we can suggest them to patch their shm path when in a snap, doesn't sound too bad.
<elopio> I'll play with preload too. Thanks for the pointer.
<jdstrand> elopio: if you are looking for the bug, it is: https://bugs.launchpad.net/snapcraft/+bug/1577514
<mup> Bug #1577514: Support preloading to make snaps feel at home <snapd-interface> <Snapcraft:Triaged by sergiusens> <https://launchpad.net/bugs/1577514>
<jdstrand> elopio: sergiusens wrote https://github.com/sergiusens/snapcraft-preload to help with that
<sergiusens> well, I ripped off from deb2snap as suggested by mterry and not quite finished
<didrocks> josepht: do you know if the part importer handles the snap/ subdirectory?
<elopio> thanks. I think this is enough info to restart the conversation with them. This is a project from lyft :)
<josepht> didrocks: I don't think so.  Let me check to be certain though.
<josepht> didrocks: no, it does not yet support snap/snapcraft.yaml.  Do you mind filing a bug and I'll get that added.
<didrocks> josepht: is there any way to workaround, like pointing to a subdir?
<didrocks> (meanwhile?)
<josepht> didrocks: sorry not that I know of.  can you add a symlink to snap/snapcraft.yaml?
<mup> Bug #1663175 opened: chroot not allowed in strict <Snappy:New> <https://launchpad.net/bugs/1663175>
<didrocks> josepht: yeah, good idea
<brunch875> is it fine to install something with apt-get when there's already its snap installed?
<brunch875> I have some strange freeze with hexchat and I want to see if it also occurs out of confinement
<ogra_> regarding the binray thats totally fine ... note that /snap/bin is last in your PATH though ... the deb version will be prefererred
<ogra_> regarding the app configuration it totally depends on the snap though
<ogra_> (and cache... data etc)
<niemeyer> joc, jdstrand: Provided a comment on snapd#2626.. can we please try to review/finalize it so we get this one through?
<mup> PR snapd#2626: interfaces: relax path requirements for serial <Created by jocave> <https://github.com/snapcore/snapd/pull/2626>
 * brunch875_ is back from crashing
<jdstrand> niemeyer: ack (responded)
<mup> PR snapd#2840 opened: unity7: support missing signals and methods for status icons <Created by 3v1n0> <https://github.com/snapcore/snapd/pull/2840>
<mup> Bug #1664297 opened: Snapped indicators using custom themes or actions doesn't properly work <snapd-interface> <Snappy:In Progress by 3v1n0> <https://launchpad.net/bugs/1664297>
<Trevinho> jdstrand: ^ about that.... I was also wondering that maybe we should instead move all the xdg-desktops related features to a different policy, and inheriting that in unity7, isn't it?
<Trevinho> jdstrand: I see some kde apps only depending on that while it wouldn't be needed, as they only care about indicators, appmenu and few others
<Trevinho> notifications, of course...
<jdstrand> Trevinho: well, unity7 is meant to be a transitional interface and I think it is ok for it to have things that kde apps won't use. there are quite a few things in there that are expected to work in a unity7 environment but that an application may choose to not use
<jdstrand> Trevinho: interfaces also don't imply other interfaces, so if it was split out, everyone would have to use 'plugs: [unity7, xdg-desktops]' instead of just 'plugs: [unity7]', which could be fine, but we can't break people now by moving stuff out
<jdstrand> perhaps for series 18 we could do that, but my first point still stands
<jdstrand> Trevinho: you have that bug marked in progress. does that mean you are preparing a PR?
<Trevinho> jdstrand: I mean at code level.... So that unity7 definition reusess xdg-desktop, then if you mention just one it will work. While mentioning both is pointless
<Trevinho> jdstrand: it's linked
<Trevinho> errr... or maybe not yet :-D
<Trevinho> jdstrand: https://github.com/snapcore/snapd/pull/2840
<mup> PR snapd#2840: unity7: support missing signals and methods for status icons <Created by 3v1n0> <https://github.com/snapcore/snapd/pull/2840>
<niemeyer> jdstrand: Thanks
<niemeyer> jdstrand: Seems okay that AA is stating something else
<niemeyer> jdstrand: We'll never even ask AA to mediate if we don't get a proper path that passes the Go one
<Trevinho> jdstrand: fixed
<niemeyer> joc: Can we please get back to having more controlled paths there, as suggested in the PR?
<Pharaoh_Atem> zyga: ping
<joc> niemeyer: we can do. ogra's argument about the maintenance burden not strong enough for you?
<niemeyer> joc: Thanks
<jdstrand> niemeyer: that's correct. the aa rule is only there as an additional protection for the cgroup anyway. both need to agree of course, but the go one is the really important one for udev tagging and the cgroup
<niemeyer> joc: I've just spent the past 6 hours reviewing snapd PRs.. I'm all for avoiding the burden of maintenance :)
<joc> hehe
<niemeyer> joc: But giving away unknown devices with names we didn't bother to consider sounds like a poor plan
<niemeyer> joc: *tty* happens to match things such as PEOPLES CONSOLES
<zyga> Pharaoh_Atem: hi
<Pharaoh_Atem> zyga: did you see the bug filed about the lack of snapd builds in Fedora?
<zyga> Pharaoh_Atem: I replied to it
<mup> PR snapd#2838 closed: allow core_support interface to modify /etc/hostname using hostnamectl <Created by ogra1> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/2838>
<Pharaoh_Atem> zyga: so have you made any progress on rebasing snapd and snap-confine patches?
<zyga> Pharaoh_Atem: no, I'm still stick and I was really not doing much this weekend :/
<zyga> Pharaoh_Atem: (or weekdays for that matter)
<Pharaoh_Atem> okay
<mup> PR snapcraft#1139 opened: plainbox-provider plugin: filter out sitecustomize <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1139>
<mup> PR snapd#2737 closed: tests: add more debug if ubuntu-core-upgrade fails <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2737>
<joc> elopio: have you seen any collisions between file etc/python3.5/sitecustomize.py in python parts?
<joc> elopio: it seems these changes to support classic are breaking things for parts that pull in python but don't use the python plugin
<niemeyer> jdstrand: ping re snapd#2714
<mup> PR snapd#2714: interfaces: interface to allow autopilot introspection <Created by sbaldassin> <https://github.com/snapcore/snapd/pull/2714>
<niemeyer> jdstrand: Sent some comments there
<Cynerva> anyone available to help us figure out permission errors on the kubelet snap? zyga?
<jdstrand> niemeyer: re autopilot> ack
<OerHeks> snap install ohmygiraffe # finally a game i master .. oh wait, those lions
<knight___> anyone have documentation on how to cross-build to armhf in snapcraft?
<kyrofa> knight___, snapcraft doesn't really support cross-building
<kyrofa> knight___, your best bet is probably to either build on-device or use the Launchpad snap builders
<knight___> well how are people building snaps for other platforms then?
<knight___> ha build on-device? yikes.
<kyrofa> knight___, personally, the LP snap builders
<sborovkov> knight___: you can actyually using docker and qemu
<knight___> sborovkov, that's what i heard. any docs on that?
<kyrofa> Yeah, qemu is an option as well, but it's brutally slow
<knight___> Can't be any slower than building on device.
<kyrofa> Fair enough
<kyrofa> knight___, I can't recommend the LP builders enough. They can even auto-upload to the store when the build has completed
<sborovkov> knight___: let me search. I am sure it was in mailing list
<knight___> Ok, open to using launchpad snap builders. Docs on that too?
<kyrofa> knight___, https://kyrofa.com/posts/building-your-snap-on-device-there-s-a-better-way
<sborovkov> knight___: https://github.com/chihchun/snapcraft-docker
<kyrofa> knight___, note that since that article was written LP added support for auto-syncing git repos from elsewhere
<knight___> Would be really cool if we had a snapcraft flag to kick off a cross-build ... like snapcraft cleanbuild --platform armhf and then it kicks it off, either on launchpad or in the snapcraft backend or in a qemu locally.
<kyrofa> knight___, so you can set things up such that new snaps are built when you push to X branch on github, for example (what I do personally)
<knight___> ahh yeah that's a good idea
<knight___> thanks @sborovkov
<lutostag> Are there any snapd bindings for other languages? (for instance if I wanted to run "snap download" "snap find" programatically, or do I have to wrap the cli manually?)?
<zyga> lutostag: yes
<zyga> lutostag: we have gio/glib bindings so you should be able to use this from any language that supports this
<zyga> lutostag: the package is (I believe) snapd-glib or something like it
<zyga> lutostag: let me know if you need something
<lutostag> zyga: neato, couldnt find them on https://github.com/snapcore, any link to to a sweet blog-post?
<zyga> lutostag: ah, I should make one :)
<zyga> lutostag: and we should move the project, it is on https://code.launchpad.net/snapd-glib
<Pharaoh_Atem> I wonder where the qt/c++ bindings are?
<knight___> thanks kyrofa, i'm reading up and registering on Launchpad now
<Pharaoh_Atem> those and the snapd-glib project need to move out of LP
<lutostag> zyga: much thanks!
<zyga> Pharaoh_Atem: not sure, I wonder if the KDE folks wrote some for the app store
<Pharaoh_Atem> they didn't
<zyga> Pharaoh_Atem: btw; I'm still sick so instead of coding I write text instead
<zyga> Pharaoh_Atem: have a look at new.zygoon.pl
<Pharaoh_Atem> supposedly the guy who wrote snapd-glib also wrote qt/c++ bindings too
<zyga> Pharaoh_Atem: I'll add comments over time
<zyga> Pharaoh_Atem: ah, I don't know anything about that
<Pharaoh_Atem> zyga: afaik, my understanding about debian and file caps is that there's no way to express them in dsc packaging
<Pharaoh_Atem> dpkg-deb just winds up stripping them :/
<zyga> Pharaoh_Atem: does .dsc care? I though that this is a tarball / weird FS someone may want to use issue
<zyga> Pharaoh_Atem: in any case, whatever it is....
<zyga> just annoying
<Pharaoh_Atem> I use "dsc packaging" as shorthand for debian source control
<zyga> divergence
<zyga> ahh
<knight___> hey kyrofa, that's pretty slick. i'm all set up and building through it now !
<zyga> right
<Pharaoh_Atem> aka, the way debian packages are made officially
<Pharaoh_Atem> zyga: nice post :)
<lutostag> In snapd's help for snap install (for the revision arg) it states: "to which you must have developer access", what precisely does that mean?
<Pharaoh_Atem> lutostag: it must be run as root
<zyga> lutostag: I believe that as a developer of a snap you can install any revision from the store
<zyga> Pharaoh_Atem: no, not that :)
<Pharaoh_Atem> no?
<Pharaoh_Atem> I thought it was referring to superuser access, since nothing in snapd works without it
<zyga> lutostag: but as a consumer you can just install the revision that is published in a channel
<zyga> lutostag: the exception is that if you have it installed already you can switch between revisions with refresh
<lutostag> zyga: and this will disable auto-updating with the regular 4x a day refreshes?
<zyga> lutostag: but just among the set you already have on your disk
<zyga> lutostag: honestly, I don't know :)
<lutostag> ehhe
<zyga> lutostag: chipaca is the person to ask
<zyga> lutostag: I work on other areas and this particular detail is a bit obscure
<lutostag> motivation... juju snap testing and switching between lots of versions when we want
<zyga> lutostag: but the general idea is that as a devleoper you see all the revisions but users just see what you publish
<mwhudson> sigh, where can i download ubuntu core images again?
<zyga> mwhudson: snap download
<mwhudson> zyga: that downloads a snap surely
<mwhudson> i want something to give to kvm
<lutostag> ehhe
<zyga> mwhudson: ah, you want the big image?
<zyga> hmmmm
<mwhudson> yes
<zyga> mmm
<zyga> there must be a place :)
<zyga> sorry, I don't recall where we publish those
<zyga> ogra_: ^^
<lutostag> http://people.canonical.com/~ogra/snappy/all-snaps/daily/current/
<mwhudson> there is http://releases.ubuntu.com/ubuntu-core/16/ubuntu-core-16-amd64.img.xz but i bet that's old
<mwhudson> lutostag: thanks
<zyga> mwhudson: you can just use it and it will update itself but you surely know that
<mwhudson> zyga: want to test what console-conf is doing in current releases so that won't help :)
<linggao> Hi all, this my firt time in this channel. Is this a place to ask Ubuntu snap questions?
<lutostag> linggao: indeed it is! welcome!
<kyrofa> Hey there linggao
<linggao> lutostag, kyrofa thanks!  We have developed a snap.  There is problem refreshing the snap on an arm device like a Rasberry Pi.
<linggao> The process died on monting.
<linggao> Mounting.
<linggao> Here is the detail.
<linggao> I ranÂ "snap refresh --devmode --edge mysnapname"Â on my rpi2 to pick up the latest snap. It downloaded the new snap, and sometime after displayingÂ [|] Mount snap "mysnapname" (53)Â it threw me into kdb on the console. After rebooting, the new snap seems to be working ok.
<linggao> The refresh works on an x86 machine though.
<linggao> The kernel debug showed this "[336032.404195] Unable to handle kernel NULL pointer dereference at virtual address 00000008"
<kyrofa> linggao, you're saying you tried to refresh a snap and when it was mounting you were thrown into a kernel debugging session?
<linggao> yes, exactly.
<kyrofa> linggao, would you mind logging a bug against snapd? https://bugs.launchpad.net/snapd/+filebug
<kyrofa> linggao, please include whatever logs you have
<kyrofa> I've never seen that before
<linggao> Sure. I will.
<kyrofa> linggao, are you running the official image? Or a custom kernel of some kind?
<kyrofa> linggao, a better question is probably: what distro are you running on the rpi?
<linggao> Let me find out.
<linggao> We are using this image: ubuntu-16.04-preinstalled-server-armhf+raspi2.img.  It is on arm architecture.
<linggao> We got it from here: https://wiki.ubuntu.com/ARM/RaspberryPi
<linggao> Under Ubuntu 16.04 LTS 'classic'
<kyrofa> linggao, okay good deal, please make sure you mention that on your bug
<linggao> ok.
<linggao> kyrofa, thanks a lot. I will file a bug report.
<linggao> Ok, I have summitted the but report. https://bugs.launchpad.net/snapd/+bug/1664368
<mup> Bug #1664368: snap refresh hangs on arm architecture <snapd:New> <https://launchpad.net/bugs/1664368>
<kyrofa> Thank you linggao
<icey> sergiusens: should I be able to use OpenGL inside of a classic snap?
<stokachu> question, should snap list <snap> return 1 if no snaps are installed yet?
<kyrofa> stokachu, that's not really an error condition...
<stokachu> kyrofa, i just noticed it trying to do a if ! snap list conjure-up; then snap install conjure-up
<stokachu> so ill just grep for that output then
<kyrofa> stokachu, ah, snap list <snap> is a little different
<kyrofa> stokachu, if I run `snap list foo` I get "error: no matching snap installed" and it exits non-zero
<stokachu> if you run it before ever snap installing anything it says no snap installed
<stokachu> exits 0
<kyrofa> stokachu, that seems inconsistent
<kyrofa> stokachu, I'd log a bug
<stokachu> kyrofa, thanks, i thought it was a little weird
<kyrofa> stokachu, I agree, let's see what the devs think
<sergiusens> icey: hey, Brandon Schaeffer was working on that
<icey> sergiusens: I'm working on getting alacritty fully and truly working; I can get it to work on my system but not when I hand it to somebody else :-/
<icey> if I do it in devmode, we both get an error about not being able to create a window, so the software itself can run
<sergiusens> icey: use snapcraft master (or soon to be 2.27)
<icey> but it seems like a display issue
<mup> Bug #1664383 opened: running snap list <snap> on a system that has no snaps installed exits 0 <conjure-up> <Snappy:New> <https://launchpad.net/bugs/1664383>
<icey> when do you think that 2.27 release will be cut sergiusens?
<sergiusens> icey: it was supposed to get into proposed on thursday but I got sick and there was necessary fix that I could only craft today; so -proposed today or tomorrow and count 2 days and it will be in -updates
<sergiusens> icey: do you have your anatine project anywhere btw?
<icey> anatine?
<sergiusens> icey: err, lol, wrong name
<sergiusens> icey: alarcity
<icey> nope :-P
<icey> I'm about to try building it on master
<icey> either way, I'll put a branch on GH
<sergiusens> icey: can you? It might be easier if we have a snapcraft.yaml we can work out of.
<icey> so sergiusens... now when I run the alacritty snap after building with master, it hangs
<icey> adding snapcraft to alacritty: https://github.com/ChrisMacNaughton/alacritty
<sergiusens> icey: and it did work with 2.26? The only interesting thing we are doing with 2.27 is not exporting variables in the wrappers, you can add it with the environment keyword in apps (a dictionary)
<sergiusens> will look later tonight or tomorrow morning
<icey> sergiusens: building with the package that apt gave me on 16.10, it was working _for me_, building from master zeems to hang
<icey> sergiusens: https://gist.github.com/ChrisMacNaughton/fb6748767443f24da14658e3a8122c2a
<icey> it is showing me "runtime/cgo: pthread_create failed:" over and over
<elopio> joc: sorry, I missed your ping. https://github.com/snapcore/snapcraft/pull/1139
<mup> PR snapcraft#1139: plainbox-provider plugin: filter out sitecustomize <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1139>
<mup> PR snapd#2841 opened: interfaces: allow recv* and send* by default, accept4 with accept and other cleanups <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2841>
<mup> Bug #1663565 changed: Media Keys do not work in strictly confined snaps <isv> <snapd-interface> <snapd:In Progress by jdstrand> <https://launchpad.net/bugs/1663565>
<mup> PR snapd#2842 opened: interfaces: misc updates for network-control, firewall-control, unity7, x11 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842>
#snappy 2017-02-14
<mup> PR snapcraft#1139 closed: plainbox-provider plugin: filter out sitecustomize <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1139>
<mup> PR snapd#2843 opened: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <https://github.com/snapcore/snapd/pull/2843>
<mup> PR snapd#2844 opened: dirs: differentiate between "distro" and "core" libexecdir <Created by zyga> <https://github.com/snapcore/snapd/pull/2844>
<mup> PR snapd#2845 opened: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845>
<mup> PR snapd#2846 opened: cmd: autoconf for centos <Created by zyga> <https://github.com/snapcore/snapd/pull/2846>
<mup> Bug #1664427 opened: thefuck snap gets an apparmor denial even in classic confinement <classic> <Snappy:New> <https://launchpad.net/bugs/1664427>
<zyga> Pharaoh_Atem: around?
<mup> PR snapd#2846 closed: cmd: autoconf for centos <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2846>
<Son_Goku> zyga: hm?
<Son_Goku> oh, btw, I think the Fedora EPEL buildroots are actually RHEL systems
<Son_Goku> though I'm not sure about that
<Son_Goku> so you'll need to add "redhat"
<Son_Goku> and "rhel"
<Son_Goku> actually, I think the identifier is just "rhel"
<Son_Goku> yep, rhel
<Son_Goku> zyga: you need to add "rhel" otherwise snap-confine won't build right in epel
<mup> Bug #1650187 changed: Can't run any snap application on Mint 18 <Snappy:Expired> <https://launchpad.net/bugs/1650187>
<liuxg> ogra_, ping
<liuxg> ogra_, I cannot console-conf my pi3 device. it just shows that (Client.Timeout exceeded while awaiting headers).  error: while creating users: cannot create use 'xxxxx". I have sent an email titled with "Currernt config hook implementation scales very badly". There are some attached picttures there. how can I resolve this problem?
<liuxg> ogra_,  sorry, the email was tittled with "Issue with ubuntu OS snap first time boot."
<liuxg> lool ping
<mup> PR snapd#2515 closed: snap run: create "current" symlink in user data dir <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2515>
<mup> Bug #1664484 opened: Missing interface to record audio from pulseaudio <Snappy:New> <https://launchpad.net/bugs/1664484>
<ogra_> liuxg, how is that related to the config hooks ?
<zyga> Pharaoh_Atem: hey, I've sent a few patches that make the code work on fedora/centos/rhel
<zyga> Pharaoh_Atem: I'll refresh the package once 2.23 which includes those fixes is out
<liuxg> ogra_,  ping
<ogra_> yes
<ogra_> i'm here :)
<didrocks> he is here \o/
<ogra_> lol
<liuxg> ogra_, currently I cannot get my pi3 device console-conf I just reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471
<mup> Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1664471>
<liuxg> ogra_, is that a network problem?
<ogra_> liuxg, sounds like a store bug to me
<ogra_> or do you have some proxy in place
<liuxg> ogra_, interestingly, my pi2 device can get the job done.
<ogra_> both through wired lan ?
<liuxg> ogra_, no, I do not have any proxy. my colleague in shanghai did get the work done.
<liuxg> ogra_, yes.
<ogra_> and through the same lan specifically ?
<liuxg> ogra_, exactly, the same cable.
<ogra_> and it is properly plugged ? :)
<liuxg> ogra_, I think so. otherwise, it cannot go the last step.
<ogra_> true, you wouldnt get an IP
<ogra_> (or do you use static ?)
<liuxg> ogra_, I tried it for the whole morning. I did not set anything, I think.
<liuxg> ogra_, I just attached the syslog file in the bug report.
<lool> liuxg: pong
<lool> ppisati_: Hi!
<lool> ppisati_: one of the MWC demos is on RPis, and it breaks with a kernel backtrace when refreshing snaps:
<lool> https://bugs.launchpad.net/snapd/+bug/1664368
<mup> Bug #1664368: snap refresh hangs on arm architecture <snapd:New> <https://launchpad.net/bugs/1664368>
<liuxg> lool, I am now having a problem on console-conf my pi3 device. I reported a bug at https://bugs.launchpad.net/ubuntu/+source/subiquity/+bug/1664471.. ogra_just now helped me to answer me.
<mup> Bug #1664471: Creating user failed when doing console-conf for raspberry pi3 device <subiquity (Ubuntu):New> <https://launchpad.net/bugs/1664471>
<lool> ppisati_: would you mind scheding some light ont his?
<lool> *this
<lool> liuxg: oh cool, sorry for the delay
<lool> hadn't opened IRC since yesterday morning
<liuxg> lool, it is ok. :)
<ogra_> liuxg, your syslog looks fine, i really bet its a login.ubuntu.com issue
<liuxg> ogra_, yeah, it is a little bit weird. my colleague also experienced the same problem. but he tried a few times more, then it became successful..
<liuxg> ogra_, lool another colleague didrocks got 10 mins to configure a device.
<didrocks> (that was in december, under the same network that I'm complaining snapd to regularly fail)
<ogra_> yeah, thats rather normal ... still being researched (part of it is that the initial snapd configuration eats all CPU cores at 100% for a while)
<didrocks> liuxg: btw, I know ogra_ and lool for years (almost 10), no need to present me :)
<lool> isn't it a nice thing though?
<ogra_> the system is under high load and very slow at that point ... sometimes you are lucky and it is fast ... but thats rather the exception
<ogra_> lool, well, your CPU is completely eaten ... not sure IO nicing would change that
<lool> haha
<lool> it took me a while to even get the joke, tells you how fried my CPU is
<ogra_> bug 1632124 btw
<mup> Bug #1632124: snapd pegging cpu at 100% <Snappy:Expired> <https://launchpad.net/bugs/1632124>
<ogra_> oh, mvo closed it ...
<didrocks> I think you are mixing the snapd network issue with this, but yeah, it could be 2 separated things
<ogra_> didrocks, if it succeeds it is the systerm load most likely
<didrocks> (when snapd disconnect, it's really due to the network/snapd interactions, even when io load and CPU are next to 0)
<mvo> ogra_: it expired, looking at it again it looks like for the wrong reasons
<ogra_> yeah
<ogra_> i know someone dug into it (Chipaca ?) ... but i dont remember it being fixed
<zyga> o/
<zyga> hey guys, I've been here just busy with meetings
<ogra_> stop having meetings then !
<ogra_> :)
<zyga> I moved all of them to one day
<zyga> (next step is to take a day off on that day) ;-)
<ogra_> do you call it the pain-day ? :)
<ppisati_> lool: replied to that lp bug and assigned to me
<lool> ppisati_: <3
<ogra_> didrocks, mvo, hah, my bug search actually failed me ... i was actually meaning bug 1638537 above
<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>
<ogra_> the classic does 100% cpu one is indeed in the works
<ogra_> (silly me, was just searching for "100% CPU" and hit the wrong one)
<didrocks> ogra_: oh btw, is your classic snap a chroot or a lxd container?
<didrocks> I was aked when reading the tutorial, I was telling it's a container
<ogra_> chroot
<ogra_> we dont have lxd support in the core snap by default
<ogra_> (you need the lxd snap)
<didrocks> ogra_: ok, thanks for the clarification :)
<mup> PR snapcraft#1127 closed: Release changelog for 2.27 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1127>
<mup> PR snapd#2775 closed: cmd: add functions to load/save fstab-like files <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2775>
<zyga> jdstrand: hey, can you please try to review https://github.com/snapcore/snapd/pull/2827/files today
<mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
<zyga> jdstrand: it's based on the earlier mount work and is very small (doesn't get used in snap-confine yet, just adds the library functions)
<zyga> jdstrand: using this I can propose nice chunks of update-ns next
<mup> PR snapd#2588 closed: cmd/snap: add shell completion to connect <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2588>
<mup> PR snapd#2251 closed: interface hooks: support for setting/getting slot/plug attributes with snapctl (step 3) <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2251>
<mup> PR snapd#2421 closed: tests: add basic test for docker <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2421>
<mup> PR snapd#2475 closed: tests: nested image testing <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2475>
<mup> PR snapd#2654 closed: i18n: look into core snaps when checking for translations <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2654>
<mup> PR snapd#2626 closed: interfaces: relax path requirements for serial <Created by jocave> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2626>
<mup> PR snapd#2847 opened: tests: enable docker test <Created by mvo5> <https://github.com/snapcore/snapd/pull/2847>
<mardy> pstolowski: hi! Quick question: if an interface is auto-connectable, and then I manually disconnect and reconnect it, will the interface hooks be run at this last step?
<pstolowski> mardy, hey. interesting question, I think they will be run, but to be 100% sure I'd need to check the code
<pstolowski> mardy, btw, my branch #3 landed
<mardy> pstolowski: I saw, great stuff! :-)
<mardy> pstolowski: should I file a bug to track when the interface hooks will be run for auto-connectable interfaces, or do you already have a task for that?
<pstolowski> mardy, no need for bug, it's on my list I shared with alecu and i've it on my whiteboard at home ;)
<mardy> pstolowski: send a pic
<mardy> pstolowski: joking ;-)
<ogra_> he cant, he has all his passwords written there too ;)
<pstolowski> autoconnect is going to be the most complex of all changes, since this code is currently kind of a special case which doesn't work the way connect does
<pstolowski> mardy, http://imgur.com/a/hILGi ;)
<pstolowski> mardy, see, i'm not making this up ;)
<mardy> pstolowski: :-D
<mup> PR snapd#2848 opened: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2848>
<jdstrand> zyga: historically setuid executables are attacked in their failure conditions
<jdstrand> zyga: everything is typically fine when things go right, but when they go wrong, there may be latent bugs. that is mitigated somewhat on Ubuntu because of the apparmor profile (though it necessarily allows a lot), but many distros don't have that
<zyga> jdstrand: I understand that, we could make the debug code somewhat more paranoid (e.g. we could quote the paths and filesystem type)
<jdstrand> zyga: I thought I was quite clear weeks ago that lots of string handling code (ie, a greater attack surface) would not be used in production, only debug
<jdstrand> zyga: and I thought all the new code I was reviewing was working towards that
<zyga> jdstrand: I think that right now we still do logging and (and do so less carefully) and this PR was aiming to fix that
<zyga> jdstrand: no that wasn't clear, I though you wanted that to be off by default (hence the lazy compute of the command)
<zyga> jdstrand: at some point without code like this the debug / die messages are useless
<jdstrand> zyga: I didn't think anything was using sc_mount_cmd yet, as it was only added to the library
<zyga> jdstrand: if you want to remove those we need a plan on how the app will be debuggable
<zyga> jdstrand: nothing is using it yet, only thew two new calls added in this PR
<jdstrand> zyga: env var aside, it isn't off by default if when you die() you run through all the code
<zyga> jdstrand: yes, and I did that on purpose
<jdstrand> I'm confused then
<jdstrand> you just said "I though you wanted that to be off by default" and then you said "I did that on purpose"
<zyga> jdstrand: I misunderstood you earlier and I implemented the lazy code so that we don't do it usually
<zyga> jdstrand: but we do compute it when the message is needed (either because debug is on or because we need to die)
<zyga> jdstrand: if you are saying I cannot, under no conditions, compute the message in production then that's fine
<zyga> jdstrand: but what is the app going to do then
<zyga> jdstrand: I think this is a reduction in functionality compared to what we have now (hand-made message in each case)
<jdstrand> zyga: I expected the die() to have a simpler must_snprintf hand-made message
<zyga> jdstrand: then the whole point of this branch is lost
<jdstrand> no it isn't
<jdstrand> someone trying to reproduce can use it with debugging enabled
<jdstrand> or
<jdstrand> you make this config file option
<jdstrand> and the config file is root owned
<jdstrand> or
<jdstrand> you permanently drop privileges
<zyga> jdstrand: nobody will do any of those things when they report a bug with  a message they got, for debugging done by an experienced person various things are possible
<zyga> jdstrand: actually
<zyga> jdstrand: how about that last idea?
<zyga> jdstrand: I have a branch for that
<zyga> jdstrand: adds library function for dropping/raising/permanently dropping privs
<zyga> jdstrand: I did that after the sprint
<jdstrand> zyga: what inexperienced person is going to debug the finer points of snap-confine's mount operations?
<zyga> jdstrand: after tyler's suggestion
<zyga> jdstrand: exactly, nobody
<zyga> jdstrand: so they will just throw a bug with a message that they get
<zyga> jdstrand: the point of this branch is to have that message as good as we can use
<jdstrand> zyga: yes, so, an experienced person could flip a setting in a config file
<zyga> jdstrand: well, you assume you can reproduce, that's not always the case
<jdstrand> anyway, there is also dropping privileges
<zyga> jdstrand: (weird kernel/setting)
<zyga> jdstrand: I'd much rather drop privs
<zyga> jdstrand: and for the config, that's more parsing (but we can explore that as it would have some value)
<zyga> jdstrand: so if you are +1 on doing this after dropping privs then I'll just do it
<jdstrand> if we *permanently* drop privileges, I have no problem
<zyga> perfect
<zyga> jdstrand: thank you and I'm sorry for the confusion
<zyga> jdstrand: I recall we spoke about this as an option (compile time choice)
<zyga> jdstrand: but I didn't think we agreed on that
 * jdstrand shrugs
<zyga> jdstrand: it's just been in review and iteration for too long and I must have forgotten (the whole mount code change)
<zyga> jdstrand: I'll get right to it :)
<zyga> jdstrand: oh
<jdstrand> one way to reduce attack surface is to not have the code compiled
<zyga> jdstrand: can you review a 3 line difff?
<zyga> for the next release tomorrow: https://github.com/snapcore/snapd/pull/2843
<mup> PR snapd#2843: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <https://github.com/snapcore/snapd/pull/2843>
<jdstrand> zyga: I was going to that when you pinged me
<jdstrand> the release is tomorrow?
<zyga> jdstrand: this makes snap-confine functional on the 3.10 kernel
<jdstrand> jeez
<zyga> jdstrand: I think it is, I'm not sure
<zyga> jdstrand: especially with the state of reexec being in the middle
<zyga> jdstrand: but mvo mentioned that deadline is tomorrow
<jdstrand> I thought it was always on thursday
<zyga> jdstrand: probably what mvo meant was EOD tomorrow is when master feezes
<zyga> s/probably/possibly/ (or maybe)
<mvo> jdstrand, zyga: 2.23 is EOD tomorrow, I plan to make the 2.23 release in my morning on Thursday
<mvo> (not having any more context, I assume this is what you asked?)
<zyga> mvo: what is the state of reexec code?
<zyga> mvo: yes
<zyga> mvo: I think we wanted to polish that to the point where we can reenable everything I removed from the policy
<popey> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1662181 # this bug is blocking a couple of snaps - can we get a plan of record on that bug? zyga ?
<jdstrand> zyga: you requested that https://github.com/snapcore/snapd/pull/2749 not land until snap-confine is executed from the core
<mup> Bug #1662181: Aliases didn't enable out of the box <isv> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1662181>
<mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<jdstrand> zyga: but there are 3 or 4 PRs that already landed that use arg filtering
<jdstrand> zyga, mvo: does that mean https://github.com/snapcore/snapd/pull/2749 won't be in 2.23?
<zyga> popey: that's something for pedronis I think
<zyga> jdstrand: I see
<mvo> jdstrand: I added it to the 2.23 list, at least it will get priority this way
<jdstrand> also, I thought that snap-confine executed from core was going to land Friday-ish
<jdstrand> I thought I saw it merged, I'm I mistaken?
<zyga> mvo: I think that we need to have a clear story on how this is going to affect 2.23, I think it's fine to delay for next week if that is required, otherwise we'd have to do more changes (negative) to the security profiles
<Son_Goku> zyga, I left a comment on https://github.com/snapcore/snapd/pull/2845
<mup> PR snapd#2845: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845>
<mvo> jdstrand: snap-confine from core is still under review, I hope we can get this in
<zyga> jdstrand: I gave +1 on one of the branches but that will break debian/14.04 I'm sure
<zyga> Son_Goku: hey
<mvo> zyga: ok, if its fine to delay, w edelay
<zyga> Son_Goku: thank you
<jdstrand> let me see if there is anything else that would break. quota and ioctl were the two we undid. I thought there were others
<zyga> Son_Goku: replied
<zyga> jdstrand: it's not merged yet: https://github.com/snapcore/snapd/pull/2810
<mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
<Son_Goku> zyga: replied ;)
<zyga> Son_Goku: replied, also given the merge window closing I think the more elaborate checks will have to wait a few weeks
<Son_Goku> okay
<zyga> Son_Goku: did you see my tweet last night?
<Son_Goku> do we need https://github.com/snapcore/snapd/pull/2844 when https://github.com/snapcore/snapd/pull/2845 already has its commit?
<mup> PR snapd#2844: many: differentiate between "distro" and "core" libexecdir <Created by zyga> <https://github.com/snapcore/snapd/pull/2844>
<mup> PR snapd#2845: dirs: use the right snap mount dir for the distribution <Created by zyga> <https://github.com/snapcore/snapd/pull/2845>
<Son_Goku> zyga: I did
<jdstrand> zyga, mvo: the other one I was thinking of was 'setpriority PRIO_PROCESS 0 <=19', but that isn't a problem because PRIO_PROCESS has been in snap-confine for ages
<jdstrand> mvo: it it help if I rebased https://github.com/snapcore/snapd/pull/2749 on https://github.com/snapcore/snapd/pull/2810? is there another way in github to say that one branch depends on another?
<mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
<jdstrand> s/it it/would it/
 * jdstrand remove the netlink rule from https://github.com/snapcore/snapd/pull/2842 since if we allow it, it will be with arg filtering
<mup> PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7, x11 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842>
<mvo> jdstrand: maybe, but let me try to get a review for #2810
<Cynerva> zyga: you available to help me figure out permission errors on the kubelet snap?
<balloons> Can you guys have a look at https://bugs.launchpad.net/juju/+bug/1660273 ? It seems like /snap/bin is missing from PATH
<mup> Bug #1660273: /etc/environment does not include /snap/bin in $PATH <cloud-images:Invalid> <juju:New> <Snap Layer:Fix Released> <snapd:New> <https://launchpad.net/bugs/1660273>
<jdstrand> mvo: can you add https://github.com/snapcore/snapd/pull/2842 to the 2.23 list? I reverted the commit that zyga, tyhicks, tsdgeos and I were discussing. the rest has a +1 from zyga
<mup> PR snapd#2842: interfaces: misc updates for network-control, firewall-control, unity7 and default policy <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2842>
<jdstrand> mvo: so just need another +1
<zyga> Cynerva: hey
<zyga> Cynerva: can you tell me more about the problem please
<zyga> Cynerva: I'll try to help but I'll be also coding on a few other branches while we speak
<zyga> balloons: I just did, can you be more specific please
<Cynerva> zyga: cool, thanks. we're working on a kubelet snap, we have it working with classic confinement, but trying to make it strict
<balloons> zyga, ty. /snap/bin is missing from PATH in /etc/environment. This means non-login shells don't have PATH set properly for snaps
<Cynerva> zyga: we're hitting permission errors on several files i can't find an interface for - a bunch related to cgroups, like /proc/self/cgroup, /sys/fs/cgroup/memory, and several others
<Cynerva> zyga: full list is here https://gist.github.com/Cynerva/9150f379cdf1d41aac9ae233597c1f64
<zyga> balloons: I don't think we can add it there, we only add it through /etc/profile.d/apps-bin-path.sh
<Cynerva> zyga: it looks like it's also trying to move the docker pid in /var/run/docker.pid (we have the docker snap installed and connected from stable channel)
<zyga> Cynerva: for everything apart from docker: do file a bug report on launchpad.net/snapd, tag it with snapd interface
<zyga> Cynerva: snapd-interface (with a dash)
<zyga> Cynerva: there's no interface for cgroups that I'm aware of and snapd also uses cgroups in some ways some please describe as much as you can what the app is doing and why
<ryebot> nessita: are you available to discuss snap store namespaces? I'm wondering if there's a way to either transfer a snap to another namespace, rename a snap, or delete a snap.
<zyga> Cynerva: for the /var/run/docker.pid, can you tell me what's going on there? why would the app move it?
<nessita> ryebot, hi! yes we can do first and last option
<nessita> ryebot, renames are not a thing yet
<nessita> ryebot, what's the snap?
<balloons> zyga, I think we want PATH to be consistent
<zyga> balloons: want != can
<ogra_> balloons, where is that ? classic ?
<zyga> balloons: whatever we want is done somehow, there's no way that we know of that would let us stick an item in path other than /etc/environemt
<Cynerva> zyga: okay, will do on the others, thanks :) as for the docker pid, i really have no idea, but i can look into it
<ryebot> nessita: ah, that's excellent, thanks! There's three of them: kube-apiserver, kube-controller-manager, and kube-scheduler
<zyga> balloons: and there are plenty of small places that keep a copy of "vanilla path" that still break
<nessita> ryebot, let me check a few things first
<zyga> balloons: I'd like to know why the current approach that we do doesn't work in the places that were mentioned in the bug
<ryebot> nessita: I think just deleting them would be fine
<nessita> ryebot, I can certainly delete them, but may I ask what's the reason?
<pedronis> popey: we are likely changing how aliases work, so that bug won't be quite the same
<ryebot> nessita: I posted them to the store for testing purposes, but we'll be making a namespace for them in the future and I didn't want the tests to be in the way. Poor choice of name the first time around, basically.
<zyga> nessita: my suggestion would be to take advantage of the new project for the store and route all such requests through bugs there
<ogra_> balloons, note that this is a bash "feature" ...
<zyga> nessita: you'll get free accountability and tracking
<nessita> zyga, did those messages are truly for me?
<zyga> nessita: yes,
<nessita> zyga, ah, I see what you mean :-)
<zyga> nessita: all the store request are informal / on irc; I think it would be a good idea, for transparency to request that they are filed as bugs on the store
<pedronis> popey: anyway short story both now and in the future you need to ask on snapcraft list or a reviewer to get the aliases enabled
<balloons> ogra_, zyga, perhaps it's better in /etc/bash.bashrc?
<nessita> zyga, sounds good, thanks for the suggestion
<pedronis> popey: through a store mechanism
<balloons> and you are right.. ksh or other users are busted too :-)
<ogra_> balloons, i thin thats not read if you have ~/.bashrc ... which we cant midify
<ogra_> *modify
<balloons> mm.. Indeed
<ogra_> (and which is created by default usually when a user is created)
<ogra_> balloons, where do you have that issue ? on classic
<nessita> ryebot, following the suggestion from zyga, would you mind filing a bug-request at https://bugs.launchpad.net/snapstore with the delete request? then I can execute asap
<balloons> ogra_, I imagine you would have it for all non-login shells
<ogra_> note that we have a bit more freedon regarding /etc/environment on the core images
<ryebot> nessita: Not at all, thanks a ton!
<balloons> ogra_, but yes this is on non-core ubuntu images
<ogra_> and the last edge images actually have that path in /etc/environment
<zyga> nessita: \o/ thank you, I think this is very important
<ogra_> for all other setups you need to add a snippet to your bashrc to source profile.d
<ryebot> nessita: https://bugs.launchpad.net/snapstore/+bug/1664601
<mup> Bug #1664601: Please remove kube-apiserver, kube-controller-manager, and kube-scheduler from the store <Snap Store:New> <https://launchpad.net/bugs/1664601>
<mup> PR snapd#2849 opened: cmd: don't reexec on RHEL family <Created by zyga> <https://github.com/snapcore/snapd/pull/2849>
<zyga> mvo: ^^ along with the other branches
<ryebot> Out of curiosity, is renaming/deleting/transferring snaps going to be a user-doable thing in the future?
<balloons> ogra_, is adding /snap/bin to /etc/environment for non-core images not an option? Do we feel this can't be modified?
<ogra_> balloons, right ... you can try to convince foundations if you feel like ... but i guess chances are low they want that :)
<nessita> ryebot, excellent! thanks
<ryebot> nessita: thank you :)
<ogra_> balloons, you cant really modify this file from a package ... snapd isnt necessary always installed everywhere so it shouldnt be in the default path in /etc7environment but instead enhance the path
<popey> pedronis: hm, okay. Any chance of a public reply on the bug so we can point people at it?
<pedronis> popey: yes
<pedronis> will write something
<balloons> ogra_, snapd actually has the prominece since xenial. I've assumed it was there akin to apt
<ogra_> balloons, debootstrap wont install it for example :)
<ogra_> balloons, bring it up with foundations, they own the classic images ... i'Ãd happily drop the hack we use for the core images and just inherit their path from the default file
<ogra_> but i fear i know the answer when you ask them :)
<ogra_> balloons, beyond that: ssh user@host "source /etc/profile; /path/script.sh"
<ogra_> that will definitely work around it as a quick hack
<balloons> ogra_, ack. Given you are correct in that it's not "always" there, asking for a change seems impossible. However, my bigger fear even assuming the change made sense was getting onto xenial at this point
<balloons> thanks for your comments. I'll add them to the bug
<ogra_> yeah, /etc/environment is created by the installer iirc ...
<ogra_> and usually not modified after install ...
<ogra_> i never understood why bash has this special treatment of remote sessions ... but there surely is a valid reason
<balloons> yea, it's a bit fun when trying to debug something you can run interactively, but not via cron
<ogra_> yup
<popey> pedronis: thanks!
<mup> PR snapd#2850 opened: config: make helpers reusable <Created by stolowski> <https://github.com/snapcore/snapd/pull/2850>
<Cynerva> zyga: looks like it's just reading /var/run/docker.pid, and when that fails, falls back to pidof. so maybe that one's not really a problem
<zyga> Cynerva: I see, can you check why it is doing that?
<mup> PR snapd#2851 opened: tests: failover test for rc.local crash <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2851>
<Cynerva> zyga: ah, looks like it's putting the docker process in a cgroup
<mup> PR snapd#2834 closed: release: add galliumos support <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2834>
<zyga> Cynerva: I see, ok
<zyga> Cynerva: that feels like a separate feature; Can you please report a second bug with the details describing this (why, which cgroup)
<Cynerva> zyga: will do, thanks :)
<zyga> Cynerva: thank you, we'll get to it but not today
<mup> PR snapd#2718 closed: cmd: add non-stub implementation of snap-update-ns <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2718>
<mup> PR snapd#2488 closed: interaces: add new boot-config interface <Created by mvo5> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2488>
<zyga> jdstrand: can you have a quick look if this is the kind of API you were thinking about?
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2852
<mup> PR snapd#2852: cmd/libsnap: add privilege elevation helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2852>
<mup> PR snapd#2852 opened: cmd/libsnap: add privilege elevation helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/2852>
<zyga> jdstrand: (I will patch the code to actually do the effective == 0 but real != 0 checks as well, this is just for the API itself
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/2749 adds a spread test in a location that is not used anymore
<mup> PR snapd#2749: interfaces/default: allow mknod for regular files, pipes and sockets (LP: #1636540) <Created by jdstrand> <https://github.com/snapcore/snapd/pull/2749>
<zyga> jdstrand: you need to put all the new tests in tests/ at the top of the tree
<zyga> jdstrand: I'll move the old tests there one by one, I should have finished that already :/
<lazyPower> nessita - can i piggy back on ryebot's bug with my own? https://bugs.launchpad.net/snapstore/+bug/1664634  -- similar situation. i've had this since initial POC and the naming was poor for a test repository
<mup> Bug #1664634: Please delete the kubectl snap from the snap-store <Snap Store:New> <https://launchpad.net/bugs/1664634>
<mup> PR snapd#2769 closed: snap-exec: support nested environment variables in environment: <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2769>
<nessita> lazyPower, sure! will check that out right after my lunch
<lazyPower> thanks nessita appreciate the alley-oop
<nessita> \o/
<zyga> jdstrand: I just pushed to 2852 again, this time with code that I think is real; you can now review both the .h and the .c files
<zyga> jdstrand: please suggest tests for this if you feel they are useful (can be done, just costly) otherwise let's land this and use it in the mount branch and in various parts of snap-confine
<mup> PR snapd#2850 closed: config: make helpers reusable <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2850>
<pedronis> popey: I wrote a comment in that bug
<zyga> Pharaoh_Atem: I got an email notifying me about deletion of  golang-github-mvo5-uboot-go-0-0.2.git5927df7.fc23
<zyga> Pharaoh_Atem: is tha because f23 if EOLd?
<mup> PR snapcraft#1137 closed: Build-depend on git <Created by cjwatson> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1137>
<mup> PR snapd#2849 closed: cmd: don't reexec on RHEL family <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2849>
<cory_fu> Is there a PPA for getting latest stable snapd on trusty?
<kyrofa> ogra_, mwhudson does console-conf place something in /etc/network/interfaces.d/ ?
<kyrofa> (after first boot)
<kyrofa> Ah, netplan
<kyrofa> ogra_, mwhudson so if I wanted to connect to a wireless network after I connected to a wired network, would I put something in /etc/netplan/ or /etc/network/interfaces.d/ ?
<mup> PR snapd#2844 closed: many: differentiate between "distro" and "core" libexecdir <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2844>
<mup> PR snapd#2845 closed: dirs: use the right snap mount dir for the distribution <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2845>
<kyrofa> ondra, any chance you're around?
<mup> PR snapd#2843 closed: cmd/snap-confine: look for PROCFS_SUPER_MAGIC <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2843>
<ondra> kyrofa hi
<ondra> jdstrand on holidays, but around for bit
<ondra> jdstrand sorry was for kyrofa
<ondra> kyrofa what's up?
<kyrofa> ondra, ah, no, go away!
<ondra> kyrofa lol
<kyrofa> ondra, I think I've got it
<ondra> kyrofa just tell me
<ondra> kyrofa killing a bit of free time here
<kyrofa> ondra, okay I'll be quick
<kyrofa> ondra, after first boot on ubuntu core, the networking config is done via netplan. Are you familiar with that piece?
<ondra> kyrofa as much as changing config on devices
<kyrofa> ondra, therein lies my question. Is changing the netplan config the recommended way to change network config?
<kyrofa> ondra, or should I be doing that in /etc/network/interfaces.d/ still?
<ondra> kyrofa I was hoping so, as I do it on some of my devices quite often
<kyrofa> Heh
<kyrofa> ondra, okay, so you use netplan as opposed to the old way?
<ondra> kyrofa I typically edit /etc/netplan/...yaml
<kyrofa> Okay good deal
<kyrofa> And then run `netplan apply`?
<ondra> kyrofa yeah edit yaml, then netplan generate + apply
<ondra> kyrofa yeah generate before apply
<kyrofa> ondra, ah, what does generate do?
<kyrofa> "backend specific configuration files"
<kyrofa> Backend being systemd-networkd?
<kyrofa> As opposed to network manager?
<ondra> kyrofa let me show you my yaml, as I had case where I have device with 4 ethernet ports and wanted to configure it to share connections
<kyrofa> ondra, oh sweet
<ondra> kyrofa this is for example I use on my deice http://paste.ubuntu.com/23997012/
<ondra> kyrofa not even sure how to configure this one through using /etc/network/interfaces.d/
<kyrofa> ondra, yeah fair enough, this is handy. Okay, thanks for the help!
<ondra> kyrofa I did try network manager, but even with help of morphis I was not successful
<ondra> kyrofa very welcome
<kyrofa> ondra, enjoy holidays, and thanks for your time :)
<ondra> kyrofa no worries :)
<cory_fu> So, my previous question was due to user error, of course.  :)  However, I'm trying to use snapd on Travis and it's failing.  Does anyone know if there's any way to make this work: https://travis-ci.org/juju-solutions/layer-cwr/builds/201647356
<kyrofa> cory_fu, no, snaps don't work on travis
<cory_fu> :(
<cory_fu> Is there any expectation that this could be resolved at some point?  Or is it just not feasible due to how Travis runs builds?
<kyrofa> What are you trying to do, exactly?
<kyrofa> cory_fu, it's totally up to travis
<kyrofa> cory_fu, their kernel, their OS
<kyrofa> cory_fu, keep in mind that they JUST moved to ubuntu 14.04
<kyrofa> From 12.04
<kyrofa> And it's still beta, I thin
<kyrofa> k
<cory_fu> Yeah, that just makes it difficult to run our tests which depend on projects that have moved to snaps.  This particular instance, charm-tools, has an apt package but it's broken at the moment.
<kyrofa> cory_fu, yeah we're going to run into that soon as well. I wonder if elopio has some magic
<kyrofa> He's the travis master
<elopio> kyrofa: cory_fu: according to the table from zyga, travis should support snaps.
<cory_fu> elopio: Table from zyga?
<kyrofa> elopio, eh? Really?
<elopio> cory_fu: https://github.com/snapcore/snapd/wiki/Distributions
<cory_fu> elopio: I don't see Travis mentioned there?
<kyrofa> elopio, where are you getting that?
<elopio> from that error you are getting, I suppose they still need to enable something in apparmor.
<kyrofa> Travis isn't even on there
<EEight> on ubuntu 15.04 sudo apt install snapd = package not found!
<nacc> EEight: 15.04 is eol
<kyrofa> EEight, that's EOL I believe
<elopio> kyrofa: cory_fu: no, but the kernel version required to support snaps in trusty.
<EEight> But the doc: https://snapcraft.io/docs/core/install
<kyrofa> elopio, ah, sure. But yeah, travis still needs to enable it
<nacc> EEight: on ubuntu implies supported/current ubuntu of course
<EEight> So Ubuntu 14.04 will work but not 15.04?
<kyrofa> EEight, indeed as 14.04 is an LTS
<EEight> Ok thx
<cory_fu> elopio: Do you know what would need to be enabled?  I could file an issue on Travis
<ogra_> kyrofa, ssh in and run sudo console-conf ... disable the wired device and configure the wlan ...
<ogra_> thats the most trivial approach
<kyrofa> ogra_, haha! That's handy
<elopio> cory_fu: well, the error says "Kernel needs AppArmor 2.4 compatibility patch." Please file the bug, and we can get zyga or jdstrand to comment there about the details.
<elopio> cory_fu: this week I wanted to try running snaps on travis. Now that you have confirmed it fails, my plan b is to try a lxd container.
<cory_fu> elopio: A LXD container on Travis?
<elopio> cory_fu: yes. I tried that like a year ago and it kind-of-worked. But at that time, lxd didn't support snaps.
<cory_fu> elopio: https://github.com/travis-ci/travis-ci/issues/7318
<cory_fu> elopio: Wouldn't that run in to the same kernel issue?
<elopio> thanks cory_fu.
<cory_fu> elopio: Also, I would expect it to hit https://github.com/juju/charm-tools/issues/303#issuecomment-279615158 at least for --classic snaps
<elopio> I don't know how lxd works or what it does to support snaps. I thought it's worth a try, but now I don't have high hopes.
<elopio> so many details failing everywhere... At least we are finding them, maybe try again next year :)
<kyrofa> elopio, yeah, that'll certainly run into the same problem
<cory_fu> elopio: https://bugs.launchpad.net/snappy/+bug/1628289/comments/18
<mup> Bug #1628289: snapd should depend on squashfuse (for use in containers) <lxd> <verification-done> <Snappy:Triaged> <squashfuse (Ubuntu):Confirmed for doko> <squashfuse (Ubuntu Xenial):Fix Released> <https://launchpad.net/bugs/1628289>
<cory_fu> That's disheartening
<elopio> cory_fu: well, but doesn't that mean that in trusty you get a xenial lxc and it will work?
<cory_fu> I suppose so.
<mup> Bug #1663060 changed: Add a title field to snap metadata <Developer registration portal:New> <Snappy:New> <gnome-software (Ubuntu):Confirmed> <snapcraft (Ubuntu):Confirmed> <snapd (Ubuntu):Triaged> <snapd-glib (Ubuntu):Confirmed> <https://launchpad.net/bugs/1663060>
<EEight> When upload my snap on myapps.dev : You must wait 1 minute before the next snap-name registration for 16. ???
<EEight> After 10 mins, cannot do nothing (no option to click)
<kyrofa> EEight, sounds like a question for nessita or noise][1
<EEight> kyrofa: my first app uploaded well on myapps.dev, but now I don't understand the error
<kyrofa> EEight, there's rate limiting on registering new names so no one can go around registering the world. But it sounds like it's been a long time and you're still unable to register?
<EEight> Ok, I see another unrelated error: You must register xxxx name for 16 before uploading, meaning that my filename (.snap) is not the same as the name I registered!? (will try)
<EEight> That was it...
<popey> EEight: are you all set? need help?
<EEight> popey: thanks, just a feedback, it is not clear that you need to register a name exactly like the filename of your .snap is...
<kyrofa> EEight, you don't, check the snap.yaml
<popey> Interesting, I'll test that with a new app to follow the flow and report bugs where necessary. Thanks for the feedback
<kyrofa> EEight, or the snapcraft.yaml. Are you sure the name is the same as the one you registered?
<EEight> checking!
<EEight> Ok I see, well of course the name in the snap is the same as the filename and then needs to be the same as registered in myapps. Cool
<kyrofa> EEight, indeed, but the filename doesn't matter, the store checks the snap.yaml contained within the snap (which gets generated from the snapcraft.yaml)
<EEight> popey: I am still not listed in Ubuntu Store under Games, is it because I need to add more info in snap.yaml or maybe because on myapps.dev I didn't select Default type: application?
<EEight> Would like also to be listed under Games - Education that would be nice
<EEight> Feedback, on Ubuntu 14.04 I can install snapd, then snap install myapp, but then I need to reboot (myapp: command not found, and not in the Application menu)?
<popey> EEight: which app did you upload?
<popey> EEight: feel free to give me the myapps url and I can take a look at it
<popey> ok i see it
<EEight> I just put the Default type: Application... not sure what it does
<popey> what desktop are you using on 14.04?
<EEight> both 14.04 & 16.04
<popey> ok and did the icon not show up in either right away?
<popey> i have seen others report this, but not seen it myself recently
<EEight> 2 problems : 1- not in Ubuntu Store; 2- need to reboot to use my app
<popey> it's certainly published, because I just installed it with "snap install <appname>"
<popey> you saying it doesnt show in ubuntu software, the graphical app?
<kyrofa> Note that the reboot is because /snap/bin isn't in the path in the image, and only gets set once snapd is installed. But you already have an environment by then
<EEight> popey: exactly the graphical app
<kyrofa> popey, it's in the store, just not in the category, I think
<popey> yeah
<kyrofa> EEight, right? You can see it in the app, but not in the right category?
<popey> yes, there is no category
<popey> does that need setting in the store or the desktop file?
<popey> Categories=Game;Simulation;
<popey> for example in the .desktop file
<EEight> kyrofa: in the graphical app (ubuntu software) not there at all, I need to search it (only in 16.04)
<popey> EEight: just to confirm, on my 16.04 system, once installed I see the icon, so ou have done nothing wrong there.
<kyrofa> Oh, that makes sense
<EEight> popey: thx, on 14.04 also I see the icon in the Ubuntu menu (that is after rebooting if just installed snapd)
<kyrofa> EEight, I don't think the software center in 14.04 will ever have that ability
<EEight> kyrofa: ok
<kyrofa> popey, don't you agree?
<EEight> what about 16.04?
<popey> correct
<popey> 14.04 software centre has no snap support
<EEight> my .desktop have Categories=game
<EEight> maybe that is the problem?
<EEight> case-sensitive!
<popey> checked a steam game I have installed...
<popey> Categories=Game;
<popey> and it _does_ appear in the category "Games" in the store..
<EEight> thank you so much, do I need to bump my version?
<popey> no, just fix and re-upload
<EEight> excellent, thank you very much!
<popey> and I checked, and one of my games is in the games category
<popey> with the Category I mentioned above
<popey> no problem, anytime
<EEight> popey: do you know how to be in Games / Kids ?
<EEight> ok got it KidsGame
<popey> I expect there is a list of categories somewhere... lets see
<EEight> found a post on stackoverflow
<popey> https://standards.freedesktop.org/menu-spec/latest/apa.html
<popey> looks like a likely candidate
<EEight> Hey thanks better
<popey> EEight: i just updated your app and note you've added Categories=KidsGame - but I don't see it in Ubuntu Software. I wonder if you need KidsGame;Game;  ?
<EEight> popey: Should I try?
<popey> let me install someone elses game and see what they did
<popey> one moment
<EEight> sweet! I have to pay you a beer
<popey> no worries :)
<popey> Categories=Game;KidsGame;
<popey> thats from raincat (whatever that is)
<EEight> Excellent updating, and just like that flush 100mb from my Games (I need to be more careful with assets)!
<EEight> All right done, let's see tomorrow (fingers crossed)!
<popey> EEight: yay :)
<mup> PR snapd#2853 opened: cmd: autoconf for RHEL <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2853>
<mup> PR snapcraft#1130 closed: catkin plugin: produce build-ready staging area <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1130>
#snappy 2017-02-15
<mup> PR snapcraft#1140 opened: catkin plugin: support building with an underlay <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1140>
<mup> PR snapd#2853 closed: cmd: autoconf for RHEL <Created by Conan-Kudo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2853>
<mup> PR snapd#2854 opened: Fix error message using GET /v2/users as non-root <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2854>
<sparkin> hi
<mup> PR snapd#2854 closed: Fix error message using GET /v2/users as non-root <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2854>
<mup> PR snapd#2855 opened: add intel realsense udev rules into camera interface <Created by swem> <https://github.com/snapcore/snapd/pull/2855>
<mup> PR snapd#2840 closed: unity7: support missing signals and methods for status icons <Created by 3v1n0> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2840>
<mup> PR snapd#2832 closed: interfaces/builtin: add network-setup-control which allows rw access to netplan <Created by morphis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2832>
<mup> PR snapd#2856 opened: debian: add "Recommends: squashfuse" <Created by mvo5> <https://github.com/snapcore/snapd/pull/2856>
<mup> PR snapd#2857 opened: Add /boot/uboot/config.txt read/write/lock support to core-support <Created by mvo5> <https://github.com/snapcore/snapd/pull/2857>
<mup> PR snapd#2830 closed: allow core_support interface to modify /etc/default/swapfile <Created by ogra1> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2830>
<mup> PR snapd#2858 opened: Add missing newline character to end of deprecated command warnings <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2858>
<mup> PR snapd#2851 closed: tests: failover test for rc.local crash <Created by fgimenez> <Closed by fgimenez> <https://github.com/snapcore/snapd/pull/2851>
<ogra_> sergiusens_, hey ...
<mup> PR snapd#2856 closed: debian: add "Recommends: squashfuse" <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2856>
<sergiusens> ogra_: hey
<mup> PR snapd#2859 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <https://github.com/snapcore/snapd/pull/2859>
<mup> PR snapd#2859 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2859>
<mup> PR snapd#2860 opened: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Blocked> <Created by pedronis> <https://github.com/snapcore/snapd/pull/2860>
<ogra_> sergiusens, i'm struggling with an old problem ...
<ogra_> sergiusens, namely with bug #1611439
<mup> Bug #1611439: snapcraft should be able to autofill the version field based on some property of the build and/or stage files. <Snapcraft:Won't Fix> <https://launchpad.net/bugs/1611439>
<ogra_> sergiusens, we need to somehow start using the snapd version string in the core snap version field
<ogra_> i tried sed'ing snapcraft.yaml during build on LP but that doesnt work, same goes for putting my own meta/snap.yaml in place ... would it be possible to allow the latter ?
<mup> PR snapd#2859 opened: [WIP] overlord: switching to explicit targets for enabled/auto aliases <Created by pedronis> <https://github.com/snapcore/snapd/pull/2859>
<ogra_> or simply have snapcraft read an env var that gets set during the build and use that for the version ?
<ogra_> SNAPCRAFT_VERSION_OVERRIDE ... or some such ...
<ogra_> iirc the snap.yaml is generated, so it should be possible to inject something there i think
<ogra_> sadly i cant manage that from the outside of the build, since the person building is free to use any PPA for the core builds ... which means i dont actually know what the final snapd version will be (and it is used that way by a few teams)
<ogra_> and indeed launchpad doesnt allow me to do the build in steps either so that i could skip prime
<mup> PR snapd#2570 closed: snap: add contact: line in `snap info` <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2570>
<mup> PR snapd#2861 opened: [WIP] interface hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <https://github.com/snapcore/snapd/pull/2861>
<pstolowski> mardy, hey, the next PR for interface hooks ^ in case you want to keep an eye on it. not yet fully ready for review, but close
<mardy> pstolowski: thanks!
<pstolowski> alecu, ^
<alecu> pstolowski: amazing!
<mup> PR snapd#2791 closed: store: use xdelta3 from core if available and not on the regular system <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2791>
<sergiusens> ogra_: you can go all the way to `snapcraft prime` and them replace `prime/meta/snap.yaml` or sed it and then `snapcraft snap prime`
<ogra_> sergiusens, how ... i'm building on launchpad
<sergiusens> ogra_: I don't mind doing this over envvars though and not promote it `SNAPCRAFT_PROJECT_VERSION=2.21 snapcraft`
<sergiusens> ogra_: but how will you get launchpad to use it?
<ogra_> sergiusens, hmm, but i dont know the version before i call snapcraft
<sergiusens> ogra_: is this related to my comment on version on the list?
<ogra_> yeah, kind of
<ogra_> we discussed it in the standup and the outcopme was that version: should be the snapd version inside the core snap
<ogra_> so we can tie features to stable snapd versions in the docs
<mup> PR snapd#2862 opened: cmd/snap, store: change error messages to reflect latest UX doc <Created by pete-woods> <https://github.com/snapcore/snapd/pull/2862>
<sergiusens> ogra_: I don't know how to solve this from a snapcraft PoV, we are peeling an onion to get the version, then putting the layers back on top and applying that to the meta data
<sergiusens> ogra_: wouldn't it be better to have a special feature for this on launchpad?
<ogra_> sergiusens, well, you could check for a pre-existing snap.yaml and in that case not generate one
<sergiusens> ogra_: if you are going to go throught the trouble of creating a snap.yaml why not just set the version?
<ogra_> sergiusens, how ? the version is already seeded when snapcraft reads snapcraft.yaml at the beginning of the build
<sergiusens> ogra_: ok, I see. so I can compromise on "existence of file in project root .snapcraft_project_version"
<ogra_> sergiusens, i only know the version i need later ... during the build
<ogra_> sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there)
<ogra_> that way i could just copy a snap.yaml in place during the build or generate it from the makefile
<sergiusens> ogra_: had a crash and we aren't chatting on rocket, will need to repeat from what last I said ;-)
<ogra_> sergiusens, but i'd be fine with .snapcraft_project_version as well indeed ... if you prefer that
<ogra_> <ogra_> sergiusens, i only know the version i need later ... during the build
<ogra_> <ogra_> sergiusens, sonmething like this http://paste.ubuntu.com/24000747/ (indeed i made up yaml.read() there)
<ogra_> <ogra_> that way i could just copy a snap.yaml in place during the build or generate it from the makefile
<ogra_> but as i said, .snapcraft_project_version would indeed work as well for my case
<ogra_> as long as prime reads it :)
<sergiusens> ogra_: I'd rather not go the route and just overload the version
<ogra_> fine with me then
<ogra_> sergiusens, should i re-open the old bug ?
<ogra_> (i am on rocket btw, we can move there if that helps)
<Son_Goku> sergiusens: yo
<Son_Goku> how's it going?
<sergiusens> ogra_: read topic ;-)
 * sergiusens finally has a reason to say that
<Son_Goku> phooey
<Son_Goku> snapcraft discussion isn't on IRC anymore? :(
<ogra_> well, like snapd development hasnt been on IRC in a long time
<Son_Goku> that's even worse
<sergiusens> Son_Goku: good good
<Son_Goku> sergiusens: :)
<sergiusens> Son_Goku: you?
<Son_Goku> sergiusens: I'm okay these days
<Son_Goku> life stuff making things annoying, as always :)
<sergiusens_> Son_Goku: great, I'll be working on repo stuff tomorrow or even this evening if time allows for it btw, will ping you for a review (probably straight on github)
<Son_Goku> awesome
<Son_Goku> looking forward to it
<caiortp> Hi folks! I'm embedded developer and I have some question about the snappy
<caiortp> I saw that it's possible to create a private snappy store...
<caiortp> There's some tool (like resin.io / openstack ) to manage the snappys instances installed in each board?
<caiortp> tks
<caiortp> ;)
<tommy_> hello
<Guest12115> do you know if it is possible to install snapd on a Wheezy Debian ?
<ogra_> Guest12115, https://github.com/snapcore/snapd/wiki/Distributions
<Guest12115> i did it but it doesnt work
<Guest12115> it cant recognize snapd
<Guest12115> do you know the source ?
<ogra_> what do you mean by "recognize" ?
<Guest12115> paquet not found
<ogra_> ah, right, wheezy is 7.0 ... afaik snapd only works in testing and unstable
<ogra_> and there is is the the archive
<ogra_> i doubt you can make it run on anything older
<Guest12115> humm ok
<Guest12115> thanks
<Guest12115> have a nice day
<Guest12115> i will dig a little
<niemeyer> jdstrand: ping
<mup> PR snapd#2863 opened: cmd/snap-confine: ensure that hotfs is root owned <Created by zyga> <https://github.com/snapcore/snapd/pull/2863>
<mup> PR snapd#2858 closed: Add missing newline character to end of deprecated command warnings <Created by robert-ancell> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2858>
<jdstrand> niemeyer: hey
<niemeyer> jdstrand: Heya
<niemeyer> jdstrand: Do you have a moment to meet with pedronis and myself?
<jdstrand> niemeyer: actually, not atm. I have an appt in a few minutes. I can do it in ~3.5 hours
<niemeyer> That sounds late for pedronis
<pedronis> it's doable but slightly late
<jdstrand> first thing tomorrow would be fine with me
<niemeyer> Ok, let's do it tomorrow then
<jdstrand> whichever you decide is fine with me
<jdstrand> ok
<jdstrand> my morning is open, so ping me at 14:00 or later when you want to meet
<jdstrand> 14:00 UTC
<ahayzen> didrocks, hey, to be able to properly test my change to the desktop-helpers, is there a way i can tell snapcraft to use a local version of the part rather than the cloud version?
<didrocks> ahayzen: sure, you can cp the part from snapcraft.yaml you are interested in
<didrocks> and change source:
<ahayzen> didrocks, ah i see thanks :-)
<didrocks> ahayzen: yw! easiest way to test AFAIK :)
<flexiondotorg> ogra_ We discussed snapd-xdg-open the other day.
<flexiondotorg> I have concerns.
<ogra_> tell me
<flexiondotorg> We talked about it need SRU to Trusty, which "fixes" a problem for Ubuntu.
<flexiondotorg> But snapd-xdg-open isn't in Debian 9, or other distros.
<flexiondotorg> Meaning the cross-distro story is broken.
<flexiondotorg> Particular for snaps such as Spotify and Skype for Linux Alpha.
<ogra_> flexiondotorg, well, talk to the snapd team, perhaps we can include it in the snapd package itself
<flexiondotorg> niemeyer It that possible?  ^
<flexiondotorg> ogra_ Thanks.
<flexiondotorg> jdstrand Your thoughts on the above?
<ogra_> thats the only idea i have beyond ... well ... pushing it into the other distros as well
<flexiondotorg> Would need switch action for Debian 9.
<flexiondotorg> mvo Is that still a possibility at this late stage?
<niemeyer> flexiondotorg, ogra_: We have better plans for that
<jdstrand> flexiondotorg: I agree it would have to be part of snapd
<flexiondotorg> That is reassuring.
<ogra_> after all the package only contains a single binary and a dbus service file
 * jdstrand hasn't heard the better plans
<flexiondotorg> niemeyer Is there a bug to track those plans?
<niemeyer> jdstrand: You probably have, but it wasn't super high profile
<niemeyer> flexiondotorg: Probably, can't remember as we haven't touched that conversation in a few weeks
 * jdstrand -> appt
<niemeyer> flexiondotorg: The idea is simple: instead of using dbus, we'll use snapctl
<flexiondotorg> niemeyer Thanks.
<flexiondotorg> OK, I'll go hunting. If I don't turn up an existing bug I'll raise a new one.
<ogra_> after all you only want to forward a url to xdg-open ...
 * ogra_ thinks there already way to much plumbing around it today, an overhaul will be healthy
<niemeyer> ogra_: I don't think we're even using the real xdg-open today
<niemeyer> It just looks like it
<ogra_> well, the final call goes to xdg-open (at least it should)
<ogra_> because that knows what to do with specific urls
<niemeyer> I don't think it does, and I don't think it necessarily should either
<ogra_> well, it needs to use the mimetypes to identify the right app to fire up for a certain handler
<ogra_> you dont want to duplicated this on our side
<ogra_> but i have never looked at the code of snapd-xdg-open so you ar probably right :)
<niemeyer> Yeah, it doesn't really.. it uses g_app_info_launch_default_for_uri
<niemeyer> ogra_: We're not duplicating code.. and we're chosing *which code* we're not duplicating. ;)
<ogra_> heh
<niemeyer> s/heh/Good idea Gustavo!/
<ogra_> oh, it just uses glib, i see
 * ogra_ just looked at the code for the first time
<niemeyer> Either way, this is the status quo
<ogra_> yeah
<niemeyer> We most probably won't be using glib in the new implementation because we don't want more dependencies
<ogra_> yeah
<niemeyer> (it will be inside snapd itself)
<niemeyer> I'd rather not use the mess of xdg-open.. but we'll see
<ogra_> i'd just let xdg-open do its job and hand over the url from snapd
<ogra_> simply because then it isnt our job to take care after the handoff
<ogra_> heh, now i scared seb
<niemeyer> We'll not implement tool-picking ourselves for sure.. but I'd prefer something cleaner if it exists
<niemeyer> We'll see
 * ogra_ would love if we could get rid of the ugly bits in the core snap ... more than caring about the handoff actually 
<Cynerva_> any advice or best practices for passing args to a daemon that needs them?
<Cynerva_> right now we're using a single "args" config, e.g. `snap set kube-apiserver args='--etcd-servers 10.123.123.14'`
<ogra_> i'd use a wrapper script ...
<Cynerva_> and a wrapper script that passes them into the daemon
<ogra_> yeah, that sounds like an okayish approach
<Cynerva_> okay, cool :) do you think it'd be better for us to break up the config?
<ogra_> well, snap set doesnt really tell your config hook which the arg was, so in the end you will re-generate the whole config anyway
<ogra_> s/arg/key/ actually
<Cynerva_> ah sorry, i mean more from an usability perspective, i guess
<Cynerva_> like instead of "args", we could have configs for "etcd-servers", "kubeconfig", etc -- all the flags that our daemon takes
<ogra_> yeah, i'd do that long term
<ogra_> and split it into categories so you can "yaml'ify" it later
<Cynerva_> okay great. Thanks ogra_!
<ogra_> :)
<niemeyer> jdstrand: Comment fixed and improved: https://github.com/snapcore/snapd/pull/2604#issuecomment-280045941
<mup> PR snapd#2604: interfaces: add classic-support interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2604>
<mup> PR snapd#2864 opened: interfaces: API additions for interface hooks <Created by stolowski> <https://github.com/snapcore/snapd/pull/2864>
<mup> PR snapd#2604 closed: interfaces: add classic-support interface <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2604>
<mup> PR snapd#2865 opened: image,cmd/snap: refactoring and initial envvar support to use stores needing auth <Created by pedronis> <https://github.com/snapcore/snapd/pull/2865>
<mup> Bug #1665029 opened: snapweb needs a link for device when store selected <Snappy:New> <https://launchpad.net/bugs/1665029>
<EEight> popey: bad news for me, my game is still not listed in Ubuntu Software. It is listed if installed via snap install, but it is not the idea, I want to have exposure from the store.
<mup> PR snapd#2852 closed: cmd/libsnap: add privilege elevation helpers <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2852>
<kyrofa> Hey barry, what is the recommended way to use ubuntu-image? From the snap, or from the deb?
<ogra_> kyrofa, from the deb it depends on your host machine (for xenial you need the PPA with a newer ext4 lib) ... i'D go for the snasp from edge
<ogra_> *snap
<ogra_> *for the deb
<kyrofa> Ah, good to know, thanks ogra_
<elopio> jdstrand: zyga is asking for you in rocket chat.
<elopio> he has "technical reasons" :)
<alex-abreu> kyrofa, ping
<kyrofa> alex-abreu, hey there! In standup right now but I'll be available in a minute. What's up?
<alex-abreu> kyrofa, np I can wait, just a few questions around configure hooks ... the usual
<alex-abreu> kyrofa, when a snap is getting installed, the configure hook is run before any daemon that the snap could host is started?
<kyrofa> alex-abreu, no, the configure hook is run _after_ the daemons are fired up
<kyrofa> alex-abreu, it's why bug #1661126 was logged
<mup> Bug #1661126: Add One-shot Install/Uninstall Hook <feature> <hook> <install> <request> <snapd:Confirmed> <https://launchpad.net/bugs/1661126>
<alex-abreu> kyrofa, yes ! ... so in general is there an easy mechanism to e.g. do a systemctl reload when a snap configuration is updated or infor the snap of a conf change?
<alex-abreu> kyrofa, thx for the bug # ...
<barry> kyrofa: really, it's entirely up to you.  consume it how you like. :)  one thing to keep in mind is that the snap version (currently) has some minor limitations, e.g. you can't put your model or extra snaps in /tmp and you can't output your images to /tmp.  other than that there shouldn't be much visible difference
<kyrofa> alex-abreu, the method I use personally is to set the daemons up to restart always
<kyrofa> alex-abreu, and then my scripts just kill the services in question (since systemctl is off limits)
<kyrofa> alex-abreu, then systemd brings them back u
<kyrofa> p
<kyrofa> barry, ah, good to know, thank you
<alex-abreu> kyrofa, this crossed my mind but sounded too "scary", ... :)
<alex-abreu> kyrofa, do you have a snap example for that?
<kyrofa> alex-abreu, definitely
<kyrofa> alex-abreu, remember though that every daemon is different. This is for apache, which has a script that wraps it and utilizes a pid file, so I could just ask it to stop: https://github.com/nextcloud/nextcloud-snap/blob/master/src/https/utilities/https-utilities#L138
<kyrofa> alex-abreu, but that could just as easily have been a kill -15
<mup> PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions <Created by zyga> <https://github.com/snapcore/snapd/pull/2866>
<alex-abreu> kyrofa, totally, thx
<kyrofa> alex-abreu, I find it actually works pretty well. It would be pretty awesome if we could call systemctl for in-snap daemons though
<alex-abreu> kyrofa, definitely ... is there a bug # for that? or a strong not to be able to ?
<kyrofa> alex-abreu, I suspect there are technical issues with that, but jdstrand could answer better. Or morphis, I think he ran into it recently
<kyrofa> By the way, jdstrand did you see my responses to https://github.com/snapcore/snapd/pull/2837 ?
<mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<kyrofa> alex-abreu, to answer your question, I don't know of a bug for that
<mup> PR snapd#2859 closed: [WIP] overlord: switching to explicit targets for enabled/auto aliases <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2859>
<mup> PR snapd#2860 closed: [WIP] asserts: a snap-declaration "aliases" header to list auto aliases with explicit targets <Blocked> <Created by pedronis> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/2860>
<mup> PR snapcraft#1141 opened: Use the existing code to find origin's snapcraft.yaml <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1141>
<kyrofa> pmcgowan, you pinged me a while back about nextcloud not working on the dragon board. I'm sorry it took so long, but I finally got around to testing this myself, and at least the latest revision works fine. Have you tried recently?
<pmcgowan> kyrofa, I haven't tried lately, I recall it was just a memory usage issue
<kyrofa> pmcgowan, yeah I wouldn't be surprised
<pmcgowan> kyrofa, did you run from stable or other channel
<kyrofa> pmcgowan, stable, yeah. I think some efficiency gains landed in nextcloud v11
<pmcgowan> ok will give it a try
<kyrofa> pmcgowan, no rush, I just have the dragon up now so I can experiment if you run into issues
<jdstrand> kyrofa: re https://github.com/snapcore/snapd/pull/2837, but haven't had a chance to circle back yet. hopefully today
<mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<mariogrip> jdstrand: Hi, I pushed a snap to the store, but it seem to be stuck on "Revision waiting for review of a previous upload." even though the review of the previous upload is done
<kyrofa> jdstrand, of course, no problem
<pmcgowan> hmm kyrofa interesting you cannot refresh a disabled snap
<kyrofa> pmcgowan, ah, I never tried. But that kinda makes sense... it's disabled
<jdstrand> mariogrip: what is the link?
<pmcgowan> kinda, but thats cause it doesnt run correctly
<kyrofa> pmcgowan, hahaha
<kyrofa> pmcgowan, good point
<mariogrip> jdstrand: https://myapps.developer.ubuntu.com/dev/click-apps/6986/
<pmcgowan> kyrofa, so I would remove and install instead
<kyrofa> pmcgowan, or enable and refresh
<pmcgowan> yeah, but then it sucks up my memory and my other snaps dont work :)
<kyrofa> Yeah, remove/install might be a better path
<kyrofa> pmcgowan, that might explain why it's working alright here-- I don't have any other snaps installed
<jdstrand> mariogrip: I'm not sure how it got to that state... can you request a manual review and then I can reject it and the next one will get reviewed
<pmcgowan> kyrofa, reminds me of a recent thread on not having snaps start right after install
<mariogrip> jdstrand: It might be because i uploaded a new one before the review was done
<mariogrip> jdstrand: but could you reject rev2 so it uses 3rev insted
<mariogrip> jdstrand: manual review requested
<jdstrand> nessita: fyi, https://myapps.developer.ubuntu.com/dev/click-apps/6986/rev/2/ seems stuck in 'Task state is unknown.'
<jdstrand> nessita: mariogrip requested that it be rejected so rev3 may be auto-reviewed
<nessita> jdstrand, hi, let me check
<nessita> jdstrand, can you reload?
<nessita> I see it failed
<mariogrip> jdstrand: it says "Manual review pending" for me
<jdstrand> nessita: ok, it isn't stuck. it took quite a while to get there. sorry for the noise
<nessita> :-)
<jdstrand> mariogrip: ok, rev2 rejected
<mariogrip> jdstrand: Thanks :)
<mup> PR snapd#2867 opened: screen-inhibit-control: add methods for delaying screensavers <Created by 3v1n0> <https://github.com/snapcore/snapd/pull/2867>
<jdstrand> alex-abreu: we can't call systemctl from snaps without patching systemd. systemd isn't diesigned to be isolated and the snap requires a ton of privileges
<jdstrand> systemctl isn't designed to isolate calls to applications that is
<jdstrand> it could be made to do so. better would be to update snapctl so snapd could call ystemctl on the snap's behalf
<alex-abreu> jdstrand, thx for the update, ... makes sense yes, something like a systemctl facility or expanding systctl could be very handy
<alex-abreu> snapsctl I mean
<kyrofa> jdstrand, agreed, we've tried to isolate snapd and snapd from knowing they're running on systemd anyway
<kyrofa> snapd and snaps*
 * jdstrand nods
<kyrofa> So snapctl seems the best solution
<jdstrand> yeah
<kyrofa> jdstrand, from a technical standpoint though, can apparmor not parse cli args to a binary?
<lutostag> any ideas what I'm hitting with https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1665102 ?
<mup> Bug #1665102: Snap refresh not working <snapd (Ubuntu):New> <https://launchpad.net/bugs/1665102>
<sethj> wasn't there a bug report about being required to sign in to install a snap?
<EEight> i poked popey directly, but if anyone knows about exposing a snap application in the ubuntu software (16.04 only) let me know, my app is not listed.
<EEight> I think that only .debs will be listed there? Am I wrong?
<nacc> isn't ubuntu software centre deprecated? gnome software seems to find sanps
<nacc> EEight: what's your snap called?
<kyrofa> EEight, I'm still not completely clear: does your snap not show up at ALL in xenial's software center, or just not in the correct categories?
<kyrofa> nacc, I assume that's what EEight means
<nacc> kyrofa: i always have to double-check in #ubuntu :)
<kyrofa> nacc, fair enough!
<EEight> nacc: bayam
<nacc> EEight: is it french?
<EEight> should be in Games / Kids
<EEight> bilangual
<nacc> my gnome software found a bayam snap
<nacc> (on 16.10)
<kyrofa> EEight, indeed, same here (on xenial)
<EEight> yes, but I don't want people to search for it, I want the exposition of the categories
<kyrofa> EEight, then you need to be clear with your problem!
<EEight> my bad!
<kyrofa> EEight, you said "my app is not listed [in ubuntu software]" which isn't the case
<nacc> note that i don't see bayam under games/all eitehr
<EEight> what is the process behind this, is there real people reviewing the snap submission?
<kyrofa> EEight, not unless your snap requires manual review
<kyrofa> EEight, I expect this is a limitation right now, of either the store or snapd
<kyrofa> (or both)
<kyrofa> EEight, I suggest logging a bug
<nacc> yeah, it seems like snaps don't hav ea "Category" field set (visibly at least)
<kyrofa> nacc, they kinda do, on the store side
<kyrofa> nacc, but I don't think anything consumes that
<nacc> kyrofa: right, i meant on the client side, sorry
<nacc> kyrofa: whereas debs do show one visibly
<kyrofa> nacc, indeed
<nacc> yeah, seems like just an oversight (I assume the field would have to be found somewhat differently between debs and snaps)
<kyrofa> Agreed
<kyrofa> EEight, specifically, I suggest logging a bug against gnome software, since that's where the issue is surfacing. It'll get triaged and also-applied from there: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+filebug
<kyrofa> EEight, again, be specific. Say that your snap shows up, but not in the categories you've requested
<EEight> but the category from the .desktop file or from the myapps.developer.ubuntu ?
<kyrofa> EEight, good question. I expect from myapps, since the desktop file is hidden away in the snap at that poit
<kyrofa> point*
<EEight> Then the myapps. should be updated to reflect all the categories...
<kyrofa> EEight, heh, one problem at a time
<kyrofa> EEight, plus I'm not certain that's the case, anyway
<EEight> Well the myapps.dev website is in french here (cannot change the language). The field html name is department_id... and it should have a category (Games) and a sub-category (Kids). But like you said, one thing at a time.
<EEight> Did my best: https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1665126
<mup> Bug #1665126: snap not listed in categories <snap> <gnome-software (Ubuntu):New> <https://launchpad.net/bugs/1665126>
<kyrofa> EEight, looks great, thank you. I tweaked the description ever so slightly, but nice job
<cjwatson> elopio: yeah, I need to finish fixing yakkety/zesty snap builds on LP
<cjwatson> I see you ran headfirst into that
<mup> PR snapcraft#1142 opened: Asset Tracking - Store versions of stage-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1142>
<mwhudson_> hm
<mwhudson_> ogra_: around?
<mwhudson_> running /var/lib/classic/enable.sh in an unpacked core snap makes snapd think it's a classic system
<mwhudson_> which is a pain
<mwhudson_> oh it's because it overwrites lsb-release i think
<kyrofa> mwhudson_, classic mode needs to act like classic ubuntu (regarding lsb-release) or various tools break
<mwhudson_> ah hm
<mwhudson_> what i am actually trying to do is make a core snap with an upgraded console-conf in it
<kyrofa> mwhudson_, snapcraft, catkin, etc.
<kyrofa> Ah
<mwhudson_> maybe there is a better way to do this these days
<mwhudson_> i guess i can just build my own core snap from scratch but ehh
<mwhudson_> actually i think i can just unpack the new debs
<mwhudson_> in this case
<mwhudson_> but that won't work in full generality
<mup> PR snapd#2868 opened: Don't return null result for async responses <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/2868>
<ogra_> mwhudson_, why the heck would you ever run that script ?
<ogra_> mwhudson_, that script is the backend for the classic snap ...
<ogra_> nothing you should run by hand :)
<ogra_> snap install --devmode --edge classic; sudo classic ....
<Guest32650> bah
<ogra_> then you use the script  the right way
<mwhudson_> ogra_: ok
<ogra_> mwhudson_, to change the core snap itself, you should use unsquash it ... unpack your deb in the squashfs-root dir that created and then snapcraft snap squashfs-root ... then you can sideload it
<mwhudson_> ogra_: yeah, that's what i did
<ogra_> but do that on a PC ...
<mwhudson_> i guess it hardly matters that the dpkg database is wrong...
<mwhudson_> ogra_: no fear, i am not in the "snappy == iot" brigade :-)
<ogra_> the dpkg database is gone
<ogra_> we rip it out :)
#snappy 2017-02-16
<mup> Bug #1665184 opened: Assertion list returned by GET /v2/assertions/type can't be reliably split <Snappy:New> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1665184>
<kyrofa> barry, the fact that ubuntu-image uses the beta channel by default surprises me and is unclear from the manpages. Shouldn't it be stable?
<barry> kyrofa: it can't be because it requires devmode.  i think we definitely want to try to convert it to a classic snap at some point, but for now we treat beta as our release channel (and edge as our "proposed")
<sgorshkov> Hi
<mup> PR snapd#2868 closed: Don't return null result for async responses <Created by robert-ancell> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2868>
<kalikiana> barry: even though you can have a snap that uses devmode without declaring it in snapcraft.yaml ;-)
<kalikiana> I don't know that it's the right thing to do, but some snaps do it, and it's not being blocked
<kalyan_> how to mount a ubuntu-core-16-dragonboard-410c.img
<kalyan_> and write a file in to the mount partition
<mup> PR snapd#2869 opened: Add Online Accounts interface <Created by mardy> <https://github.com/snapcore/snapd/pull/2869>
<ernstp> what's the difference between meta/snap.yaml and snapcraft.yaml?
<ogra_> one is used to build a snap, the other is meta information inside a snap package
<ogra_> snap.yaml is all the "non-build" meta info from the snapcraft.yaml usually
<ernstp> sometimes you create a snap.yaml manually though?
<ogra_> not really ... you *can* do that but it means the build takes two steps and you cant use the auto-builder on launchpad
<ernstp> looking at https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder and https://docs.ubuntu.com/core/en/guides/build-device/board-enablement
<ogra_> (like you can create a deb from scratch by putting the right files in the right places and using ar and gzip to finally create the package, you can do the same with a snap, but nobody would seriously do that)
<ogra_> ernstp, thats rather outdated
<ernstp> wow, rly?
<ogra_> from a time where snapcraft did not understand "type: gadget"
<ernstp> this page looks nice and official: https://docs.ubuntu.com/core/en/guides/build-device/board-enablement
<ernstp> but it's already outdated?
<ogra_> yet it is outdated :)
<ogra_> https://github.com/snapcore/pi3-gadget
<ogra_> have a look there
<ogra_> ondra, ^^^ perhaps you shoudl update that ;)
<ernstp> I started at these wonderful pages that haven't been updated since 2011 :-) https://wiki.ubuntu.com/ARM/RootStock https://wiki.ubuntu.com/ARM/RootfsFromScratch
<ogra_> hah
<ogra_> yeah, thats all obsolete but some of it might still work
<ernstp> yeah I mean debootstrap will always work I guess
<ogra_> its not like the underlying technology changes much there
<ernstp> and there's multistrap
<ogra_> rootstock went out of maintenance some time ago though ... but its just a script, easy to asdjust if needed
<ernstp> ogra_: but thanks for pointing to the pi3 thing, I'll dig through it...
<ogra_> if you have questions, just ask :)
<ernstp> ogra_: is this up to date... ? https://github.com/snapcore/snapd/wiki/Gadget-snap
<ernstp> it mentions meta/snap.yaml again..
<ogra_> no, that needs updating too it seems
<ernstp> I like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/tree/master/builder because it includes building  u-boot etc
<ogra_> ernstp, yeah, you could just call that from the snapcraft.yaml
<ernstp> there's no kernel snap in the rpi3 repo?
<ogra_> no
<ogra_> the kernel is from the official builds in the ubuntu archive
<ernstp> right
<ogra_> the source for it is on kernel.ubuntu.com
<ernstp> I guess I'm comparing this to yocto...
<ogra_> you cast really :)
<ogra_> *cant
<ernstp> where you build a kernel, u-boot, pick up some userland, and then bake it all into an image
<ogra_> all the bits are separately upgradeable and you can also roll back each of them individually
<ernstp> of course the point of using Ubuntu Core would be to _not_ compile all of userland from scratch
<ogra_> in case of kernel that happens even automatically if a new kernel doesnt finish booting
<ogra_> also the resulting image is readonly with only the few bits made writable the system needs to run, you cant really tinker with it
<ogra_> (snaps are signed readonly squashfs files)
<ernstp> well comparing to yocto I still need to take a bunch of source, compile it and then combine it to an image I can flash to a device
<ogra_> well, the kernel and bootloader, yeah
<ernstp> yes
<ogra_> (if your board is supported by the generic kernel only the bootloader ... )
<ernstp> no I've got a custom board
<ernstp> the arm world is moving forward but it's going slow...
<ogra_> yep
<ernstp> how could that setup look then...
<ogra_> well, enabling the beaglebone black which has mainline support was a 30min job for me ... simply because i didnt need to care for the kernel
<ernstp> gadget/gadget.yaml gadget/snapcraft.yaml kernel/snapcraft.yaml
<ogra_> https://github.com/snapcore/snapcraft/tree/master/demos/96boards-kernel/snap
<ernstp> I'm using an imx6 processor plus a custom board
<ogra_> https://snapcraft.io/docs/reference/plugins/kernel has the docs for that
<ernstp> ogra_: right, that's just like https://github.com/kubiko/roseapple-pi-ubuntuCore-build/blob/master/builder/kernel/snapcraft.yaml makes perfect sense to me
<ogra_> right
<ernstp> that's exactly what I need for the kernel, pointing out config, dtb, some options and whatnot
<ernstp> then I want to build a gadget around that
<ogra_> right, and then an image
<ogra_> (docs for that are at https://docs.ubuntu.com/core/en/guides/build-device/image-building )
<ernstp> which leads to the https://docs.ubuntu.com/core/en/guides/build-device/board-enablement page that was outdated you said
<ernstp> Can I reference snaps locally?
<ernstp> right, I can, gadget and kernel refer to snaps already existing in the store or in the current directory
<ogra_> ernstp, yes, with the --extra-snaps option
<ogra_> ernstp, note that even if the page is outdated, the resulting snap will work and you can later port to plain snapcraft.yaml if you want
<ogra_> so just follow it for now :)
<mup> PR snapd#2870 opened: tests: failover test for rc.local crash <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2870>
<mup> PR snapd#2871 opened: utils: helper function for creating a deep copy of interface attributes <Created by stolowski> <https://github.com/snapcore/snapd/pull/2871>
<hangun> hi
<hangun> I registered a new account and the profile is at https://launchpad.net/~ucrobotics123
<hangun> but when I executing " snapcraft register-key" commmand and inputing account and password
<hangun> I got an error like this:   you need to set a usename. it will appear in the developer filed alongside the other detials or your snap.
<ernstp> hangun: I think it's confusingly called "Developer namespace" in the account details online
<hangun> hi ernstip
<hangun> how I set up the "namespace"
<hangun> I dont see where to set up in my account https://launchpad.net/~ucrobotics123
<ogra_> hangun, did you set it up on login.ubuntu.com ?
<ernstp> hangun: if you read the full error message there's an url
<hangun> I set up the "Username" filed at https://login.ubuntu.com/
<hangun> any role for that?
<hangun> my username is "ucrobotics123"
<ogra_> and you can log in with that on https://myapps.developer.ubuntu.com ?
<ogra_> there is a ""developer namespace" option in the account settings
<hangun> thanks ogra_
<hangun> it works now
<hangun> I have another question:  after snappy system booting up,  executing commands " snap install hello-world" , "hello-world"
<hangun> but got error like this: cannot bind-mount the mount namespace file /proc/11268/ns/mnt -> hello-world.mnd
<hangun> support process for mount namespace capture exited abnormally
<cachio> niemeyer, hi, I am trygin to push to spread a branch with the change that I did to export xunit format but I am getting
<cachio> remote: Permission to snapcore/spread.git denied to sergiocazzolato
<niemeyer> cachio: Hi
<niemeyer> cachio: Got your email as well
<niemeyer> cachio: Typical workflow in github is you fork the project into your own space, push the changes you want, and then send a pull request (PR) to the original project
<niemeyer> cachio: You don't need write access to the master branch for that
<cachio> niemeyer, I did that
<niemeyer> cachio: Not really.. you see the message above?
<niemeyer> cachio: You're trying to write into snapcore/spread.git.. that's not your fork
<cachio> niemeyer, in that case I' try again
<niemeyer> cachio: You're not supposed to be able to push there (yet, at least)
<cachio> niemeyer, ok
<hangun> hello all
<hangun> I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457
<mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
<zyga> hello, sorry from being absent from IRC
<zyga> anyone had a question about namespaces in snaps?
<ogra_> zyga, that was hangun
<ogra_> more abour namespaces in kernel i suspect though
<ogra_> *about
<mup> PR snapd#2864 closed: interfaces: API additions for interface hooks <Created by stolowski> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2864>
<zyga> hangun: hey
<zyga> hangun: how can I help you, can you please repeat your question?
<mup> PR snapd#2524 closed: interfaces/builtin,cmd/snap-confine: add the overmount interface <Created by kalikiana> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2524>
<niemeyer> zyga:
<niemeyer> <hangun> hello all
<niemeyer> 10:22:33 I have the similar issue like this https://bugs.launchpad.net/snap-confine/+bug/1645457
<mup> Bug #1645457: cannot bind-mount the mount namespace file on Kernel 3.10 <Snappy Launcher:New> <https://launchpad.net/bugs/1645457>
<ogra_> heh, and he left
<mup> PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2866>
<jdstrand> zyga: hey, why make the libcap stuff conditional? it will work everywhere
<zyga> jdstrand: because we cannot add dependencies to snapd easily now
<zyga> jdstrand: I want to just enable it on compile time if it is available
<zyga> jdstrand: and as we work on resolving the other bug (that affects apt) we can just hard-depend on it
<jdstrand> zyga: but the code is correct... why can't you add a dependency?
<zyga> jdstrand: right now because of how apt works it means people will not update
<zyga> jdstrand: mvo has the gory details
<zyga> jdstrand: but that's the bottom line
<jdstrand> we add new stuff all the time
<jdstrand> look at bind9 updates
<jdstrand> this isn't a reason to not do stuff
<zyga> jdstrand: and stats show us that people are stuck on ancient snapd
<jdstrand> I know that thread
<zyga> jdstrand: we researched this, apt behaves this way if you use a particular command
<jdstrand> so fix apt
<jdstrand> that was the takeaway from the conversation as I understood it
<zyga> jdstrand: I'm not aware of that, I need to ask mvo
<zyga> jdstrand: I asked him today and he recommended against adding deps to snapd
<zyga> jdstrand: in any case, on ubuntu the build will not use libcap and will just do that unconditionally
<zyga> jdstrand: on fedora we can use libcap
<zyga> jdstrand: I think this is fine
<zyga> jdstrand: until we can address the issue in apt
<jdstrand> I don't think it is fine because it adds code complexity in the setgroups check
<zyga> jdstrand: wh?
<zyga> *why?
<jdstrand> we are using libcap to see if we can use setgroup
<zyga> the only complexity will be an #ifdef in the sc_has_capabaility
<jdstrand> no
<zyga> without libcap it will just say yes
<jdstrand> and that will be wrong
<zyga> why?
<jdstrand> if you call drop privs as non-root, setgroups will fail
<jdstrand> that is the whole reason the check is there
<zyga> oh we ca easily check for that
<zyga> we have the cap if running as root
<jdstrand> yes, but the code is correct. we need to fix the underlying problem, not contort our code
<zyga> that's one line in the #else part of the has_capability
<jdstrand> the underlying problem is a distro problem that affects more than just snapd. not fixing it and people aren't getting other updates. snapd shows the symptom, but that is only because it is the only thing we are looking at
<jdstrand> also, the xfslibs change also introduced a dependency. are we going to yank that out? cause that will affect security policy
<jdstrand> kernels, bind9, and other things all do this regularly in the distro
<zyga> jdstrand: I noticed that too
<zyga> jdstrand: one secodn
<zyga> jdstrand: (mvo says it is hard socially)
<zyga> jdstrand: for that I think we just need the macro definitions
<zyga> jdstrand: not any real dependency at runtime, right?
<zyga> jdstrand: or we can link libacap statically
<zyga> jdstrand: that's easy too
<zyga> jdstrand: would you +1 that?
<Son_Goku> :/
<jdstrand> for quota patch, it shouldn't pull in a runtime dep, only the build afaics (according to ldd)
<zyga> jdstrand: I think we pulled in libhandle, not sure why
<zyga> I saw it in ldd
<zyga> Son_Goku: hey
<jdstrand> oh, I don't have the right branch, hold on
<Son_Goku> zyga: hi
<zyga> jdstrand: I mean libhandle from xfs is in master
<jdstrand> no, I have the right branch
<jdstrand> ldd ./snap-confine/snap-confine
<jdstrand> I see no libhandle
<jdstrand> that is with quota patches but not up to date master
<jdstrand> and with up to date master, no libhandle
<jdstrand> mvo: hey, can you comment on the no new deps thing? ^
<zyga> jdstrand: I agree, I wonder why I saw it on centos, I'll check later
<zyga> Son_Goku: question, so the centos package
<zyga> Son_Goku: can we build a small centos package separately from the fedora package?
<zyga> Son_Goku: just something that could live in copr for now
<zyga> Son_Goku: I was looking at rhel and man, no build deps for anything
<Son_Goku> haha
<mvo> jdstrand: in a meeting right now
<zyga> Son_Goku: so I think the package should build on centos first
<Son_Goku> well, if it can build in EPEL, that's enough
<zyga> Son_Goku: and then can move over as a binary package
<zyga> Son_Goku: exactly
<Son_Goku> no, I mean, that's enough for everyone (CentOS, RHEL, etc.)
<zyga> Son_Goku: did you see my blog post about centos?
<zyga> Son_Goku: ah, I see
<Son_Goku> EPEL is RHEL + EPEL packages
<mvo> jdstrand: what dependency was that again?
<Son_Goku> and because CentOS is binary compatible, it works there
<zyga> mvo: libcap2
<zyga> mvo: (and libcap-dev as build-dep)
<jdstrand> mvo: this time, libcap
<jdstrand> libcap2, yes
<mvo> jdstrand: isn't that part of a the default install anyway?
<mvo> if so, we are fine
<zyga> hmmm, good question
<jdstrand> let me double check
<zyga> it is in main
<ogra_> we definitiely ship it in core
<jdstrand> I checked the apt-cache rdepends, but didn't finish looking at it before I got fired up :)
<mvo> it is installed in my pbuilder chroot
<jdstrand> ogra_: we have libcap-ng in core
<zyga> I think it's in bydefault
<zyga> jdstrand: in that case let's re-open and land as-is
<mup> PR snapd#2866 opened: cmd/libsnap: add helper for dropping permissions <Created by zyga> <https://github.com/snapcore/snapd/pull/2866>
<jdstrand> avahi-daemon needs it, so it is in the desktop
<zyga> jdstrand: can you review it now
<jdstrand> iputils-ping needs it, and that is in minimal
<ogra_> jdstrand, i see libcap2 here and libcap2-bin
<jdstrand> (on trusty)
<hangun> hi zyga
<jdstrand> same for xenial
<hangun> just left for a while
<ogra_> on trusty we still use the same core
<ogra_> https://launchpadlibrarian.net/306642126/core_16.04.1_amd64.manifest is the manifest file for the core snap
<jdstrand> and yakkety and zesty
<jdstrand> well, the core snap isn't an issue cause it'll just be slurped in, but I did check there. let me check again
<Son_Goku> zyga: EPEL in Koji uses RHEL 7 base, EPEL in COPR uses CentOS 7 base
<ogra_> http://people.canonical.com/~ogra/core-builds/ has links to all the manifests
<jdstrand> ogra_: you are right. libcap2 is in /lib but libcap-ng is in /usr/lib. I only checked /usr/lib
<jdstrand> it's in minimal, so crisis averted for this
<Son_Goku> jdstrand: bah, UsrMerge :)
<Son_Goku> do iiiit :D
<jdstrand> however, I thought a fix for apt-get was the way to go to make it work the same as apt
<zyga> Son_Goku: I suspect 18 will do it
<Son_Goku> FINALLY
<zyga> Son_Goku: nobody cares though :)
<Son_Goku> :'(
<zyga> it's a change that changes nothing relevant for anyone
<zyga> internal refactor
<Son_Goku> y'all suck :)
<zyga> hangun: hi
<zyga> hangun: I want to help you with the issue you mentioned
<zyga> hangun: I merged a small fix into snapd master that affects 3.10
<jdstrand> zyga: all this said. it is actually interesting to think about (not for this PR) to make snap-confine statically linked, or at least, partially so
<zyga> jdstrand: yes, I agree, though we will use core libs for re-exec linking it statically is not a bad idea
<zyga> hangun: can you try master and tell me exactly what error are you getting
<jdstrand> zyga: well, re-exec is only for classic
<zyga> jdstrand: yes
<zyga> jdstrand: do you see advantages to static linking on core?
<jdstrand> but it does help the re-exec case. it also would allow us to reduce the apparmor profile. potentially avoids problems where the libs it would dynamically link out to change incompatibly such that snap-confine fails. that *should* never happen and tests would reveal that type of thing
<jdstrand> it does mean that we need to rebuild for security updates
<jdstrand> it is something to think about. I'm not recommending it atm, just thinking out loud
<zyga> jdstrand: I think we should add that to the list of things to investigate once core splits into core + base
<zyga> jdstrand: could be used to keep core totally tiny
<jdstrand> well, it would actually be a little bigger
<mup> PR snapd#2872 opened: tests: only check core refresh if there's no update available <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2872>
<jdstrand> since it doesn't use many libraries and most of those are fundamental-- I doubt any would drop of, so there would be duplication. but I'm not saying this is a concern, just that it wouldn't be smaller
<zyga> jdstrand: only if something else also depends on libcap in core
<hangun> zyga:  My env like this snapd version (2.21), snapcraft version (2.26) ubuntu-snappy version (2.21).
<jdstrand> libcap is the only thing
<jdstrand> that it would save
<zyga> hangun: you need to build snapd from master
<jdstrand> if it is totally staically compiled, then libc is there and in core
<zyga> hangun: there's a lot of improvements that landed since 2.21
<zyga> hangun: and the fix to 3.10 that I did is not released yet
<zyga> hangun: I don't know it fixes the issue you are seeing but I did use it run on a 3.10 kernel
<zyga> hangun: (though without apparmor)
<zyga> hangun: but you need that fix to get it to work anyway
<morphis> lool: lool: https://github.com/morphis/tvheadend/tree/snap-support
<jdstrand> of course, you could just statically link libcap
<jdstrand> anyway, something to think about
<mup> PR snapd#2835 closed: strutil: support version compare with empty strings <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2835>
<hangun> zyga:  thanks, i try it now.
<zyga> Son_Goku: what are those notificationabout snap-confine for f23 being deleted?
<zyga> Son_Goku: is that because of EOL?
<Son_Goku> no
<Son_Goku> I think it's because you never submitted them as updates
<zyga> so what is exactly being deleted?
<Son_Goku> if they're not tagged, koji aggressively gc's them
<Son_Goku> the build artifacts
<zyga> ah
<zyga> that's fine
<zyga> Son_Goku: we should try to get those packages out
<zyga> Son_Goku: 2.23 has all the fixes for fedora now
<Son_Goku> is it released?
<Son_Goku> I didn't see mvo announce 2.23 yet
<Son_Goku> did we also get any new systemd units that I need to refresh my systemd unit patch for?
<zyga> Son_Goku: mvo will release it today I think
<zyga> mvo: when is the release? today?
<zyga> Son_Goku: no, we can drop units now
<zyga> Son_Goku: more less
<Son_Goku> well, our systemd units work slightly differently from ubuntu's remember
<zyga> Son_Goku: we have a packaging/ directory
<zyga> Son_Goku: yes, I mean we should put them there
<zyga> Son_Goku: if you commit them we don't need to carry the patch
<Son_Goku> well, I can certainly submit a PR with them, if you'd like
<zyga> Son_Goku: please, I really want those
<zyga> Son_Goku: you didn't answer my question about the centos blog post
<Son_Goku> I didn't read it yet
<zyga> Son_Goku: did you see the stuff I added there?
<zyga> Son_Goku: ah, OK
<Son_Goku> reading it now
<Son_Goku> looks like zbyszek left comments on your blog?
<zyga> Son_Goku: yes
<zyga> Son_Goku: nice to see feedback from systemd developers :)
<Son_Goku> talking to them often helps, too :)
<Son_Goku> Lukas and Zbyszek are nice people
<zyga> I'm sure, I'd love to meet them in person one day
<Son_Goku> Lukas is the RHEL systemd maintainer, and Zbyszek is the Fedora one
<zyga> I could use more sleep ;)
<Son_Goku> or more coffee :)
<zyga> I think I need to survive too ;)
<hangun> zyga:  is this the snapd link https://github.com/snapcore/snapd/ ?   How I compile it or any easy way to get a latest nightly deb package?
<zyga> hangun: yes that is it
<lool> morphis: awesome!
<zyga> hangun: not sure where are the nighly packages, I think they are built somewhere but I cannot say
<zyga> hangun: I wrote a blog post about how to build it from source on centos lately, the instructions are almost enitirely valid for other distributions (you just need the right build dependencies)
<zyga> hangun: https://new.zygoon.pl/post/case-study-snapd-on-centos/
<hangun> zyga:  awesome
<zyga> hangun: feel free to ping me with question
<zyga> hangun: you can try to build just the snap-confine parts
<zyga> hangun: and you can make install DESTDIR=/tmp/foo if you just need a particular file to test
<zyga> hangun: I'm not sure what the process is on your device
<hangun> zyga:  my board is bubblegum 96board http://www.96boards.org/product/bubblegum-96/
<zyga> hangun: I see
<zyga> I don't have that board at home
<ogra_> hopefully all needed config options are set in that kernel
<hangun> zyga:  i will re-build snapd following your blog
<mup> PR snapd#2841 closed: interfaces: allow recv* and send* by default, accept4 with accept and other cleanups <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2841>
<mup> PR snapd#2842 closed: interfaces: misc updates for network-control, firewall-control, unity7 and default policy <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2842>
<Son_Goku> zyga, what should I label the folder inside of packaging/ ?
<Son_Goku> I originally was using the catch-all top level directory dist/, but I guess that doesn't fit here
<zyga> Son_Goku: just put packaging/fedora-25 there
<zyga> Son_Goku: we can use symlinks for others
<zyga> Son_Goku: and then we can use that in downstream packages
<zyga> Son_Goku: we can also keep a copy of the spec for CI
<Son_Goku> even if the units are useful for more than fedora? they're basically the ones anyone that isn't using Debian uses
<zyga> Son_Goku: yes
<zyga> Son_Goku: symlinks :)
<zyga> Son_Goku: we can sim;lify over time
<Son_Goku> okay
<Son_Goku> as for spec for CI, that would mean that snapcore-selinux needs to somehow be available for spread to pull in
<Son_Goku> or is it always going to retrieve that from fedora dist-git?
<zyga> Son_Goku: yes, I think we can come up with something
<Son_Goku> okay
<zyga> Son_Goku: not sure yet
<zyga> jdstrand: what about 2863?
<zyga> jdstrand: I'd like that in candidate that's going out now
<mup> PR snapd#2866 closed: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2866>
<jdstrand> zyI already commented on that yesterday. I didn't think it needed more work from me, but I'll approve it
<mup> PR snapd#2873 opened: tests: several improvements to the nested suite <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2873>
<zyga> re
<jdstrand> zyga: I already commented on that yesterday. I didn't think it needed more work from me, but I'll approve it
<zyga> jdstrand: just the approval :)
<jdstrand> zyga: note, you merged https://github.com/snapcore/snapd/pull/2866 without a second +1, just mine
<mup> PR snapd#2866: cmd/libsnap: add helper for dropping permissions <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2866>
<zyga> jdstrand: I cannot merge it without it
<jdstrand> well, you'll need a second +1 too
<jdstrand> unles the commit policy changed
<zyga> jdstrand: that counts as one
 * jdstrand is just operating under what he's been told
<jdstrand> zyga: what counts as one? my +1? yes, and you need two +1s other than yourself as I've been told
<hangun> zyga:  I git clone snapd from source and then  ./mkversion.sh
<hangun> zyga: *** Setting version to '2.22.2+git475.g7900000.dirty' from git.
<Son_Goku> zyga, does snap-confine get the same versioning as snapd now?
<Son_Goku> or does it still maintain its own version somewhere?
<zyga> Son_Goku: yes
<zyga> Son_Goku: it's the same version, easier :)
<Son_Goku> okay
<Son_Goku> zyga: working on the snapd.spec rebase to v2.23... https://github.com/Conan-Kudo/snapd/commit/f73baebb3d0d9f049568b1134365c2b47368c981
<Son_Goku> let me know if there's something I'm missing that should be added
<Son_Goku> haven't built it yet, either, as I need to go to work
<Son_Goku> I'll test and fix up the inevitably broken file lists...
<zyga> Son_Goku: looking
<zyga> Son_Goku: BuildRequires: pkgconfig(libcap)
<Son_Goku> on snap-confine?
<Son_Goku> does that mean we can use file caps?
<zyga> Son_Goku: also requires xfsprogs-devel
<zyga> Son_Goku: no but we start to use libcap
<zyga> Son_Goku: maybe we can switch over time, but the dependency is in place now
<zyga> Son_Goku: you also want glibc-static
<Son_Goku> uh why glibc-static?
<zyga> Son_Goku: though we don't need to ship the resulting file (system-shutdown)
<zyga> Son_Goku: there's a special helper that systemd runs on core systems to unmount the filesystem correctly
<zyga> Son_Goku: it's only used on core
<zyga> Son_Goku: and it runs back in intrd land
<zyga> Son_Goku: so it has to be static
<zyga> Son_Goku: just add the build-dep for now, we can make that conditional on something like --non-core-build or something later
<zyga> Son_Goku: check the list in the blog post, I listed all the packages for centos and that's pretty much the same list for Fedora
<zyga> Son_Goku: reading the rest now
<zyga> Son_Goku: make sure the configure call matches autogen (not sure if it doenst)
<zyga> Son_Goku: we have a new go executable (snapctl) that should be built and installed to %{_bindir}
<zyga> Son_Goku: we should include the /var/lib/snapd/void directory that is root.root 0000
<zyga> Son_Goku: snap-confine creates it but it should be owned by the package
<Son_Goku> it is
<zyga> oh, must have missed it
<Son_Goku> snapctl goes in snap-confine?
<zyga> Son_Goku: no, more like snapd
<zyga> Son_Goku: I'd merge them TBH
<zyga> Son_Goku: one binary package
<zyga> Son_Goku: but digress,
<zyga> Son_Goku: we need a new info file
<zyga> Son_Goku: it is in libexecdir for now
<zyga> Son_Goku: it is in data/info after build AFAIR
<zyga> Son_Goku: it's just a version dump
<zyga> Son_Goku: oh and we should run ./mkversion.sh
<zyga> Son_Goku: right now we skipped that but it is mandatory for snap-confine and everything else now
<zyga> Son_Goku: we _probably_ have to fix mkversion
<zyga> Son_Goku: or have it just echo the fedora version
<zyga> Son_Goku: it looks at git
<zyga> Son_Goku: but then falls back to debian/changelog
<zyga> Son_Goku: it's a bit hard to say where the reference version should be
<zyga> Son_Goku: we can fix that but not sure where to put the version
<Son_Goku> if we could just write a file out somewhere, I can inject the version that way
<Son_Goku> with like echo "%{version}" > VERSION
<zyga> Son_Goku: the script generates a go version file, a static file for snap-confine (configure.ac reads it) and the info file (snapd reads it at runtiime)
<zyga> Son_Goku: kind of yes,
<zyga> Son_Goku: but if you do that in mkversion.sh as a patch we can upstream it and it will not drift over time
<Son_Goku> yeah, alright, I'll take a look at it
<zyga> Son_Goku: that script was a quick and dirty way to progress and this is a good chance to just make it nicer
<Son_Goku> I gotta go to work
<zyga> Son_Goku: thank you, let's sync later
<zyga> Son_Goku: you can drop SNAPD_REEXEC, reexec is disabled on fedora and similar now
<zyga> Son_Goku: you can keep it just in case you want to for now but it's not useful anymore
<Son_Goku> I'm going to leave it as reference
<zyga> Son_Goku: oh and we have a few more manual pages Is uspect
<zyga> Son_Goku: still not enough but more than before :-)
<zyga> I plan to write the missing few when I have a chance to look at this
<zyga> (fighting other dragons now)
<zyga> Son_Goku: we may have more directories in /var/lib/snapd/ we should cross-check with debian packaging
<zyga> (and document them in snapd man page)
<zyga> Son_Goku: that's all I could see on a quick read, again *thanks* for picking this up :)
<brunch875> does snappy have any system for bug reporting?
<brunch875> not snappy itself, but for specific snaps
<zyga> brunch875: no not at present
<brunch875> zyga, is it planned?
<zyga> brunch875: there's work for landing a way to display contact information, it should be ready in the next release
<brunch875> nice!
<zyga> brunch875: I think that can be extended to include other URLs (e.g. a support URL)
<zyga> brunch875: you want to ask mvo about this, he was working on the feature
<zyga> brunch875: but I think he's very busy today, working on the release
<zyga> brunch875: so perhaps tomorrow
<zyga> brunch875: or just send an email to the snapcraft mailing list
<mvo> snap info snapname in master will give you contact information
<mvo> (in a meeting)
 * zyga hugs mvo
<zyga> thanks! :)
<brunch875> thank you!
<stokachu> im seeign this on 14.04 : 2017-02-16T15:34:49Z INFO snap "core" has bad plugs or slots: core-support (unknown interface)
<ogra_> stokachu, well, just an INFO message ... does it behave correctly ?
<stokachu> ogra_, not sure yet still trying to load my snap
<ogra_> (core just got upgraded to  new version, you most likely just got that one)
<zyga> stokachu: this is a known issue, not sure where the bug for tracking that is
<stokachu> zyga, ok thanks
<ogra_> it shouldnt cause any harm though
<popey> mvo: just saw your mail about new core and tried to update...
<popey> $ snap refresh
<popey> 2017-02-16T15:40:17Z INFO snap "core" has bad plugs or slots: core-support (unknown interface)
<popey> core 16.04.1 from 'canonical' refreshed
<popey> is that expected?
<mvo> popey: yes, its just a warning (still not nice)
<ogra_> so it refreshed fine and informed you that the old core didnt have that interface
<popey> oh, it's moaning about the old core, I see.
<popey> thanks
<ogra_> well, about the one in use at the time of the upgrade
<ogra_> (also, core-support is moot on classic systems)
<ogra_> (at least it should be :P)
<jdstrand> kyrofa: fyi, responded to https://github.com/snapcore/snapd/pull/2837
<mup> PR snapd#2837: interfaces/apparmor: allow reading from ecryptfs <Created by zyga> <https://github.com/snapcore/snapd/pull/2837>
<mup> Bug #1648615 changed: Apps hit apparmor denial trying to connect to unity8's mir_socket <Canonical System Image:Confirmed for alecu> <Snappy:Invalid by mterry> <https://launchpad.net/bugs/1648615>
<mup> PR snapd#2874 opened: kmod: added Specification for kmod security backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/2874>
<mup> PR snapd#2829 closed: tests: add libvirt interface spread test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2829>
<sdrobertw> Found this forum post on 96Boards: http://bit.ly/2kWV5l5
<kyrofa> sdrobertw, not sure what's going on there-- I suggest an email to the snapcraft list, or have them hop in here so we can troubleshoot
<kyrofa> barry, ah, no, I was using the deb anyway. I meant when I run ubuntu image without `-c`, it defaults to using beta
<ogra_> sdrobertw, i guess thats the same guy we have on the mailing list, he has assembled a non-working image (kernel snap not fully working etc)
<ogra_> sdrobertw, his image is/was built in a way that the firstboot initialization did not properly work, which results in snapd not working
<barry> kyrofa: that must be a behavior of snap prepare-image.  if no -c is given to u-i, we don't pass --channel to `snap prepare-image`
<sdrobertw> kyrofa: I will tell them to join the channel
<kyrofa> barry, ah, interesting. Perhaps you should, haha!
<kyrofa> barry, that way you can document it. No one knows you're actually using snapd behind the scenes
<barry> kyrofa: we should definitely document that, but understand that u-i will also eventually create classic images, so it's not supposed to be so tied to snaps.  i guess snap prepare-image needs better documentation and/or defaults
<kyrofa> barry, understood. Although keep in mind that documentation for snap prepare-image won't help anyone if it's always wrapped by ubuntu-image
<kyrofa> barry, if we eventually need to call prepare-image ourselves (is that what you mean?), that's fine
<barry> kyrofa: well, what i'd like to do is document u-i "backends" (of which there is only one right now) and that's where we can document how prepare-image is called under the hood
<barry> kyrofa: no, you should never have to call it yourself
<kyrofa> barry, I see, okay
<lool> kyrofa: hey, is cleanbuild working for you with a snap/snapcraft.yaml?
<lool> I've got this error when trying a build:
<lool> Processing triggers for libc-bin (2.23-0ubuntu5) ...
<lool> Could not find snap/snapcraft.yaml. Are you sure you're in the right directory?
<lool> To start a new project, use 'snapcraft init'
<kyrofa> lool, I haven't tried. To be completely honest I don't use cleanbuild-- I just create a clean container myself so I can utilize caching
<lool> kyrofa: would you know if the tarball is supposed to contain snapcraft.yaml?
<kyrofa> lool, ohhh
<kyrofa> lool, I know what you hit
<lool> I looked as the tarignore logic, and it seems correct yet the tarball doesn't contain snapcraft.yaml
<kyrofa> lool, indeed, way back when 'prime' used to be called 'snap' so cleanbuild had logic to ignore it when creating the tarball
<kyrofa> lool, that's since been fixed, let me see if it's been released yet
<lool> oh ok, just me looking at fixed source code which is not the one I'm running, blah
<kyrofa> lool, ah, 2.27
<kyrofa> lool, it's in proposed
<kyrofa> lool, haha, that'll always get ya
<kyrofa> lool, sorry about that, we caught that issue too late
<lool> no that's great news, it's already fixed
<lool> kyrofa: it's funny cause I actually thought of this snap/ ignore explanation and thought "oh that will be easy to fix"
<kyrofa> lool, yeah it was like four characters
<kyrofa> Plus tests, of couse
<kyrofa> with an r in there somewhere
<lool> BTW I've noticed two pieces of potentially interesting behavior
<lool> one is with dependent libs
<kyrofa> Oh?
<lool> I have these binaries that require libsctp1
<lool> they are prebuilt
<lool> if I build the snap on a system that has the package, the lib gets copied automagically
<lool> however if it's missing, no error but the snap is incomplete
<lool> this would be caught by cleanbuild
<lool> in the sense that if I always used cleanbuild and tested the snap I would notice
<lool> but someone doing changes / buidling the snap wont notice
<lool> I wonder if you should warn/fail the build when trying to copy libs and failing, don't know
<kyrofa> lool, indeed. There are a few things here
<kyrofa> lool, first, check out https://snapcraft.io/docs/build-snaps/syntax and read about the `build-attributes`
<lool> it's kind of hard to both be tolerant in case it's in a later part and to be rigorous to make sure all libs are there
<kyrofa> lool, long story short, this is really unclear behavior as you noticed
<lool> ah didn't know about build-attributes: no-system-libraries
<kyrofa> lool, we're moving to, instead of magically copying things we know we need, erroring on them
<kyrofa> lool, we're hemming and hawing on it because it will break a lot of things, though
<lool> ok
<kyrofa> lool, not sure when that will happen or what it'll look like
<kyrofa> lool, however, if you want that behavior now, you can use that build-attribute
<lool> can I set build-attributes globally? seems per part
<kyrofa> lool, indeed, per-part
<kyrofa> lool, it's really there for content sharing when "yes I know that lib isn't here, I don't _want_ it to be"
<lool> kyrofa: is it build-attributes: [no-system-libraries]?
<kyrofa> You got it
<kyrofa> lool, what that means is that you'll need to specify all the libs you need as stage-packages
<lool> ok, the other thing I wanted to mention, probably bottom of the priority pile thing, is about 32-bits in amd64
<lool> I'm building an amd64 snap on amd64 but it contains a 32-bits runtime because "meh"
<lool> when I do this, I get tons or warnings
<pmcgowan> kyrofa, is there a way to "pin" a version of a snap so it doesnt update
<lool> kyrofa: actually I get one per binary
<lool> e.g. Unable to determine library dependencies for b'prime/xyz'
<lool> seems fair in terms of number of warnings, just thinking this could the same as for 64 bits, but again I dont expect any priority on this, just thought I'd mention I came across this
<kyrofa> lool, got pulled into a call, give me a few and I'll get back to you
<lool> kyrofa: no worries, this was just FYI
<mup> PR snapd#2865 closed: image,cmd/snap: refactoring and initial envvar support to use stores needing auth <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2865>
<kyrofa> Alright, done with the call
<ogra_> who won ?
<ogra_> :)
<kyrofa> Me, duh
<kyrofa> lool, ah, indeed that's interesting. We use the host's ldd to check that
<kyrofa> lool, but it's not a native elf file, so it skips it
<kyrofa> pmcgowan, sorry for the delay: not that I know of. I think you can disable refresh systemwide by stopping the right systemd unit, but that doesn't sound like what you asked for
<kyrofa> pmcgowan, however, that's a pretty popular request. manik is tracking it
<pmcgowan> kyrofa, not exactly, so if I revert a snap, does that effectively do it?
<pmcgowan> I assume the snap wont update after a revert?
<kyrofa> pmcgowan, it won't update to the revision from which you reverted, but I do believe it'll update when a new update comes out
<pmcgowan> makes sense
<DedSec> does anyone know if its possible to have an snap get the current version of an app using an github tag?
<kyrofa> DedSec, you mean when building?
<DedSec> yes
<kyrofa> DedSec, oh certainly
<kyrofa> DedSec, use source-tag
<kyrofa> DedSec, so you have `source: <github repo>` followed by `source-tag: <tag>`
<kyrofa> DedSec, `snapcraft help sources` may prove helpful as well
<DedSec> gotcha, so i could easily create an tag for Dev buils and one for stable and then have different snapcraf.yaml files for each version
<DedSec> sounds easy :)
<brunch875> does anyone know why there are two telegram snaps? I'm using sergiusens one because it has never given me any trouble
 * ogra_ uses it becaause he is a sergiusens fanboy
<kyrofa> brunch875, the store only cares about the names being unique. Anyone can release anything
<brunch875> So I could upload my own telegram? neat
<brunch875> thanks kyrofa, that cleared my doubts
<kyrofa> brunch875, so if you run `snap find telegram` you'll see that sergiusens has one, and pain7 has one. Pick your poison, or upload your own!
<kyrofa> brunch875, the one thing you can be certain of is that telegram has not officially released their own
<kyrofa> brunch875, because that would probably be called "telegram" and come from the "telegram" developer
<kyrofa> (or something)
<brunch875> what if I registered as telegram?
<kyrofa> brunch875, I suspect the name is reserved
<brunch875> I take it telegram would be able to reclaim its name
<kyrofa> brunch875, you'll have to justify it
<Pharaoh_Atem> sergiusens: hey, any luck on the PR?
<mup> PR snapd#2875 opened: mkversion.sh: Add support for taking the version as a parameter <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2875>
<Cynerva> Is there a way for a snap configure hook to get all the config keys?
<kyrofa> Cynerva, what do you mean?
<Cynerva> kyrofa: I'd like to get a list of every config that's been set for the snap. Partially for validation - so if someone says `snap set mysnap potato` but we don't have a potato config, I'd like to have the hook fail with feedback for the user
<kyrofa> Cynerva, ah okay. While I know you can retrieve multiple values at once with `snap get key1 key2 key3 ...` I don't think there's a way to retrieve _everything_
<kyrofa> Cynerva, but I think the plan is at some point to allow the snap to specify some sort of schema
<kyrofa> (don't take my word for it though, not quite sure on the plan)
<jdstrand> ogra_: hey, I was excited to see a new core in stable hoping for logging and ntp options (though they aren't there yet). That's fine, but I wanted to play with 'snap get', so I tried 'sudo snap get core ssh' and various other things, but it didn't work
<jdstrand> $ sudo snap get core ssh
<jdstrand> error: snap "core" has no "ssh" configuration option
<jdstrand> ogra_: I feel like I am missing something obvious
<jdstrand> https://docs.ubuntu.com/core/en/guides/build-device/config-hooks only shows 'set'
<kyrofa> jdstrand, assuming things haven't changed too much, you can only get things once it's been set. If the hook in the core snap doesn't `snapctl set` them when installing, you can get them
<jdstrand> it seems /snap/core/1083/meta/hooks/configure doesn't implement 'get', but I've not used the configure hook
<kyrofa> jdstrand, `get` is a snapd function
<jdstrand> oh
<kyrofa> jdstrand, it just returns the config value corresponding to that key for the snap
<jdstrand> let me try with rsyslog rather than ssh
<Cynerva> kyrofa: ahh okay, we'll make do without the validation for now, thanks :)
<kyrofa> jdstrand, which you can set via `snap set` (in which case the `configure` hook is run and can validate it) or from within the hook via `snapctl set`
<ogra_> jdstrand, snap get service.ssh.disabled
<jdstrand> sure enough
<ogra_> jdstrand, snap get service.rsyslog.disabled
<jdstrand> $ sudo snap set core service.rsyslog.disable=false
<ogra_> err
<jdstrand> $ sudo snap get core service.rsyslog.disable
<jdstrand> false
<ogra_> yeah
<ogra_> so setting it true disables ssh
<ogra_> same for rsyslog
<jdstrand> $ sudo snap get core service.ssh.disable
<jdstrand> error: snap "core" has no "service.ssh" configuration option
<jdstrand> right
<jdstrand> so you have to 'set' it first
<ogra_> yep
<jdstrand> ok, I'll file that away while I wait for ntp and remote logging :)
<jdstrand> kyrofa, ogra_: thanks!
<ogra_> well, service.systemd-timesyncd.disable
<ogra_> that one wroks already
<ogra_> (so you could install an ntp snap)
<ogra_> timeserver is next on my list
<mup> Bug #1665438 opened: Running command can end up with wrong security profile if refreshed <Snappy:New> <https://launchpad.net/bugs/1665438>
<stokachu> im trying to make a network interface persists through reboots using the daemon configuration, the interface is listed in ip addr but no ip address or iptables rules applied, https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L20-L24
<stokachu> this is a classic snap, am i missing anything here?
<stokachu> here i sthe output from systemctl status https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada
<stokachu> i dont see any errors here
<stokachu> https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada#file-gistfile2-txt that shows running the command directly also works
<mwhudson> what's the eta on snap info showing tracks?
<mup> Bug #1665184 changed: Assertion list returned by GET /v2/assertions/type can't be reliably split <Snappy:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1665184>
<kyrofa> barry, python3 -m flake8 is finding the one bundled in ubuntu-image before it finds python3-flake8
<kyrofa> barry, is that a problem on my machine?
<kyrofa> barry, running from the ubuntu-image deb, by the way
<barry> kyrofa: i'm not sure what that means.  flake8 isn't bundled with u-i
<kyrofa> barry, /usr/lib/python3/dist-packages/ubuntu_image/testing/flake8.py
<barry> kyrofa: how is that even on sys.path?
<barry> kyrofa: show me all the commands you're doing
<kyrofa> barry, within the snapcraft tree: python3 -m flake8 --max-complexity=10 snapcraft
<kyrofa> barry, and boy I'll tell you... it's not happy with snapcraft :P
<barry> kyrofa: you mean, you're inside a snapcraft git clone?
<kyrofa> Indeed
 * barry tries to repoduce
<kyrofa> barry, which contains another snapcraft directory
<kyrofa> barry, my sys.path doesn't look outrageous: http://pastebin.ubuntu.com/24009515/
<barry> indeed
<barry> kyrofa: wtf?!
<kyrofa> barry, do you see it as well?
<barry> kyrofa: i do see it in a traceback
<barry> offs
<barry> kyrofa: i know what the problem is :(
<barry> almost
<kyrofa> barry, I'm curious
<barry> kyrofa: i need to find one more piece of the puzzel
<barry> *puzzle
<lool> oh I have a funny one
<lool> I have a symlink under stage/blah that is pointing to an absolute directory location on my system
<lool> snapcraft tries to go in there and change stuff  :-)
<kyrofa> lool, how are you getting an absolute symlink into stage?
<lool> I wasn't getting this issue until I had something installed in the system location
<lool>     install: |
<lool>       # ship static symlink pointing to writable dir
<lool>       mkdir -p $SNAPCRAFT_PART_INSTALL/config
<lool>       ln -sf /var/snap/lteenb-lool/current/rf_driver \
<lool>           $SNAPCRAFT_PART_INSTALL/config/rf_driver
<lool> in one of my parts
<kyrofa> Ah, you're just asking for trouble
<lool> I need the symlink though  :-/
<kyrofa> lool, snapcraft works really hard in its plugins to prevent that, because you'll end up with a broken link in the final snap
<lool> kyrofa: it actually works well in the final snap!  :-)
<kyrofa> lool, it won't make it through review, I expect
<kyrofa> Oh wait...
<kyrofa> lool, you cheater!
<kyrofa> I didn't read the entire path
<kyrofa> But yeah, I'd still be surprised if the review tools let that through. Have you tried?
<kyrofa> lool, I'm assuming the snap is called "lteenb-lool"?
<lool> yes
<barry> kyrofa: LP: #1631156
<mup> Bug #1631156: flake8.extension entry point has global ramifications <Ubuntu Image:Won't Fix> <https://launchpad.net/bugs/1631156>
<barry> which doesn't help you much unfortunately :(
<kyrofa> barry, ouch. Yeah, I guess I'll remove it then
<barry> kyrofa: are you on zesty?
<kyrofa> barry, xenial
<barry> dang
<barry> i could fix it for zesty, but i'd have to put flufl.testing in backports for y and x
<barry> which maybe i should do
<barry> fwiw, it has nothing to do with snapcraft; any invocation of flake8 will break :(
<ogra_> lool, and cp instead of linking doesnt work ?
<lool> ogra_: would like to keep the up-to-date master configs in the snap
<kyrofa> barry, alright, thank you for the investigation!
<ogra_> hmm
<barry> kyrofa: let me think more on it
<bdmurray> https://snapcraft.io/docs/build-snaps/metadata makes reference to using wrappers, how I can add things to the wrapper?
<kyrofa> lool, what exactly are you trying to accomplish there?
<lool> kyrofa: the config has an include system with include <rf_driver/foo>; rf_driver is a symlink to the actual backend
<ogra_> bdmurray, easiest is to just add another wrapper (yay onions)
<kyrofa> bdmurray, those are small scripts you'd write yourself
<lool> instead of having the whole config copied into SNAP_DATA, I have SNAP/rf_driver -> SNAP_DATA/rf_driver and I manage the SNAP_DATA/rf_driver symlink with the snap's config
<kyrofa> lool, why not generate it at install time?
<mup> PR snapcraft#1143 opened: Switch Track and Arch in channel maps <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1143>
<lool> kyrofa: well the configs are under SNAP, so cant write there
<bdmurray> ogra_: Could you elaborate?
<ogra_> bdmurray, command-<command>.wrapper is generated, you cant really change it ... but you can make "command" another wrapper that then calls the actual command
<kyrofa> lool, ah yes of course
<ogra_> bdmurray, an onion of shell wrappers ...
<kyrofa> lool, so when you say snapcraft messes with it, what do you see happening?
<mup> PR snapd#2824 closed: overlord: make seeding work also on classic, optionally <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2824>
<lool> generally, it doesn't build anymore right now, I think it used to with previous version; but more interestingly, when I build it with the snap installed, because the absolute symlink ends up in stage/, snapcraft dives into it and tries to move files underneath
<lool> I suspect I have changed other things in the build that trigger this issue though
<kyrofa> lool, yeah probably because it notices it's absolute, so it's trying to follow the symlink and copy the dir
<bdmurray> ogra_: there's nothing that can be put in the yaml file to just set env variables in the wrapper?
<ogra_> bdmurray, i think something was recently added ... not sure it is in a released snapcraft yet ?
<kyrofa> bdmurray, you'll be able to do that in snapcraft v2.27, in proposed
<ogra_> kyrofa, was the environment handling in snapcraft.yaml released already ? (and are there docs for bdmurray )
<kyrofa> ogra_, too slow!
<ogra_> ah, yeah :)
<ogra_> <- old fart :P
<lool> kyrofa: I'll play a bit more with it, I think I can reduce the number of weird things
<pmcgowan> ogra_, kyrofa which services do I need to disable to stop auto updates? is snap.refresh.service enough?
<kyrofa> pmcgowan, I _think_ so
 * kyrofa wonders about snapd.refresh.timer
<pmcgowan> kyrofa, that was my thought
<kyrofa> pmcgowan, I haven't done this if you can't tell :
<kyrofa> :P
<bdmurray> How can I only rebuild the necessary parts of the snap after I added environment information to the yaml file?
<kyrofa> bdmurray, just run `snapcraft` again, that meta-data is always copied over
<kyrofa> bdmurray, are you running out of snapcraft master, then?
<bdmurray> kyrofa: no 2.27 is in -proposed and I installed it
<kyrofa> bdmurray, ah, okay
<kyrofa> Then you should be good, yeah
<lool> kyrofa: so I was wrong, everything is fine now; I think the new snapcraft was actually stricted and made me fix a bug (trying to install this symlink twice) which probably snapcraft shouldn't bother detecting
<lool> what was really happening was that another part was shipping a default version of this symlink (the upstream one) and when snapcraft tried installing it, it installed in the system dir due to my hacked symlink
<lool> not something you should worry about really
<kyrofa> Ahh, yeah that would be tough
<lool> once I stopped priming that copy of the symlink, things worked again just fine
<kyrofa> Good catch though
<lool> well snapcraft was good actually
<lool> it's actually been a pleasure to do this build from source that upstream requested (instead of the from debs I had)
<kyrofa> Yeah in my experience anything complex from debs just require all sorts of hackery to make work
<kyrofa> From source is so much easier in a lot of cases
<pmcgowan> kyrofa, after some search I decided to disable the timer just fyi
<lool> kyrofa: it was from a PPA in this case, but otherwise trivial to use the debs
<kyrofa> pmcgowan, I guess you'll see in a few hours if that's what was required :P
<kyrofa> Ah, okay
<mup> PR snapcraft#1118 closed: Trigger beta tests on travis every day <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1118>
<mup> PR snapcraft#1144 opened: Trigger beta tests on travis every day <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1144>
<bdmurray> kyrofa: So that didn't work out too well for me. http://pastebin.ubuntu.com/24009810/
<kyrofa> bdmurray, that doesn't mean anything to me. But I assume you're saying the environment variable wasn't defined? Can I see your snapcraft.yaml?
<bdmurray> kyrofa: I'm saying I think the "\n" is an issue
<kyrofa> bdmurray, wait.... you're essentially calling `open('$SNAP')`?
<bdmurray> kyrofa: no $SNAP/lib/python3.5/site-packages/etc/apport/crashdb.conf
<kyrofa> bdmurray, point is, python isn't going to resolve that for you
<kyrofa> bdmurray, I'm not sure where that's coming from in this case, but that's definitely wrong
<bdmurray>       APPORT_CRASHDB_CONF: $SNAP/lib/python3.5/site-packages/etc/apport/crashdb.conf
<bdmurray> That's what I put under environment:
<kyrofa> bdmurray, looks like the environment is working then
<kyrofa> bdmurray, but your python code needs to support that string containing an environment variables
<kyrofa> Which it seems it does not
<kyrofa> bdmurray, to be clear, $SNAP is defined at runtime, not at build time
#snappy 2017-02-17
<mup> PR snapcraft#1145 opened: tests: skip the tests that can't be run in arm64 <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1145>
<foobar_> hi
<foobar_> i'm trying set up a typical unix environment on my raspberry pi
<foobar_> i was wondering if there was a way to load the classic snap whenever I ssh'd in
<foobar_> versus invoking it
<foobar_> or if there was a way to install vim, git, etc via snaps
<mup> PR snapd#2826 closed: overlord: optional device registration and gadget support on classic <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2826>
<mup> PR snapd#2867 closed: screen-inhibit-control: add methods for delaying screensavers <Created by 3v1n0> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2867>
<mup> PR snapd#2863 closed: cmd/snap-confine: ensure that hostfs is root owned <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2863>
<Son_Goku> sergiusens: hey
<mup> Bug #1652273 changed: Ubuntu Core 16.04 Docker Seg Faults 139 <Snappy:Fix Released> <https://launchpad.net/bugs/1652273>
<mup> Bug #1665029 changed: snapweb needs a link for device when store selected <Snappy:Invalid> <snapweb:Triaged by dbarth> <https://launchpad.net/bugs/1665029>
<mup> Bug #1655262 changed: Driver doesn't support ap mode <Snappy:Invalid> <snappy-hwe-snaps:New> <https://launchpad.net/bugs/1655262>
<mup> PR snapd#2876 opened: snap: error when `snap list foo` is run and no snap is installed <Created by mvo5> <https://github.com/snapcore/snapd/pull/2876>
<jamesh> mvo: hi.  Are you able to merge https://github.com/snapcore/snapd/pull/2783 for me?  It looks like jdstrand is happy with the changes I made w.r.t. his review.
<mup> PR snapd#2783: interfaces: add an interface for use by thumbnailer <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/2783>
<mup> PR snapd#2783 closed: interfaces: add an interface for use by thumbnailer <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2783>
<mvo> jamesh: yes, looked at it this morning and looks fine, I was waiting for tests to go green (unrelated failure in there so I had to re-ruN)
<jamesh> mvo: thanks!
<mvo> yw
<mup> PR snapd#2877 opened: interfaces: new chroot interface <Created by mvo5> <https://github.com/snapcore/snapd/pull/2877>
<zyga> o/
<zyga> Pharaoh_Atem: hey, thank you for the contributions and for accepting the CLA
<zyga> Pharaoh_Atem: we're on the final 2 PRs for 2.23
<zyga> Pharaoh_Atem: I think this one can go into fedora :)
<hangun> zyga: hi
<zyga> hangun: hey, did you have luck in getting that to work?
<hangun> zyga:  following your blog, I am trying to build snapd from master branch
<hangun> zyga:  my env: ubuntu 16.04
<hangun> zyga: but got same errors http://pastebin.com/3ySFyvNX
<mup> Bug #1665590 opened: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:New> <https://launchpad.net/bugs/1665590>
<zyga> hangun: did you run ./get-deps.sh?
<hangun> not yet
<zyga> hangun: well, why not?
<zyga> hangun: you have to run that to build the go parts
<zyga> hangun: try that, it should build without issues afterwards
<mup> Bug #1665592 opened: cannot bind mount nvidia driver /usr/lib/nvidia-367 <landscape> <Snappy:New> <https://launchpad.net/bugs/1665592>
<hangun> zyga:  after running ./get-deps.sh , that error was fxed.
<hangun> zyga:  sudo install -m 0755 -o root -g root -D $GOPATH/bin/snap-exec /usr/libexec/snapd/
<hangun> zyga: install: target '/usr/libexec/snapd/' is not a directory: No such file or directory
<zyga> hangun: that was for centos, on ubuntu you need to use /usr/lib/snapd/
<zyga> hangun: (all of libexec becomes just lib)
<hangun> zyga: thanks
<hangun> zyga:  trouble you again.  when I run "snapcraft register-key " ,  got an error like this: Key registration failed: Failed to save account-key-request assertion for account_id
<hangun> zyga: invalid revision: could not add assertion (revision 0 is already the current revision)
<zyga> hangun: I'm not that familar with that part, kyrofa or sergiusens are the experts there
<mup> PR snapd#2875 closed: mkversion.sh: Add support for taking the version as a parameter <Created by Conan-Kudo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2875>
<zyga> or perhaps pedronis ^^
<zyga> pedronis: that assertion error looks weird
<zyga> pedronis: this is master built locally
<hangun> kyrofa:  when I run "snapcraft register-key " ,  got an error like this: Key registration failed: Failed to save account-key-request assertion for account_id
<hangun> kyrofa: invalid revision: could not add assertion (revision 0 is already the current revision)
<pedronis> hangun: it means you already registered that key
<pedronis> or somebody did
<pedronis> likeyly you though
<hangun> pedronis:  can I delete the key by "snap delete-key"
<hangun> pedronis:  re-register it
<pedronis> no, revoke/expire key are not stil work in progress
<pedronis> hangun: what does snapcraft list-keys shows ?
<pedronis> s/are not stil/are still/
<Son_Goku> mvo: so I'm working on preparing fedora packaging to merge into snapd git
<Son_Goku> I'm hoping on having that ready to go today so it can go in with snapd 2.23
<hangun_> pedronis:  is there any way to work it out ?
<pedronis> hangun_: ?
<mvo> Son_Goku: I'm about to wrap up 2.23 - but for that I would do a 2.23.1 :-D that is pretty cool
<mvo> s/pretty/very very/
<hangun_> pedronis:  the key in my machine have been registered.  snapcraft register-key always  dones't work
<pedronis> hangun_: sorry IÂ don't undersand what you are saying
<pedronis> what does snapcraft list-keys says ?  is your key there?
<pedronis> (there's no secret in that list, it's just public bits of the key )
<hangun_> pedronis:  haha, no secret.
<hangun_> pedronis: snapcraft list-keys
<hangun_> pedronis: Name     SHA3-384 fingerprint
<zyga> Son_Goku: fantastic
<hangun_> pedronis: default  9rrxV3xRkNjih58E4_TVKIOZrZwX3VYySFzZx3qUveRf_7xkPSYpPQFTw6Y0JAaN  (not registered)
<zyga> Son_Goku: I'm fighting autocraptools
<Son_Goku> I mean... man, that was *your* fault
<pedronis> hangun_: that's the key you are trying to register?
<Son_Goku> cmake and meson both existed :)
<hangun_> pedronis: yes, it is.
<zyga> Son_Goku: meson maybe, cmake is yuck and I'd rather use bare make or ... you know
<pedronis> hangun_: ok, IÂ need to have lunch, then IÂ can check about it in the store
<hangun_> pedronis: thanks a lot
<zyga> Son_Goku: how about merging the policy into snapd now?
<Son_Goku> ....
<zyga> Son_Goku: though up to you, I don't know if you had plans for that
<Son_Goku> I thought about it
<zyga> (to merge into the bigger policy package?
<Son_Goku> well, keeping it as a module seems to make more sense than merging it back into selinux-policy
<Son_Goku> especially since the scope of snapd increases with every release
<zyga> Son_Goku: up to you
<zyga> Son_Goku: I think it will make sense to keep it close over time
<Son_Goku> mvo: what do you think?
<zyga> Son_Goku: as we enable CI it would just be built and installed
<Son_Goku> should I propose to merge the policy module into the snapd source tree?
<zyga> Son_Goku: we could experiment, in one PR, with changes that change policy and fix something in the core
<zyga> mvo: this is the selinux policy, about 5 files
<Son_Goku> https://gitlab.com/Conan_Kudo/snapcore-selinux
<popey> anyone on the device enablement side able to help here? ogra_ ? :) http://askubuntu.com/questions/884346/creating-a-custom-ubuntu-core-image-for-intel-joule
<mvo> zyga, Son_Goku my gut-feeling is that having that in the snapd git repo would be good
<zyga> +1
<Son_Goku> is there a way to preserve the commit history with doing that?
<zyga> Son_Goku: absolutely
<zyga> Son_Goku: just add it as a remote
<zyga> Son_Goku: and merge
<zyga> with --no-commit
<zyga> then move them around and commit
<zyga> I did that with snap-confine
<Son_Goku> what were the exact steps?
<zyga> git remote add policy /path/to/policy/repo
<zyga> git merge --no-commit policy master
<zyga> git mv ...
<zyga> git commmit
<zyga> then remove the remote
<zyga> it's pretty neat as history is fully preserved this way
<zyga> including before the merge
<Son_Goku> merge: sepolicy - not something we can merge
<Son_Goku> zyga: am I missing a step?
<zyga> git fetch
<zyga> I bet I forgot :)
<zyga> sorry
<zyga> (merge is local after all)
<ogra_> popey, hanging directly after selecting the image in grub points to a kernel issue ...
<Son_Goku> fatal: refusing to merge unrelated histories
<Son_Goku> zyga: it doesn't like that much
<zyga> mmm, let me think
<zyga> I wonder if I still have that in bash history
<ogra_> popey, i'd suggest to him to try each snap on its own ... i.e. build the gadget, build an image with the official pc kernel, see if that boots ... only then start plying with the kernel ... also, the gadget is at https://github.com/snapcore/pc-amd64-gadget
<zyga> Son_Goku: --allow-unrelated-histories
<zyga> Son_Goku: odd, maybe git updated since, I don't recall using it
<zyga> Son_Goku: try it with that option
<Son_Goku> yay, now conflicts with COPYING and README.md files
<zyga> great!
<zyga> Son_Goku: you should be good now :)
<Son_Goku> mvo, zyga: what should the folder be?
<popey> ogra_: any chance you can paste that in? :)
<popey> for the karma
<mvo> Son_Goku, zyga: maybe just data/selinux ?
<zyga> mvo: sounds good to me
<zyga> Son_Goku: unless you have a better idea
<mvo> zyga, Son_Goku: or packaging/fedora/selinux if its specific to that (but it sounds like it is not)
<Son_Goku> it's not
<zyga> mvo: I think it is generic for many selinux systems
<Son_Goku> I set it up to work on Fedora, Debian, and Arch/Gentoo hardened
<Son_Goku> all systems that prefer selinux for hardened configurations
<apeattack> Does anyone know if canocials landscape will support snappy in the future ?
<Son_Goku> zyga: do you know how I can filter out a directory?
<zyga> mmm, not sure, I bet there's a way
<zyga> what do you want to do?
<zyga> manybe for a one-off it is easier to just do it manuall
<zyga> apeattack: it is plausible but I don't have anything to back this up
<Son_Goku> zyga: I want to remove dist/ folder
<apeattack> is there any other way to manage snaps instead ?
<Son_Goku> snapd uses packaging/ as its equivalent
<apeattack> Make sure that a certain snap is installed on a machine at acertain time ?
<Son_Goku> and I'm not using the selinux module spec for this
<zyga> Son_Goku: I think we can drop the .refresh timer + service now
<zyga> Son_Goku: you can rm -rf it now
<zyga> Son_Goku: becausethis is --no-commit you can still tweak it
<zyga> Son_Goku: it will be in the history but that's okay
<zyga> apeattack: mvo was working on  way to set the refresh schedule, there's a new way to control this
<zyga> apeattack: but you cannot manage the device to tell it to install a specific snap remotely yet
<apeattack> ok thanks
<pedronis> hangun_: so in the store there's  a request to register that key, but not the key itself, IÂ need to talk with the person responsible for that code to understand how that happened, but he is off today
<hangun_> pedronis: thanks
<pedronis> hangun_: for now I created a bug:  https://bugs.launchpad.net/snapstore/+bug/1665617
<mup> Bug #1665617: user key with account-key-request present in the store but no matching account-key <Snap Store:Confirmed for cjwatson> <https://launchpad.net/bugs/1665617>
<mup> PR snapd#2878 opened: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
<Son_Goku> zyga, mvo ^
<zyga> Son_Goku: commented already
<Son_Goku> zyga: done
<zyga> Son_Goku: I saw, thanks
<Son_Goku> I don't know how to wire up the debian packaging to produce the selinux policy module
<Son_Goku> so you're going to have to do that :)
<mup> PR snapd#2879 opened: asserts: improved information about assertions format in the Decode doc comment <Created by pedronis> <https://github.com/snapcore/snapd/pull/2879>
<morphis> sergiusens, kyrofa: ping
<mup> Bug #1665592 changed: cannot bind mount nvidia driver /usr/lib/nvidia-367 <landscape> <Snappy Launcher:Triaged by zyga> <https://launchpad.net/bugs/1665592>
<sergiusens> morphis: pong?
<morphis> sergiusens: not sure if I found a regression with snapcraft 2.27
<sergiusens> Son_Goku: got delayed with the snapcraft release, starting the work on it today
<morphis> sergiusens: but our network-manager builds are now failing with:
<morphis> /usr/bin/ld: ./.libs/libNetworkManager.a(nm-vpn-editor-plugin.o): undefined reference to symbol 'dlclose@@GLIBC_2.2.5'
<Son_Goku> sergiusens: fantastic!
<morphis> see https://launchpadlibrarian.net/305337019/buildlog_snap_ubuntu_xenial_armhf_network-manager-daily_BUILDING.txt.gz for a build with snapcraft 2.26 and https://launchpadlibrarian.net/306823655/buildlog_snap_ubuntu_xenial_amd64_network-manager-daily_BUILDING.txt.gz for one with 2.27
<morphis> there are no changes on the snap side
<sergiusens> morphis: interesting; is that using classic confinement?
<morphis> no
<morphis> sergiusens: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snapcraft.yaml
<sergiusens> hmm, we had no changes in this area iirc
<morphis> hm
<sergiusens> elopio: that needs to be added to the nightlies ^
<morphis> sergiusens: trying to see if I get that locally too
<sergiusens> morphis: k, this is xenial, right? I am going to clone your project and build here too
<morphis> sergiusens: it is
<sergiusens> morphis: can you create a bug on our lp tracker for us to add your projects to our nightly builds? List all the projects you care about not breaking and elopio will add them to our nightly check of snaps against snapcraft master
<sergiusens> it is equivalent of "archive rebuild"
<morphis> sergiusens: nice, will do that!
<pmcgowan> ogra_, hi, I disabled snapd.refresh.timer but I still see it trying to refresh, do I need to disable the service as well?
<ogra_> pmcgowan, oh, that might be
<ogra_> i hought the timer is enough, but if it still runs then most likely not
<pmcgowan> let me try
<pmcgowan> ogra_, status doesnt indicate its disabled, unless I miss something
<hangun> pedronis: thanks
<ogra_> mvo, hmm, did we drop the snap refresh timer without having the core option for refresh.schedule in place ?
<mvo> ogra_: yes
<ogra_> mvo, i cant find the timer in systemctl anymore
<ogra_> but also not the timer option
<mvo> ogra_: in 2.23 it is now internal
<mup> PR snapcraft#1144 closed: Trigger beta tests on travis every day <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1144>
<mvo> ogra_: what do you need in particular?
<ogra_> right, but no way to turn it off yetz
<mvo> ogra_: no easy way, you can set "snap set core snapd.last" to something recent
<ogra_> mvo, well,s ee the discussion on the ML ...
<mvo> ogra_: let me check
<ogra_> where max asks about a way to find if a refresh is due and then wants to do some testing first
<ogra_> (the replies to "New stable "core" and "ubuntu-core" snaps released" )
<mvo> ogra_: we have the store side validation mechanism for this
<ogra_> ah
<sergiusens> morphis: reproduced :-/
<sergiusens> I think I know what it may be
<pmcgowan> mvo, so is there no way to turn ff autoupdates atm?
<pmcgowan> off
<mvo> pmcgowan: unfortuantely not, if that is a blocker we need to talk and maybe delay the release
<pmcgowan> mvo, my question is actually for a core system
<pmcgowan> if that matters
<ogra_> should be the same nowadays
<mvo> pmcgowan: total disable is a much discussed topic
<pmcgowan> mvo, my example use case is we staged a demo machine for next week and would like to keep it the same
<pmcgowan> although real world examples probably meatier
<mvo> pmcgowan: right, well, let me put it differently, we can trivialy add code for this (there is even code in snapd to disable refresh). we need to decide (at a level above me) if that is something we want or not :)
<pmcgowan> mvo, understood
<pmcgowan> mvo, I think with better use of tracks/channels for the snaps we could be fine
 * mvo nods
<mup> Bug #1663942 changed: snappy-debug suggests network-control, when network is enough <Snappy:Invalid> <https://launchpad.net/bugs/1663942>
<sergiusens> morphis: kyrofa reverting https://github.com/snapcore/snapcraft/commit/3052b0f459ded440dad2e2362946ee37e09c8606 fixes it
<sergiusens> so boo
<mup> PR snapcraft#1146 opened: Revert "repo: remove symlinks to libc. (#1100)" <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1146>
<morphis> sergiusens: ok, thanks
<morphis> sergiusens: are you pushing a minor release out to fix this?
<morphis> this will cause all our CI to break until this is fixed
<sergiusens> morphis: yes
<sergiusens> morphis: with luck it can be out on Monday, is that ok? https://bugs.launchpad.net/snapcraft/+milestone/2.27.1
<morphis> sergiusens: yeah, that should be ok
<sergiusens> I am thinking that this will hit most autotools/libtool projects though
<morphis> sergiusens: you still want a bug report for this?
<morphis> yeah
<sergiusens> morphis: I think LP: #1665089 is related
<mup> Bug #1665089: snapcraft 2.27 fails to build the mosh classic snap <classic> <Snapcraft:In Progress by sergiusens> <https://launchpad.net/bugs/1665089>
<sergiusens> but the 'classic' misled the importance
<morphis> sergiusens: ok
<sergiusens> morphis: my guess is that `libtool` does some guessing and then hardcodes expected library paths depending on the libraries it finds; not entirely sure but the whole auto world is full of black magic
<morphis> it is :-)
<stokachu> what's the snap install syntax to install from a track/channel?
<morphis> sergiusens: so Monday means in proposed for xenial?
<mup> Bug #1650671 changed: Content sharing from snap common is broken <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1650671>
<mup> PR snapcraft#1135 closed: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1135>
<mup> PR snapd#2881 opened: cmd/snap-confine: don't crash if nvidia module is loaded but drivers are not available <Created by zyga> <https://github.com/snapcore/snapd/pull/2881>
<mup> PR snapcraft#1134 closed: 2.26 dragonboard fixes <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1134>
<mup> PR snapcraft#1136 closed: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <Closed by piso77> <https://github.com/snapcore/snapcraft/pull/1136>
<zyga> Son_Goku: some build woes on rawhide with golang packages on ppc? I just got a bunch of bug reports about this
<Son_Goku> we just did a mass rebuild
<zyga> https://kojipkgs.fedoraproject.org//work/tasks/3376/17733376/build.log
<Son_Goku> so it's possible
<zyga> yeah, I saw that
<Son_Goku> this is where you get to talk to the fedora golang guys :)
<zyga> Son_Goku: ay, will do
<mup> PR snapcraft#1147 opened: snapcraft.yaml: 96boards: minimal changes to get a working kernel snap <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1147>
<mup> Bug #1604346 changed: snapd apparmor tests fail on ArchLinux <Snappy:Won't Fix by zyga> <https://launchpad.net/bugs/1604346>
<stokachu> im having some issues trying ot get my systemd script to run on boot https://gist.github.com/battlemidget/e7ea01bfb37a3feb38f2c0fc5e138ada
<stokachu> zyga, ^ are you familiar with this at all?
<stokachu> i need a custom bridge interface to come up on boot thats handled through this snap run mechanism
<stokachu> https://github.com/conjure-up/conjure-up/blob/master/snap/snapcraft.yaml#L20-L24
<stokachu> is my daemon config
<stokachu> if i run the snap run command manually it works
<zyga> stokachu: looking
<ogra_> didrocks, have you heard about any Gtk theme errors when using the desktop launcher for ubuntu-app-platform ? i get:
<ogra_> ogra@anubis:~/datengrab/devel/branches/rocket-client-webapp$ rocket-client-webapp.ogra-rocket-webapp
<ogra_> QGtkStyle could not resolve GTK. Make sure you have installed the proper libraries.
<ogra_> "file:///build/webbrowser-app-96smi5/webbrowser-app-0.23+16.04.20161028/src/app/webcontainer/webapp-container.qml:-1 File not found\n"
<mup> Bug #1612909 changed: Unable to install snappy in Fedora <Snappy:Invalid by zyga> <https://launchpad.net/bugs/1612909>
<morphis> sergiusens: https://bugs.launchpad.net/snapcraft/+bug/1665658
<mup> Bug #1665658: Add system enablement snaps to nightly build of snapcraft <Snapcraft:New> <https://launchpad.net/bugs/1665658>
<didrocks> ogra_: could be. There are quite some warning when using Qt, but I don't think that one. Mirv is responsible for ubuntu-app-platform and manage it. It could be a missing dep
<didrocks> the file not found with webapp-container.qml is more annoying
<ogra_> oh, i thought thats just fallout of the first
<mariogrip> Is it possible to use pkexec in a snap? (with --devmode)
<didrocks> ogra_: I don't think it is
<ogra_> yeah, now that you say it :P
<ogra_> who maintains the webapp-helper remote part ?
<mup> PR snapcraft#1148 opened: kernel plugin: if dtb target == NULL and arch == (arm||arm64), build and install all dtbs <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1148>
<mup> PR snapcraft#1149 opened: kernel plugin: if kernel's target == NULL, use per-arch default target <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1149>
<ogra_> i guess the issue is in there
<didrocks> ogra_: Alberto (from https://wiki.ubuntu.com/snapcraft/parts)
<zyga> stokachu: sorry, I'm not sure what to look at
<zyga> stokachu: what is the error specifically?
<zyga> stokachu: I don't see any
<stokachu> zyga, there are no errors, systemctl status show it applying the items in my bridge.start script
<stokachu> but it doesn't actually do anything
<ogra_> mardy, ^^^ seems the webapp-helper is broken
<stokachu> there are some reexec commands in there
<stokachu> snap rexec
 * mardy reads...
<Mirv> (s/Mirv/SDK team/, also t1_mp and kali_kiana can be pinged among else)
<mardy> ogra_: oh, lool has met just the same issue :-)
<mardy> ogra_: where are you building it? 16.04?
<ogra_> yeah, we are brothers in spirit :)
<ogra_> snapcraft cleanbuild on 16.04
<zyga> stokachu: not sure if that's related
<zyga> mvo: have a look at this vvvv
<zyga> Feb 16 20:32:11 chonk /usr/bin/snap[1400]: cmd.go:105: DEBUG: restarting into "/snap/core/current/usr/bin/snap"
<zyga> Feb 16 20:32:11 chonk /usr/bin/snap[1400]: cmd.go:59: DEBUG: re-exec disabled by user
<zyga> snap reexcs to say "nah disabled by the user"
<zyga> stokachu: still, no idea what the problem is
<zyga> stokachu: what does the wrapper do?
<stokachu> zyga, https://github.com/conjure-up/conjure-up/blob/master/snap/wrappers/bridge.start
<mardy> ogra_: you must enable the stable-phone-overlay PPA, as the webapp-container from xenial is too old
<ogra_> eeek
<ogra_> ok
<stokachu> zyga, basically systemd loads this script file and i can see it running those commands, but then it never applies
<zyga> stokachu: and what is the actual issue, that the network changes you did with iptables don't show up?
<stokachu> zyga, yes
<stokachu> and that network interface isn't brought up
<zyga> stokachu: no idea, that's not related to snaps, is it?
<zyga> stokachu: (with classic confinement)
<stokachu> zyga, well it works with my debian package
<stokachu> so not sure what the issue is
<zyga> stokachu: can you provide a small test case, a oneshoot daemon does something in classic confinement
<mup> PR snapcraft#1150 opened: kernel plugin: remove MAKEFLAGS from the environment <Created by piso77> <https://github.com/snapcore/snapcraft/pull/1150>
<zyga> stokachu: and that thing is not applied
<stokachu> zyga, sudo snap install conjure-up --classic on xenial
<stokachu> see ifconfig output to see interfaces
<stokachu> reboot
<stokachu> interfaces gone
<stokachu> no errors in syslog
<zyga> stokachu: I don't want to run that on my system
<zyga> stokachu: a _small_ test case I can read and change would be better
<zyga> stokachu: ah
<zyga> stokachu: reboot
<zyga> stokachu: after reboot is the job started?
<stokachu> yes the job is started
<zyga> stokachu: maybe it runs too early
<zyga> stokachu: and there's no network or something like that yet
<stokachu> i dont know how to set the targets in snapcraft.yaml
<stokachu> to tell it to wait for network.target
<zyga> stokachu: there's no way to do that
<stokachu> zyga, https://github.com/conjure-up/conjure-up/blob/2.1.0-beta5/debian/conjure-up.service
<stokachu> thats what the service should look like
<zyga> stokachu: there's no way to express that in snapd
<zyga> stokachu: partially by design
<zyga> stokachu: please report an issue and discuss this with gustavo when he's back next week
<zyga> stokachu: technically this is easy-ish to do but this is a design issue not a technical issue
<stokachu> k
<zyga> stokachu: technically we should model dependencies inside snap services and among a curated set of services like network
<zyga> (targets)
<stokachu> ok
<stokachu> is there a plan to add an uninstall hook?
<zyga> I don't know
<zyga> stokachu: there's some chatter about install hooks
<zyga> stokachu: (on the ML)
<stokachu> yea i need them too
<zyga> I really feel we need an RFC process or PEP-like process
<ogra_> mardy, thanks that worked
<mup> PR snapcraft#1151 opened: Remove 'Series' from channel maps.   <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1151>
<mup> PR snapd#2882 opened: snapstate: ensure snapstate.CanAutoRefresh is nil in tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/2882>
<mup> PR snapd#2883 opened: seccomp: added Specification for seccomp backend <Created by stolowski> <https://github.com/snapcore/snapd/pull/2883>
<gQuigs> is there a list of ports/servers snap needs to access to work?
<lool> ogra_: also captured solution in https://bugs.launchpad.net/webapp-container/+bug/1651812
<mup> Bug #1651812: snaps of webapps <webapp-container:Confirmed for mardy> <https://launchpad.net/bugs/1651812>
<lool> also I hit this first https://lists.ubuntu.com/archives/snapcraft/2016-November/001735.html
<ogra_> i didnt hit that one ... but my icon and .desktop file arent found by unity somehow
<ogra_> it seems all correct but still
<mup> Bug #1665683 opened: Strictly confined desktop applications snaps can't toggle Launch at Login  <Snappy:New for flexiondotorg> <https://launchpad.net/bugs/1665683>
<kyrofa> sergiusens_, morphis that doesn't make sense. That lib should just be in the host machine now, still picked up
<kyrofa> Hard-coded paths, then?
<zyga> kyrofa: which lib?
<morphis> kyrofa: I don't know, but I know it breaks all builds for some of our snaps like network-manager
<morphis> and it doesn't with snapcraft 2.26
<mup> Bug #1591148 changed: snap install fails with a kernel lacking apparmor support <security> <snapd:Confirmed> <https://launchpad.net/bugs/1591148>
<kyrofa> That's unfortunate, we'll need to figure out another fix for bug #1658774
<mup> Bug #1658774: Symlinks to libc left dangling <Snapcraft:Fix Released by kyrofa> <https://launchpad.net/bugs/1658774>
<sergiusens_> kyrofa: the effects of pkg-config and libtool might be at play ;-)
<kyrofa> sergiusens_, :(
<mup> PR snapd#2884 opened: snapstate: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <https://github.com/snapcore/snapd/pull/2884>
<mup> PR snapd#2885 opened: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <https://github.com/snapcore/snapd/pull/2885>
<jdstrand> nessita, noise][: is something wrong with the store:
<jdstrand> $ sudo snap install core
<jdstrand> error: cannot perform the following tasks:
<jdstrand> - Download snap "core" (1079) from channel "stable" (received an unexpected http response code (500) when trying to download https://public.apps.ubuntu.com/anon/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_1079.snap)
<jdstrand> $ wget https://public.apps.ubuntu.com/anon/download-snap/99T7MUlRhtI3U0QFgl5mXXESAiSwt776_1079.snap
<jdstrand> ...
<jdstrand> HTTP request sent, awaiting response... 500 INTERNAL SERVER ERROR
<jdstrand> 2017-02-17 11:39:55 ERROR 500: INTERNAL SERVER ERROR.
<ogra_> jdstrand, stokachu just reported the same on rocket
<nacc> seems like it (happens here too)
<nessita> jdstrand, yes, we are getting sort of DoS by snapd itself
<nessita> working on it
<jdstrand> ok
<stokachu> we just did a big release announcent
<stokachu> fyi nessita
<nacc> heh
<jdstrand> I should be able to just sideload, so I'm not blocked
<nacc> stokachu: use snaps! oh wait ... don't use them so hard! :)
<stokachu> :D
<nessita> stokachu, there is an issue with the transition from ubuntu-core -> core that's making snapd ask for package details in a loop
<jdstrand> yikes
<nessita> so is not strictly on amount of users, but on an loop of requests, still investigating
<stokachu> nessita, ok people are actively trying to download conjure-up so it's giving them a bad first impression
<nessita> cprov, see above %
<stokachu> nessita, just letting you know the severity
<nessita> stokachu, thank you
<kyrofa> Hey ogra_, I tried comparing an amd64 ubuntu core image to an amd64 cloud image (the disk1.img), and Ubuntu Core is larger, which surprised me. Any idea why?
<cprov> right, we are actively working on it with the snapd team.
<mup> PR snapd#2882 closed: snapstate: ensure snapstate.CanAutoRefresh is nil in tests <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2882>
<ogra_> kyrofa, i have never seen one fo the cloud images ... so i cant really tell
<kyrofa> ogra_, ah darn
<ogra_> not even sure who produces them
<ogra_> but i guess they dont have a kernel :)
<kyrofa> ogra_, well, I know the rootfs ones don't, but I thought the disk1.img was flashable
<stokachu> nessita, i think it's working for now
<kyrofa> ogra_, if I wanted to say "this is how stripped down ubuntu core is" what would you recommend I compare to?
<nessita> stokachu, I was about to say downloading should work now
<stokachu> nessita, thank you!
<nessita> hehe still more to do! but you are welcome
<ogra_> kyrofa, ubuntu-server vs the core snap
<kyrofa> ogra_, ubuntu-server what, though? Not the ISO, for example
<noise][> FYI, snap download issue is resolved
<mup> PR snapd#2879 closed: asserts: improved information about assertions format in the Decode doc comment <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2879>
<lazyPower> is there a pattern for interfacing with man in snaps? Would I need to ship it as a part?
<kyrofa> lazyPower, not yet, but that's something we're working on. bash-completion, too
<lazyPower> ah ok, i found this - http://askubuntu.com/questions/764835/how-can-i-view-man-pages-for-apps-installed-via-snaps
<kyrofa> lazyPower, yeah I suppose that works
<lazyPower> seems like a big hack... not sure if we want to follow up there or not on that answer when the feature lands. Is there a bug i can subscribe to and track this?
<kyrofa> lazyPower, indeed, definitely a hack
<kyrofa> lazyPower, I think this is it: https://bugs.launchpad.net/snappy/+bug/1575593
<mup> Bug #1575593: Snappy installed manpages aren't accessible through man <Snappy:Triaged> <https://launchpad.net/bugs/1575593>
<lazyPower> Thank you kyrofa, my launchpad-fu failed me
<lazyPower> ta :)
<kyrofa> lazyPower, hardly-- snappy bugs are spread all over the place :P
<kyrofa> lazyPower, we're trying to make that better as well
<lazyPower> is there a way to fix this in the short term? if it were a classic snap would that make a consistent work-around fix until this gets bumped from low priority?
<lazyPower> s/would that/ would that help/
<lazyPower> i guess it would work like this: and i think it would work fine in strict mode too: set that manpath  env, and i would have to include man as a part, and then make petname call petname.man which would fix petname -h complaining it cant find man...  thoughts on this approach?
<kyrofa> lazyPower, mvo or zyga might have some thoughts on that
<lazyPower> ok just sounding out a work-around out loud :) thanks kyrofa
<lazyPower> yeah my thought was outlined in that bug pretty well too by paelzer already.
<lazyPower> nice, thanks again.
<kyrofa> lazyPower, make sure to mark "effects me too"
<lazyPower> Just did :)
<mup> PR snapd#2885 closed: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2885>
<mup> PR snapd#2886 opened: releasing package snapd version 2.22.3 <Created by zyga> <https://github.com/snapcore/snapd/pull/2886>
<mup> Bug #1665756 opened: environment variable setting issue <Snappy:New> <https://launchpad.net/bugs/1665756>
<mup> PR snapcraft#1146 closed: Revert "repo: remove symlinks to libc. (#1100)" <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1146>
<noonien> Hello folks!
<noonien> Does snappy have repositories?
<noonien> Can I host my own snap repo?
<nacc> noonien: i believe you'd need your own store
<noonien> How can I store private snaps then?
<nacc> https://insights.ubuntu.com/2016/06/24/howto-host-your-own-snap-store/ ... but i'm not sure that is official
<nacc> noonien: i think this is an open feature, but i'd wait to see if someone can respond officially
<noonien> Cool, I'll look into it! Thanks! ^_^
<mup> PR snapcraft#1152 opened: Changelog for 2.27.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1152>
<noonien> From what I undestand from that blogpost, snapd doesn't support multiple stores.
<kyrofa> noonien, indeed, you understand correctly
<noonien> Well, that's kind of a bummer :(
<kyrofa> noonien, the goal as I understand it is for snapd to have one authoritative source, instead of essentially duplicating PPAs
<kyrofa> noonien, whether that's the Ubuntu store, or someone else's. Still one source
<noonien> I see, don't really understand the reasoning for such a limitation though.
<kyrofa> noonien, I for one never liked adding PPA from <random person> to my system
<noonien> Well, as long as the store is public(as is the ubuntu store), I don't see how anything is improved
<kyrofa> noonien, public i.e. anyone can put anything in there?
<noonien> Yes, is that not the case with the ubuntu snappy store?
<kyrofa> noonien, indeed it is, but there are two things. 1) snaps are typically confined, and 2) in the case where they're not, they undergo manual review by the store/security team. In the case of Ubuntu, I trust them. I don't place that trust easily
<ogra_> yes, and thats the reason for the "one store" policy ... since that one store has certain policies and security checks in place so poeple can not upload malicious stuff
<kyrofa> noonien, indeed, as ogra mentioned, there are a lot of automated checks done on the store as well
<noonien> So I cannot upload any packages I like under my developer namespace?
<ogra_> (or rather ... people can uploads anything malicious they want but it will be harmless on the endusers machine)
<kyrofa> noonien, you'd have none of those guarantees if anyone could use any store
<ogra_> yo can upload anything you like
<ogra_> under your namespace
<ogra_> evil things will hit the wall and get stuck in "manual review" though
<noonien> So what's the difference between installing from a PPA or a developers namespace?
<ogra_> compliant things will just go through
<noonien> Ugh, so everything under my dev namespace needs to get reviewed?
<ogra_> you dont define the namespace as the enduser
<kyrofa> noonien, only if it doesn't pass automated review
<ogra_> why would it get reviewed ?
<noonien> hmm, is there anywhere where I can read about the process?
<kyrofa> noonien, which process, uploading snaps? Installing them?
<ogra_> https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
<noonien> I'm trying to create an automated build bot that packages and publishes snaps of the apps I need. It would be a major PITA and waste of time if ubuntu decides my packages don't belong in their store.
<ogra_> noonien, well, as long as they comply with the security policies of snaps they will just go through
<kyrofa> noonien, Ubuntu doesn't care as long as the snap is safe. I also use CI to push snaps
<ogra_> they need to properly use interfaces to talk to the system etc
<noonien> I see, that's a relief. I'll look into the whitepaper
<ogra_> if thats given then yoou can just upload ... or even use launchpad pointing to your git/bzr/wahatever trees to have that auto-build and upload for you
<kyrofa> noonien, check out snapcraft.io as well, it'll walk you through how snaps are put together, including walking you through interfaces
<ogra_> (for all the arches launchpad supports)
<noonien> kyrofa: thanks, will do!
<ogra_> noonien, i'd also recommend http://snapcraft.io and https://docs.ubuntu.com/core/en/
<noonien> I'd prefer to avoid launchpad as much as I can.
<ogra_> well, it gives you arch builders for free and is fully integrated with all the snap tools ... so it saves a lot of work
<ogra_> but up to you indeed :)
<kyrofa> noonien, note that you don't have to host your code there, FYI
<ogra_> whats the reason you dont like it though ?
<noonien> I've had some issues with it in the past, a long time ago, when I tried to contribute to some projects, it's probably a lot better now
<noonien> The applications I'd like to packages already have git repos, I'm trying to create a build bot that updates the snaps when the developers push to their repos and deploy them using my snapcraft manifests, as long as they don't wish to support snappy.
<ogra_> it can easily build github trees for example ... no need that you move your whole project over just to use the snap build mechanism
<noonien> And from the brief look I took over snapcraft.io some time ago, snappy seems like a pretty decent alternative to debs.
<ogra_> it totally is !
<noonien> Hopefully less work needs to be put into building a snap than a deb.
<ogra_> yeah
<ogra_> all you eed is the snapcraft.yaml file ... try out the hello-world example on snapcraft.io
<ogra_> that yaml file can even point to some remote source ... so it doesnt necessary need to live inside your upstream branch (though that is indeed the best) snapcraft gives you all the freedom you can imagine
<noonien> I have, sadly the packages I want to build are a bit more complex, they have lib dependencies, need to access X, etc. AFAIR some time ago snappy hardly had any support for such stuff. However, from what I gather it's pretty easy to setup now.
 * ogra_ has some snaps that he re-packs from proprietary deb binaries for personal use ... there are pretty much no restrictions what you package or how 
<ogra_> yeah
<ogra_> well, read up on it, tinker with it, and if you have questions, we are here :)
<mup> PR snapcraft#1153 opened: contribution guide: add commit message template <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1153>
<noonien> https://github.com/jaagr/polybar is one such package
<noonien> I'll try to get it running first. Will check in if there's anything i'm struggling with
<noonien> You guys have been of great help! Thank you! ^_^
<ogra_> :)
<jdstrand> davidcalle: hey, I just noticed https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/ still says ~rc5. the pdf is correct
<jdstrand> noonien: fyi, if reading the whitepaper, get the pdf ^
<kyrofa> ogra_, why does the core manifest include apt?
<ogra_> because it is taken before we remove packages
<kyrofa> Oh, you strip from there? Of course, you use this to create classic huh
<kyrofa> (classic mode, that is)
<ogra_> right
<kyrofa> ogra_, FYI, you might be not stripping libapt, I think sergiusens hit that
<ogra_> we do ... but only in edge
<kyrofa> ogra_, ah
<ogra_> stable is usually 300 revs behind edge ... the fun is in the edge ;)
<kyrofa> ogra_, I don't suppose you generate a manifest of everything that actually ends up in the core snap? i.e. excluding stripped items?
<ogra_> (sounds like a 70s song title)
<ogra_> nope
<ogra_> that would be hard to obtain since the package info is gone then
<kyrofa> Yeah... I figured. Haha, I really have no information to put on this "Ubuntu Core is a flavor of Ubuntu with a minimal footprint" slide
<mup> PR snapcraft#1152 closed: Changelog for 2.27.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1152>
<kyrofa> Hey jdstrand, remember that weird DNS-not-working-from-within-the-snap issue I mentioned the other day?
<kyrofa> jdstrand, after some more investigation, the only thing that seemed different on his setup than mine was that his /etc/resolv.conf points to 127.0.0.53
<kyrofa> Whereas mine is 127.0.1.1
<kyrofa> jdstrand, any chance this could have something to do with systemd-resolved?
<jdstrand> kyrofa: maybe? you might ask foundations. I'm not using systemd-resolved...
<kyrofa> jdstrand, yeah me neither
<jdstrand> kyrofa: I can say I've heard of people having dns issues when using systemd-resolved with snappy. I didn't help debug it (ie, I heard it in passing)
<kyrofa> jdstrand, any chance you remember who was discussing it?
<jdstrand> it might've been Zygmunt
<kyrofa> zyga, do you remember any issues with systemd-resolved related to snappy?
<zyga> kyrofa: yes
<zyga> kyrofa: but ask me some other time, this is not the best moment
<zyga> kyrofa: tired and fire-fighting
<zyga> jdstrand: hey :)
<zyga> jdstrand: how are you?
<zyga> (no reviews)
<jdstrand> zyga: hi :)
<zyga> heh
<jdstrand> zyga: I see that! unfortunately, I know why :\
<zyga> no I mean I don't want a review :)
 * jdstrand nods
<zyga> jdstrand: I'll catch you next week, I'm about to sign off soon
<jdstrand> zyga: you've been busy today
<jdstrand> ok
<jdstrand> zyga: you probably know this, but fyi, Monday is national holiday for US
<zyga> jdstrand: ah, enjoy then
<zyga> jdstrand: man that's not good tho :D
<kyrofa> zyga, okay... any chance you know of a bug, or someone else familiar with the issue?
 * ogra_ wonders if the US had these many free days last year too ... 
<kyrofa> ogra_, hahaha
<ogra_> or is that a trump bonus ?
<mup> PR snapd#2887 opened: merge release/2.22 branch into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2887>
<zyga> kyrofa: no idea
<ogra_> suffer more but get more free days
<kyrofa> zyga, alright I'll ask next week, thanks
<mup> PR snapd#2886 closed: releasing package snapd version 2.22.3 <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2886>
<kyrofa> ogra_, this coming from the guy who gets three months of paternity leave?
<ogra_> paternity ?
<kyrofa> Well, not you personally
<ogra_> :)
<ogra_> heh, indeed
<ogra_> france is worse than germany though
<kyrofa> What is it in france?
<ogra_> more paternity leave i mean
<ogra_> what do you celebrate on monday ?
<kyrofa> Washington's birthday
<kyrofa> Otherwise known as President's Day
<ogra_> ah ...
 * ogra_ holds back on the trump jokes :)
<mup> PR snapd#2888 opened: many: display kernel version in 'snap version' <Created by zyga> <https://github.com/snapcore/snapd/pull/2888>
<mup> PR snapd#2887 closed: merge release/2.22 branch into master <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2887>
<mup> Bug #1665808 opened: Unable to install core snap in an ephemeral boot: cannot create namespace group directory /run/snapd/ns: Bad file descriptor <Snappy:New> <https://launchpad.net/bugs/1665808>
#snappy 2017-02-18
<noonien> How can one tell what interfaces a snap needs?
<noonien> I'm guessing there's no way of knowing, not even at runtime
<jamesh> noonien: "snap interfaces" should tell you
<jamesh> "snap interfaces $snap_name" will limit it to just a particular named snap
<amosbird> hello
<amosbird> can I use snap in centos 6?
<noonien> jamesh: I'm creating a snap of an app of which I don't know everything about
<noonien> And would like to know what interfaces said app needs
<noonien> Hmm, I'm using snap-debug.security to check interface violations, I gave a snap I made a plug to "home", however, it cannot access files in my home directory.
<noonien> It gets denied by apparmor
<noonien> the snap gets listed under home in `snap interfaces`
<ogra_> noonien, dont forget that the home interface will not allow access to hidden dirs (for security reasons)
<noonien> Yes, I know. It was not a hidden directory
<jgdx> ogra_: is wlan expected to work on pi3? i get a timeout. Ethernet works fine.
<jgdx> also, are there any instructions on how to set up wlan on a running core?
<noonien> Snap looks like great packaging, however, due to needing to specify every single thing that an app needs access to, I've decided not to use it
<ogra_> jdstrand, only if you fist configure it with wired ... there is a driver bug ...
<ogra_> bah
<jgdx> :)
<ogra_> jgdx,
<ogra_> jgdx, so on first boot, set it up with wired ... then reboot, ssh in, run sudo console-conf, turn off wried and enable wlan ... rebopot again and it should all work
<jgdx> cool, thx!
<jgdx> ogra_: is it known that rocket chat isn't accepting anything on 80/3000 out of the box?
<noonien> Perhaps an android type permission system would have been better, allow everything until an interface for restricting is implemented.
<jgdx> noonien: wouldn't that â¦ what??
<noonien> Packaging apps that need minimal access to the system seems trivial, but packaging something that needs access to a wider set of system facilities seems rather impossible at this point, as far as I can tell.
<jgdx> noonien: then you write an interface, then another â¦ there's only a finite number of interfaces to write. There are, however, a bazillion ways to get hacked on a traditional system with no security
<noonien> I wonder how apps that support plugins are supposed to be packaged, considering some plugins might need interfaces that the app did not.
<noonien> jgdx: I agree, however, from my point of view, because of the said restrictions, I would have to either invest time into creating interfaces, or drop snappy, the latter would provide me with even less security than what I proposed.
<jgdx> noonien: it doesn't get any clearer than that
<ogra_> if your app has an upstream way to handle these plugins already you just make sure they are used from one of the snap dirs and ship a tool to download and install them ... as long as the plugin doesnt need HW access you wont need interfaces, just handle it internally in the snap itself
<ogra_> the trick with snaps it to stop thinking in old packaging mechanisms, everything is possible, just different ;)
<ogra_> s/it/is/
<jgdx> ogra_: if the snap already have hw acc, e.g. a .so in the common dir would also have access to it?
<ogra_> if it is in $SNAP_COMMON ? sure
<jgdx> okay good, thanks
<ogra_> jgdx, oh, and i totally missed your second ping, what ports would you like rocket to use ?
<ogra_> (and why)
<jgdx> ogra_: i'm not getting any response on the ports I try, so any, really.
<ogra_> well, its a web service
<ogra_> port 80 should definitely return some hhtp :)
<ogra_> *http
<jgdx> i agree, but it doesn't.. logs confirms it's running fine afaics
<jgdx> anyway, maybe the default web server is configured to use localhost as a host. Need to take a closer look
<Cyrus104> Good day, looking to see if having multiple default command is in the snap roadmap.
<noonien> How would one support alternatives? For example, let's say an app relies on command "X", packaged by app X, however, app "X-but-better" also provides "X", how can my app use the X from "X-but-better"?
<Son_Goku> you don't :)
<noonien> As far as I can tell, the only solution is to build every permutation of the app.
<Son_Goku> noonien: :)
<jgdx> noonien: out of curiosity, when would that ever be wanted? You have file level control during creation of a snapâ¦
<noonien> Well, for example, I was trying to package polybar, it depends on i3, however, I'd like to have the flexibility of using i3-gaps, and do not know if the communication protocol is completely compatible.
<noonien> So I don't know if the polybar package should depend on i3 or i3-gaps.
<Son_Goku> sergiusens: morning!
<jgdx> ogra_: is snap installation possible on rasbian?
<Bashfulrobot> I have been reading through the site, and the one thing I can't seem to find info on is how to get your snap into the channels. Is there a documented process? Review? Etc.
<oky> Bashfulrobot: to publish into a channel, you have to use the CLI (afaict) - its documented somewhere
<oky> for review, it seems like automated vetting (i've packaged one package and submitted to beta channel, so that's very small experience point)
<ogra_> jgdx, well, perhaps without any confinement enabled, not sure, but i guess even then the kernel will miss a lot
<jgdx> ogra_: okay
<ogra_> Bashfulrobot, just go to https://myapps.developer.ubuntu.com, log in and in the details page of your snap you can then select the channels you want it in
<oky> Bashfulrobot: ok, i checked my command history. i did: `snapcraft push <package_file.snap>`, followed by `snapcraft release <package> <ver> <channel>`
<ogra_> right, as oky said you can also use snapcraft release...
<oky> ogra_: the web UI was quite confusing to me and i could not see how to change channels its available in
<oky> maybe Bashfulrobot will have different experience (and i hope so)
<ogra_> you click on the revision on the left ... then there is a "Channels" on the right with a "Release" link ... if you click that there is a form with the list of possible channels and checkboxes next to them
<oky> Bashfulrobot: notice that to release to certain channels, your package has to be marked 'stable' or whatever the equivalent is. otherwise, edge / beta are the available channels
<oky> ogra_: awesome, thanks!
<ogra_> right, the stable channel only allows packages with strict confinement ... also note that "snap find" or the software center only operate on the stable channel
<Bashfulrobot> Oh! Just push it yourself and that is that. Great to know.
<Bashfulrobot> Is there a spot on the site that explains this? Was I a dumbass that missed this?
<thos37> @kyrofa @JohnAgosta Iâm working on a time-sensitive embedded system project in which weâre attempting to use Ubuntu 16.04 (desktop or snappy) on an Intel Joule 570x (codename tuchuck) instead of Intelâs minimalistic Ostro linux.  A pretty big deal-breaker problem is lack of support in 16.04 for the boardâs 2 SPI ports and 2 UARTs.  An answer on one of our AskUbuntu threads
<nothal> thos37: No such command!
<thos37> (http://askubuntu.com/questions/879580/spi-appears-broken-ubuntu-core-and-intel-joule) referenced this #channel and the channel logs (https://irclogs.ubuntu.com/2017/02/01/%23snappy.html#t18:25) referenced a private bug tracked at  https://bugs.launchpad.net/tuchuck/+bug/1661067   This is a high priority issue for our project.  Is there any possibility that I could have access to at least this bug and this tuchuck tracker channel?  We can
<thos37> offer significant quality technical feedback and testing on this issue if needed.
#snappy 2017-02-19
<CrazyTux> hello, what is snappy?
<no_email> can you install ubuntu core without a ubuntu SSO account? I just want to experiment and i don't like beeing forced into (another) account
<no_email> by the way, i am trying the rpi 3 version
<OerHeks> no_email, no, but after install you can generate your own keys.
<OerHeks> It used Ubuntu SSO to configure a user account with ssh public key authentication on headless devices, rather than using a stock, pre-set username and password.
<no_email> ok, thanks (i will use a fake account for now then :) )
<AndyS2> Hi. Just found out about snappy/snaps. Is snapcraft free open source software? Did not find it on the website, but it's an ubuntu project, so yes?
<AndyS2> I would like to package gscan2pdf for opensuse. Small company.
<Son_Goku> AndyS2, this is wrong place for that
<Son_Goku> for opensuse packaging, please go to #opensuse-factory
<AndyS2> Maybe I said it wrong. Snappy seems to be application virtualization for desktop applications. I want that :)
<AndyS2> I don't want to package something 'normally' for opensuse.
<Son_Goku> unfortunately, we do not have working packaging for openSUSE
<Son_Goku> https://new.zygoon.pl/post/state-of-snapd-support-across-distros/
<Son_Goku> https://github.com/snapcore/snapd/wiki/Distributions
<AndyS2> Just found the github link, btw. It's hidden in plain sight :)
<AndyS2> Ahh, that's sad. It seemed like the right tool for the job :(
<AndyS2> I'll read up
<AndyS2> ah, seems like it doesn't even build on opensuse 42.2 atm. Guess I'll check back at a later time (or try myself, maybe)
<orby> can i ask questions about ubuntu core in here?
<orby> also on https://www.ubuntu.com/desktop/snappy `sudo snap refresh all` is no longer valid, at least as of the current rev of snap
<orby> at least snap version 2.22.3
<orby> i was unable to setup a new ubuntu core install (series 16) using a static ip, on a raspberry pi 2
<orby> had to use dhcp, as it kept erroring out when attempting to configure eth0
<orby> now that i've got the system setup, i can't find a resonable way to reconfigure the networking to be static ip
<orby> and i can't find any documenation on ubuntu's site that specifies how that should be done under the core/snap design
<OerHeks> sudo snap refresh # this should work fine
<orby> yeah, i figured out the correct command by accident, just pointing out the docs are wrong and i don't see a way to indicate that on the website :)
<OerHeks> then this page should be editted too > https://www.ubuntu.com/desktop/snappy
<orby> from what i can tell, netplan under snap/core seems to be in charge, but i'm not sure how to correctly make changes
<orby> looks like running `sudo console-conf` was able to reconfigure the network remotely, although I'm not sure it was done cleanly as screen isn't available
<orby> rebooting to see if that sticks
<orby> looks like it does
<mup> Bug #1666074 opened: Can't update "snapweb' snap <Snappy:New> <https://launchpad.net/bugs/1666074>
#snappy 2018-02-12
<mborzecki> morning
<mup> Bug #1700560 changed: âsnap findâ returns confusing results <Snappy:Fix Released> <Snap Store:Invalid> <https://launchpad.net/bugs/1700560>
<zyga> hello
<zyga> sorry for being late
<zyga> mborzecki how are you doing? :-)
<mborzecki> zyga: hey
<mborzecki> it's snowing outside (again)
<mborzecki> zyga: have i missed anything interesting on friday?
<mvo> hey zyga and mborzecki
<zyga> haha, same here :-) snow snow snow
<zyga> good morning mvo
<mvo> here as well!
<mvo> snow!
<mborzecki> mvo: morning
<zyga> well, I had a great Friday EOD except for one test that made me think all weekend about it
<mborzecki> zyga: what was the test?
<zyga> https://github.com/snapcore/snapd/pull/4644
<mup> PR #4644: tests: add a spread test for layouts <Created by zyga> <https://github.com/snapcore/snapd/pull/4644>
<zyga> look at the diff first
<zyga> it passes everywhere but on core
<zyga> jamesh hello
<mborzecki> btw. this is what mikoÅajki looks like this time of the year: https://imgur.com/a/1Np8S
<zyga> oh, we have a bug report hidden on github: https://github.com/snapcore/snapd/pull/3889#issuecomment-364637980
<mup> PR #3889: interfaces: mount host system fonts in desktop interface <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/3889>
<zyga> mborzecki woah, nice!
<zyga> warsaw is full of smog because of inefficient combustion heaters and people burning trash :/
<mborzecki> sounds like every major city during the winter :P
<mborzecki> there's an area in lodz, south-west, towards pabianice, mostly older housing, the air quality meters are usually going all red during the winter
<zyga> yeah, it's all around poland
<zyga> I miss spain, nobody burned trash, it wasn't that cold, air was clean
<mborzecki> it wasn't that cold <-- that's your solution there :)
<zyga> yeah but also everything was heated by gas, not coal/wood/garbage
<zyga> and also a bit more money on average
<mborzecki> zyga: that test failing, `cannot stat /var/lib/snapd/seccomp: No such file or directory` ? another thing, was there no /etc in the snap rootfs?
<zyga> there is /etc in the core snap, we also have writable paths that change how that operates
<mborzecki> zyga: there's a separate path for all this in snap-confine too?
<zyga> nope
<zyga> well, not for layouts
<zyga> I have a suspicion what the problem might be... stay tuned :)
<mborzecki> zyga: right, not for layouts, but for bootstrapping the mount namespace
<zyga> yes, we do have different setup there
 * zyga looks at http://aqicn.org/city/poland/mazowieckie/warszawa/ursynow/ and at http://aqicn.org/city/spain/catalunya/barcelona-eixample/
<jamesh> zyga: hi
<zyga> hey!
<zyga> I merged master into your PR
<zyga> and resolved some conflicts due to a recent big code move
<zyga> jamesh I may also work on that branch further this week, mainly by chopping it down and landing parts while the last validation problem gets solved
<jamesh> thanks.  I've been thinking a bit more about the checks jdstrand wanted.  If we can't work out a way to reliably reconstruct the mount source from the mountinfo file, I wonder if it would be enough to ensure it is on the right device?
<zyga> jamesh I don't know yet, I need to think about that and focus (just barely woke up)
<jamesh> i.e. if we expect the mount source to be in the user's /run/user/$UID tmpfs, we should be able to reliably check that it is still from that file system after the mount
<jamesh> (e.g. hasn't been replaced by a symlink to /etc on a different device)
<zyga> yes, that's doable
<zyga> one thing we can do is to check that after the mount op finishes there are no more symlinks than before
<zyga> but I need to think about what we might be racing with here
<jamesh> of course, for the xdg-document-portal case, the mount point is in a fuse file system under $XDG_RUNTIME_DIR, so we can't just check the one device number
<jamesh> I think we could do a simple walk backwards through mountinfo before the mount to find out the expected device for the source, and then check the details of the new mountinfo entry afterwards to confirm
<zyga> yeah, that's doable, I think we need to walk both the mount table and the path components and see where we land at each stage (if we follow any symlinks along the way)
<zyga> jamesh btw, I was also wondering about one more thing, if we can simplify the problem by 50% by doing "mount -t stuff /dev/stuff ."
<jamesh> for user mounts, I think it'd be okay to consider any cross-device symlinks to be an error
<zyga> if we mount in the current directory, if that's even doable, we have smaller attack surface
<zyga> not sure if we're going to mount more than fuse filesystems now
<mborzecki> mvo: could you upload a .vendor.tar.gz release files to github releases page for 2.31?
<jamesh> zyga: what do you mean by "mount -t stuff" here?
<zyga> jamesh: pushd && cd /tmp && mount -t tmpfs tmpfs . && popd
<zyga> jamesh no way to attack mount target directory (mount point)
<zyga> and after we cd we can take all our time to investigate where we've landed
<zyga> (we can also write a secure chdir)
<mvo> mborzecki: sure, let me do this
<jamesh> zyga: is that more secure than doing "cd dest; mount --bind /source ." ?
<mborzecki> mvo: thanks
<zyga> no, that's exactly what I meant
<zyga> the idea is to avoid mount /one/path /another/path
<zyga> and to reduce that to /one/path
<jamesh> just wanted to check what would happen when mounting over a symlink: the command line tool dereferences the symlink itself, so that doesn't help much
<zyga> jamesh yeah, that happens at syscall level too, that's why mount(2) sucks so much :/
<jamesh> so who wants to propose a mountat() system call? :)
<zyga> there were some proposals like that
<zyga> but I think it's a bit complex for reasons I don't fully understand
<zyga> there is some reason why it's path based more than just FD based
<zyga> the last thing I remember was ...
 * zyga still searches
<zyga> https://lwn.net/Articles/718638/
 * zyga breaks for breakfast
<alexlarsson> jamesh: hey, did you look at the document portal?
<zyga> hey alexlarsson
<alexlarsson> hey hey
<alexlarsson>  You can't get any simple mount() changes in
<alexlarsson> because al viro hates the mount syscall and wants to completely redo it
<alexlarsson> Thus blocking minor improvements
<alexlarsson> Not that i disagree with him...
<zyga> well, a no-follow flag would do wonders
<zyga> but yeah
<zyga> I'd love to see a new API too
<jamesh> alexlarsson: I haven't done a full test of your branch yet.  I'll get that done and add some feedback to the PR.
<zyga> (don't really mind if both happen)
<jamesh> there is a fantasy linux mount API described here: https://lwn.net/Articles/718638/
<alexlarsson> What i would love is a bind mount + make readonly in a single call
<alexlarsson> I have some horrendous complicated code for recursive read-only bind mounts :/
<alexlarsson> https://github.com/projectatomic/bubblewrap/blob/master/bind-mount.c
<alexlarsson> this is total bullshit
<alexlarsson> and should just be MS_BIND | MS_REC | MS_RDONLY
<zyga> all software evolves till it parses mountinfo ;-)
<alexlarsson> I asked al, and he agreed it was bullshit. But...
<zyga> but nack to small improvements?
<alexlarsson> yeah
<zyga> is he working on the new big API or is it just fossilisation stage and nothing happens?
<alexlarsson> unclear
<jamesh> If you fixed mount() so that flags other than MS_REC were respected when performing a bind mount, how would the app even know?
<zyga> jamesh I think it'd require a MOUNT_EXTRA_FLAGS flag or something similar to indicate desire to use a richer interface
<zyga> or an entirely new syscall
<jamesh> zyga: the syscall is currently documented as ignoring other flags, and the call is likely to succeed on an old kernel anyway
<jamesh> so you'd need to check after the fact to see if they were applied
<zyga> too messy, the idea is to make userspace easier, not just hard but different
<zyga> given what you said a new syscall is really needed
<alexlarsson> jamesh: child of MS_MGC_VAL ?
<jamesh> If they'd instead made it an error to specify the flags that it currently ignores, there'd be something user space could check for
<alexlarsson> yeah
<alexlarsson> but that would make sense!
<zyga> haha
<zyga> all the good choices we never did
<zyga> and even once the new interface is here it will be many many cycles before it can be used as a dependency without cutting a significant chunk of users
<Chipaca> morning all
<mvo> hey Chipaca, good morning
<Chipaca> mvo: hiya
<Chipaca> I suck at naming things. What would *you* call this Thing, and what would you call the arguments to New after the first? https://gist.github.com/chipaca/21222a4fa23ae5d8629c84cc016f23ea
<Chipaca> ^ that's what i've been playing with this weekend
 * Chipaca now gets back to work
<mvo> Chipaca: hm, maybe Formater?
<Chipaca> mvo: it's not strictly work, and it's got bugs still, but if you want to play with it, https://people.canonical.com/~john/snap-find should work on amd64
<Chipaca> (needs a running snapd)
<mvo> Chipaca: nice
<mvo> Chipaca: Columnizer , ColumnFormater, SheetFormater for some more ideas
<Chipaca> oooh, Columnizr and be all web 2.0
<Chipaca> wrt the bugs, one is go's, in that i need to add code to handle double-wide characters by hand (search for 'hello' and look at hello-bluet)
<Chipaca> another is that in long listings it seems to be doing something wrong and leaving too much space for things it's not going to print yet, so there's a cutoff missing its spot
<Chipaca> but anyway,lots of fun rune-twiddling to be had
<mvo> Chipaca: :) looks/sounds like it indeed!
 * Chipaca -> physio break
 * Chipaca -> *really* physio break
<mup> PR snapd#4648 opened: debian, snap: only static link libseccomp in snap-seccomp on ubuntu <Created by mvo5> <https://github.com/snapcore/snapd/pull/4648>
<mup> PR snapd#4645 closed: snapctl: allow `snapctl get` from any uid <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4645>
<mup> PR snapd#4649 opened: many: record if snap was installed with --dangerous, snow relevant annotation in `snap info` and `snap list` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4649>
<mup> PR snapd#4650 opened: daemon: allow `snapctl get` from any uid <Created by mvo5> <https://github.com/snapcore/snapd/pull/4650>
<Chipaca> hmmm, hangouts seems rather dark right now
 * Chipaca turns it off and back on again
<Chipaca> oh god they're trying to use opengl
<mup> PR snapd#4629 closed: ifacestate: only rewrite security profiles if the system-key changes <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4629>
<Chipaca> man, go-flags is terrible at formatting this stuff
<Chipaca> :-(
<Chipaca> https://pastebin.ubuntu.com/=dS8vNTVhrM/
<Chipaca> like, wtf is going on with the option alignment
<Chipaca> --hello
<Chipaca> .                                       --yes-im-over-here
<Chipaca> .    --WAT
<mup> PR snapd#4651 opened: cmd/snap: add help for service commands (oops) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4651>
 * Chipaca hugs mup
<Son_Goku> today is a day where I curse Go for making it so that build flags are comments in Go files
<mborzecki> Son_Goku: CGO_LDFLAGS_ALLOW is your friend
 * Son_Goku sighs
<mborzecki> Son_Goku: they did forget to add a similar for pkg-config though :)
 * Son_Goku mournfully looks over at the nice stuff in Rust with Cargo...
<mborzecki> off to pick up the kids
<mvo> zyga: 4643 has a trivial suggestion for a comment fix
<zyga> ack
<mup> PR snapd#4638 closed: devicestate: fix autopkgtest failure in TestDoRequestSerialErrorsOnNoHost <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4638>
<mup> PR snapd#4651 closed: cmd/snap: add help for service commands (oops) <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4651>
<Chipaca> wooooo
<Chipaca> that's got to be a record
<Chipaca> 23 minutes from PR to landed with 2 +1s and green spread
 * mvo hugs Chipaca 
<mup> PR snapd#4646 closed: snap-seccomp: fix cgo pkg-config and LDFLAGS <Created by stapelberg> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4646>
<mvo> the classic confinement test segfaults on bionic :( /me wants the `snap run --gdb` branch to be merged to debug this
<Chipaca> jdstrand: you around?
<mup> PR snapd#4643 closed: snap: disallow layouts in various special directories <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4643>
<jdstrand> Chipaca: hey, yes
<Chipaca> jdstrand: I was looking through the review tools wondering about version validation
<Chipaca> jdstrand: are they still from lp:click-reviewer-tools ?
<jdstrand> Chipaca: for the moment
<Chipaca> jdstrand: and if so, is it _verify_pkgversion in common.py
<Chipaca> jdstrand: and if so, maybe update it so it matches snapcraft's validator?
<Chipaca> jdstrand: or, sync with snapcraft about it
<Chipaca> there are things that one considers invalid that the other doesn't, in both directions
<jdstrand> Chipaca: I can do that. it matched at one point...
<jdstrand> Chipaca: is there a particular issue you are looking at?
<Chipaca> jdstrand: I'm adding version validation to snapd
<Chipaca> and I'd like to write that it matches what the review tools and snapcraft do
<Chipaca> but currently i cannot :-)
<jdstrand> then, yes, I'll adjust the review tools to match snapcraft
<jdstrand> Chipaca: since you've looked at snapcraft, where is the validation happening there?
<Chipaca> jdstrand: ^[a-zA-Z0-9.+~-]{1,32}$ is what snapcraft is checking fwiw
<jdstrand> so '~' is a valid version?
<Chipaca> jdstrand: schema/snapcraft.yaml
<Chipaca> jdstrand: yes
<Chipaca> jdstrand: also README.~1~
<jdstrand> Chipaca: let me rephrase. '~', '.', '+' and '-' are all supposed to be valid versions?
<Chipaca> jdstrand: in snapd, _anything_ is a valid version :-)
<Chipaca> but yes in snapcraft those things are valid versions
<jdstrand> Chipaca: the store has its own checks separate from the review-tools aiui, and the review tools reflect that
<jdstrand> Chipaca: I know it is in snapcraft :P is snapcraft *wrong*?
<Chipaca> this is turning into a Meeting, isn't it
<Chipaca> *gasp*
<Chipaca> surely not
<Chipaca> sergiusens: you on national holiday today, n'eh?
<Chipaca> kyrofa: kalikiana: can we talk about versions for a bit?
<Chipaca> or maybe i should open a bug
<kyrofa> Chipaca, sure!
<jdstrand> Chipaca: honestly, I think we need the store team. iirc there are checks there
<Chipaca> kyrofa: am I right in thinking that snapcraft uses the schema/snapcraft.yaml thing to validate versions?
<kyrofa> Oh, looks like I have some reading to do
<kyrofa> Chipaca, yes, if it's a string it's validated with that regex
<Chipaca> jdstrand: ok
<jdstrand> I'll change the review tools to whatever is agreed to. the version check was more important when we had the version as part of the security label
<Chipaca> noise][: who knows about the version validation the store does?
<Chipaca> noise][: that is, validation of the version string in a snap
<kyrofa> Chipaca, yeah we have no horse in this race either-- you just tell us what you want it to be and it shall be done
<Chipaca> kyrofa: basically the regexp there is suspect, but we have apparently three different ones already :-) so, this
<Chipaca> kyrofa: version must match ^fantastic-.*$
<Chipaca> \o/
<jdstrand> I *think* what I was remembering was that we were doing what the store does, not what snapcraft does, since people can run the review-tools on a snap prior to upload (no one does that now, but when this was written, that was the thinking)
<kyrofa> Yeah seems reasonable
<kyrofa> :P
<Chipaca> jdstrand: right, but I'm not sure the store enforces the "version must be debianish" rule any more
<jdstrand> it's possible now that click and snapv1 are gone, the version check in the store was removed
<jdstrand> right. me either
<jdstrand> hence you asking them :)
<pedronis> jdstrand: Chipaca: I don't see a version check in the store
<Chipaca> hmmm
<pedronis> there's just a max length
<jdstrand> it had to do with the upload
<pedronis> afaict
<jdstrand> I forget what it was called...
<Chipaca> maybe I should just try to upload something with a ridiculous version and see what happens
<jdstrand> I don't know if the output of the test is: 'Is a valid package' or 'Stated package version matches snap.yaml'
<jdstrand> those two tests are not from the review tools
<jdstrand> pedronis: does what you looked at have those checks? ^
<Chipaca>   - malformed 'version': 'this is some silly potatoes'
<diddledan> no spaces?
<pedronis> Chipaca: that seems review tools tough
<pedronis> not the store itself
<pedronis> I don't see a pattern check for version in the store code
<Chipaca> jdstrand: note review tool's [A-Za-z0-9.+:~-]+? means those things are also valid versions for this, fwiw
<Chipaca> so, it's just snapcraft and review tools, beyond the length limit
<jdstrand> Chipaca: yes
<pedronis> there's a 32 chars max-length
<Chipaca> jdstrand: and i just pushed a thing with a version of ~ just to make sure
<pedronis> in the sotre
<pedronis> store
<jdstrand> alright, well, if there are no checks in the store, I'll just update the review tools to match snapcraft
<pedronis> jdstrand: I'm double checking with other people about the store
<Chipaca> kyrofa: is there any reason snapcraft explicitly disallows epoch-style versions things?
<Chipaca> kyrofa: (there's no ":" in there)
<kyrofa> Chipaca, not that I know of. This regex has been there as long as I can remember
<jdstrand> pedronis: it was some code that westby wrote. I can't remember the name of it. it might be gone now
<kyrofa> Chipaca, we don't use the version for anything other than plopping into the snap.yaml and putting it into the filename of the resulting snap
<jdstrand> kyrofa: it probably should include ':'. people like to snapcraft a stage-package and just use the deb version
<kyrofa> jdstrand, yeah easy peasy. Sounds like we want some other changes too though, perhaps to not start or end or have multiple [.+~-:]
<Chipaca> would ^[a-zA-Z0-9]([a-zA-Z0-9:.+~-]{,30}[a-zA-Z0-9+])?$ be any better?
<Chipaca> oh, oh, _ also
<pedronis> jdstrand: other store people seems to confirm there's no check (atm)
<Chipaca> ^[a-zA-Z0-9]([a-zA-Z0-9:.+~_-]{,30}[a-zA-Z0-9+])?$
<pedronis> *seem
<kyrofa> Yeah seems fine to me Chipaca. You want it, you got it
<Chipaca> mvo: you also know something about versions, could you eyeball it? ^
<mvo> Chipaca: in a meeting right now, will look soon
<Chipaca> mvo: ack
<jdstrand> Chipaca: I would suggest: ^[a-zA-Z0-9]([a-zA-Z0-9:.+~_-]{,30}[a-zA-Z0-9+~])?$
<jdstrand> Chipaca: (allow ~ at the end)
<Chipaca> jdstrand: i don't mind; what version are you imagining that needs it?
<jdstrand> 1.2.3-2~
<Chipaca> I left the + in there because I imagined somebody wanting a 3.2+ version
<jdstrand> I've seen that before
<Chipaca> ok, fair
<mvo> yeah, 1.0~ will be common
<mvo> (ish)
<mvo> its a common pattern for e.g. backports
<Chipaca> also if [+~_-] isn't an emoticon it should be
<jdstrand> Chipaca: alright, adding to trello ^[a-zA-Z0-9]([a-zA-Z0-9:.+~_-]{,30}[a-zA-Z0-9+~])?$. ping me if changing
<Chipaca> jdstrand: will do, thank you!
<jdstrand> I'm also surprised that the review tools allow what they do... they didn't always. I remember the discussions. anyway, who cares, it is changing now :)
<Chipaca> kyrofa: running with this one ^ will shout if it changes
<Chipaca> also may i suggest you python people use (?: instead of plain ( :-P
<Chipaca> kyrofa: actually i'm not sure what the schema validation uses for regexps; if {,30} trips it up, you can use a * and the max-length of 32 will catch it
 * Chipaca breathes in, lets people deal with their problems, and gets back to his own
<kyrofa> Chipaca, sounds good
<kyrofa> Sorry, made the mistake of launching chrome. Had to reboot
<Chipaca> written forum post ahead of PR, because why not: https://forum.snapcraft.io/t/snapd-enforcinig-snap-versions/3974
<Chipaca> (currently not listed so people aren't confused :-) )
<kyrofa> Chipaca, waiit.. how do you do unlisted posts?
<kyrofa> jdstrand, what kind of timeline do you anticipate for that change? We should coordinate
<Chipaca> kyrofa: magic
 * kyrofa hears "special permissions you don't have"
<Chipaca> kyrofa: (tap the gear, it should be there)
 * Chipaca publishes a snap with a version of 'unpredictable-counterrevolutions'
<kyrofa> I see hide details and poll
<jdstrand> kyrofa: not terribly soon unless someone wants it *right now*
<Chipaca> kyrofa: you pleb
<kyrofa> jdstrand, no rush from me. I suppose snapcraft could make the change before you folks and it would be okay. It'd be bad the other way around
 * kyrofa puts together a PR
<mvo> Chipaca: the version of "base-18" is "very-unstable", but that should still validate right?
<Chipaca> mvo: unpredictable-counterrevolutions validates :-)
<mvo> Chipaca: heh
<jdstrand> kyrofa: what is in the review-tools is pretty close to what we agreed to
<kyrofa> Good deal
<jdstrand> kyrofa: I guess just commit to snapcraft soon and these can just roll in later
<kyrofa> jdstrand, sounds good
<jdstrand> the only problematic one is '_' in that you'll start allowing '_' but the review tools won't
<jdstrand> but, you'd have to know that all of a sudden you could use it
<jdstrand> the other bits show the review tools more strict already, and people haven't been complaining
<Chipaca> or we haven't heard them :-)
<Chipaca> (i think it's the sort of thing that people will hit, complain, tweak the string, and move on
<Chipaca> )
<Chipaca> s/complain/grumble/ perhaps
<jdstrand> point is, status quo if we aren't in perfect sync
<jdstrand> when we are in perfect sync, no more grumbling
<roadmr> hi jdstrand
<roadmr> jdstrand: so nothing will change with the review tools r1000 unless I set that resquashfs env vraiable, right?
<jdstrand> roadmr: not wrt resquash, no
<roadmr> jdstrand: ok - right. I have r1000 on staging right now and it was happy with my usual, trivial test snap
 * jdstrand nods
<jdstrand> roadmr: you may have noticed all the snaps in tests/ in the bzr tree
<roadmr> jdstrand: oh I did not! awesome!
<jdstrand> roadmr: that was part of all the testsuite updates I did
<Chipaca> jdstrand: kyrofa: you've probably realised by now that it's {0,30} not {,30} in the regexp
<jdstrand> Chipaca: yes
<Chipaca> the {,30} might be a perlism, or it might be a bug in my head :-)
<roadmr> jdstrand: fantastic! I usually sanity-check locally against some bogus snap I have, to avoid pushing a bogus revno, but this should make all that moot!
<roadmr> moot-woot!
<jdstrand> roadmr: if you want to send me that snap, I can add it to the tools
<jdstrand> or anything else you like to test
<roadmr> jdstrand: I don't think it's needed, it's an empty snap with classic confinement and only meant to protect against that case we had once...
<roadmr> jdstrand: where you had an undeclared dependency so the thing worked for you but failed when pushed to the store
<jdstrand> I may already have that use case in there
<roadmr> jdstrand: to be honest I think I'll switch my local testing from my crap snap to the list you have here, though again it's for sanity, if you ran that test suite at merge time that looks quite thorough
<jdstrand> roadmr: note I said 'wrt resquash'. that is because there are new and updated checks, but that is all normal stuff
<roadmr> jdstrand: so does resquash modify the snap-under-test? or just verifies that when resquashing, the result is identical to what was uploaded?
<roadmr> jdstrand: (that's why I zeroed in on that feature - was worried it might somehow alter the uploaded snap)
<roadmr> in which case many components would be unhappy
<jdstrand> roadmr: there is a big matrix for testing that I use. 14.04 was tested. running 'make functest' will run the tools on tests/, but the output is different on 14.04 and 16.04 on some click stuff due to testsuite mocking
<jdstrand> roadmr: that will go away when I drop click/snapv1
<roadmr> that'll be awesome
<jdstrand> roadmr: the resquash will *not* modify the original squash. it unsquashes then resquashes and makes sure they are the same
<jdstrand> s/they are/it is the same as the orig/
<roadmr> jdstrand: ah, nice!
<jdstrand> yeah, we totally don't want to touch the original
<jdstrand> roadmr: also note, that the resquashfs have always run
<roadmr> ohh
<jdstrand> roadmr: they are even running in r1000. I didn't change that
<jdstrand> roadmr: the env vars say whether the check is enforced or not, and whether or not to use fakeroot
<jdstrand> they haven't been enforced for a long time, and r1000 doesn't change that
<jdstrand> once snapcraft 2.39 is is in -updates on all the releases, I'll turn enforcement back on
<roadmr> jdstrand: I see. So if it's enforced it'll actually return an error if they don't match?
<jdstrand> roadmr: yes
<jdstrand> but the snap needs to be squash with -no-fragments, otherwise false positives
<jdstrand> and snapcraft 2.39 does that
<roadmr> jdstrand: ok. I was thinking how to set that variable but from this I get we shouldn't, until you ask for a tools update which enforces this, right?
<jdstrand> roadmr: yes. you don't need to do anything. I was mentioning it in case you wanted to test it yourself or do something on staging, etc, but prod doesn't need to do anything
<roadmr> jdstrand: ok. Sounds like we'll test that once you enable it (at which point it'll make it to staging anyway)
<jdstrand> roadmr: when I turn on enforcement, it'll be by default and the tools will honor SNAP_RESQHASHFS_ENFORCE=0 to turn it off
<roadmr> jdstrand: much fiddlier for me to add a feature flag to set the env var
<jdstrand> yes
<roadmr> jdstrand: right, we can totally add the feature flag if we see a lot of false positives and we want to be able to switch that off quickly
<jdstrand> the env var was mostly for us in debugging the enforcement feature
<jdstrand> I never wanted you to have to do anything
<roadmr> thanks :)
<roadmr> we're clear on that then. r1000 should land in prod sometime this week
<jdstrand> \o/
<jdstrand> thanks :)
<roadmr> jdstrand: I'll be afk from tomorrow until Feb 21st
<jdstrand> roadmr: ack. while I have you, you adjusted the debs to install already?
<roadmr> jdstrand: yes, I did that first on staging to ensure none of the deps wrecked the world, then updated the tools, which are running fine too
<jdstrand> perfect
<jdstrand> thanks again! :)
<jdstrand> most of those deps you probably had. a few are if you want to run parts of the testsuite there
<roadmr> jdstrand: yes, we did tweak the set of deps a bit (removed python3-all since we already install python3) but there were only 5 new ones
 * jdstrand nods
<Chipaca> why, oh why, doesn't the go test runner tell me exactly what file it's running? There are eleventyone backend_test.go and at least five have a TestUpdatingSnapToOneWithFewerHooks :-/
<mup> PR snapd#4652 opened: tests: fix spread test failures on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4652>
<RobertGlick> Hello everyone I am having problems removing a snap
<RobertGlick> I keep getting an error I have googled and seems like I must be the only one
<RobertGlick> the error is error: cannot remove "chromium": snap "chromium" has changes in progress
<RobertGlick> I did a reboot and did not open chromium and I am still getting this message
<ogra_> snap changes ?
<RobertGlick> no
<ogra_> (i mean ... run that command to see the changes in progress)
<RobertGlick> ah ok
<kyrofa> RobertGlick, then run `snap change <changeid for chromium>` to see what it's doing
<RobertGlick> ok got 4 errors installing chromium
<RobertGlick> but then it succesfully installed
<ogra_> can you just paste the output of the snap changes command to https://paste.ubuntu.com/ ?
<ogra_> also "snap version" would be helpful
<RobertGlick> hmm I pasted
<ogra_> give us the url then :)
<RobertGlick> but should there be a link
<ogra_> yes, in the url bar in your browser window
<RobertGlick> https://paste.ubuntu.com/=cybnndDSsC/
<RobertGlick> how to see snap version
<ogra_> just run "snap version"
<RobertGlick> thanks
<ogra_> that will print all relevant version info ybout your system
<RobertGlick> 2.30
<ogra_> the full output please :)
<RobertGlick> snap    2.30
<RobertGlick> snapd   2.30
<RobertGlick> series  16
<RobertGlick> solus   3
<RobertGlick> kernel  4.14.18-51.current
<ogra_> ah
<ogra_> solus ...
<RobertGlick> yup
<ogra_> ikey, your customer ! ^^^^^
<ogra_> :D
<RobertGlick> Thanks
<RobertGlick> will do
<ikey> ogra_, what the who
<ikey> oh hey a customer
<ogra_> ikey, yeah, you have them !
<ogra_> :)
<ikey> we need to update our snapd before we look further into bugs me thinks
<ikey> so that everyone is on the same baselevel
<ogra_> well, 2.30 is the current stable one
<ikey> o .31 is unstable?
<ogra_> candidate
<ikey> o
<mup> PR snapd#4642 closed: many: add nfs-home flag to system-key <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4642>
<RobertGlick> ogra_ and ikey fixed it  not sure how this worked but i did sudo snap revert chromium then sudo snap remove chromium and it removed
<ogra_> great
<ogra_> it was probably just still doing some delayed operation while you tried the remove the first time
<RobertGlick> hmm strange i did a reboot and did not open the app
<RobertGlick> and was still getting that error
<RobertGlick> but happy reverting and removing worked
<RobertGlick> ogra_ one last question how do I clear the cached version to download a fresh copy?
<ogra_> there is no caching
<ogra_> it should just download anew if you removed the snap before
<RobertGlick> ok
<RobertGlick> thanks
<mup> PR snapcraft#1923 opened: mypy: update to 0.560 <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1923>
<mup> PR snapcraft#1914 closed: docker: add Dockerfiles for all risk levels <Created by kyrofa> <Merged by kyrofa> <https://github.com/snapcore/snapcraft/pull/1914>
<jdstrand> tyhicks: so, that dbus service activation change is proving to be annoying: https://github.com/snapcore/snapd/pull/4652#discussion_r167665241
<mup> PR #4652: tests: fix spread test failures on 18.04 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4652>
<jdstrand> tyhicks: I'm not sure why dbus isn't defaulting to 'unconfined' if AssumedAppArmorLabel is not set...
<jdstrand> tyhicks: istr you saying you'd look at it, comment in a bug, something... (am I crazy?)
<tyhicks> jdstrand: that sounds like something I said but I think I let it fall off my plate once it sounded like there was a usable workaround
<jdstrand> tyhicks: I mean, really, it could even be configured via bus configuration
<tyhicks> (I think that was mid-sprint, too, so maybe that had something to do with it)
<jdstrand> <apparmor mode="(enabled|disabled|required)" assumedlabel="unconfined"/>
<jdstrand> tyhicks: ok... how should we proceed now? what are your thoughts on what it should be doing?
<tyhicks> jdstrand: I've taken a note to look into it soon
<jdstrand> tyhicks: ok, thanks. holler if you want me to do anything. in the PR with mvo, I recommended adjusting systemd's timedate1 dbus service file
<tyhicks> jdstrand: I don't have an answer right now but I think we discussed a new permission that may be implied by an existing permission
<jdstrand> oh right
<jdstrand> tyhicks: well, when you have time to look at it, feel free to ping me to discuss
<tyhicks> jdstrand: will do - thanks!
<roadmr> jdstrand: hey so the tools already support common-id for apps within a snap, right?
<jdstrand> roadmr: as of r1000
<roadmr> jdstrand: fantastic :) thanks! (just checking)
<jdstrand> roadmr: 980.1.3 to be specific
<roadmr> right :) cool!
<jdstrand> roadmr: and 980.1.4 has your ctime fix
<jdstrand> as it happens, I saw that issue today with r950. looking forward to r1000
<roadmr> jdstrand: oh perfect :) yes, I haven't seen it super often but sometimes it happens
<roadmr> jdstrand: haah it was fun with wxmaxima which had daily builds and when one got stuck it built a queue of like 100 revisions :/ pushing them through by hand was fun
 * roadmr said fun twice, imagine how fun it actually was
<jdstrand> hehe, yes :)
<mup> PR snapcraft#1564 closed: setup: changes to make installable from PyPI <Created by sergiusens> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1564>
<mup> PR snapd#4653 opened: all: snap versions are now validated <Created by chipaca> <https://github.com/snapcore/snapd/pull/4653>
<mup> Bug #1749028 opened: snapd and disks <Snappy:New> <https://launchpad.net/bugs/1749028>
#snappy 2018-02-13
<mup> PR snapcraft#1924 opened: schema: update version regex <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1924>
<mup> PR snapcraft#1836 closed: Update test_export_login.py <codein> <Created by heesen3> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1836>
<mup> PR snapcraft#1846 closed: go plugin: remove confusing importpath message <codein> <Created by Nissaar> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1846>
<mborzecki> morning
<zyga_> good morning
<mborzecki> zyga: hey
<zyga> man, I was so useless yesterday
<zyga> maybe the weather is getting to me :/
<zyga> chihchun_afk: I hope we don't make any core snap invalid wrt version validation now
<mborzecki> zyga: do you have any ideas about https://github.com/snapcore/snapd/pull/4647#issuecomment-365171068 ?
<mup> PR #4647: cmd/snap: fix UX of snap services <Created by niemeyer> <https://github.com/snapcore/snapd/pull/4647>
<zyga> good morning niemeyer :)
<zyga> Job for snapd.socket canceled.
<zyga> hmm, we've seen that countless times
<zyga> I don't remember what that is off the top of my head
<mborzecki> zyga: right, i suspect that's somewhat related to snapd going down with sigpipe, getting restarted automatically and us trying to stop snapd.service and snapd.socket
<mvo> its only 14.04, right?
<zyga> I wonder if we can reproduce that on a simpler service
<zyga> mvo is it?
<mborzecki> mvo: yes
<mvo> the job canceled? yes - I only saw it on 14.04 so far
<mvo> I think its a bug in the old systemd we use there
<zyga> hey mvo :)
<zyga> some random bug report
<zyga> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=768208
<zyga> are we still shutting down snapd.service before snapd.socket?
<zyga> hmmm
<mborzecki> the timers are stopped before the tests?
<zyga> I don't recall
<zyga> I think we set the schedule (internal one)
<zyga> I don't know if we do something about the timers
<mup> PR snapd#4653 closed: all: snap versions are now validated <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4653>
<mup> PR snapd#4648 closed: debian, snap: only static link libseccomp in snap-seccomp on ubuntu <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4648>
<mup> PR snapd#4650 closed: daemon: allow `snapctl get` from any uid <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4650>
<mup> PR snapd#4654 opened: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4654>
<mborzecki> let's see if this makes any difference in the long run
<mvo> mborzecki: thank you
<kalikiana> sliff
<zyga> mborzecki thanks!
<mborzecki> mvo: we need to keep an eye on the strace spread tests, i saw it reaching kill-timeout in john's pr, maybe there's some syscall, that we haven't accounted for, that's causing issues
<mvo> mborzecki: yeah, definitely, is there any trace in that PR where it hangs?
<mvo> mborzecki: we might need to blacklist more
<mborzecki> mvo: it stopped in tests/main/snap-run, this line: `snap run --strace test-snapd-tools.echo "hello-world" >stdout 2>stderr`
<mborzecki> the next line was kill-timeout reached
<mvo> mborzecki: is it killed eventually?
<mvo> mborzecki: hm, do we get debug output on kill? if so we need to add the last lines of stderr. if not we need to talk to gustavo
<mborzecki> it was the only test that failed, so i hope it was killed
<mvo> xnox: hey, if you are around I would love to talk about 1749000
<mup> PR snapd#4647 closed: cmd/snap: fix UX of snap services <Created by niemeyer> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4647>
<mup> PR snapd#4625 closed: daemon: remove redundant UserOK markings from api commands <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4625>
<mup> PR snapd#4633 closed:  snap: introduce  timer service data types and validation  <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4633>
<mup> PR snapd#4654 closed: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4654>
 * Chipaca realises he made life harder for himself with #4653
<mup> PR #4653: all: snap versions are now validated <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4653>
 * Chipaca shakes fist at self
<mup> PR snapd#4615 closed: overlord/snapstate/backend: perform cleanup if snap setup fails <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4615>
<mborzecki> systemd timers are confusing, our timers are confusing too, ergo probably all timers are confusing
<mvo> maybe like make systems? I need to find one I actually not dislike still
<Chipaca> mborzecki: no no, you need to find a random timer, base a timer on it, and if you can prove it's confusing just from that, you've got the 1 case and the n+1 case and you can deduce the all-of-em case
 * Chipaca can feel his maths prof glaring at him right now
<mborzecki> Chipaca: iirc you need n, n+1, n+2 samples to infer anything :)
<mborzecki> anyways, looks like the timer services will be a mix of systemd (to fire a timer helper regularly) and snapd (to keep the state) :/ and that makes me a bit uneasy
<mvo> mborzecki: yeah, I am not sure we should rely on systemd available. we don't do that in e.g. snap run as well (made a concious effort to not depend on a running snapd there)
<mvo> mborzecki: eh
<mvo> mborzecki: sorry, snapd being available
<mvo> mborzecki: systemd of course (freudian slip ;)
<mborzecki> mvo: on one hand systemd can activate timers on regular intervals, but it's timer syntax is limited, eg. our 10:00-12:00 means 'happens once between 10am and 12am', once/between part cannot be expressed in systemd.time syntax, their events happen at specific time, eg. 10:00, as a workaround we could translate our timer to multiple oncalendar events every eg. 10minutes, then when running the service check if
<mborzecki> it already ran in the interval and do nothing or let it do its work
<mvo> mborzecki: yeah, I think we need a helper (not necessarily snapd) and we write a systemd timer that runs e.g. every 10min, passes the time string to the helper and the helper keeps the state when to fire
<mvo> mborzecki: I think this is pretty much what you described, right?
<mborzecki> mvo: yup
<mvo> great
<mborzecki> mvo: wonder if we could have like a templated oneshot service that gets activated by the timer
<mvo> mborzecki: yeah, that could work
<mup> PR snapd#4655 opened: osutil: add and update docstrings <Created by zyga> <https://github.com/snapcore/snapd/pull/4655>
<Chipaca> hmmm
<Chipaca> there's a failing test on master
<mborzecki> Chipaca: which one?
<Chipaca> mborzecki: systemKeySuite.TestInterfaceSystemKey in interfaces/
<zyga> oh
<zyga> Chipaca link?
<Chipaca> zyga: on master
<mborzecki> Chipaca: looks green to me
<Chipaca> zyga: like, on my box, right here
 * zyga runs
<Chipaca> because the test is looking at _my fstab_
<Chipaca> WTF
<zyga> Chipaca aah
<zyga> missing mocking
<Chipaca> *my* fstab
<zyga> which test fails?
<Chipaca> *mine!*
 * Chipaca hugs it to his chest
<Chipaca> sshhh, shhh, i won't let the nasty hacker hurt you
<Chipaca> zyga: systemKeySuite.TestInterfaceSystemKey
<Chipaca> zyga: also, i'll have you know ânone /tmp tmpfsâ is a perfectly valid fstab entry :-)
<zyga> optional options
<zyga> Chipaca so what's your fstab like
<zyga> I'll fix the parser
<zyga> an can you please check if 4656 fixes it for you?
<Chipaca> zyga: I'd also rather it didn't look at the real fstab
<mup> PR snapd#4656 opened: interfaces: mock away real mountinfo/fstab <Created by zyga> <https://github.com/snapcore/snapd/pull/4656>
<Chipaca> ah
 * Chipaca fetches zyga
<Chipaca> zyga: I can confirm it doesn't fix it
 * Chipaca runs it again to make sure
<zyga> so what did you add to your fstab, I can test quickly locally to get this to work
<Chipaca> uhhhh
<Chipaca> zyga: so
<Chipaca> zyga: you're doing the mocking wrong
<Chipaca> badly wrong in fact
<Chipaca> zyga: if you do
<Chipaca> 	defer osutil.MockMountInfo("")()
<Chipaca> in SetUpTest
<zyga> man
<zyga> I see now
<Chipaca> that'll get un-mocked at the exit of SetUpTest
<zyga> :D
<Chipaca> :-)
<zyga> sorry :
<zyga> :)
<zyga> Chipaca force pushed
<Chipaca> zyga: mucho bettero
<Chipaca> zyga: I miss python's ability to make callable lists
<Chipaca> but only sometimes
<zyga> callable lists?
<Chipaca> zyga: you can pop a __call__ on anything
<zyga> as in class funky(list) def __call__(self, *args, **kwargs): for fn in self: fn(*args, **kwargs)
<Chipaca> zyga: yep
<Chipaca> zyga: or return [i(*a, **kw) for i in self]
<mup> PR snapd#4521 closed: many: move /lib/udev/snappy-app-dev to /usr/lib/snapd/snappy-app-dev <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4521>
<mvo> hm, 4491 needs a second review pretty please
<zyga> Chipaca one more for you 4657
<zyga> mvo I'll do it
<mup> PR snapd#4657 opened: osutil: parse mount entries without options field <Created by zyga> <https://github.com/snapcore/snapd/pull/4657>
<Chipaca> zyga: welll.....
<zyga> yes?
 * Chipaca tries
<Chipaca> ah
 * Chipaca tries harder
<Chipaca> zyga: let me get an example that breaks
<Chipaca> zyga: nothing, 's fine
<Chipaca> zyga: :-) good
<Chipaca> zyga: #4656 green
<mup> PR #4656: interfaces: mock away real mountinfo/fstab <Created by zyga> <https://github.com/snapcore/snapd/pull/4656>
<mup> PR snapd#4656 closed: interfaces: mock away real mountinfo/fstab <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4656>
<zyga> ok  	github.com/snapcore/snapd/x11	0.004s
<Chipaca> zyga: can all tests be that fast? kthx
<Chipaca> zyga: are there cases where ParseMountEntry fails but you still need to use the (partial) MountEntry it returns?
<zyga> no, I don't think so
<zyga> we only read stuff we wrote (which has a fixed format) and when we read /etc/fstab
<zyga> but when we read fstab we AFAIR ignore errors
<Chipaca> ignore errors -> if it fails you still use the returned MountEntry?
<zyga> no
<zyga> I mean if we cannot determine if you're on NFS we just assume you are not and carry on
<Chipaca> mvo: have you seen #1747272?
<mup> Bug #1747272: Polkit dialogs of snapd are not translatable <l10n> <patch> <Ubuntu Translations:New> <snapd (Ubuntu):In Progress by gunnarhj> <https://launchpad.net/bugs/1747272>
<mup> PR snapd#4657 closed: osutil: parse mount entries without options field <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4657>
<Chipaca> mvo: it has a patch ;-)
<zyga> mvo reviewed 4491
<mup> PR snapd#4655 closed: osutil: add and update docstrings <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4655>
<mup> PR snapd#4658 opened: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
 * kalikiana going for a short break
<popey> mborzecki: heya! What's the plan for updating snapd in opensuse? (I may have missed a conversation about this previously, sorry).
<popey> (it's outdated and causes some modern snaps to not function)
<Son_Goku> popey, there's an openSUSE guy working on rebasing snapd based on the Fedora packaging
<Son_Goku> I'm helping him with it
<popey> <3 thanks Son_Goku
<popey> that's great to hear
<zyga> Son_Goku what is his name?
<Son_Goku> popey: a big part of the problem is that the current snapd packaging doesn't comply fully with guidelines to get into Factory (the main entrypoint for the SUSE distribution)
<zyga> Son_Goku please send him here, it will be easier to coordinate
<popey> feel free to poke me if there is anything to test, we have copious vms here
<Son_Goku> zyga: he has been here before
<Son_Goku> you should already know him
<zyga> sorry, I don't recall
<Son_Goku> hurricanehrndz
<zyga> thank you
<zyga> I invited him here
<Son_Goku> he's already been here...
<mvo> Chipaca: thanks for the pointer to the dialogs
<Son_Goku> popey: will do
<mup> PR snapd#4659 opened: snap: improve the version validator's error messages <Created by chipaca> <https://github.com/snapcore/snapd/pull/4659>
<Chipaca> ^ RFC PR about snap version validation error messaging
<mup> PR snapd#4660 opened: systemd: update comment on SocketsTarget <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4660>
<mborzecki> trivial PR ^^
<GunnarHj> Hi zyga, do you have some time for bug #1747272? I have attached two alternative patches, showing the idea for a solution, but I'm not able to test it properly (don't know how to build snapd).
<mup> Bug #1747272: Polkit dialogs of snapd are not translatable <l10n> <patch> <Ubuntu Translations:New> <snapd (Ubuntu):In Progress by gunnarhj> <https://launchpad.net/bugs/1747272>
<zyga> hey
<zyga> GunnarHj I think mvo here worked on an alternative patch
<zyga> GunnarHj I myself haven't touched thay yet
<zyga> *that
<mborzecki> zyga: close enough? https://4.bp.blogspot.com/-NrtzlHIkl24/Vb5EXABEWbI/AAAAAAAAmeM/4qeOSmXcrp8/s1600/deadmau5-lamborghini-puracan-huracan-nyanborghini.jpg
<zyga> I think the idea is to really link dynamically by default and do special magic where we need to
<GunnarHj> zyga: Ah, great! mvo ^ ?
<zyga> mborzecki nyan cat!
<zyga> hmm
<zyga> interesting failure
<zyga> + test-snapd-tools.env. execl failed: Permission denied
<zyga> [Tue Feb 13 13:03:14 2018] audit: type=1400 audit(1518526994.091:78435): apparmor="DENIED" operation="exec" profile="/snap/core/4060/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snappy-app-dev" pid=4025 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<zyga> mvo ^ is this what I think it is
<zyga> fallout of that branch you merged a moment ago?
<mvo> zyga: I don't know (yet)
<zyga>     /usr/lib/snapd/snappy-app-dev ixr, # drop
<zyga> we have this rule
<mvo> zyga: oh, right
<zyga> but it feels like this was not what was on disk
<zyga> https://github.com/snapcore/snapd/pull/4658
<mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
 * Chipaca gives zyga a quick intro course to advance mathematics concepts such as "1 != 0"
<Chipaca> :-D
<zyga> Chipaca what? :D
<Chipaca> zyga: https://github.com/snapcore/snapd/pull/4659#discussion_r167858672
<mup> PR #4659: snap: improve the version validator's error messages <Created by chipaca> <https://github.com/snapcore/snapd/pull/4659>
<zyga> hh
<zyga> d'oh :)
<zyga> thanks for pointing that out
<Chipaca> :-)
<Chipaca> TBH the "you can slice this way, you can slice that way, but you can't slice both ways at once" catches me out quite often
<mvo> jdstrand: when you have a moment, a re-review of 4652 would be great, should be super easy (much smaller now)
<Chipaca> zyga: "which character violated the regular expression" returns a universe
 * zyga breaks for quick lunch
<zyga> mvo let's trace that error in 30 min
<mvo> zyga: yeah, I think there is more broken in master right now
 * kalikiana lunch
<jdstrand> mvo: done. fyi, tyhicks and I aren't super excited by the upstream dbus change and will review if it can be improved. I don't know what will happen there, so just fyi
<jdstrand> zyga, mvo: re /usr/lib/snapd/snappy-app-dev: what's going on there-- that sounds like it would've come from my go rewrite branch (that I've been unable to circle back to, but will eventually)
<zyga> jdstrand yes, that branch landed
<jdstrand> my branch landed?
<zyga> and we have issues now
 * jdstrand needs to check email :)
<zyga> no, that's the mv branch
<zyga> sorry, not the rewrite branch
<jdstrand> ok
<jdstrand> yes, will, if you move it, you definitely need to adjust the snap-confine profile
<mvo> jdstrand: my branch that just puts it into a different place landed
<mvo> jdstrand: this is to fix a bug with core18
<jdstrand> snappy-app-dev is called by udev during hotplug/unplug events and by snap-confine for device cgroups wrt interface connections
<mvo> jdstrand: the rewrite is (AFAICT) orthogonal
<zyga> jdstrand we adjusted the profile too but something is broken still
<jdstrand> mvo: yes, it would be orthogonal, but there was talk of incorporating the move, so I was confused for a sec
<jdstrand> where's the PR?
<jdstrand> or rather, where is the failing test?
<mvo> jdstrand: aha, ok
<zyga> jdstrand https://github.com/snapcore/snapd/pull/4658
<mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
<zyga> the last commit fails on this now
<zyga> (have a look at the PR as well)
<jdstrand> so, it seems there is an issues applying the changed profile
<jdstrand> in the testsuite
<jdstrand> profile="/snap/core/4060/usr/lib/snapd/snap-confine": that needs to have the new '/usr/lib/snapd/snappy-app-dev ixr,', but for some reason it doesn't
<jdstrand> zyga: did you maybe pull in the change to move the binary but not the change to the profile?
<zyga> no, I didn't do anything actually, this branch is unrelated
<jdstrand> I don't know how all this landed
<zyga> and we simply merged master elswehre
<zyga> I meant "merged to master elsewhere"
<zyga> I'm checking if this is reproducible now
<jdstrand> well, there is a testsuite issue with generating snap-confine.apparmor
<jdstrand> snap-confine.apparmor is not getting cached somehow, is it? is snap-confine.apparmor.in being used on every spread run?
<zyga> we now create and destroy machines for each spread run, I doubt there is something stale there
<jdstrand> I didn't phrase tha well. when spread pushes the code to the node, is snap-confine.apparmor being regenerated at the right time from snap-confine.apparmor.in?
<zyga> the push runs on a fresh machine
<zyga> the whole build / install / test cycle is followed
<jdstrand> zyga: right, but *perhaps* snap-confine.apparmor is on the host and being preferred over regenerating it from snap-confine.apparmor.in
<jdstrand> I don't know, just trying to think through where it could break down
<zyga> well, it _may_ be but we reinstall the package (which loads the profile) and then you can see this is the profile from reexec
<zyga> hmm
<zyga> one idea is that we compute the reexec profile from something stale / old
<zyga> but ... not sure how
<jdstrand> zyga: but that line of thought is, you have snap-confine.apparmor, you pull from master something that changes snap-confine.apparmor.in, you run spread, snap-confine.apparmor isn't regenerated
<zyga> I ran spread again locally, let's see if I can hit this
<zyga> if that were (simply) true it would fail for any profile modification and we ran into those
<jdstrand> zyga: a package reinstall could complicate things too, yes
<zyga> in any case, I'm looking, not sure what the fault is yet
<jdstrand> zyga: eg, you generate the profile, load it, then (re?)install the package
<zyga> yep, that's what roughly happens
<zyga> we build snapd, install that package
<zyga> repackage core to include that new snapd
<zyga> and then go
<zyga> and repackaged snapd conta
<zyga> oh
<zyga> :D
<zyga> maybe we don't replace this binary correctly
<jdstrand> the binary is using /usr/lib/snapd-snap-confine
<jdstrand> but the profile isn't allowing it
<zyga> hmm
<jdstrand> so there is something happening where they didn't end up in sync in the testsuite
<mborzecki> i'm off to pick up the kids
<zyga> jdstrand reproduced
<ikey> boy or girl? congrats either way
 * ikey walks out
 * Chipaca hugs ikey 
<ikey> ^^
<zyga> http://paste.ubuntu.com/p/v9rPYyH44b/
<zyga> [  477.039513] audit: type=1400 audit(1518531578.798:45): apparmor="DENIED" operation="exec" profile="/snap/core/4060/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snappy-app-dev" pid=13872 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<zyga>     /lib/udev/snappy-app-dev ixr, # drop
<zyga> this is the rule on disk (in /etc/apparmor.d/snap.core.4060.usr.lib.snapd.snap-confine)
<zyga> jdstrand I think I get it
<zyga> linode:ubuntu-16.04-32 /snap/core/current# find -name snappy-app-dev
<zyga> ./lib/udev/snappy-app-dev
<zyga> ./usr/lib/snapd/snappy-app-dev
<zyga> the repackaged core snap has this inside:     /usr/lib/snapd/snappy-app-dev ixr, # drop
<zyga> *hmm*
<zyga> one more idea
<zyga> jdstrand the preserved project state contains the stale profile
<zyga> jdstrand the tarball we create in tests
<zyga> snapd-state.tar.gz
<zyga> then snapd doesn't regenerate the profile
<zyga> I'll look at fixing this
 * kalikiana re
<zyga> https://securelist.com/zero-day-vulnerability-in-telegram/83800/ <- interesting
<jdstrand> zyga: cool, nice find
<jdstrand> zyga: this will help anyone touching the snap-confine profile :)
<mvo> zyga: thanks for finding this!
<mup> PR snapd#4660 closed: systemd: update comment on SocketsTarget <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4660>
<ogra_> jdstrand, https://forum.snapcraft.io/t/bin-sync-not-allowed/3988/1
<Nissaar> im packaging the nodejs snap 'POKEMON SHOWDOWN', here is the .aml file and the issue im facing: https://paste.ubuntu.com/p/PjV9tgDr24/
<zyga> Error: Command failed: git merge-base master HEAD
<zyga> you need to put git inside your snap
<Nissaar> uhmmm how ?
<ogra_> add a build-packages entry
<ogra_> and add git to it
<Nissaar> in 'parts' section ?
<ogra_> yes
<ogra_> https://github.com/snapcrafters has a ton of example snaps you can steal from :)
<Nissaar> like this https://paste.ubuntu.com/p/jRzqwK96rk/ ?
<jdstrand> ogra_: yes, I saw. responded
<ogra_> yeah, i saw too, thanks !
<mup> PR snapd#4652 closed: tests: fix spread test failures on 18.04 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4652>
<mup> PR snapd#4491 closed: snap: allow options for --strace, e.g. `snap run --strace="-tt"` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4491>
<Nissaar> https://paste.ubuntu.com/p/vqFY5HVxDZ/ this is my new yaml
<Nissaar> https://paste.ubuntu.com/p/mXwf4N2C8D/
<Nissaar> the error is the same
<Nissaar> i have added stage-packages: [git]] to the yaml
<mup> PR snapd#4661 opened: snap: improve `snap run` comments/naming <Created by mvo5> <https://github.com/snapcore/snapd/pull/4661>
<ogra_> Nissaar, and the snap did build fine ? no errors or anything ? (how did you create it before using "snap run" )
<ogra_> (you should theroetically not actually need build-packages: [ git ], snapcraft should care for it on its own when building)
<Nissaar> ogra: https://docs.snapcraft.io/build-snaps/node
<Nissaar> https://paste.ubuntu.com/p/vqFY5HVxDZ/
<ogra_> and there were no errors when you did build it ?
<Nissaar> used the example form the 1st link to edit the snapcraft.yaml in the 2nd one
<ogra_> yeah, the snapcraft.yaml looks basically sane (at least to build a proper node based snap from it)
<ogra_> do you have a log of the build ?
<Nissaar> ogra_: https://paste.ubuntu.com/p/25zR3JDhHY/
<Nissaar> here it is
<ogra_> ah, it seems that your snap actually uses git internally at runtime
<ogra_> change "build-packages:" to "stage-packages:"
<ogra_> re-build and it should finr git
<ogra_> *find
<Nissaar> im on it
<greyback> zyga: gentle reminder you've been asked a question in my PR: https://github.com/snapcore/snapd/pull/4545
<mup> PR #4545: interfaces/x11: allow X11 slot implementations <Created by gerboland> <https://github.com/snapcore/snapd/pull/4545>
<zyga> greyback ack, I didn't notice. that
<greyback> no worries
<zyga> I'll finish fixing master and then switch to this
<mup> PR snapd#4662 opened: tests: removing packages which are not needed anymore to generate random data <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4662>
<zyga> mvo, almost done with that fixx
 * kalikiana out for the day
<jdstrand> ogra_: hey, so twice I've seen the bbb refresh the core snap in the background and drop to a uboot shell. If I type 'reset' it boots. have you seen this?
<ogra_> nope
<ogra_> any errors ?
<jdstrand> when? before the uboot? no
<ogra_> well, yeah, on serial typically
<jdstrand> I connected serial to type 'reset'
<ogra_> "in" uboot ...
<jdstrand> there was nothing before the prompt
<ogra_> yeah, i guess serial wont show you the backlog
<jdstrand> I'm refreshing the core snap and will reboot with serial connected
<jdstrand> it'll probably work fine
<ogra_> if there was an error it would show between u-boot starting and the showing of the prompt
 * jdstrand nods
<jdstrand> ogra_: yep booted fine. that's what happened in december
<ogra_> it is very likely that the refresh failed somehow ... what i can do is to force CONFIG_RESET_TO_RETRY and "CONFIG_BOOT_RETRY_TIME  5" in the uboot build, that way it would auto-reboot after 5 sec on the uboot prompt
<jdstrand> ogra_: I guess I'll continue to keep an eye on it
<jdstrand> ogra_: that would be good
<ogra_> ... but that makes development really annoying since it will *always* reboot after 5sec ... even if you are interacting with the prompt
<jdstrand> ogra_: cuase it looked like th refresh did fail. when I 'reset' I went into an old core
<jdstrand> ogra_: 60 seconds would've been fine in this case
<zyga> mvo it turned out larger but I'm sure you will like it :)
<zyga> jdstrand and you too ;)
<zyga> :-)
<ogra_> (the question is if there are actually people developing on that level)
<jdstrand> I use this as a little armhf build machine
<jdstrand> and I went to login to it and it was down
<jdstrand> (actually, I knew it was down cause of nagios ;)
<ogra_> yeah, 60sec sounds mildly sahe
<ogra_> *sane
<jdstrand> ogra_: 300? :)
<ogra_> haha
<jdstrand> I really don't care much. if I could ssh in and debug after noticing it went down and reboot, that would work for me
<jdstrand> this happened in the middle of the night
<ogra_> for actual bootloader development people can defintely just turn it off and rebuild the gadget
<jdstrand> anyway, whatever timeout you think is good wfm
<ogra_> (the option that is)
<ogra_> yeah, i''ll add that
<jdstrand> thanks!
<ogra_> you will need a fresh install though
<ogra_> since we still dont have gadget upgrades :P
<ogra_> (or do we and i missed that ?)
<jdstrand> really? I thought we just didn't on rpi2 (and I thought that was because of lack of promotion due to the underlying issues...)(
<jdstrand> I have no idea tbh
<jdstrand> ogra_: I'm still on r1
<jdstrand> that's all there seems to be
<ogra_> me neither ... since i moved to CE i'm to busy with actual customer stuff to follow this
 * jdstrand shrugs
<jdstrand> heh
<jdstrand> well, if you upload the gadget to the store, I can try. if it blows up, I'll regenerate
<jdstrand> zyga: cool!
<ogra_> jdstrand, i'll let you know ... (not tonight anymore though ... )
<jdstrand> ogra_: sure. thanks again :)
<ogra_> well, thanks for reporting :)
<jdstrand> :)
<Chipaca> hrmph, just realised we can't go with our usuall "Noun verbed" for the 'check-snapshot' verb
<Chipaca> maybe the verb is wrong, or english is terrible :-)
<Chipaca> "Snapshot 42 checked." leaves you going "...and? what do I _have_, doctor?!?"
<Chipaca> "your blood results came back" "..." "sit down" "...?" "cuppa tea?" <dies> "no sugar then"
<kyrofa> Should that be "verify" instead?
<kyrofa> The meaning of "check" is indeed overloaded
<kyrofa> Or rather, you could be checking something for numerous reasons
<ogra_> depends on the $$$ really
<Chipaca> kyrofa: "verified" has the same problem: it tells you the verification finished, not that the snapshot was ok
<kyrofa> Hmm
<Chipaca> maybe it's the nature of the beast, and i just need to print "checked and passed" or sth
<kyrofa> Chipaca, what are you actually checking?
<Chipaca> kyrofa: my current account
<Chipaca> no, er
<Chipaca> kyrofa: it's like md5sum -c
<kyrofa> Chipaca, validated?
<Chipaca> kyrofa: if it's not valid i don't even open it
<Chipaca> :-)
<kyrofa> English is stupid
<Chipaca> if it's not valid, as in the zipfile is corrupt, or the index is corrupt, or doesn't match _its_ hash, the snapshot isn't even listed
<Chipaca> bah, there is something called 'valid' in this context, but it's more subtle, snapshots that aren't valid in the above sense are just not snapshots at all
<Chipaca> ej
<Chipaca> kyrofa: don't worry, i'm more ranting than anything
<Chipaca> or sharing the pain
<Chipaca> not strictly looking for solutions at this time
<Chipaca> (there are 110+ comments on the PR i'm working through, and this one is not one of them)
<mup> PR snapd#4663 opened: interfaces/builtin: allow MM to access login1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/4663>
<Chipaca> zyga: you around?
<zyga> yep
<Chipaca> zyga: are you running something newer than 16.04 there?
<zyga> yep
<zyga> 17.10
<zyga> I have 18.04 as well
<Chipaca> zyga: can you check if on a terminal there, ð shows up (1) double wide, and (2) counted as narrow?
<Chipaca> zyga: as opposed to æ which should show up as double-wide and counted as double-wide
<zyga> one sec
<zyga> actually
<zyga> how do I check?
 * nacc was wondering the same thing
<zyga> Chipaca I can show you and you can tell me
<Chipaca> zyga: paste it in the terminal and write an 'a'
<zyga> Chipaca in standup
<Chipaca> going ;-)
<jdstrand> davidcalle: hey, ping re https://docs.snapcraft.io/deprecation-notices/dn5
<Chipaca> so, everything is terrible in 16.04 but it gets better :)
<Chipaca> oh, zyga, was that 18.04 or 17.10?
<zyga> 17.10
<Chipaca> perfect
<Chipaca> zyga: I can _probably_ detect it at least for gnome terminal using $VTE_VERSION but I'm not at all sure I want to :-)
<zyga> mvo I pushed the rework to 4658
<zyga> if it passes I will propose it separately
<Chipaca> â¦
<zyga> jdstrand the rework includes use of ensure-dir-state to write and load the apparmor profile for snap-confine in core
<Chipaca> i can use escape sequences to find out
<Chipaca> did i want to know this
<zyga> Chipaca you can talk to the tty
<Chipaca> exactly
<zyga> as in, you can talk to the terminal emulator
<zyga> and ask it stuff
<Chipaca> yes
<zyga> not sure how much gnome vte implemented there
<Chipaca> including "how wide did you think this thing was
<Chipaca> "
<zyga> well, you can just get the cursor position
<Chipaca> yes, but reading that back is a nightmare
<zyga> why so?
<zyga> mvo, jdstrand: the new interesting bit is https://github.com/snapcore/snapd/pull/4658/files#diff-57dc34ab6f4bf9730b356d0439daa0fdR170
<mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
<Chipaca> zyga: termios black magic
<zyga> mvo and the function immediately below that
<zyga> Chipaca screw termios
<zyga> hold on
<zyga> https://invisible-island.net/xterm/ctlseqs/ctlseqs.pdf
<zyga> (I really like that pdf)
<Chipaca> zyga: i know the control sequences
<Chipaca> zyga: but to read what it echoes back, which doesn't include a newline, you need to set the terminal into raw mode + unbuffered or whatever it is, then echo the char, then read it, then set it back to cooked
<Chipaca> that's the termios bit i'd rather avoid
<Chipaca> anyway, i'll stop distracting you -- i'm not working and you are :-)
<mup> Bug #1749276 opened: Interface request: dvb <snapd-interface> <Snappy:New> <https://launchpad.net/bugs/1749276>
<mup> PR snapd#4664 opened: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
<zyga> mvo, jdstrand: https://github.com/snapcore/snapd/pull/4664
<mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
<zyga> this is the bit I cherry-picked out of 4658
<zyga> I'll break now, ttyl
<mvo> zyga: thank you
 * Chipaca wanders off to figure out dinner
<mup> PR snapd#4661 closed: snap: improve `snap run` comments/naming <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4661>
<cachio> niemeyer, hey, could you please take a look to this https://github.com/snapcore/spread/pull/50 ?
<mup> PR spread#50: Adding repeat option again <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/50>
<zyga> cachio. linde is belly up
<zyga> *linode
<cachio> zyga, yes, I am trying to reproduce those errors
<cachio> and fix them
<zyga> cachio this is linode failing
<zyga> what can you do?
<cachio> zyga, ahh, I am researching this error https://travis-ci.org/snapcore/snapd/builds/341118599#L2993
<cachio> it made fail like 5 or 6 builds today
<zyga> cachio that is not what I was talking about
<zyga> linode fails on API requests
<zyga> this bug is fixed in my PR
<zyga> https://github.com/snapcore/snapd/pull/4664
<mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
<cachio> zyga, great, I'll review it
<cachio> zyga, which error are you talking about, some networking problem?
<zyga> cannot create new VMs
<zyga> linode doesn't work :.
<zyga> :/.
<cachio> zyga, ouch
<zyga> I restarted that branch a few times and it timed out at 49 minutes
#snappy 2018-02-14
<mborzecki> morning
<mup> Bug #1749374 opened: The /bin/sync command is not allowed by default <Snappy:New> <https://launchpad.net/bugs/1749374>
<zyga> hey
<zyga> mborzecki linode was broken last night
<mborzecki> zyga: did we break it?
<zyga> I suppose so
<zyga> it stopped responding to API requests
<mborzecki> haha omg
<zyga> let's hope it's not that bad today
<mborzecki> zyga: any idea how advanced is the move to GCE or DO?
<zyga> mborzecki no, I hope it's under way though
<zyga> mborzecki are any of your branches working/
<mborzecki> zyga: don't have any new PRs open atm
<zyga> I'm running tests in linode and locally to compare
<zyga> mborzecki can you please have a look at 4664
<zyga> it is designed to unbreak master
<zyga> it came out of 4658
<zyga> I also pushed it there to show that it fixes things
<zyga> (except where linode doesn't work)
<mborzecki> looking
<zyga> I could move some of the patches out to an even smaller prerequisite branch if that helps
<kalikiana> o/
<zyga> hey kalikiana
<telboon-> hmm. is snap designed to be a fully secured container?
<zyga> it depends on what you mean by a container
<telboon-> cos i've somehow just escaped the snap and managed to create files outside of the container...i think
<zyga> snap apps are not typical containers
<telboon-> are they meant to protect the rest of the environment?
<zyga> it depends
<zyga> it all depends on how you installed the snap, which interfaces you connected to it and what the "outside of the container" really is
<zyga> please tell me more and I will try to help you
<zyga> if you think this is a security issue you can contact me in private
<zyga> or send me an encrypted mail
<zyga> telboon- let me know if you need more information
<telboon-> zyga: let me try to reproduce it in a few scenarios
<zyga> + tar -C/ -xf /home/gopath/src/github.com/snapcore/snapd/snapd-state.tar.gz
<zyga> <kill-timeout reached>
<zyga> hmm :/
<zyga> I see this often but on random tests
<Chipaca> with all the verbosity in tests, maybe we should add a -v to that tar :-)
<zyga> -vv
<zyga> --poem
<mvo> zyga: quick question, how far are user mounts away (roughly)? days? weeks?
<zyga> mvo days
<zyga> mvo but unhappy master is making stuff sad
<zyga> or is it just my branch?
<zyga> hey mvo, how are you doing?
<mvo> zyga: I'm fine thank you
<mvo> zyga: yeah, unhappy master makes me unhappy too
<mvo> zyga: what error do you see? I also see some strange errors
<zyga> timeouts
<zyga> but not the ones we saw before
<zyga> I see tests reaching 49 minutes
<zyga> many linode api errors
<zyga> errors on tar (see above) being killed by timeout
<zyga> honestly, I don't know what's wrong
<zyga> mvo I ran my branch in qemu all the way (though not without hiccups)
<mvo> zyga: ok
<zyga> but my record on linode is "red since yesterday"
<zyga> maybe something is related to nfs, I need to look at that
<zyga> + umount /home
<zyga> umount.nfs: /home: device is busy
<zyga> 2018-02-14 08:26:18 Error restoring linode:ubuntu-16.04-64:tests/main/nfs-support :
<zyga> we cannot unmount nfs, then we cannot remove the nfs kernel server package
<Chipaca> zyga: and you can't umount home because that's where spread's running
<Chipaca> zyga: chroot time?
<Chipaca> would that even work
<zyga> Chipaca this is not a new test
<zyga> look at main/nfs-support
<Chipaca> zyga: i see it, but i still wonder it works
<Chipaca> zyga: does it hang every time with your changes?
<zyga> no
<Chipaca> ah drat :-)
<zyga> yeah
<zyga> so something else depends on ordering
<Chipaca> zyga: does it hang every time if you specify the seed of the time it hung?
<zyga> maybe my patch is just broken
<zyga> I didn't try (~~ hours)
<zyga> let's see
<Chipaca> zyga: if it's reproducible, you can figure out what's holding it back
<Chipaca> zyga: OTOH if it works with any subdir instead of just home, maybe use a subdir in the tests, one that isn't being used by the tests :-)
<Chipaca> (but if it works sometimes, maybe figuring out what blocks it when it doesn't is better)
<zyga> the unmount earlier should not have failed
<zyga> some process is lurking
<zyga> but
<zyga> this is just one of the failure
<zyga> *failures
<mwhudson> does anyone here have any Opinions on go 1.9 vs go 1.10 as default in bionic?
<zyga> mwhudson I suspect 1.10 is just a bit younger so it will be EOLd later
<zyga> mwhudson does go have LTS-like releases?
<pedronis> no
<mwhudson> right, that's certainly a consideration, and no
<pedronis> it's why we should really think how to use newer go
<pedronis> for snapd, at some point it will bite us
<zyga> using new go is easy, using new go everywhere is hard
<zyga> changing base requirement is hard
<mborzecki> it will have to happen at some point though
 * zyga reproduced nfs error with debug shell
<zyga> inspecting
<zyga> hmmmmmm
<zyga> so, I have a suspicion
<zyga> it is actually related to nfs
<zyga> my code was too optimistic
<zyga> and it's failing
<zyga> when the nfs aspect changes the code won't load the profile
<zyga> the reexec profile handling code needs to be nfs aware
<zyga> hmm hmmm
<zyga> (that came out wrong, it's more subtle)
<zyga> I'm running another run with extra logging
<zyga> mvo can you look at 4664 since you wrote the original code there
<mvo> zyga: ok
<mvo> zyga: debugging a thorny test fialure right now, will do once that is done
<mvo> zyga: silly question, what was broken in the old one?
<ikey> zyga, jdstrand https://youtu.be/faqQuJkqCIA?t=584 or "why steam snap is threatened"
<zyga> mvo the old one was happy with stale file on disk
<zyga> mvo as long as it was present it would say, yeah fine
<mvo> zyga: how could the file be stale? it was rewriten on a new core release and once written the core template never changes?
<zyga> mvo because our test code tarballed the state
<zyga> and it contained the old one after fresh core install
<zyga> then we repackage core and things go down from there
<mvo> zyga: could we just exclude this file from the saved state in the tests? would that re-generate it ?
<zyga> yes
<zyga> though I would really prefer a properly working generator
<zyga> I *think* I fixed it now, testing locally
<zyga> well, I suspect I know what the problem was, now I'm thinking about how to solve it in a non-hackish way
<mvo> zyga: sure, was mostly trying to understand it (and also thinking YAGNI a bit). I have a look in a wee bit
<zyga> mvo the new code is conceptually easier to grok IMO, just the bugging aspect of apparmor nfs
<zyga> thanks!
<mvo> heh, ok - if it really is easier I will shut up and hug you
<zyga> yes, just now we see why the old code worked in more cases :)
<zyga> it always reloaded
<zyga> mvo I also found a subtle error escaping due to error mishandling
<zyga> but nothing serious
<zyga> https://github.com/snapcore/snapd/pull/4664/files#diff-57dc34ab6f4bf9730b356d0439daa0fdL208
<mup> PR #4664: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <https://github.com/snapcore/snapd/pull/4664>
<zyga> if err is an error (but not ENOENT) it will be ignored
<mvo> zyga: nice catch
<zyga> whee
<zyga> ok works
<mup> PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
<zyga> uh
<zyga> I hit wrong key and suspended my VM
<Chipaca> ogra_: I blame you ^
<Chipaca> making me look at code
 * ogra_ makes note to cash in bonus for that 
<popey> zyga: what was the outcome yesterday of the opensuse conversation, I may have missed it. Are we likely to get an update over there soon?
<zyga> popey not sure, there's a community member that works on packaging snapd for factory
<zyga> I reached out to him and invited him to join us here
<zyga> mvo: https://github.com/snapcore/snapd/pull/4658/commits/0a0a3faa4e0b7f6ef5fdda907870924668523625
<mup> PR #4658: many: don't allow layout construction to silently fail <Created by zyga> <https://github.com/snapcore/snapd/pull/4658>
<zyga> popey I',m "not sure" because it can also mean that the update will take a while and will hit opensuse properly
<zyga> I think someone should still look at the "PPA"
<mup> PR snapd#4666 opened: interfaces/apparmor: generalize apparmor load and unload helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4666>
<mvo> zyga: reviewed and agreed, its conceptually simpler
<ikey> OK looking for some details please, because finding out the true roadmap is a somewhat opaque thing..
<ikey> 1) How far away is actual complete desktop integration (theming, etc.)
<ikey> 2) What is the current holdup with apparmor changes to unblock steam-support?
<pedronis> ikey: afaiu from the forum  jdstrand was waiting on input from Gustavo about 2
<ikey> Ok ty
<ikey> In that case I'm removing snapd integration from the roadmap for Solus 4
<ikey> We were meant to be releasing in january and this snapd debacle has had me held up for months now
<ikey> I've lost too much time on this
<ikey> I can't support crippling of our own cadence to match that of Ubuntu
<mvo> ikey: theming and all that is pretty close (zyga will know the details but my understanding is that most of things needed to make it work have landed now)
<pedronis> ikey: afaiu our deadline its +-  beginning of march
<zyga> mvo theming is now open for business but it's just getting started on the actual theme snaps
<ikey> Would be nice if that had been communicated ahead of time to others, thats what I mean about opaque
<ikey> I'm flying blind on the outsides here
<ikey> But I believe it safe to say that snapd isn't completely ready yet for the desktop
<zyga> ikey theming will be in 18.04 for sure but it's not here now
<ikey> Right, an Ubuntu target
<zyga> well, more less a deadline for us to reach, many things are in progress
<pedronis> I didn't even know you were waiting on us, so I'm probably the wrong person to chime in either way
<ikey> pedronis, several months now
<zyga> ikey I agree that themes are a known missing feature
<niemeyer> ikey: We are late on it ourselves.. and it's not because we are bound to Ubuntu, but because it takes time to develop.. zyga has been working on mounts since forever
<ikey> It's taken so long that the flatpak/collabora camp are now developing their own version of what I've been blocked on
<ikey> Which to be blunt is crippling my own value-add
<ikey> By putting all my eggs in one basket
<ikey> At this point waiting on snapd is affecting business decisions in Solus, and I can't allow that to continue
<ikey> (I know, its the word we don't like to use)
<ikey> But that is the reality
<ikey> So I'll defer snapd integration until such point as its suitable and remove it from the Solus 4 roadmap
<ikey> As we're way overdue
<ikey> Then we can revisit it around the time of 18.04
<niemeyer> ikey: It's okay, by the end of the day you know your own priorities much better than anybody else.. we'll continue to be here pushing things forward if you change your mind
<ikey> niemeyer, ? im not sure you get it. ive been contributing and my own work has been repeatedly blocked. its not like my mind needs changing
<ikey> the platform isn't ready, im blocked on what i need to do for months, and i cant allow it to continue blocking the release
<niemeyer> ikey: I totally get it.. our own work gets blocked all the time too.. the more interesting a project becomes the harder it is to make everybody happy about the pace that things move on..
<ikey> niemeyer, thats great - but you know whats going on, us poor mortals on the outside do not
<ikey> and snapd's interests are clearly aligned with Ubuntu and hasn't got to compete
<zyga> ikey we'll get the desktop bits implemented and will gladly have you use snaps more in solus when you feel they meet your goals
<niemeyer> ikey: We've been giving you and Solus a fair share of our attention, and we appreciate having you with us, but apparently we still cannot make things work for you as fast as you need
<ikey> niemeyer, again its not about speed, its a failure in communication
<ikey> repeatedly stone walled and left in the dark
<niemeyer> ikey: That's not what I hear above
<ikey> I'd appreciate it if you stopped turning this around to put yourself on the moral highground
<niemeyer> 2) What is the current holdup with apparmor changes to unblock steam-support?
<niemeyer> 08:44:30
<niemeyer> <pedronis> Samuele Pedroni ikey: afaiu from the forum  jdstrand was waiting on input from Gustavo about 2
<niemeyer> 08:45:00
<niemeyer> <ikey> ufee1dead Ok ty
<niemeyer> 08:45:08 In that case I'm removing snapd integration from the roadmap for Solus 4
<ikey> niemeyer, because again failure to communicate
<ikey> i shouldnt have to be meekly asking every week
<ikey> and more often times than not, ignored
<ikey> Communication is the core problem
<niemeyer> ikey: I've been on holiday because it's been Carnival in Brazil.. I'm not actually sorry for spending some of my time with my family :)
<zyga> ikey ok, what would you have us change to make things better on communication?
<ikey> niemeyer, dude, jesus christ
<ikey> stop with the guilt trips and making it about you
<niemeyer> ikey: Yes, sort of related to jesus christ
<ikey> fuckin hell
<ikey> ill talk to zyga
<ikey> zyga, probably not have niemeyer interjecting with childish remarks would be a good start
<ikey> As I said in the past, just being kept in the loop would be enough
<ikey> Knowing how things are going and the future goals, how things are progressing, is entirely enough
<ikey> Then folks external to Ubuntu know how to plan appropriately
<ikey> It really is that simple
<ikey> And doesn't require the drama that niemeyer is trying to stir
<zyga> do you think a periodic (say weekly) update on the roadmap, blockers and similar things, in written form would be sufficient to convey this information
<ikey> Yeah eow update sounds perfect
<zyga> I think we have a few things going on but they are probably not coordinated with each other (some newsletters, some forum posts, etc)
<ikey> Like I wanna be perfectly clear here, I did *not* say I was removing snapd from Solus (so the overreaction was completely unwarranted) - I said i was removing snapd *integration* from the Solus 4 roadmap
<ikey> i.e. inclusion in the software center, promoting of default snaps
<niemeyer> :)
<ikey> Frankly I'm shocked at the immediate hostility
<zyga> I agree that communication is hard and it's probably most evident for people that don't participate in daily standups where everyone shares their progress and priorities
<ikey> zyga, i totally get it though, ive been in similar situations, when we had to liase with green-badges at intel
<ikey> so its not a blame game
<ikey> just saying that those of us outside the core circle aren't always abreast of targets/goals
<ikey> Thus in the interest of future work, that would be much appreciated and helpful
<mvo> ikey: thanks for sharing this with us, I know it sounds cliche but it is important feedback. I personally had the feeling that we get the communication right (now that we have the forum and there is a lot of buzz there). so its good to get corrected on that view
<zyga> right, I think we should advertise our roadmap and updates more, maybe we could start a recurring update forum post (written by everyone hacking on snapd) and collectively sent/shared every week
<ikey> yeah i mean i dont think it needs to be overly formal, you just need to expose the pulse, if that makes sense
<mvo> ikey: just to double check that I get this correctly - the main problem was e.g. that "theme support" was on the roadmap but no clear times/dates attached and not clear if/how much progress was happening(?)
<mvo> (so for the things you cared about the sense of "where are we" was missing?)
<ikey> mvo, so in a nut shell yeah, aware of items drifting on the horizon for some length of time, but we dont know where they are or when they come or whats stopping them
 * mvo nods
<ikey> the other important aspect for that is you provide a point for newcomers to the project who want to onboard and contribute
<ikey> they see the blockers and have something to work on
<ikey> wait for the cringe: virtuous cycle of growth
<niemeyer> ikey: We did report recently about the desktop progress: https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510
<mvo> ikey: thats a good one too, I wonder if the forum and a pinned topic would help with that. I personally find this apsect (good newcomer tasks one of the hardest)
 * mvo messed up the () above, clearly needs to do more lisp
<ikey> niemeyer, if you think im going to talk to you now you're very much mistaken, you're one of the core issues with this project
<zyga> mvo I think pinning might be the key, we have lots of discussions now (because the forum is quite successful) and it's hard to find the essential news in summarized form
<ikey> once you correct your attitude I'll recommence communications
<mvo> zyga: yeah, thats a good point, the front-page scrolls by super fast
<ikey> zyga, most topics with tag would last a week in the scroll i think?
<ikey> like you might need to click the tag first to filter
<mvo> zyga: or maybe more categories, but not sure if that would help and now discoverable this actually is
<zyga> I don't know the technical forum answer yet, we need to experiment and see how it looks like
<zyga> I understand the forum page is personalised so it might need testing in a private browser session
<ikey> oh right
<ikey> TIL. :)
<niemeyer> ikey: That will make collaboration a bit harder.. :)
<ikey> pot calling the kettle black
<ikey> Anyway, I'm gonna take my leave for now, because I really can't be in the same room as him right now.
<ikey> Hope I've provided enough details on the report thing
<ikey> Like I said, only removing the target for snapd *integration*
<ikey> not snapd itself
<ikey> Besides, I made aa-lsm-hook, not removing apparmor now :P
 * Chipaca hugs ikey 
<Chipaca> ikey: thank you, and sorry, and â¦ stuff
<ikey> Chipaca, pfft dont be. you're awesome
<Chipaca> ikey: "sorry for not being awesomer" sounds like a lame non-apology
<ikey> lol
<Chipaca> ikey: to be clear, thank you for speaking up and not just going off in a huff
<Chipaca> that's hard to do and i appreciate it a lot
<Chipaca> ikey: and sorry that you had to do so, we like to think we're better than this and need reminding every so often
<ikey> bit hard to cross back over the river when the bridge is in flames :)
 * Chipaca brings out the marshmallows
<ikey> Chipaca, well i always look at these things as a way to refresh the path forward tbh
 * Chipaca brings out the marshmallow rpg
<ikey> like, ok now we know such and such doesn't happen now, revisit it then, and correct stuff in the meantime
<ikey> too old and hairy now for drama
<zyga> mborzecki can you please look at https://travis-ci.org/snapcore/snapd/builds/341366071?utm_source=github_status&utm_medium=notification
<mborzecki> looking
<zyga> one test failed there
<zyga> doesn't look related to the change
<mborzecki> hmm, w8, how does it pass on master?
<zyga> what do you mean?
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/4654 stops the timer in prepare
<mup> PR #4654: tests/lib/prepare: disable snapd.refresh.timer <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4654>
<zyga> maybe we are running tests of the branch, not of the merged result
<zyga> (that would be an interesting find)
<mborzecki> iirc that's what travis does by default
<zyga> that == merged or just branch?
<mborzecki> branch
<mborzecki> anyways, that test was there before right?
<zyga> yes
<mborzecki> right, so 4654 travis job was ok, some master jobs after that PR was merged were fine too, so why does it fail now?
<zyga> yeah, I don't know that
<mborzecki> clearly it will file if the timer is stopped
<mborzecki> so somehow it must be started again :/
<zyga> + test -f /usr/share/dbus-1/services/io.snapcraft.Launcher.service
<zyga> + diff -u /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig /usr/share/dbus-1/services/io.snapcraft.Launcher.service
<zyga> --- /usr/share/dbus-1/services/io.snapcraft.Launcher.service.orig	2017-12-18 14:41:33.000000000 +0000
<zyga> +++ /usr/share/dbus-1/services/io.snapcraft.Launcher.service	2018-02-13 16:57:31.000000000 +0000
<zyga> @@ -1,3 +1,4 @@
<zyga>  [D-BUS Service]
<zyga>  Name=io.snapcraft.Launcher
<zyga>  Exec=/usr/bin/snap userd
<zyga> +AssumedAppArmorLabel=unconfined
<zyga> -----
<zyga> I have a feeling that our prepare restore code is buggy
<Chipaca> mvo: tweaked the system-shutdown sync comment, see what you think
<Chipaca> might be getting a little rambly
<zyga> + snap install test-snapd-control-consumer
<zyga> error: cannot install "test-snapd-control-consumer": cannot get nonce from
<zyga>        store: store server returned status 418
<zyga> that's the teapot, right Chipaca ?
<Chipaca> yes
<Chipaca> mup, what's http status 418
<mup> Chipaca: In-com-pre-hen-si-ble-ness.
<Chipaca> zyga: se?
<Chipaca> zyga: see?
<zyga> thanks
<mvo> Chipaca: thanks, comment looks fine
<mup> PR snapd#4662 closed: tests: removing packages which are not needed anymore to generate random data <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4662>
<Son_Goku> [06:16:41 AM]  <Chipaca>	ikey: thank you, and sorry, and â¦ stuff
<Son_Goku> did I miss an emotional moment or something?
<ikey> we hugged
<ikey> :3
<Chipaca> Son_Goku: ikey called us out on stuff we thought we were better at than we are
<Son_Goku> Chipaca: I just don't bother anymore
<Chipaca> Son_Goku: you're just wanting a hug too
 * Chipaca hugs Son_Goku 
<Son_Goku> aww
 * Son_Goku hugs Chipaca back
<ikey> o wait its valentines day
<ikey> not to make the hugs awkward or anything
<Son_Goku> Yeerp
<ikey> .. :D
<Son_Goku> :D
 * zyga would pour some vodka but then again this is IRC
<Son_Goku> I stay the _hell_ away from your vodka
<ikey> yeah you can only have 512 of the vodka
<zyga> haha
<Son_Goku> but yeah, these days, I don't really know whats going on with the features for snappy that I need to accomplish my objectives
<Son_Goku> unlike ikey though, I don't have the time to dig into everything all the time
<Son_Goku> so I just kinda let it go and hope something comes up to give me a better picture later
<Son_Goku> I've barely had _any_ time to work on the RPM backend for snapcraft
<Son_Goku> which I already know requires me to implement some functionality in DNF to make things a little less stupid
<zyga> Son_Goku btw, offtopic. hurricanehrndz is idle for about a month (on irc), is that the right nickname?
<Son_Goku> I think that's the right nick
<Son_Goku> worst case, I'll probably do some work myself on the openSUSE packaging
<mup> PR snapd#4664 closed: interfaces/apparmor: ensure snap-confine profile for reexec is current <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4664>
<mup> PR snapd#4666 closed: interfaces/apparmor: generalize apparmor load and unload helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4666>
<Son_Goku> zyga, but at least from a fedora point of view, the main things I want to see is *some* effort towards a selinux backend for snap-confine
<Son_Goku> it doesn't even have to involve code
<Son_Goku> just at least discussions with selinux developers to figure out gaps and how to close them, if any
<Son_Goku> and of course, a way to swap core snaps for building a modular Fedora system built on snaps
<zyga> that 2nd thing may come out of base/core 18 work where things will force us to move snapd out of core
<zyga> or out of the "one" nap
<zyga> *snap
<zyga> naming things aside
<zyga> 1st thing is something I just don't have time to work on, I agree it is interesting and would like to see that started eventually
<niemeyer> mborzecki: Replied in the timer conversation
<mborzecki> niemeyer: thanks
 * zyga switches focus to user mounts for the rest of the day
<zyga> and takes a break to relieve back pain
 * kalikiana going for a brief break
 * Chipaca -> lunch
<mup> PR snapcraft#1925 opened: elf: cache crawled files <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1925>
<mup> PR snapcraft#1922 closed: elf: fast track when the host used matches the base <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1922>
<pedronis> I'm getting this:  Cannot allocate linode:ubuntu-16.04-64: cannot boot linode:ubuntu-16.04-64 (Spread-5941868): missing or incomplete Linode startup profile.  Contact Linode support.
<jdstrand> ikey: for my part, sorry steam-support dragged a bit. honestly, I didn't know it was a blocker for solus 3, but I'm going to keep working at it. also, fwiw, I thought you were saying you were dropping snapd too so glad to hear you are keeping that and apparmor :)
<mup> PR snapd#4658 closed: many: don't allow layout construction to silently fail <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4658>
 * kalikiana lunch
<pedronis> mvo: let me if IÂ can help with that issue, IÂ also noticed that I replicated the issue in my new branch about the new api
<mvo> pedronis: thanks, I will prepare a PR and ask you for a review (with appropriate comments)
<mup> PR snapd#4667 opened: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4667>
<koza> pedronis, hey, quick question: assuming eth cables are plugged in and internet is available can I be sure that prepare-device hook runs after the networking connection is established or there is a race?
<pedronis> koza: I don't know in general, prepare-device will be retried though if needed
<koza> pedronis, i know just want to make sure if i can safely assume it runs with networking *if* is available at the time of boot and properly configured
<mborzecki> zyga: 4667 should address the failure in tests/main/ubuntu-core-services you were seeeing
<pedronis> koza: I don't know, that seems related to the systemd services setup,  mvo might know more about that
<koza> pedronis, mvo, ^^ and what has to happen for prepare-device to be retried; do i remember rightly it will happen when the Initialize Device stage is failed?
<pedronis> koza: yes,  also if prepare-device itself fails
<koza> pedronis, got it, thanks
<mvo> koza: we just use "WatnedBy=multi-user.target", so no gurantee other than that
<mvo> koza: i.e. we do not have anything like after=network of network-online.target
<koza> mvo, right, understood; but one could rely on retry and wait for net to be up in case there is a race between these two
 * kalikiana re
<mup> PR snapd#4668 opened: store: revert PR#4532 and do not display displayname <Created by mvo5> <https://github.com/snapcore/snapd/pull/4668>
<mborzecki> off to pick up the kids
<alexlarsson> zyga: when referring to snap in writing, what do i use "snap", "snappy"?
<popey> alexlarsson: we tend not to use "snappy"  so much, snap and snapcraft are more widely used
 * popey realises he is saying that in #snappy
<zyga> alexlarsson hmmm
<zyga> I try to say "snapd" because snappy is a compression format and snap typically a file
<zyga> alexlarsson it also depends on what you are writing about, snap packages are "snap" but it is "snapd" who manages them
<popey> (and snapcraft [generally] that makes them)
<alexlarsson> more like refering to the project/organization/people
<alexlarsson> "snap wants to use portals"
<popey> "the snap developers want to use portals"
<zyga> I would say "snapd integrates with portals" and "snap packages can use portals"
<alexlarsson> ok, cool
<popey> niemeyer: we have a new user on the forum who is going to post a call for testing of their snap. They will get anti-spam blocked linking to their issue tracker. Can you help?
<popey> (I am pre-emptively asking because I know this will happen)
<zyga> Chipaca 4669 is trivial and I think you wrote the original
<zyga> or perhaps mvo
 * zyga knows how to gather reviewers ;-)
<mup> PR snapd#4669 opened: osutil: reimplement IsMounted with LoadMountInfo <Created by zyga> <https://github.com/snapcore/snapd/pull/4669>
<Chipaca> zyga: mountSuite does the mocking of proc/mounts?
<Chipaca> or whatever it was :-)
<Chipaca> ah tere it is
<zyga> re
<zyga> Chipaca, no, there's mocking in each function
<niemeyer> popey: Yeah, happy to help
<niemeyer> popey: In general I tend to respond to such blocks quickly if it's during my day
<niemeyer> popey: But please feel free to ping here or on Telegram when necessary
<popey> niemeyer: will do
<niemeyer> popey: I just approved a different one moments ago coincidentally, which was responding to a request for version
<niemeyer> popey: Not sure why it triggered the anti spam.. too many pre blocks?
<popey> Excellent. :)
<mvo> zyga: heh
<zyga> Chipaca, mvo: another part of the per-user mount split: https://github.com/snapcore/snapd/pull/4670
<mup> PR #4670: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
<zyga> trivial 34 additions PR
<mup> PR snapd#4670 opened: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
<mvo> zyga: in a meeting right now
 * zyga nods
<zyga> jdstrand quick ack on https://github.com/snapcore/snapd/pull/4670
<mup> PR #4670: interfaces/mount: add support for per-user mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/4670>
<zyga> jdstrand I'll reduce the per-user branch to the most essential (hard) changes today
<mup> PR snapd#4667 closed: tests/main/ubuntu-core-services: enable snapd.refresh.timer for the test <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4667>
<zyga> Chipaca can you please merge master into https://github.com/snapcore/snapd/pull/4665
<mup> PR #4665: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
<zyga> (or rebase since it's so tiny)
<mup> Bug #1749538 opened: refresh time docs lacks the correct command <docs> <Snappy:New> <https://launchpad.net/bugs/1749538>
<jdstrand> zyga: ack
<mup> PR snapd#4669 closed: osutil: reimplement IsMounted with LoadMountInfo <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4669>
<zyga> hmmm
<zyga> https://travis-ci.org/snapcore/snapd/builds/341459647?utm_source=github_status&utm_medium=notification
<zyga> It says "We couldn't find the repository snapcore/snapd"
<mborzecki> zyga: restart the job?
<zyga> look at that page
<zyga> there's no link for that
<zyga> in fact
<zyga> it looks like all travis jobs are broken
<zyga> cachio ^
<zyga> man
<zyga> this feels like a time to EOD and take a break
<cachio> zyga, let me take a lokk
<zyga> mvo ^ (in case you were hoping for releases)
<kalikiana> bah. what is it with containers and networking that it works perfectly but also doesn't
<mborzecki> zyga: refreshed now and the job page is there
<zyga> same here
<mborzecki> zyga: also restarted the build, seems like github failed this time :/
<kalikiana> I guess I'll have something to investigate tomorrow morning
<zyga> broken travis?
<zyga> mborzecki can you look at 4670
<zyga> it's trivial and blocks other bits
<cachio> zyga, travis is a caos
<zyga> caos?
<cachio> chaos
<zyga> cacaos :)
<cachio> hehehe
<cachio> zyga, I still cant run tests on linode
<cachio> from localhost
<zyga> no? what happens
<zyga> I ran some this morning
<mborzecki> tried to something here ~3pm, didn't work either
<mborzecki> i was getting: '2018-02-14 14:59:29 Cannot allocate linode:ubuntu-core-16-64: cannot decode Linode response (status 200): json: cannot unmarshal string into Go struct field linodeServerData.PLANID of type int', a change in linode's API?
<cachio> mborzecki, I see errors from linode
<cachio> mborzecki, yes
<cachio> that
<zyga> eh :/
<zyga> thank you for the feedback Chipaca!
<mup> PR snapd#4665 closed: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4665>
<mup> PR snapd#4665 opened: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <https://github.com/snapcore/snapd/pull/4665>
<zyga> Chipaca fixed
 * zyga heads for some food
<zyga> ttyl
<mup> PR snapd#4665 closed: cmd/system-shutdown: move sync to be even more pessimistic <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4665>
<mup> PR snapd#4671 opened: tests: adding new test to validate the raw-usb interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4671>
<Oooohboy> hello all, I'm getting what looks to be a permissions issue when running snapcraft. "Can't drop privileges for downloading as file"
<Oooohboy> anyone have any links or anything to general troubleshooting docs on snapcraft? This is probably user error here, but I've tried sudo and sudo -H
<nacc> Oooohboy: you don't generallly want to be root to buildl a snap
<nacc> Oooohboy: can you pastebin your exact command and output?
<Oooohboy> https://pastebin.com/DnFdGfxt
<Oooohboy> should be everything needed there I think
<nacc> Oooohboy: do you possibly have a ppa on your system that doensn't work?
<nacc> Oooohboy: ppa.launchpad.net_tista_adapta_ubuntu_dists_artful_
<Oooohboy> nacc: yes
<Oooohboy> nacc: well, I think it works...
<nacc> Oooohboy: sorry, i'm not sure then; i'd wait till a snapcraft dev is arounnd
<Oooohboy> nacc: thanks for looking. As this is my first snap I was sure it was something I was/am doing wrong
<kyrofa> Oooohboy, have you tried without sudo?
<Oooohboy> kyrofa: yeah sorry heres that paste https://pastebin.com/YRiWqasy
<kyrofa> Oooohboy, I suspect things are owned as root now in that dir. Try blowing away the snapcraft cache in `/home/sbrady/.cache/snapcraft` and trying again (without sudo)
<mup> PR snapd#4672 opened: tests: adding test for removable-media interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4672>
 * cachio afk
<Oooohboy> kyrofa: thanks for looking...did that, same issue...apt-get update and upgrade are working fine https://pastebin.com/4stUYuGR
<kyrofa> Oooohboy, note that stage-packages don't use `apt-get` directly
<Oooohboy> ok
<kyrofa> That's not actually the same error... something is segfaulting
<kyrofa> Oooohboy, can I see the output of `snap version` please?
<Oooohboy> https://pastebin.com/HkFZRcXR
<mup> PR snapcraft#1924 closed: schema: update version regex <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1924>
<kyrofa> Hmm, 17.10, I've not tried that recently
<mup> PR snapd#4670 closed: interfaces/mount: add support for per-user mount entries <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4670>
<mup> PR snapd#4673 opened: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
<zyga> jamesh, I'm chopping your user-mounts branch into pieces, I will merge master into the main branch until it reduces to an empty diff
<zyga> this way it will get in faster as smaller pieces are easier to iterate on
<zyga> I'm going to bed, talk you tomorrow!
#snappy 2018-02-15
<mup> PR snapcraft#1925 closed: elf: cache crawled files <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1925>
<mup> PR snapcraft#1923 closed: mypy: update to 0.560 <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1923>
<mborzecki> morning
<zyga> hey hey
<mborzecki> zyga: hey
<zyga> darn tests
<zyga> I wish someone would go through the prepare/restore process and made restore really purge stuff
<zyga> and made prepare install a cached copy of core
<zyga> it feels like tests are leaking all the time
<zyga> leaving junk around
<mborzecki> ideally take a snapshot of filesystem before the test, restore after the test, don't know if there are tools to do that
<zyga> mborzecki that's also interesting, yeah
<zyga> but in all honesty, purge would be a simple approach that ought to mostly work
<zyga> I worry about random places less than about our essential files
<zyga> I will do an experiment, I have some old branches that did full caching of all the snaps used for testing
<zyga> but I can simplify that to just one snap (core) and purge+install package, install core
<zyga> I really don't like how prepare and restore are swapped in our setup
<zyga> where restore prepares
<zyga> and prepare does nothing much
<mvo> zyga: hey, good morning! whats up?
<zyga> hey
<zyga> nothing major so far, just me being grumpy about tests that clearly run in some corrupted state
<zyga> I'm doing code reviews
<mvo> zyga: aha, so master is in un-happy land?
<mvo> zyga: at random times
<mvo> ?
<zyga> I think master is fine but our test suite is not perfect
<zyga> I tried to fix it a few times but without major success, I'll try to push forward slightly today
<mvo> ok
<zyga> mvo https://github.com/snapcore/snapd/pull/4600 needs deconflicting
<mup> PR #4600: configstate: validate known core.* options <Created by mvo5> <https://github.com/snapcore/snapd/pull/4600>
<mvo> zyga: it needs a +1 from niemeyer about the concept
<mvo> zyga: I mean, its not clear that we want this (and if so in what way)
<mvo> zyga: (I personally think so but thats just me :)
<zyga> mborzecki https://github.com/snapcore/snapd/pull/4571 has unaddressed comments but could land shortly
<mup> PR #4571: data, cmd, packaging: use autotools to generate artifacts under data <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4571>
<mborzecki> zyga: i'll be coming back to it once i'm done with timer services
<mborzecki> mvo: morning
<zyga> thank you!
<mvo> hey mborzecki, good morning! how are you?
<mborzecki> mvo: grumpy, found a bug in timer schedules :)
<zyga> oh? :)
<mvo> mborzecki: meeeh, but better you than our users. how bad is it? (2.31.1 material?)
<mborzecki> eg. mon1-tue2,10:00-12:00 is a window 10 to 12, from 1st monday to the 2nd tuesday, well it doesn't work this way, it skips wednesday to sunday :/
 * mvo nods
<mvo> mborzecki: is there a fix yet? and if so, how invasive is it?
<mborzecki> mvo: still looking into it
<mvo> mborzecki: ok, keep me updated please
<zyga> mvo is trivial if you want to look https://github.com/snapcore/snapd/pull/4673 :-)
<mup> PR #4673: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
<zyga> (this is chopped from the user mounts PR)
<mvo> zyga: ok
<kalikiana> good morning
 * zyga -> afk for 40 minutes
<mup> PR snapd#4668 closed: store: revert PR#4532 and do not display displayname <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4668>
<mup> PR snapd#4674 opened: packaging: fix build on sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/4674>
<Chipaca> moin moin
<Chipaca> did somebody pull the plug on the dc?
<Chipaca> JamieBennett: mvo: I can't access anything in the dc. Is my ISP sucking at its job, or is it everybody? this thing thinks it's up: https://down.com/?q=https%3A%2F%2Fsnapcraft.io
<JamieBennett> snapcraft.io is up for me
<mvo> Chipaca: I can log into people.c.c so its not fully down
<zyga> hey Chipaca
<zyga> Chipaca works for me
<zyga> Chipaca want to VPN through my network? ;-)
<zyga> Chipaca thanks for the review yesterday
<zyga> I addressed all of those and merged that one
<Chipaca> looks like it's the vpn that's crashed
<Chipaca> turned that off and i'm in
<zyga> Chipaca can I quickly drag you into another review?
<zyga> builds on the mount spec change for user mount entries
<zyga> this time the mount backend spits out a new file based on those
<zyga> very mechanic and shorty
<zyga> *short
<Chipaca> zyga: mostly (late) in the town hall
<Chipaca> zyga: but sure
<zyga> https://github.com/snapcore/snapd/pull/4673/files :-)
<mup> PR #4673: interfaces/mount: generate per-user mount profiles <Created by zyga> <https://github.com/snapcore/snapd/pull/4673>
<zyga> thank you!
<Chipaca> zyga: duuuude
<zyga> hmm?
<Chipaca> zyga: two chunks of code that are exactly the same
<zyga> aaaaw, ok
<zyga> I'll dedupe it :)
<zyga> thanks for pointing that out
<Chipaca> zyga: you don't even need a helper, just a loop
<zyga> Chipaca pushed, I opted to do a helper in the end, have a look
<Chipaca> yeah, the fstab vs user-fstab would've made the loop clunky i guess
<Chipaca> at least without a big refactor :-)
<zyga> thanks John
<mborzecki> mvo: one fix for schedules comint up shortly
<mborzecki> what an annoying edge case though
<zyga> hmm
<zyga> + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc
<mup> PR snapd#4675 opened: timeutil: fix scheduling on nth weekday of the month <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4675>
<zyga> I'm wondering if we have anew problem
<zyga> or if I broke it somehow (but unlikely since this PR is about mounts)
<mborzecki> zyga: what's the problem?
<zyga> + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc
<zyga> hwclock: Unable to connect to audit system
<zyga> hmm
<zyga> look at https://api.travis-ci.org/v3/job/341809848/log.txt
<zyga> I bet this is not related to my PR
<zyga> and it is a genuine problem elsewhere
 * mvo hugs mborzecki
<mborzecki> zyga: seccomp?
<zyga> yes, this is seccomp for sure
<zyga> the bad system call thing is
<zyga> the one about audit is more curious
<zyga> looks like apparmor
<zyga> which would be "bugs all over the place"
<zyga> hmm hmm but the same debug log below shows no seccomp or apparmor issues
<zyga> broken log?
<mborzecki> zyga: there are no denials from apparmor though :?
<mborzecki> zyga: what if the rtc does not work in those vms?
<zyga> this test didn't fail before
<mborzecki> zyga: or /dev/rtc is not a device node, showing would be useful
<Chipaca> ooooh, my new keyboard arrived \o/
<mvo> speaking of strange errors - https://travis-ci.org/snapcore/snapd/branches shows 2.31 broken in spectacular ways that do not make any sense at all :/
<zyga> Chipaca what did you get?
<zyga> mvo looking
<zyga> + MATCH gadget - on debian 9 this makes no sense
<zyga> should this test even run there
<zyga> hmmm
<mvo> zyga: also it makes no sense because the diff is very small so it can't break like this
<mvo> ohwell
<Chipaca> zyga: https://twitter.com/chipaca/status/964099012281487360
<zyga> woah
<zyga> man
<zyga> I look forward to seeing you type on this :)
<Chipaca> zyga: the firmware is open
<Chipaca> zyga: â¦
<Chipaca> i didn't have enough side projects
<zyga> how come I didn't follow you yet
 * zyga follows chipaca
<Chipaca> zyga: probably because i was private for a while
<mup> PR snapd#4674 closed: packaging: fix build on sbuild <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4674>
<zyga> mborzecki posted a question on 4675
<mup> PR snapd#4676 opened: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4676>
<mup> PR snapd#4663 closed: interfaces/builtin: allow MM to access login1 <Created by alfonsosanchezbeato> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4663>
<mup> PR snapd#4635 closed: snap: add support for `snap run --gdb` <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4635>
<zyga> mborzecki how are arch spread tests doing?
<zyga> is that still on hold?
<mborzecki> waiting :)
<mborzecki> i want to finish timer services for 2.32 first, then come back to autotools in $(top_srcdir)/data and then arch
<zyga> ok
<mborzecki> zyga: right, so interface-time-control is failing in my pr too
<mborzecki> Chipaca: does the keyboard come with the straps to attach each half to a hand? :)
<Chipaca> mborzecki: it comes with two different length cables to connect the halves to each other, a rail to connect the two halves into a single thing at adjustable angles, two feet to stand them independently and angled any which way, a screwdriver to take it apart, and a booklet to put it back together again
<mborzecki> Chipaca: nice, looking forward to hearing more about your impressions once you use it for a while
<Chipaca> impression #0: it's going to have a learning curve
<Chipaca> was currently in the zone in a bit of a refactor, put it to one side
<mborzecki> wow, it even comes with source code and stuff
<zyga> re
<zyga> I'm tethered from my phone, not sure why local ISP (both of them) failed
<mborzecki> zyga: https://paste.debian.net/1010385/
<zyga> netlink
<zyga> weird
<zyga> thank you for checking that
<mborzecki> why is it touching netlink?
<zyga> maybe the test started to rely on netlink now
<zyga> (for whatever reason)
<mborzecki> actually socket(AF_NETLINK, SOCK_RAW, NETLINK_AUDIT) ?
<zyga> is hwclock coming from systemd?
<zyga> or maybe some nss plugin or something
<mborzecki> zyga: just strace on host http://paste.debian.net/1010387/
<zyga> yeah
<zyga> no netlink
<mborzecki> i don't see socket anywhere
<mborzecki> zyga: ok, os here's hwclock from the core snap: https://paste.debian.net/1010389/ no clue why it does socket() call
<zyga> mborzecki does it do this in stable?
<zyga> or just in edge?
<mborzecki> zyga: it's edge
<mborzecki> let me try stable
<zyga> yeah, try stable
<zyga> I wonder if it's a regression
<zyga> (^H "new feature")
<zyga> brb, let me try normal internet again
<Son_Goku> zyga, mborzecki, mvo: what do I need from the release/2.31 branch that isn't part of the 2.31 tagged release?
<zyga> ok, internet is back
<zyga> Son_Goku I think just take all of release/2.31 since that's exactly what it is for
<zyga> mvo will do a .1 soon AFAIK
<zyga> but you really want to ask mvo about that
<Son_Goku> mvo, do you plan on doing a 2.31.1?
<mborzecki> damn, random lockup, cursor moving and all, but the rest was frozen
<zyga> mborzecki ryzen?
<mborzecki> zyga: no, i think it's the damn wifi
<mborzecki> it's the 2nd time this happened, and kernel backtrace shows warnings from iwlwifi
<Chipaca> perhaps I should lunch
<mup> PR snapcraft#1926 opened: Release changelog for 2.39.1 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1926>
<mvo> Son_Goku: there will be a 2.31.1 with some small fixes, probably monday
<Son_Goku> mvo, okay, then I won't prepare a snapd update just yet, then
<zyga_> mborzecki, ok, I know what's causing this
<jdstrand> mborzecki: I don't have any special insight except that the audit system sounds like ne of CAP_AUDIT_READ, CAP_AUDIT_WRITE or CAP_AUDIT_CONTROL and/or NETLINK_AUDIT
<jdstrand> zyga_: ^
<jdstrand> mborzecki, zyga_: *or* /dev/rtc isn't in the device cgroup
<jdstrand> mborzecki, zyga_: no, that should be a different error
<jdstrand> zyga: "mborzecki, ok, I know what's causing this"
<jdstrand> zyga: what is it?
<zyga> util-linux (2.30.1-0ubuntu4.1) artful; urgency=medium
<zyga>   * Add --with-audit to rules file and libaudit-dev to build depenedencies.
<zyga>     The hwclock needs audit defined in order to create audit records when
<zyga>     time is changed. (LP: #1722313)
<mup> Bug #1722313: Enable auditing in util-linux. <rls-aa-notfixing> <verification-done-artful> <verification-done-xenial> <verification-done-zesty> <util-linux (Ubuntu):Fix Released by j-latten> <util-linux (Ubuntu Xenial):Fix Released> <util-linux (Ubuntu Zesty):Fix Committed> <util-linux (Ubuntu
<mup> Artful):Fix Released> <util-linux (Debian):New> <https://launchpad.net/bugs/1722313>
<zyga>  -- Joy Latten <joy.latten@canonical.com>  Sun, 05 Nov 2017 18:14:49 -0600
<zyga> change in util-linuxy
<jdstrand> so it is what I thought
<jdstrand> mborzecki: I don't have any special insight except that the audit system sounds like ne of CAP_AUDIT_READ, CAP_AUDIT_WRITE or CAP_AUDIT_CONTROL and/or NETLINK_AUDIT
<jdstrand> zyga: ^
<jdstrand> have it plugs netlink-audit
<jdstrand> that won't actually give you audit_write though
<jdstrand> time-control needs updating
<zyga> so we need to add netlink audit snippets to that interface
<zyga> jdstrand right?
<jdstrand> capability audit_write,
<jdstrand> ^ apparmor
<zyga> + socket bits I suspect
<zyga> but yeah
<zyga> (I think it was getting killed by socket syscall)
<jdstrand> bind
<jdstrand> socket AF_NETLINK - NETLINK_AUDIT
<jdstrand> seccomp ^
<jdstrand> but wait a second
<zyga> thanks!
<zyga> jdstrand if you want just send the branch :)
<jdstrand> it is probably going to need capability net_admin,
<jdstrand> is this on bionic?
<zyga> jdstrand no, it's in xenial
<jdstrand> oh, sru
<zyga> yep
<zyga> and it's now present in the core snap in endge
<jdstrand> ok. this would affect other distros btw
<jdstrand> (if they had strict mode)
<zyga> just run strace -e socket /snap/core/current/sbin/hwclock
<zyga> indeed
 * jdstrand nods
<zyga> and compare stable and edge
<jdstrand> ok. let me think about this. I don't want to just give out net_admin
<zyga> yeah, it sucks
<zyga> I wonder if we could *not* give the permission
<zyga> so that it gets socket
<jdstrand> yeah, that capabilities subsystem has some icky spots
<zyga> and doesn't crash
<jdstrand> well, I was thinking of adding netlink-audit-control
<zyga> but doesn't audit
<jdstrand> we want it to audit though
<jdstrand> we could add the socket, not the cap, then add both in the -control interface
<jdstrand> then it doesn't die, but won't audit until netlink-audit-control is added
<jdstrand> that's pretty reasonable
 * jdstrand adds to list
<zyga> yes, that's very nice
<jdstrand> I've got two other investigations to do. I'll send up a PR for this in a bit
 * kalikiana going for lunch break, while the poor laptop will have to keep running test cases
<mup> PR snapd#4677 opened: cmd/snap: introduce `snap run --timer` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4677>
<mup> PR snapd#4678 opened: snap: fix `snap moo` output <Created by mvo5> <https://github.com/snapcore/snapd/pull/4678>
<mvo> zyga: keep me updated on the --with-audit issue please
<zyga> mvo ack, I think jdstrand is making a PR that will address it now
<zyga> I will just review it
<mvo> zyga: great, we will need it for 2.31.1 too
<zyga> yes, absolutely
<Chipaca> mvo: OMG :-)
<cachio> mvo, hey, could you please upload the snap test-snapd-physical-memory-control ?
<mvo> cachio: ups, forgot that, sure, let me do that now
<cachio> mvo, tx
<magicaltrout> my google fu is failing me
<mvo> cachio: do you have a link
<magicaltrout> is there a snapcraft_part_... build directory
<mvo> cachio: is it in one of your PRs?
<cachio> mvo, https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-physical-memory-control
<magicaltrout> variable I can use in a snapcraft build ?
<mvo> cachio: thanks
<cachio> mvo, I did not create a PR yet
<cachio> I'm waiting for the snap :)
<mup> PR snapd#4679 opened: systemd: add default target for timers <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4679>
<mborzecki> trivial PR ^
<mup> PR snapd#4680 opened: snap: pass full timer spec in `snap run --timer` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4680>
<mborzecki> most of the timer services stuff is open for review now, still need to cut the service wrappers into smaller pieces
<mborzecki> afk to pick up the kids
<kalikiana> re
<mup> PR snapd#4681 opened:  testutil: add File{Matches,Equals,Contains} checkers <Created by chipaca> <https://github.com/snapcore/snapd/pull/4681>
<Chipaca> now, where was I?
<kalikiana> Chipaca: unicorns? cats?
<Chipaca> kalikiana: por quÃ© no los dos?
<kalikiana> Always :-D
<seb128> why do some of the snaps have several loop mounts?
<ogra_> for the same snap file ?
<seb128> seems like several revisions are active?
<seb128> dunno what you mean by "snap file"
<ogra_> (there should always be three revisios of each snap ... and each has a mount)
<ogra_> a file ending in .snaop
<ogra_> *.snap
<seb128> oh ok
<seb128> why 3 revisions? can I tell snap that for a particular snap 1 is enough?
<ogra_> i dont theink we technically need all of them mounted though
<seb128> do they end up using 3 times the space?
<ogra_> yes
<seb128> :(
<ogra_> for rollback etc
<seb128> why 3 and not 2?
<ogra_> i dont know why 3, 2 technically are enough ... thats a niemeyer question
<seb128> k
<seb128> thx
<Chipaca> 3 revisions
<Chipaca> because it leaves you one more revert in case things go bad
<Chipaca> seb128: if you need to make space you can remove the revisions you're not using
<zyga> re
<kalikiana> o/ zyga
<zyga> hey hey
<seb128> Chipaca, how? snap list doesn't list them
<Chipaca> seb128: snap list --all
<Chipaca> seb128: and then, snap remove --revision=NNNN thesnap
<seb128> Chipaca, thx, that's non obvious as an user of the system :/
<Chipaca> seb128: you're trying to do something out of the ordinary
<Chipaca> seb128: i'm not sure what part is the non-obvious though
<Chipaca> seb128: but it's not surprising that to do advanced things you need to know the advanced things
<jdstrand> zyga, mvo: I am now, yes
<zyga> cook
<zyga> cool :D
<seb128> Chipaca, I started from "it's annoying that all those loop mounts show in the "df -h" cmd output, wth is there even 3 mounts for each snap"
<jdstrand> mvo: what is the timeframe for 2.31.1 policy updates? I'll do that one right now, but there are some others I can work on this morning
<Chipaca> kyrofa: jdstrand: did you see gustavo's request to drop the _ from the valid versions?
<zyga> jdstrand I think .1 is next monday
<zyga> so sufficient time
<jdstrand> mvo: from my perspective, none are required, but you mentioned that we could sneak some in, so asking
<jdstrand> ah, ok.
<Chipaca> seb128: df -h -x squashfs
<seb128> Chipaca, which I'm probably not the only one being annoyed about, but you are right it's a different topic of revisions installed and how to uninstall somes, it just made me wonder/try to understand why it was this way (which is the non obvious part)
<jdstrand> Chipaca: not yet, but ack
<seb128> Chipaca, we should make that option default :)
<Chipaca> seb128: a year ago i'd've said 'fat chance', but with everything graphical now doing that, maybe the time is right to suggest it
<Chipaca> seb128: OTOH i don't think df has an anti-x, ie a way of undoing an -x
<seb128> :/
<seb128> also is there an equivalent flag for "mount"?
<Chipaca> $ df -h -x squashfs -t squashfs
<Chipaca> df: file system type âsquashfsâ both selected and excluded
<mvo> jdstrand: I plan 2.31.1 for monday
<Chipaca> seb128: mount output is useless these days
<ogra_> well, we should really also mount the snaps dynamically ... whats the reason for havin all three revisions permanently mounted
<Chipaca> seb128: mount | grep -v squash | wc -l <- 41 lines
<mup> PR snapd#4682 opened: tests: new spread test for physical-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
<zyga> seb128 I think that with the advent of cgroups and more exotic filesystems regular df stopped being for humans
<zyga> I use pydf often for that reason
<seb128> zyga, df works fine when you don't have snaps :)
<ogra_> "in the old world"
<seb128> it's the only thing I've installed that create noise here
<ogra_> :)
<zyga> ah, sorry, I confused df with mount
<seb128> ogra_, you know your constant trolling is getting old
<Chipaca> seb128: wrt mount, even mount(8) says "use findmnt(8) for listing"
<Chipaca> seb128: and, findmount -t nosquashfs
<Chipaca> findmnt*
<seb128> that's better indeed :)
<seb128> anyway thx, the noise just made me wonder why several instance of each snaps are mounted
<seb128> I'm still unsure why the ones kept for fallback purpose needs to be mounted all time
<Chipaca> seb128: findmnt -t nosquashfs,nocgroup
<zyga> seb128 no reason, just work to get it not mounted
<Chipaca> ;-)
<zyga> seb128 e.g. snapd doesn't cache snap/meta.yaml
<Chipaca> there was a reason for it
<Chipaca> but i think it no longer applies
<Chipaca> but, changing it takes work
<Chipaca> zyga: and it's meta/snap.yaml :-p
<zyga> snap yaml it is
<zyga> <yodavoice>
<mvo> Chipaca: iirc back in the day we would use systemds automunt feature but we kept things mounted for simplicity
<zyga> mvo did we really try to do that?
<zyga> but even if we did auto-mount on demand it wouldn't be enough to be sane
<Chipaca> mvo: there was something we needed to do that required it to be mounted, but i lose the details
<zyga> as "snap list" will mount everything
<Chipaca> seb128: ooooh, findmnt has --df
<Chipaca> seb128: and the circle is complete
<zyga> I would say that if we kept snap meta-data in cache elsewhere
<zyga> and not mount anything
<zyga> we could even have snap run do the mounting (via api call to snapd)
<mvo> zyga: well, snap list would mount it and after some inactivity it would go away
<pedronis> well, we always said we don't want to call snapd from snap run
<pedronis> so at least current needs to be mounted
<zyga> yeah but 1) silly 2) silly 3) lots of IO/memory
<zyga> 4) silly
<zyga> pedronis well, yes,
<zyga> but we also do things like wait for snapd to generate seccomp profiles from snap-confine
<zyga> so ... hmm
<zyga> I think the idea that app doesn't need to be mounted is useufl
<pedronis> well
<zyga> *useful
<zyga> and for sure, not for the inactive revisions
<pedronis> trade offs
<Chipaca> hmm, is the timecontrol failure known, or are things broken?
<zyga> this makes the discussion simpler, inactive revisions could be unmounted
<pedronis> Chipaca: it's known
<zyga> Chipaca it's known
<Chipaca> ah, that's the one about netlink
<zyga> it's being fixed by jdstrand
<Chipaca> ?
<zyga> yes
<Chipaca> right
<Chipaca> teh suck
<pedronis> audit netlink that stuff
<mup> PR snapd#4671 closed: tests: adding new test to validate the raw-usb interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4671>
<mup> PR snapcraft#1906 closed: remote_parts: handle connection errors <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1906>
<niemeyer> Now Linode is reporting spam in one of our machines.. except the machine was not in our account by the time the spam was sent.. :)
<mup> PR snapd#4683 opened: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4683>
<zyga> oohh
<zyga> looking
<zyga> jdstrand offtopic, linux "sockets" are a pile of historic mess :/
<zyga> jdstrand reviewed
<mup> PR snapd#4685 opened: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4685>
<jdstrand> zyga: and there is one for 2.31 ^
<jdstrand> zyga: note, I didn't create netlink-audit-control because reading netlink-audit, it was always meant to allow writes
<zyga> makes sense
<jdstrand> zyga: it is arguably not a typo since it is 'plugs' in the yaml
<jdstrand> zyga: I can fix it right now if you want
<zyga> "should use plugs"
<zyga> I think "should plugs" just sounds unnatural
<zyga> not sure, not a native speaker
<zyga> I will leave that up to you
<jdstrand> it is unnatural and wrong for the verb, yes. but using the yaml definition as a verb, no
<jdstrand> I'll fix
<zyga> I thinbk there's no verb in that sentence,
<zyga> that's what's bugging me about it
<jdstrand> I'm using 'plugs' as a verb just like people use 'facebook' as a verb these days
<jdstrand> again, I'm fixing it
<zyga> ah, I see
<zyga> I should have googled it ;)
<jdstrand> well, I was making up language there, but, fixed
<zyga> I was joking with "google" being a verb nowadays :)
<jdstrand> oh haha. I totally missed that. nice :)
 * jdstrand was multitasking
<zyga> it's interesting how we caught a change in the core snap this way
<zyga> it's certainly unusual and a result of unique things that snapd does
<jdstrand> yeah
<jdstrand> it is too bad that a change in an SRU regressed edge. it would be interesting to think about running the spread tests as part of SRU
<niemeyer> cachio: The workaround for the corruption bug is now pushed to spread's master
<jdstrand> but, it is edge, so no one was affected, and it did catch it, so that's good
<jdstrand> if the SRU was bad enough, we could file bugs to have it reverted/fixed and the broken core would never make it to stable
<jdstrand> basically, testing is a great thing :)
<zyga> real men used to test in production on floppy disks
<zyga> but I'm glad we're not there anymore
<jdstrand> hee
<mup> PR snapd#4299 closed: osutil/user: replace our uses of os/user and filepath.Glob("/home/*") <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4299>
<Chipaca> jdstrand: mvo: maybe edge should include -proposed
<Chipaca> or is it -updates
<Chipaca> i always forget the name
 * Chipaca thinks it's -proposed
<jdstrand> Chipaca: it has -updates
<jdstrand> Chipaca: so I think you meant -proposed
<zyga> yeah,
<zyga> -proposed is really teh edge
<zyga> but then it's confusing
<jdstrand> but I don't think it should, unless you never promote from edge -> beta
<zyga> because we don't want to test edge with proposed and beta with -updates
<zyga> exactly :)
<Chipaca> lots of red fish
<zyga> I wish travis had a way to "bless" a branch
<zyga> this branch unbreaks master
<zyga> block all CI until it lands
<zyga> "halt and stop fire" could be a nice name
<cachio> niemeyer, great, tx
 * zyga goes for some grocery shopping
<blackboxsw> pedronis: thanks for the meeting, I updated retracted comments on https://github.com/snapcore/snapd/pull/4599
<mup> PR #4599: many: send  new Snap-CDN header with none or with cloud instance placement info as needed <Created by pedronis> <https://github.com/snapcore/snapd/pull/4599>
<pedronis> blackboxsw: thank you
<mup> PR snapd#4686 opened: daemon: make the ast-inspecting test smarter; drop 'exceptions' <Created by chipaca> <https://github.com/snapcore/snapd/pull/4686>
 * Chipaca couldn't resist that one
 * Chipaca has low resistance
<elopio> snappy-m-o autopkgtest 1926 xenial:armhf
<snappy-m-o> elopio: I've just triggered your test.
<elopio> sergiusens: ^
<sergiusens> snappy-m-o: autopkgtest 1926 xenial:amd64 xenial:arm64
<snappy-m-o> sergiusens: I've just triggered your test.
 * cachio afk
<zyga> re
<zyga> 3 hours and still pending. :(
<zyga> crap
<jdstrand> davidcalle: ping re https://docs.snapcraft.io/deprecation-notices/dn5
<jdstrand> davidcalle: any nm, it is fixed now
<jdstrand> s/any/ahh/
<davidcalle> ;-)
<jdstrand> davidcalle: thanks! :)
<zyga> oh,
<zyga> jdstrand you pushed just before I pushed :)
<jdstrand> :)
<jdstrand> diddledan: hey, I just tried to connect to you on wired. trying to look into https://forum.snapcraft.io/t/wire-snap-fails-to-use-the-network/3845
<jdstrand> diddledan: not able to reproduce yet
<diddledan> ello
<diddledan> it only occurs once the call is acccepted
<jdstrand> ok
<jdstrand> I can create a second account then
<jdstrand> diddledan: thanks!
<diddledan> np :-)
<mup> PR snapcraft#1927 opened: catkin plugin: extract Wstool into its own module <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1927>
<mup> PR snapcraft#1928 opened: tests: remove duplicate tests <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1928>
<mup> PR snapd#4683 closed: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit <Critical> <Created by jdstrand> <Merged by jdstrand> <https://github.com/snapcore/snapd/pull/4683>
<mup> PR snapd#4687 opened: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4687>
#snappy 2018-02-16
<mup> PR snapd#4688 opened: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4688>
<mup> PR snapd#4689 opened: tests: new spread test for kvm interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4689>
<crumbles> How does snapcraft decide which library dependencies to include in a snap? I understand that snapcraft excludes libraries that core snap already has. What happens if my app requires other libraries that are not in core snap?
<nacc> crumbles: that's up to the plugin, presumably
<mborzecki> morning
<mborzecki> mvo: morning
<mborzecki> mvo: i see that travis jobs on master is passing now
<mvo> mborzecki: oh, interessting - its failing badly in 2.31
<mborzecki> mvo: afaik it needs this https://github.com/snapcore/snapd/pull/4685
<mup> PR #4685: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 <Critical> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4685>
<mborzecki> mvo: something weird, master tip built failed with some random store related faiilure, restarted it and waiting for results
<mborzecki> mvo: but jdstrand's PR on 2.31 fails for some totally unrelated reasons
<mvo> mborzecki: yeah, thats what I mean, 2.31 is in a really unhappy state and its not clear why
<mborzecki> mvo: maybe something new in core from edge?
<mvo> mborzecki: yeah, must be something external, still super strange
<mborzecki> let me run that pr from spread
<mvo> mborzecki: yeah, we need to get to the bottom of this, also super strange that master is fine but 2.31 is broken
<mborzecki> + test-snapd-timedate-control-consumer.hwclock-time -r -f /dev/rtc
<mborzecki> execl failed: No such file or directory
<mborzecki> hmm maybe somthing wrong with patht ot snap-confine/snap-exec
<mborzecki> mvo: debian does not reexec right?
<mvo> mborzecki: it does not currently
<mvo> mborzecki: oh, its related to /lib/udev/snappy-app-dev - but that should still be there in 2.31
<mvo> mborzecki: aha, I get it - core no longer has /lib/udev/snappy-app-dev
<mborzecki> hah
<mvo> mborzecki: the core snap - we need to symlink it
<mvo> mborzecki: yay, mystery solved!
<mborzecki> so many moving parts :)
<mvo> mborzecki: indeed
<mup> PR snapcraft#1926 closed: Release changelog for 2.39.1 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1926>
<mup> PR snapd#4690 opened: packaging: provide a compat symlink for snappy-app-dev <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4690>
<mvo> mborzecki: ^- should fix things.
<mborzecki> mvo: missing newline at the end, otherwise +1
<zyga> o/
<mvo> mborzecki: meh, indeed
<mborzecki> zyga: hey
<mvo> force-pushed the \n
<zyga> hey, sorry for being so late folks, I feel a bit off today
<kalikiana> good morning
<kalikiana> o/ zyga
<zyga> hey kalikiana, how are you doing?
<mvo> good morning kalikiana
 * zyga has a headache today, pretty unusual for him 
<kalikiana> I feel like I'm the conductor of a bug triaging train this week... all I'm missing is the hat
<zyga> kalikiana haha, that's awesome :)
<kalikiana> zyga: have a hot soup? like, stock in a cup and hot water. makes you feel good
 * kalikiana just had a miso soup, nice and salty
<zyga> nice :)
<zyga> I don't think I have any though, it's sandwich day everyday
<mup> PR snapd#4691 opened: cmd/snap: use proper help strings for `snap userd --help` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4691>
<mborzecki> mvo: ^^ may be a 2.31 material too
<mborzecki> btw. 4691 is trivial review so if anyone could take a look :)
<zyga> ack
<mborzecki> btw. there's also a file cmd_shell.go, does not appear to be used at all
<mborzecki> gometalinter throws: cmd_shell.go:33:1â ï¸ cmdShell is unused (deadcode)
<zyga> mborzecki let's remove it
<zyga> mborzecki can you also fire that tool on osutil
<mborzecki> zyga: is it something that predates snap run --shell?
<zyga> I suspect there are some unused bits for mounting related tasks
<mvo> mborzecki: aha, thanks
<mvo> mborzecki: great job
<zyga> hmm, tests are not in a happy place
<mup> PR snapd#4692 opened: cmd/snap: linter cleanups <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4692>
<mborzecki> trivial PR ^^
<zyga> mvo do we need https://github.com/snapcore/snapd/pull/4690 for 2.31?
<mup> PR #4690: packaging: provide a compat symlink for snappy-app-dev <Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/4690>
<mvo> mborzecki: thanks for the cleanups
<mvo> zyga: we don't need it in 2.31, just in master
<zyga> ok
<mvo> zyga: 2.31 still has the old path
<mvo> zyga: and we need travis slots :/
<zyga> let's hold on with new PRs
<zyga> until that one lands
<mvo> yeah
<mborzecki> uhh, sorry, i've take a couple of slots recently
<mborzecki> zyga: have you looked at https://github.com/snapcore/snapd/pull/4682 ? wonder what will happen if you poke that address
<mup> PR #4682: tests: new spread test for physical-memory-control interface <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4682>
<zyga> woah
<zyga> nothing good will happen
<zyga> that's a weird address to poke
<zyga> I don't understand that test TBH
<Chipaca> moin
<mborzecki> Chipaca: morning
<mborzecki> Chipaca: how are you keyboardio typing skills today?
<Chipaca> I'm only typing a few minutes a day on it until I get used to it
<Chipaca> Hella slow
<Chipaca> That was all typed on the butterfly as was this
<Chipaca> but this is top speed
<mborzecki> i can imagine, remember using one of the 'ergonomic' keyboards from MS for the first time, the one where the middle was a bit higher than the sides, you had a feeling that you're using an orb not a keyboard :)
<mborzecki> keyboardio must be a whole new level
<Chipaca> the thing that most catches me out is space being only on one side
<Chipaca> when I think "space", the nearest thumb twitches
<Chipaca> man t
<Chipaca> man those quotes were hell to type :-)
<mborzecki> you can remap the keys though, right?
<Chipaca> ah, yes, probably? but that's not my problem, just that i have never trained to use my pinkies
<Chipaca> my typing is self taught
<Chipaca> and, mostly two fingers (maybe 2.5) and thumbs,
<Chipaca> so using my whole hand is going to need some time
<Chipaca> (i'm now back on the regular qwerty)
<Chipaca> in my defense, there was no way my 12-year-old pinkies could move the commodore's keys
<Chipaca> mvo: morning sah
<mvo> Chipaca: good morning
<Chipaca> mvo: tell me more about this magic realism^W^W ast thing
<Chipaca> mvo: should I add a comment about what it's doing, from a higher leverl than the step-oriented comments I put in there (that are mostly to help future me)
<Chipaca> mvo: I _could_ make it a general thing, move it to testutils and add tests
<mvo> Chipaca: I think the code and comments are fine, I just wonder if we should have a test for the test itself, i mean, how do we know it works :) ?
<Chipaca> mvo: if you think it's worth it :-)
<mvo> Chipaca: maybe not
<mvo> Chipaca: I was mostly wondering
<Chipaca> mvo: well, we'll find out it isn't working easier than we find out it is
<Chipaca> er
<Chipaca> i mean it counts only one way we could be adding commands, if we ever add them a different way it'll fail
<Chipaca> it's very restrictive
<mvo> Chipaca: ok, that sounds good then
<Chipaca> if we create a function that returns *Commands and use that it'll fail for example
<mvo> Chipaca: ok, thats all right then, I was not aware of this property. no need for an extra test in this case I think
<niemeyer> Hello snapping people
<Chipaca> mvo: should I add a high-level comment with this? otherwise we'll forget why it was ok :-)
<Chipaca> niemeyer: go to bed niemeyer you're asleep
<mvo> hey niemeyer ! you are up early!
<mborzecki> niemeyer: hello, you're up early
<niemeyer> Heya!
<mborzecki> Chipaca: hah found a diy one https://docs.keeb.io/iris-build-guide.html
<niemeyer> I've been awake for about 6h now.. sleep is indeed catching up a bit by now
<Chipaca> mborzecki: heh. Give keyboard.io's blog a read sometime, it's fun
<niemeyer> The good news is we have a working spread in GCE
 * Chipaca hugs niemeyer 
<Chipaca> running spread against qemu on my old laptop that no longer likes having 8gigs is torture
<niemeyer> Chipaca: Aw..
<niemeyer> Chipaca: Although I haven't managed to run anything realistic yet, I can already tell that the networking does make a difference
<mvo> niemeyer: \o/
<niemeyer> I have secret hopes of pushing the suite below 20 minutes soon, but it's a bit early to tell yet
<mup> PR snapd#4690 closed: packaging: provide a compat symlink for snappy-app-dev <Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4690>
<zyga> whee, thank you mvo
<mvo> zyga: yw, I build a new core now, then things should be normal again
 * kalikiana coffee
<Chipaca> github, you so broken
<niemeyer> mvo: Do we actually have snappy-app-dev inside /lib/snapd now?
<mvo> niemeyer: yes
<mvo> niemeyer: that PR got merged a couple of days ago so that bases work correctly there
<niemeyer> mvo: I was just hoping for a better name on the transition, but probably too late
<niemeyer> snappy-app-dev is bad on every token.. :)
<mvo> niemeyer: uh, sorry, was not aware of this desire. we can still do this
<niemeyer> mvo: I probably never mentioned because it was a legacy piece
<mvo> niemeyer: if you have a good name I am happy to make it happen
<mvo> niemeyer: there is also a desire to rewrite it or integrate it into snap but that is orthogonal to some extend
<niemeyer> mvo: I was just hoping to get it somewhat closer to its purpose, and less enigmatic
<mup> PR snapd#4691 closed: cmd/snap: use proper help strings for `snap userd --help` <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4691>
<mvo> niemeyer: happy about suggesitons - snap-udev-helper?
<mvo> niemeyer: should be easy enough and best to do it now instead of having yet another transition
<niemeyer> mvo: That sounds good
<niemeyer> mvo: How is that tool called?  From within a udev rules file?
<mvo> niemeyer: yes, also from snap-confine
<niemeyer> mvo: Cool, sounds good
<niemeyer> mvo: The current functionality might lean itself to something around cgroups instead of udev, but I guess that udev might need something else in the future and we'd still want to put it around the same place
<mvo> niemeyer: we could also use "snap-devices-helper" to be more generic
<niemeyer> mvo: Ah, even better! +1!
<niemeyer> mvo: Perhaps singular: snap-device-helper
<mvo> niemeyer: sounds good, I work on this now
<niemeyer> mvo: Perhaps even just "snap-device".. in theory most of the things inside lib/snapd are helpers
<mup> PR snapd#4673 closed: interfaces/mount: generate per-user mount profiles <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4673>
<mup> PR snapd#4692 closed: cmd/snap: linter cleanups <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4692>
<Chipaca> mvo: when I can't imagine how to do something, it usually indicates a failure of my imagination. Remind me of this more often.
 * Chipaca fixing stuff
<mup> PR snapd#4687 closed: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4687>
<zyga_> mborzecki question about --timer=... on commands
<zyga_> are such commands exported in /snap/bin?
<zyga_> and what is the --timer=%q part for (in LauncherCommand)
<mborzecki> yes
<zyga_> mborzecki hmm, what is that for?
<zyga_> why would the user wish to have a timer on their path
<mborzecki> zyga_: --timer is the schedule given service runs with;, eg --timer="mon,10:00~12:00,,fri,13:00"
<zyga_> what I don't understand is why do we want to put a command on path
<mborzecki> the way it works, is that we have a *.timer and a *.service, the *.service uses `snap run --timer ..`, when the timer activates the service it will call snap run --timer, then when 'time.Now()' matches the scedule, the service will be ran, otherwise it exits
<mup> PR snapd#4693 opened: many: rename snappy-app-dev to snap-device-helper <Created by mvo5> <https://github.com/snapcore/snapd/pull/4693>
<mvo> Chipaca: heh :) I'm not sure what happend but I'm glad you are fixing stuff
<zyga_> mborzecki are we doing that because our timer syntax is richer than that of systemd?
<mup> PR snapcraft#1929 opened: sources: proper errors for invalid handlers <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1929>
<Chipaca> mvo: found a way of making the current implementation give a false negative, fixed it and adding tests
<mborzecki> zyga_: yes, at least the --timer part is for this
 * Chipaca bows before mvo's greater wisdom
<zyga_> mborzecki would that still work if the command was not on path (not in /snap/bin)
<mvo> Chipaca: lol - I just like asking silly questions
<Chipaca> suuure
<mborzecki> zyga_: yeah, probably if i tweak snap run it would, but why would you do that?
<zyga> mborzecki mainly because I don't see why I would like to have timers on path
<zyga> it's an implementation detail (typically)
<zyga> and since the timer unit can just say "snap run ... "
<zyga> there's no real need for that command to be exposed
<mborzecki> zyga: hmm ok, i need to how to invoke it, can you leave a comment in the PR?
<zyga> sure
<zyga> I'm going through that now
<mborzecki> thanks
<mup> PR snapd#4679 closed: systemd: add default target for timers <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4679>
<Chipaca> niemeyer: are you still amongst us?
<niemeyer> Chipaca: I shall be
<Chipaca> niemeyer: as pressure continues to mount to add things to 'snap list' and 'snap find', how do you feel about making it single-line-per-entry only if stdout is a tty?
<Chipaca> i.e. wrap some of the columns if the thing is too wide, but only if a user is looking at it
<Chipaca> (i have a change request that will make it wider)
<niemeyer> Chipaca: The output we have right now is quite nice.. what else do we need there at the moment?
<Chipaca> niemeyer: remember 'Tracking'?
<niemeyer> Chipaca: Without further details, my temptation would be to argue to keep it nimble instead of making it larger
<Chipaca> I'd say the output of 'snap find' is _not_ nice today, already (but Tracking is for snap list, which isn't there yet)
<zyga> mborzecki can you look at https://github.com/snapcore/snapd/pull/4675#pullrequestreview-97145880 please
<mup> PR #4675: timeutil: fix scheduling on nth weekday of the month <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4675>
<mup> PR snapd#4693 closed: many: rename snappy-app-dev to snap-device-helper <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4693>
<zyga> mvo do you know what is going on in 2.31 release branch
<mvo> zyga: the symlink was not enough, I need to pick my daugther up in some minutes, but right now I'm a bit uncertain why the symlink did not help
<zyga> mvo I was looking at a PR from jamie and it looks like all kinds of weird stuff is going on with interfaces
<mvo> zyga: its failing because snap-confine cannot execl /usr/lib/udev/snappy-app-dev
<mvo> zyga: which appears to happen inside the core snap
<mvo> zyga: but its strange because our tests modify the core snap so maybe soemthing there
<zyga> mmmm, is is perhaps related to the stale apparmor profile bug
<mvo> zyga: probably not, its not a eaccess, its a not-found
<zyga> aha
<zyga> ok
<mvo> zyga: I will need to leave in 2min but will think over it, ideas welcome, definitely related to the snappy-app-dev rename
<zyga> kk
<koza> im not on this mtg
 * koza hates focus follows mouse
<mup> PR snapd#4694 opened: cmd/snap-update-ns: small refactor for upcoming per-user mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/4694>
<zyga> Chipaca *nice* testing helpers
<Chipaca> zyga: ik,r?
<mvo> zyga: yeah, he rocks
<zyga> and also for making them useful across the tree!
<zyga> Chipaca review on 4681
<Gnjurac> can i build snaps form github
<zyga> great work there
<Gnjurac> cuz atm on page it says failing
<Gnjurac> https://github.com/snapcore/snapd
<zyga> Gnjurac hey, sure you can, have you seen snapcraft.io?
<Gnjurac> yep
<Gnjurac> but i am on voidlinux
<Gnjurac> so no snap in repo
<ogra_> you are building snapd, not a snap package ?
<zyga> you can hook up your github repository to snapcraft.io and have it built automatically
<Chipaca> Gnjurac: are you trying to build snapd, or a snap?
 * zyga won't repeat that now but this is a valid question
<Gnjurac> i want snapd so i can install snaps
<Gnjurac> apps
<zyga> ah. ok
<zyga> you will need the golang stack, a C compiler and some basic libraries,
<zyga> at runtime you will likely need systemd
<zyga> what kind of issues are you running into now?
<ogra_> zyga, void uses "runit" not systemd ...
<zyga> yes, I read
<ogra_> that might be a bit more work :)
<zyga> Gnjurac I can help you out
<Gnjurac> hmm meybe too much work for newbie like me, guess i will post request for it on github
<zyga> Gnjurac but you have to do the work :)
<Gnjurac> zyga: really?
<zyga> I can just offer help and ideas
<Gnjurac> i am willing
<zyga> I think not having systemd is a major issue though
<Gnjurac> have time
<zyga> is systemd an option or is it just not packaged?
<Gnjurac> no systemd
<Gnjurac> at all
<Gnjurac> void use runit
<zyga> does runit provide systemd-like shim so that software written for system can run on top?
<Gnjurac> hmm duno like i say am newb , i know i can just add services in runit and thats all
<zyga> Gnjurac this may be a little bit of a steep learning curve, you may want to try a systemd-enabled distribution to play with snaps first
<Gnjurac> http://smarden.org/runit/
<Gnjurac> hmm ye i am thinking that same
<Gnjurac> anyway do you maybe have dotnet installed?
<Gnjurac> or mono
<Gnjurac> i need msbuild binary
<zyga> Gnjurac I see some chatter about dotnet snaps on the forum (forum.snapcraft.io)
<zyga> and I see there si a dotnet-sdk snap currently in the edge channel
<zyga> you may want to check with the people interacting with those forum topics
<mup> PR snapcraft#1928 closed: tests: remove duplicate tests <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1928>
<mup> PR snapd#4695 opened: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
<zyga_> mborzecki quick feedback done
<mborzecki> thanks
<andyrock> mvo: hey so regarding ubiquity and the store login, using the chroot is not possible
<zyga_> https://github.com/snapcore/snapd/pull/4694/files needs a trivial review
<mup> PR #4694: cmd/snap-update-ns: small refactor for upcoming per-user mounts <Created by zyga> <https://github.com/snapcore/snapd/pull/4694>
<andyrock> mvo: the problem is that when we show the login page it could be possible that snapd is not yet installed in the chroot
<andyrock> mvo: would be possible to add a way to seed login keys in some way?
<Chipaca> zyga_: can you point me at a test where you'd use a FileState checker if it existed?
<Chipaca> i might as well add it while i'm there, but not without a concrete use case
<zyga_> I don't use any such checker yet
<Chipaca> otherwise it's just wankery :-)
<zyga_> nah, ignore me
<zyga_> I will try that myself and see if it's sensible
<Chipaca> zyga_: let me push a little refactor that should make it trivial
<zyga_> but I think some tests could compute the file state and check if it was applied this way
<zyga_> an interface maybe?
<mup> PR snapd#4696 opened: wrappers: timer services <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4696>
<mborzecki> hmm wish github had like a topic under which you could open PRs, there's a couple of PRs related to timer services and no way of telling that they are in the same 'group' unless it's in the comments
<Chipaca> zyga: https://github.com/snapcore/snapd/pull/4697
<mup> PR #4697: osutil: refactor EnsureFileState to separate out the comparator <Created by chipaca> <https://github.com/snapcore/snapd/pull/4697>
<zyga> mmm
<Chipaca> mmm, or hmmm?
<mup> PR snapd#4697 opened: osutil: refactor EnsureFileState to separate out the comparator <Created by chipaca> <https://github.com/snapcore/snapd/pull/4697>
<zyga> +1 nice
<zyga> it was just "mmm, looking"
<zyga> this made me realise we could improve the case where content matches but mode doesn't
<Chipaca> there is, of course, a problem with os.IsNotExist
<Chipaca> :-)
<Chipaca> I don't know what it says about me that I drill in to the silly corner cases
<Chipaca> but if foo/bar is a file, and you ask it about foo/bar/baz, you get an error that is not IsNotExist
<zyga> yeah, that's fine
<Chipaca> ok :-)
<jdstrand> mvo: you siad /usr/lib/udev/snappy-app-dev. did you mean /usr/lib/snapd/snappy-app-dev?
<zyga_> jdstrand can you give me a quick +1 on trivial 4694 please
<jdstrand> let me look
<zyga> jdstrand thanks, I'm working on the next chunk there but I'm still playing with some experiments to make things better than what we had before
<jdstrand> zyga: how does this relate to the one check I requested that was keeping 3963 from landing?
<zyga> jdstrand it's related, I'll implement the check
<jdstrand> I think you said something about being able to be race free?
<zyga> I'm just shrinking the original branch so that it's easier for people to actually see the code and to make progress
<jdstrand> but maybe that was for something else
<zyga> it was for that, I'm experimenting (still)
<zyga> it would be a one trick pony
 * jdstrand wasn't sure how to prevent that race so was curious what you came up with :)
<zyga> but might work for the thing we want here
 * jdstrand nods
 * jdstrand knew it was related, just wasn't sure how
<jdstrand> I'll be patient and wait for the big reveal :)
<zyga> if it works you'll see, if it fails I'll tell you the idea
<jdstrand> hehe ok :)
<zyga> holly crap, some of this rocks :-)
<zyga> jdstrand i think the linux kernel is amazing and so full of weird features I'm really afraid
<jdstrand> heh
<mup> PR snapd#4694 closed: cmd/snap-update-ns: small refactor for upcoming per-user mounts <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4694>
<mup> PR snapcraft#1930 opened: lxd: friendly errror with suggestions if network is broken <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1930>
<zyga> jdstrand so, I wasn't aware you can reach across mount namespaces
<zyga> this easily
<zyga> without setns
<zyga> you can go to /proc/pid/root and lo and belhod, it's there
<zyga> so
<jdstrand> zyga: hmm
<jdstrand> that seems like it might go against a design constraint
<jdstrand> (of ours)
<zyga> it behaves oddly though
<jdstrand> yeah, with mount namespaces and pivot_root...
<jdstrand> this is what I was thinking of: https://github.com/snapcore/snapd/pull/4329/commits/7824fb1d4001e94121b5efd1644aa1af7599b906#r154192314
<mup> PR #4329:  cmd/snap-confine: discard stale mount namespaces (v2) <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4329>
<jdstrand> that doesn't say to not use /proc/pid/root specifically, but it wouldn't surprise me at all if it doesn't work. if it does work, we should consult with jj
<zyga> yeah, it's certainly possible
<jdstrand> yeah, it looks like it is just a symlink
<jdstrand> root -> /
<zyga> jdstrand it's not a real symlink
<zyga> it's actually a gateway to that namespace, it's all weird
<zyga> you can see what's mounted there
<zyga> even if that doesn't show up in your mountinfo
<jdstrand> hmm
<zyga> for instance I can use it to write to a tmpfs mounted in a namespace I don't inhabit
<zyga> over a mount point that doesn't exist
<jdstrand> wow
<zyga> I think it was meant for chroot
<jdstrand> that sounds like a bug
<zyga> and pivot root and mount namespaces
<zyga> made it worse
<jdstrand> oh you are still in the shared mount
<zyga> yeah, I'm checking the sources
<zyga> I mounted tmpfs in a slave mount namespace
<zyga> unshared from the main one
<zyga> it really feels like /proc/pid/root is a magic gateway that feels like traversing setns
<zyga> I wonder how far this goes
<jdstrand> that does sound like a breakout and not one I would think would be allowed. stgraber did a lot of work checking out different things in /proc. perhaps he has more details on /proc/pid/root
<zyga> nsenter -m/proc/1/root/run/snapd/ns/hello.mnt
 * jdstrand is thankful for strict mode
<zyga> we can jump across this
<jdstrand> ftr, that does break our design contraints ;)
<jdstrand> but I realize you are just playing here
<zyga> yeah, I'm checking how deep this thing goes
<zyga> and if it has useful properties for what we need to do
<jdstrand> perhaps it is working as designed and container managers are expected to mount over that so the contained process doesn't have access to it?
<zyga> that when it ges weird
<jdstrand> the alternative would be frightening
<zyga> it doesn't seem to work that way
<zyga> I wonder if I can chroot there
<jdstrand> https://www.kernel.org/doc/Documentation/filesystems/proc.txt has very little info
<zyga> yeah, it feels like it's from chroot era
<zyga> and hasn't been touched since
<mup> PR snapd#4649 closed: many: record if snap was installed with --dangerous, snow relevant annotation in `snap info` and `snap list` <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/4649>
<kalikiana> re
<stgraber> jdstrand, zyga: /proc/PID/root is indeed a great way to cross mntns boundaries and one we actually make use of very often as a way to access the container's filesystem from the host, or in the case of our snap, to access the host filesystem with the right view of all mounts (though we've mostly switched to /var/lib/snapd/hostfs for that these days)
<stgraber> in real containers, we make sure to always use a pid namespace and always use a new instance of /proc, which prevents the container from seeing any pids from the host and so preventing access to /proc/PID/root
<zyga> thank you for sharing that
<zyga> I wish it was more documented and that one could do mounts in that "place"
<zyga> it seems that mounts traverse symlinks (as expected) and then end up in the current namespace
<stgraber> zyga: the kernel actually has logic specifically preventing passing mounts through that
<jdstrand> zyga: I'm not sure what apparmor is going to do wrt /proc/pid/root. if planning on using it, we need jjohansen to weigh in
<zyga> stgraber what is the motivation for that logic? can you point it to me?
<stgraber> zyga: we tried a number of trick to send mounts through /proc/PID/root in the past, using things like dirfd + bind-mount from /proc/self/fd and the like, but we kept hitting the cross mntns security check that's in the kernel
<zyga> haha
<zyga> I was thinking about using something like that :)
<zyga> and I'm reading kernel source code to see what's going on
<stgraber> zyga: there is a check in the mount code that makes sure the source and target mntns are the same, that was added as a security check a long time ago and nobody seems quite sure what that was for
<jdstrand> ok, so maybe no need to bring jjohansen in if even unconfined won't work
<stgraber> zyga: but also nobody wants to remove it
<zyga> jdstrand yeah, I think it's premature now, let jjohansen have his focus
<zyga> stgraber it would really be nice if that would work though, given enough permissions, could simplify mount management in containers
<zyga> but I'd give that away if mount handled fd's better instead :)
<mborzecki> off to pick up the kids
<mup> PR snapcraft#1931 opened: No plainbox <Created by yphus> <https://github.com/snapcore/snapcraft/pull/1931>
<jdstrand> mvo, zyga: just as an fyi which you are probably aware of, Monday is a US holiday
<jdstrand> (so I'm off)
 * cachio_ lunch
<mvo> jdstrand: thanks for letting us know
<mup> PR snapd#4685 closed: interfaces/time-control,netlink-audit: adjust for util-linux compiled with libaudit - 2.31 <Critical> <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4685>
<jdstrand> mvo: thanks for fixing up 4685 and getting it in! :)
 * jdstrand merges master for the 2.31 policy updates PR
<jdstrand> err
<jdstrand> merges release/2.31
<mvo> jdstrand: yeah, please do! thank you
<jdstrand> mvo: and sorry for the go fmt. /me slaps wrist
<mvo> jdstrand: no problem
<mvo> jdstrand: it tells more about the (sad) state of the tests than about you
<mvo> jdstrand: but we will make them better again
<mvo> actually we will make them great again!
<jdstrand> I fiddle with the policy so much which isn't affected by that and I typically run the unit test and sometimes forget the full ./run-checks
<jdstrand> I think it says something about me :)
<mvo> jdstrand: np - its an easy fix
<jdstrand> and you for fixing it for me :)
 * mvo hugs jdstrand 
 * jdstrand hugs mvo :)
<jdstrand> that AF_CONN commit was interesting
<jdstrand> socket(0x7b, ...)
<mvo> jdstrand: yeah, that looked interessting
<jdstrand> 0x7b?
<jdstrand> :)
<jdstrand> but then it all made sense when I realized it was encapsulated
<jdstrand> and why it would never be the kernel
 * mvo nods
<jdstrand> bi in*
<jdstrand> man
<jdstrand> be in*
<jdstrand> I think I am ready for the weekend :)
<mvo> jdstrand: lol - I know exactly what you mean :-D
<diddledan> https://www.youtube.com/watch?v=kfVsfOSbJY0
 * diddledan hides
<jdstrand> diddledan: hahaha
<jdstrand> that is *terrible* :P
<diddledan> :-p
<diddledan> I aim to please
 * jdstrand is still chuckling
<zyga> bibi bop
<mborzecki> diddledan: https://distrowatch.com/table.php?distribution=rebeccablackos
<diddledan> IIRC that was the first distro to ship wayland ootb
<mborzecki> omg https://sourceforge.net/p/rebeccablackos/activity/?page=0&limit=100#5a86d2213241d2526d18ca96 last commit 3 hours ago
<zyga> on sourceforge!?!
<diddledan> does anyone actually use sourceforge these days?
<mborzecki> rebeccablackos guys do apparently :)
<diddledan> (actually supertuxkart does - as I discovered while trying to get downloads for the snap)
<diddledan> you can't point snapcraft at a sourceforge download url. it will download an html page instead even if you used the "direct link" url, because omg adverts
<mborzecki> dl.sourceforge.net does not work anymore?
<diddledan> I couldn't get anything to work, and there wasn't much information on other people getting automated downloads working
<mvo> jdstrand: are you merging 2.31 into policy-updates-xxv-2.31 or shall I ? sorry for being a bit pushy, I want to do a bionic upload before my EOD :)
<diddledan> I saw anecdotal statements that suggest that sf does user-agent sniffing so if snapcraft pretends to be wget it might work
<mborzecki> diddledan: yocto uses a weird mix: https://paste.ubuntu.com/p/Nds4R5T3d6/ but I don't recall if the downloader teaks user-agent string, probably not (it used to be wget in the past btw)
<mcphail> diddledan: the nextcloud snap uses sourceforge for the boost source code
<diddledan> hmm
<diddledan> what was I doing wrong then?
<mcphail> maybe it has changed. My nextcloud snap repo is very very stale. But it built when I last tried it
<jdstrand> mvo: I am. I was running run-checks :)
<jdstrand> and then got pinged
<jdstrand> and asked to look at something
<jdstrand> etc
<jdstrand> etc
 * jdstrand is on it :)
<mvo> jdstrand: cough - already done
<mvo> jdstrand: sorry for being (yet again) too impatient
<jdstrand> mvo: oh heh. well, I repushed after pulling
<mvo> jdstrand: thats fine, no worries
<mvo> jdstrand: travis is handing out slots slowly today anway :/
<jdstrand> mvo: so, other than nursing that PR, I don't have anything planned for 2.31.1
<jdstrand> (fyi)
<jdstrand> I picked up a new item in the forum today, but not worth respsinning everything
<mvo> jdstrand: sounds good, if anything last minute comes up please just ping me - the plan is to have 2.31.1 on monday for beta and 2.31 (.0) in stable monday
<mvo> (and 2.31.1 a week later in stable)
<jdstrand> mvo: right. trying not to interfere with any of that, and ack
<mvo> jdstrand: :) ta
 * zyga goes to do taxes, ttyl
<zyga> (and enjoy your weekends!)
<Chipaca> zyga: you too
<Chipaca> enjoy your taxes!
<Chipaca> :-p
 * kalikiana wrapping up for the week
 * Chipaca whacks spread on the head with some stale bread
<diddledan> in bed
<diddledan> with a disembodied head
<diddledan> dammit, I used head a second time
<diddledan> how about "with a lump of lead"
<Chipaca> diddledan: that's leadership
<Chipaca> zyga: when you've whacked your taxes enough, I was wondering why findUid in snap-seccomp returns a uint64
<Chipaca> (when uids are uint32)
<Chipaca> (but only if you're doing things right)
<mup> Issue snapcraft#1932 opened: Revamp tests that verify correct utility is being used (deb/snap/docker) <Created by kyrofa> <https://github.com/snapcore/snapcraft/issue/1932>
<mup> PR snapcraft#1910 closed: tests: expect in-snap unsquashfs when using docker <Created by kyrofa> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1910>
<Chipaca> mwhudson: go in 1.10/beta is older than 1.10/candidate, which is a little surprising; is this on purpose?
 * mvo is slightly sad that the two 2.31 PRs still did not get a travis slot :(
 * Chipaca pushes more PR to make mvo sadder
<Chipaca> or I could grab a beer
 * mvo considers tea
 * Chipaca hugs mvo
 * mvo hugs Chipaca 
<brunosfer> Hi guys! I'm building a snap that needs access to bluetooth sdp however I can't figure out what configs I have to make in the snapcraft.conf to make /var/run/sdp appears on the system.
<brunosfer> I mean snapcraft.yaml file
<Chipaca> brunosfer: that sounds like a topic for the forum, to me
<brunosfer> chipaca: true! I've done that Dec 17th and I'm still struggling here... https://forum.snapcraft.io/t/failed-to-connect-to-sdp-server-permission-problem/3085
<Chipaca> brunosfer: huh, looks like nobody saw that
<Chipaca> niemeyer: is there a way to 'bump' a post that got no replies, so it's close to the top again? without just answering gibberish on it i mean
<Chipaca> ah he's probably asleep
<Chipaca> brunosfer: man, you've waited two months
<Chipaca> brunosfer: is there any more info you can add to that? this'll serve the double purpose of bringing it to the top so people see it, and adding more context for people that know thiss tuff
<Chipaca> brunosfer: (OTOH it's friday and europe and large chunks of asia have mostly checked out for the weekend already)
<niemeyer> Chipaca: I'm afraid not, on both counts
<niemeyer> Chipaca: The traditional way is indeed to ping
<Chipaca> niemeyer: np
<Chipaca> i feel bad that that's sat unanswered for two months :-(
<Chipaca> but i don't know the answer (i can barely understand the question :-) )
<Chipaca> ogra_: you gone?
<brunosfer> chipaca: I've been developing my snap from scratch but I knew that was a problem when I was trying to set up a regular connection using bluetooth. But now I hava everything done and I'm stuck on that problem.
<Chipaca> brunosfer: do you see any denials in the logs?
<brunosfer> chipaca: I'm going to add more information on the forum, hoping to get some solution, I'm on a 2 week streak trying to get this up and I can't figure it out...
<diddledan> if you don't have them try adding network and/or network-bind
<diddledan> although being a bluetooth specific thing I am not expecting that'll help
<Chipaca> jdstrand: is there a forum post about figuring out denials? i thought there was but i can't find it now
<diddledan> `snappy-debug.security scanlog`
<jdstrand> yeah
<diddledan> brunosfer: did you add and connect either or bluetooth-control or bluez?
<diddledan> of*
<jdstrand> Chipaca: https://forum.snapcraft.io/t/security-policy-and-sandboxing/554
<Chipaca> jdstrand: thanks
<jdstrand> Chipaca: I suspect Debugging and Tips are what you're after
<jdstrand> (two different sections)
<brunosfer> diddledan: I created a slot that is connected to both services you mentioned
<diddledan> no, a plug
<diddledan> the slots for those two are provided by core
<brunosfer> diddledan: could you give an example of how would you connect a plug to those slots?
<diddledan> in your `apps:` section for an app add to `plugs:` an entry for each, e.g. `plugs: [bluetooth-control, bluez]`
<diddledan> then it's just a case of rebuilding the snap and running `snap connect your-snap:bluetooth-control` and `snap connect your-snap:bluez` (once you've installed the new build)
<diddledan> bluetooth-control is for kernel interactions with the bluetooth device(s) where bluez is a library/daemon which marshalls communication, so depending on which method your app uses to interact you'll only need one of them
<diddledan> their descriptions, what little there is of them, is at https://docs.snapcraft.io/reference/interfaces
<diddledan> there's not much more than I've already stated though
<brunosfer> diddledan: thanks for the help. I'm going to try that ;)
<diddledan> there can only be one `plugs` list per app in the `apps:` block, so you might (read: are likely to) need to merge with the one already there
<mup> PR snapd#4675 closed: timeutil: fix scheduling on nth weekday of the month <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4675>
<mup> PR snapd#4688 closed: interfaces: miscellaneous policy updates for home, opengl, time-control, network, et al - 2.31 <Created by jdstrand> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4688>
<jdstrand> mvo: thanks! :)
<mvo> jdstrand: thank you!
<jdstrand> :)
<kyrofa> Chipaca, you still around?
<brunosfer> diddledan: Yes I just did that, however when I do `snapname.sdptool browse local` it shows that sdp is missing permissions.
<diddledan> hmm
<diddledan> I wonder what permissions it wants
<brunosfer> diddledan: sdp file /var/run/sdp file doesn't exist.
<diddledan> it might be possible to configure that to go to $SNAP_DATA or $SNAP_USER_DATA
<diddledan> it'll need sdptool to play ball though
<brunosfer> diddledan: To solve this issue on Ubuntu Artfull I do chmod 777 /var/run/sdp
<brunosfer> diddledan: However here that file doesn't exist.
<Chipaca> cachio__: you around?
<Chipaca> kyrofa: I am still around (now)
<Chipaca> (was having dinner and watching steven universe with the boys)
<cachio__> Chipaca, yes
<kyrofa> Chipaca, you answered me in the forum, no problem :)
<Chipaca> cachio__: do you know, during sru validation, whether core is from stable or edge?
<Chipaca> kyrofa: i am awesome, i am
<kyrofa> Indeed you are
<cachio__> Chipaca, we update from stable
<cachio__> Chipaca, and use the stable which is in proposed
<cachio__> Chipaca, why?
<Chipaca> cachio__: proposed isn't a channel though, you mean candidate?
<Chipaca> cachio__: the core snap, not snapd
<cachio__> Chipaca, the core snap is the one in stable
<Chipaca> I could always leave it as is, and know it'll break the first time you do sru validation :-)
<Chipaca> cachio__: ah, perfect, i'll set it to test that then
<cachio__> Chipaca, nice, just ping me if you need any help
<Chipaca> kyrofa: I'll also be updating the forum post once the PR's in
<Chipaca> (currently running tests on a different PR, then i'll do that one, and one further, and then i'll call it a month)
<mup> PR snapcraft#1933 opened: schema: remove underscore from version pattern <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1933>
<kyrofa> Chipaca, you're out for a few weeks? Nice
<kyrofa> Anything fun?
<mup> PR snapd#4697 closed: osutil: refactor EnsureFileState to separate out the comparator <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4697>
<Chipaca> kyrofa: no, i'm just wishing we were at eom already
<kyrofa> Hahaha
<mup> PR snapd#4698 opened: snap: remove underscore from version validator regexp <Created by chipaca> <https://github.com/snapcore/snapd/pull/4698>
<zyga_> Chipaca I don't remember, we probably fished that code from future golang and that was the type that was used but perhaps I'm mistaken
<Chipaca> niemeyer: are you _still_ here ?
<zyga_> Chipaca taxes done
<zyga_> now dinner time
<Chipaca> zyga_: :-)
<zyga_> how's stuff ?
<zyga_> Chipaca ohhh
<zyga_> underscores
 * zyga_ has horror memories from 15.04
 * Chipaca nods
 * Chipaca __nods__
<__chip__> oh know what have you done
<zyga_> Chipaca remember when I joined and there was some obscure part of data that was only conveyed through a filename that used undesrcore encoding
<zyga_> *underscore
<zyga_> when we were just starting with interfaces I had issues with switching the whole code over to that
<zyga_> because of this obscure thing that was used as a way to communicate
<zyga_> I think it was services and udev related
<zyga_> it was soooooo weird back then
<zyga_> man, I don't want to remember that code anymore
<zyga> jdstrand I see you
<zyga> http://blog.dustinkirkland.com/2018/02/10-amazing-years.html
<__chip__> zyga: developer namespace
<zyga> is that you on the right there?
<mup> PR snapcraft#1934 opened: catkin plugin: support recursive rosinstall files <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1934>
<Chipaca> man, if I'd gotten a second +1 on #4659 i could land it and deconflict the smaller, easier one
<mup> PR #4659: snap: improve the version validator's error messages <Blocked> <Created by chipaca> <https://github.com/snapcore/snapd/pull/4659>
<zyga> doing
<zyga> aww, I already looked
<zyga> Chipaca I can give you +1
<Chipaca> zyga: you already did
<zyga> merge it :)
<zyga> it's easier to ask for forgiveness
<mup> PR snapcraft#1935 opened: elf: contemplate more patching scenarios <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1935>
<zyga> especially on fun and good features
<Chipaca> zyga: :-)
<Chipaca> we should change it to "2 +1s or 1 +1 from all those awake"
<jdstrand> zyga: oh, hehe
<zyga> Chipaca jdstrand will give you a +1
<zyga> ;-)
<Chipaca> oooohhhh
<Chipaca> the most secure error messages! \o/
<Chipaca> zyga: OTOH RFC PRs don't make much sense if I'm not going to wait for comments
<zyga> true
<zyga> maybe time to EOD? :-)
<pedronis> Chipaca: that sort of detailed errors would make more sense if snapcraft used this for validation
<Chipaca> pedronis: I hope to get us there soon
<niemeyer> Chipaca: Sort of :)
<niemeyer> Chipaca: Anything I can help with?
<Chipaca> i mean, that's the plan, right? have 'snap pack' be its own standalone tool (that works cross-platform)? and it might as well validate as well
<niemeyer> Yeah, that's indeed the plan
<Chipaca> niemeyer: it was about snap info alignment, but it wasn't important or I'd remember more
<niemeyer> Chipaca: Ack :)
<Chipaca> I'd like to get that working soon, fwiw
<Chipaca> but not today :-)
<niemeyer> The good news is that Spread just managed to allocate 50 machines in a blast
<niemeyer> The bad news is that it allocated 28 more too :P
<zyga> wow, we're all heere
<zyga> on friday
<kyrofa> Here's mvo?
<kyrofa> Where's*
<niemeyer> Sleeping or enjoying his family, I hope!
<jdstrand> Chipaca: done
<jdstrand> and with that
<jdstrand> see you Tuesday :)
<Chipaca> jdstrand: thank you :-)
<Chipaca> jdstrand: have a good one
<jdstrand> you too :)
<niemeyer> Okay, I have a good case to debug when I'm back, but now I really need to do something else for a while..
<niemeyer> Have a good weekend all
<Chipaca> niemeyer: you too dude, get some sleep
<jdstrand> bye niemeyer :)
<mup> PR snapd#4659 closed: snap: improve the version validator's error messages <Blocked> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4659>
<mup> PR snapd#4699 opened: cmd/snap: tweaks to 'snap info' output <Created by chipaca> <https://github.com/snapcore/snapd/pull/4699>
<nacc> niemeyer: c-n-f on bionic now emits a snap related warning
<nacc> error: unknown command "advise-snap", see "snap --help"
<nacc> fix already in progress/available/
<nacc> ?
<nacc> not sure if anyone else from snappy is around, oh well
<mup> PR snapcraft#1936 opened: storeapi: handle errors even for >400 responses <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1936>
<mup> PR snapd#4681 closed:  testutil: add File{Matches,Equals,Contains} checkers <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4681>
<mup> PR snapd#4698 closed: snap: remove underscore from version validator regexp <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4698>
<Chipaca> nacc: huh
<Chipaca> nacc: how're you getting that?
<nacc> Chipaca: wheneve c-n-f tries to run
<Chipaca> how, not when :-)
<Chipaca> nacc: do you have any snaps installed?
<nacc> Chipaca: typing any not existing command i mean
<nacc> Chipaca: sure
<nacc> core git-ubuntu
<Chipaca> nacc: what version is your core ?
<nacc> 16-2.30
<Chipaca> (beyond that, it's obviously a bug because the idea was to c-n-f to skip it if it failed)
<nacc> Chipaca: i can file one if you like; perhaps i'm due for a reboot?
<Chipaca> nacc: nah, can you try using 'candidate'?
<nacc> Chipaca: for core?
<Chipaca> nacc: snap refresh core --candidate
<Chipaca> yes
<nacc> one sec
<nacc> Chipaca: fixed
<nacc> Chipaca: will that roll out soon? i'd rather not track candidate unless i need to
<Chipaca> nacc: yes
<nacc> Chipaca: ok, thanks!
#snappy 2018-02-17
<mup> PR snapcraft#1937 opened: store: support pushing snap with no architectures <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/1937>
<mup> PR snapcraft#1933 closed: schema: remove underscore from version pattern <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1933>
<mup> PR snapcraft#1931 closed: No plainbox <bug> <Created by yphus> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1931>
<mup> PR snapcraft#1937 closed: store: support pushing snap with no architectures <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1937>
<mup> PR snapcraft#1938 opened: tests: improvements to demos <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1938>
<mup> PR snapd#4700 opened: interfaces/builtin: add the dvb-video interface <Created by ThyMYthOS> <https://github.com/snapcore/snapd/pull/4700>
<niemeyer> nacc: Thanks for the report, and yeah, that's definitely a bug because even if you have no snap around at all, it should still not report anything
 * zyga starts to see failures on     - linode:ubuntu-14.04-64:tests/main/security-device-cgroups:uinput
<hurricanehrndz> how do you audit snaps, where can you find the yaml build files
<zyga> hurricanehrndz not all snaps publish source files and build instructions
<hurricanehrndz> Ah...
<hurricanehrndz> got it
<hurricanehrndz> So it would be a good way for someone to distribute or install a malicious app without really knowing
<hurricanehrndz> That's sad
<zyga> not better than all the other ways that already exist
<diddledan> hurricanehrndz: it's better than a PPA or direct download because of the confinement
<hurricanehrndz> zyga: true, but at least with debs you can audit, diddledan: very true although some are classic
<zyga> hurricanehrndz how can you audit skype.deb from microsoft?
<hurricanehrndz> zyga: Point taken
<zyga> all the old ways of being nasty are there, nothing is new, it's slightly safer as people will, over time, look for random packages less and less and will use the store
<hurricanehrndz> I guess I learn a lot from example, so what I was trying to find is the source yaml files from the qt team since I have heard they have done a good job on making it easier
<zyga> where we have more confinement than usual, we can stop nasty apps once they are know, etc
<zyga> I think one think we ought to improve is to point the way to the source for FOSS snaps
<hurricanehrndz> I'm just having a hard time finding the source files, I have stumble on a couple on lauchpad
<hurricanehrndz> zyga: Yes, that would be awesome
<hurricanehrndz> zyga: that way other devs could contribute
<zyga> I'll check if that's on the roadmap, it's very sensible and should be easy to add
<hurricanehrndz> zyga: Thank you.
<diddledan> for snaps built by the build service the source git repo should be automatically added to metadata IMO
<zyga> I cannot find anything quickly, I will check with snapcraft devs next week
<hurricanehrndz> Is there anyway right now for me to find that source for foss projects in the snapstore online
<diddledan> for all the snapcrafters ones they're at github.com/snapcrafters, to begin with
<diddledan> others are either under individual user accounts for community maintained ones, so those you'll possibly need to contact the author, and others are maintained directly by upstream so it's likely wherever they usually keep their source
<zyga> hurricanehrndz you can also search for snapcraft.yaml on github
<hurricanehrndz> lol
<hurricanehrndz> of course
<hurricanehrndz> Thanks zyga, and thanks for passing that onto to devs, I think having a pointer listed in the output of info would be helpful to foster greater collaboration
<hurricanehrndz> zyga: or a support url in order to submit bugs as well
<zyga> yeah, I think that's some great feedback, thank you
<zyga> I think we have that one already
<zyga> AFAIR
<hurricanehrndz> Let me check
<diddledan> support url already exists
<hurricanehrndz> How do I get it, sorry very new to snaps
<zyga> snap info $snapname
<diddledan> run `snap info corebird` for example
<diddledan> it points to the snapcrafters repo's issue tracker
<hurricanehrndz> Yup, got it, I was checking vscode and that only has an email
<diddledan> flexiondotorg is idling here :-p he's out to curry right now though so you'll not get a reply :-D
<ahayzen> diddledan, github.com/snapcrafters seems to be what is in edge not stable ? Is there a place for the stable snapcraft.yaml ?
<zyga> ahayzen interesting point!
<diddledan> hmm?
<diddledan> I don't understand
<ahayzen> eg mattermost-desktop is 3.7.1 in the store, 4.0 on github/snapcrafters, mumble is 1.2.17 in the store, 1.3.0 in github/snapcrafters
<ahayzen> i haven't been able to find the snapcraft.yaml that is for the stable builds
<diddledan> the repos have a history you can go through
<ahayzen> that's not really useful, they aren't even tagged
<ahayzen> i can't create a reproducible build with that as i don't know which commit was used
<zyga> I think this is all valid feedback, we're just getting started with that aspect of snaps
<zyga> but I think there are some low hanging fruit there
<mup> PR snapcraft#1936 closed: storeapi: handle errors even for >400 responses <bug> <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1936>
#snappy 2018-02-18
<mup> PR snapd#4701 opened: Release/2.31 <Created by sevadmin> <https://github.com/snapcore/snapd/pull/4701>
 * Son_Goku pokes niemeyer 
<niemeyer> Here
<Son_Goku> niemeyer: there doesn't appear to be any valid licensing for spread itself
<Son_Goku> could you look to license it properly under some kind of Free Software license?
<niemeyer> Son_Goku: Ah, thanks for raising that.. yeah, there should be a license file there for sure
<Son_Goku> I was looking to package it for my use, and lo, no licensing
<Son_Goku> somehow we went 158 commits and two years without noticing this :P
<niemeyer> Son_Goku: Done
<Son_Goku> :D
<niemeyer> Son_Goku: Yeah, not too surprising.. this is more of a helper tool for us
<Son_Goku> niemeyer, also did you guys get a new person?
<Son_Goku> I saw a pull request open by some guy who has no meaningful profile in the snapd repo
<Son_Goku> https://github.com/snapcore/snapd/pull/4701
<mup> PR #4701: Release/2.31 <Created by sevadmin> <https://github.com/snapcore/snapd/pull/4701>
<Son_Goku> when I first saw it, I thought you guys might have been hacked...
<Son_Goku> I'm not sure you haven't, tbh
<niemeyer> Son_Goku: Why does that taste like hacking?
<niemeyer> Son_Goku: I mean, anyone can push PRs, right?
<Son_Goku> niemeyer, the guy has no proper profile, it's the only thing he's actually done
<Son_Goku> and the doesn't even look right
<Son_Goku> err, the PR doesn't look right
<Son_Goku> maybe...
<Son_Goku> you know, I've never tried
<niemeyer> Son_Goku: I know, but pushing a PR requires zero permissions
<Son_Goku> huh, you're right
<Son_Goku> so it's just a weird guy hitting buttons
 * Son_Goku shrugs
<Son_Goku> carry on then
<Son_Goku> pushing a PR from a branch you don't control to another branch you don't control is apparently possible
<niemeyer> Son_Goku: Yeah, proposing is open
<hurricanehrndz> Anyone know how to use version from git
<hurricanehrndz> https://github.com/snapcore/snapcraft/pull/1260
<mup> PR snapcraft#1260: meta: version from git support <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1260>
<hurricanehrndz> Yes, I have read through it
<hurricanehrndz> I get fatal error though, not a git repository
<hurricanehrndz> My part is git, snapcraft is not git
<niemeyer> hurricanehrndz: Not sure I get what you mean.. would you mind to open a topic in the forum with more details?  We have several eyes there and more chances of helping you out quickly
<hurricanehrndz> niemeyer: Thanks, I might have thought of away around the issue
<niemeyer> hurricanehrndz: np, and please let us know if you need some info
<mup> PR snapd#4701 closed: Release/2.31 <Created by sevadmin> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/4701>
<mup> Issue snapcraft#1939 opened: rust plugin: i386 multiarch linker error  <Created by General-Beck> <https://github.com/snapcore/snapcraft/issue/1939>
<hurricanehrndz> niemeyer: okay so I found the issue, version: git only works when the snap files are part of the original projec
<hurricanehrndz> if you are building a snap from another dev's project and using source-type: git, it doesn't work
<mup> PR snapd#4702 opened: cmd/snap: also include tracking channel in list output <Created by chipaca> <https://github.com/snapcore/snapd/pull/4702>
<popey> hurricanehrndz: correct. We sometimes have to jump through hoops to set the version number when the yaml isn't in the upstream source
<popey> hurricanehrndz: like this. https://github.com/snapcrafters/discord/blob/master/snap/snapcraft.yaml#L15
<hurricanehrndz> popey: thank, I saw that in another one of your contributions. I think atom
<hurricanehrndz> Anyone have a dbus example?
#snappy 2019-02-11
<zyga> good morning
 * zyga welcomes everyone after the busiest break ever :)
<zyga> brb
<zyga> re
<zyga> hello mvo :)
<mvo> hey zyga
<zyga> how are you doing?
<mvo> zyga: I think what you had last week (infection) got me sunday and today :/
<mvo> zyga: but otherwise doing well!
<zyga> ouch, good luck with that
<mvo> zyga: how are you?
<pstolowski> morning!
<zyga> hey pstolowski
<zyga> mvo: tired
<zyga> mvo: they are still at the hospital
<zyga> maybe if all goes good they will be back on Tuesday
<zyga> but I was told the exact same thing a week ago
<mvo> zyga: uh, good luck!
<mvo> sil2100: hey, are you guys in the process of building new cosmic images or something? or any other reason why our snapd sru to comsic got rejected?
 * zyga goes to make tea, picks up ancient PR https://github.com/snapcore/snapd/pull/6111
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<mwhudson> mvo: the message i saw implied that vorlon wanted the version currently in -proposed to migrate to updates rather than superseding it and waiting another 7 days
<mvo> mwhudson: aha, misread the message then
<mvo> mwhudson: yeah, thats fine
<mvo> mwhudson: I missed that cosmic got accepted
<mwhudson> mvo: well, or i did :)
<sil2100> mvo: it got rejected? What was the rejection message?
<pstolowski> mvo: hey, i've run console-conf twice and it consistently fails on network_wifi_static test - http://paste.ubuntu.com/p/fGwfvvSymX/ - know? must be a flaky test since i had no issue with console-conf during all the previous testing
<pstolowski> *known
 * dot-tobias says hi
<Chipaca> o/
<zyga> hey Chipaca
<zyga> it's good to be back :)
<Chipaca> zyga: :-) you're feeling better, then?
<Chipaca> zyga: less contagious?
<zyga> Chipaca: yes
<zyga> Chipaca: though the expanded family is not reunited yet, they are still at the hospital for a few more days
<zyga> but there's good progress so hopefully by the middle of the week we'll be all home
<popey> Chipaca: can I just give you (and team) a massive <3 for having the date in snap info now. It really improves my workflow.
<sil2100> mvo: ok, hmmm
<mvo> pstolowski: thanks! now that sergio is back its probably best to check with him, I have not run this test myself on the pi, only in a VM
<pstolowski> mvo: ok
<sil2100> mvo: so, since there's 2.37.1+18.10 in cosmic-proposed ready to go, I guess Steve wanted that to be released, right?
<sil2100> mvo: I remember you mentioned .1 didn't have any blocking issues?
<Chipaca> popey: that one goes all the way up to sabdfl
<popey> It's ace
<mvo> sil2100: sorry for the slow reply, was in a meeting
<mvo> sil2100: there is one small issue if people have symlinks in /var/lib/jenkins
<mvo> sil2100: but I think we can fix this by removing "/var/lib/jenkins" from the core snap
<mvo> sil2100: I slightly prefer .2 as it fixes this known regression but its really a corner case
<sil2100> eeek, so the core18 'fix' for jenkins that added /var/lib/jenkins actually caused a regression?
<pedronis> sil2100: it was not really a fix actually
<mvo> sil2100: we misunderstood a subset of the bug :(
<zyga> hey pedronis :)
 * Chipaca takes a break
<mup> PR snapd#6488 opened: interfaces/network-manager: no peer label check for hostname1 <Created by alfonsosanchezbeato> <https://github.com/snapcore/snapd/pull/6488>
<pstolowski> mvo: do you have a moment to re-review https://github.com/snapcore/snapd/pull/6486 ? that would unblock another pr
<mup> PR #6486: interfaces/hotplug: renamed RequestedSlotSpec to ProposedSlot, removed Specification <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6486>
<pstolowski> cachio: hey
<cachio> pstolowski, hey
<dot-tobias> If someone from the Snappy HWE team would be so kind to have a look at this: https://forum.snapcraft.io/t/apparmor-denials-for-dbus-objectmanager-network-manager/9885/4?u=tobias â any ETA for network-manager 1.10 track on ARM?
<pstolowski> cachio: how was your holidays?
<cachio> pstolowski, awesome!!! thanks for asking
<mvo> hey cachio ! welcome back
<cachio> mvo, thanks
<cachio> I am in the jungle again :(
<cachio> mvo, I am creating images to run beta validation for 37.2
<pstolowski> cachio: great!
<pstolowski> cachio: i've been running console-conf validation tests this morning, and network_wifi_static test was failing consistently; is this a known issue? full log - http://paste.ubuntu.com/p/fGwfvvSymX/
<cachio> pstolowski, checking
<cachio> pstolowski, it was passing during last executions
<cachio> pstolowski, which board is that?
<cachio> pi2 pi3?
<pstolowski> cachio: pi3
<pstolowski> cachio: it's possible i did something wrong. the testing guide doesn't tell to pre-configure pi3 before tests, but i found it was necessary (manual setup of console-conf on first boot, so that test scripts can connect)
<cachio> pstolowski, yes, initial setup is required
<cachio> it is for 37.2?
<cachio> niemeyer, hey
<cachio> niemeyer, I see a permissions error creating new images https://paste.ubuntu.com/p/zsPBGfszkw/
<niemeyer> cachio: Hey
<cachio> niemeyer, all the images scripts have failed due to this permission error
<Chipaca> ogra: curious that you'd have 6 hardlink-count-1 files in the cache; has anything strange happened recently?
<Chipaca> ogra: like, snapd crashing mid install?
<Chipaca> or â¦ dunno :-)
<niemeyer> cachio: Are you sure you have the right credentials?  Just reminding of the previous issue we discussed
<niemeyer> cachio: I'm checking the project
<cachio> niemeyer, well, those scripts are using the sa that you created a time ago
<cachio> the new one
<cachio> image-baker
<niemeyer> cachio: I know they should be.. just raising the fact last time it was a credentials issue.
<niemeyer> cachio: Anyway, checking
<Chipaca> ogra: ah, figured it out, you've done a 'snap remove' :-)
<pstolowski> cachio: ok. i'm pretty positive console-conf works and it was just something wrong with the test. i've been using console-conf manually a lot last week during beta-validation
<Chipaca> where should I put a de-logger? (that converts the debug http snapd logs to something more legible) test-snapd-tools?
<cachio> pstolowski, it is probably there is a problem with the test, I'll check it later today
<cachio> pstolowski, it is for 2.37.2 right?
<niemeyer> cachio: Done, please test now
<niemeyer> cachio: Something must have changed in the code
<niemeyer> cachio: Either way, I just added the permission.. doesn't seem problematic
<pstolowski> cachio: right
<cachio> niemeyer, what I saw reviewing the logs is that the image is created but the permission error is raised
<cachio> niemeyer, no code changes in our side but perhaps the google library I am using changed
<niemeyer> cachio: That's what I mean too
<cachio> niemeyer, :)
<cachio> niemeyer, thanks for the update
<niemeyer> cachio: Please let me know if it works
<cachio> niemeyer, can I run it now?
<cachio> niemeyer, in progress
<zyga> hey niemeyer :)
<zyga> hey cachio :)
<niemeyer> zyga: Heya!
<niemeyer> zyga: How're things there?
<zyga> niemeyer: great, I just got a call from my wife that they are coming home today :)
<niemeyer> zyga: Fantastic news
<mvo> zyga: \o/
<mvo> cachio: thank you for the validation, we did a lot of those already, give me a sec, I will send you our trello link
<cachio> mvo, THANKS
<zyga> mvo: I've built the early version of refresh-app-awareness
<zyga> zyga@yantra:~/snapd/cmd/snapd> snap refresh gnome-calculator
<zyga> error: cannot refresh "gnome-calculator": snap "gnome-calculator" has running apps or hooks
<zyga> niemeyer: ^ will be ready for review by the next sprint
<mvo> cachio: see /msg - I sent you the link and also added you to the card
<mvo> zyga: nice!
<mvo> zyga: really nice
<niemeyer> zyga: Sweet!
<niemeyer> zyga: How's the strategy for not delaying forever going?
<zyga> niemeyer: it's not, I just started on this todat
<zyga> (I'm back after last week)
<niemeyer> zyga: Ack
<cachio> mvo, nice, it is ok if I finish the missing ones?
<zyga> niemeyer: I think we will do what was planned in cape town
<cachio> niemeyer, ERROR: (gcloud.compute.images.create) Could not fetch resource:
<cachio> zyga, hey
<mvo> cachio: sure
<mvo> cachio: thank you!
<zyga> all of the code so far is on https://github.com/snapcore/snapd/compare/master...zyga:feature/refresh-app-awareness?expand=1
<cachio> mvo, I'll update the card
<cachio> and review the results
<niemeyer> cachio: ?
<cachio> niemeyer, it is failing but now with that permission error
<niemeyer> cachio: That's not a permission error
<mvo> cachio: great, thank you!
<niemeyer> cachio: The permission error is what comes below it
<zyga> Chipaca: hey
<Chipaca> zyga: 'sup
<zyga> do you have a minute for a  silly question
<zyga> so I added an extra check in Update and UpdateMany
<zyga> when I run snap refresh gnome-calculator
<cachio> niemeyer, right now it failed because I need to clean up the temp images
<zyga> I get this delay of about 4 seconds
<cachio> niemeyer, sorry, there was a name overlap
<zyga> and then it does stuff and actually says that the snap cannot be refreshed
<niemeyer> cachio: Coo
<niemeyer> l
<zyga> Chipaca: so either I did something silly and I really do the refresh check and then fail
<zyga> or something else is at play
<zyga> any ideas
<zyga> ?
<zyga> Chipaca: https://github.com/snapcore/snapd/compare/master...zyga:feature/refresh-app-awareness?expand=1#diff-4f584006240926759b614bfd921c5fc0R1147
 * Chipaca looks
<Chipaca> zyga: I'm not sure where the 4 seconds are coming from, but you're checking all snaps instead of just those that have a refresh?
<zyga> Chipaca: I'm checking those that have the refresh, I think
<Chipaca> zyga: you get the candidates after doing the soft refresh check
<zyga> right
<zyga> so it shouldn't be slow, right?
<Chipaca> zyga: log stuff before, during, and after the loop?
<zyga> is UpdateMany hit on one snap name?
<zyga> or is that always routed to Update?
<Chipaca> zyga: one snap goes to Update
<pedronis> Update takes many more options
<pedronis> snap refresh <1 snap>
<pedronis> always goes through Update
<zyga> 2019/02/11 14:03:42.831902 snapstate.go:1174: before soft check
<zyga> 2019/02/11 14:03:42.832542 snapstate.go:1176: failed soft check
<zyga> so the check itself is fast, must be something prior to that
<zyga> I'll dig
<pedronis> might be assertion refreshes
<Chipaca> zyga: sorry, silly question
<pedronis> if you have a lot of snaps
<Chipaca> zyga: why check before looking for candidates?
<Chipaca> you'd be erroring out even for snaps that don't have a refresh
<zyga> ah, good point
<zyga> well
<pedronis> that sounds wrong :)
<zyga> hmm
<pedronis> especially for auto-refresh
<Chipaca> zyga: also, also
<Chipaca> zyga: why is softwarerefreshcheck not cehcking all snaps in a batch?
<zyga> if you are running and you are asking to refresh something is it better to get <delay>nothing to do or <delay>cannot because running?
<zyga> Chipaca: why would it?
<Chipaca> zyga: the things it's doing look like they'd be a lot more efficient checking for N snaps at once instead of 1 at a time in a loop
<zyga> which things specifically?
<zyga> I could move the get-from-state part outside of the function
<zyga> but other than that?
<zyga> Chipaca: as for timing, Update is called after the delay, so something else is slow
<zyga> Chipaca: zyga@yantra:~/snapd/cmd/snapd> SNAPD_DEBUG=1 snap refresh gnome-calculator
<zyga> 2019/02/11 14:06:22.606869 cmd_linux.go:70: DEBUG: re-exec not supported on distro "opensuse-tumbleweed" yet
<zyga> 2019/02/11 14:06:27.672286 error.go:100: DEBUG: error: cannot refresh "gnome-calculator": snap "gnome-calculator" has running apps or hooks
<zyga> error: cannot refresh "gnome-calculator": snap "gnome-calculator" has running apps or hooks
<zyga> Chipaca: the check is entirely per-snap anyway
<Chipaca> zyga: the logs in snapd are the ones you want, not the ones in snap :-)
<ogra> Chipaca, nothing has happened but my install is really old so it could well bee that at some point something did happen
<ogra> definitely nothing recently though
<zyga> aha
<zyga> it checks for a zillion assertions first
<Chipaca> zyga: as pedronis siad
<Chipaca> said*
<Chipaca> ogra: but it should be cleaned up on any install/refresh
<ogra> hmm, weird then
<Chipaca> ogra: can you turn on debug and install something you don't have? (may i suggest 'icdiff' :)
<zyga> Chipaca: one more question
<Chipaca> zyga: shoot
<zyga> Chipaca: when refreshing many I may get three cases: some can be refreshed and some cannot or all can or cannot be refreshed
<zyga> when all cannot be refreshed it can be a synchronous error
<zyga> but when some can be refreshed
<zyga> I would like to refresh those
<zyga> and still do something sane with the ones I cannot
<ogra> Chipaca, not right now but i'll try that later
<zyga> any advice on that?
<Chipaca> zyga: it depends on what was requested
<zyga> snap refresh gnome-calculator core  # refreshing core in the background but failing the gnome-calculator refresh in a way that the user  sees
<pedronis> we have various code that does similar things right now just with logs
<pedronis> but has comments to move to warning
<zyga> I see
<Chipaca> zyga: if it's a bare 'snap refresh', I'd suggest to tell the user and update what can be done
<zyga> should that be a warning?
<zyga> Chipaca: tell via warning or is there another mechanism?
<Chipaca> hold on
<Chipaca> if it's "snap refresh foo bar baz", i'd say fail the whole thing
<Chipaca> auto-refresh, use warnings
<zyga> ok
<zyga> I'll try that :)
<pedronis> yes
<Chipaca> that's three different things
<zyga> but first, walk the dog
<Chipaca> 'snap refresh': print message, update what's updatable
<zyga> time is running quickly today
<Chipaca> 'snap refresh foo bar baz' -> error
<Chipaca> auto-refresh -> warning
<zyga> Chipaca: print message -> warning, right?
<zyga> or if not, how do I print?
<Chipaca> zyga: no
<zyga> logger or something smarter?
<cachio> niemeyer, https://paste.ubuntu.com/p/B6KnsSfsxG/
<cachio> niemeyer, same error
<Chipaca> zyga: abuse the fact that the log of tasks get printed to the user?
<Chipaca> not sure
<cachio> compute.globalOperations.get permission
<Chipaca> might need something adhoc
<niemeyer> cachio: The image admin service now has that permission
<zyga> haha, ok
<zyga> Chipaca, pedronis: thank you, that is super useful
<pedronis> Chipaca: we don't have good support for that case
<niemeyer> cachio: I suspect something very similar to the issue we've observed last time is taking place
<pedronis> Chipaca: inform but proceed
<Chipaca> pedronis: zyga: we could use warnings for the inform-but-proceed but it'd suck a bit
<pedronis> Chipaca: agreed
<Chipaca> unless we tweaked refresh for this case
<Chipaca> but if we're tweaking, we could tweak to jfdi
 * pedronis quick errands
<niemeyer> Oh my
<niemeyer> And now GCE just did something silly and destroyed the role due to the lack of atomicity of their operations
<niemeyer> ARGH
<cachio> niemeyer, :(
<niemeyer> Extremely frustrating
<niemeyer> cachio: We'll need to recreate the role again from the ground up.. but I'll have lunch first
<cachio> niemeyer, sure, np
<cachio> thanks for helping
<mup> PR snapcraft#2466 closed: ruby plugin: support new download URL <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2466>
<pstolowski> cachio: i think our nested vm images will need updating and checking, i found out last week while working on hotplug tests that 16.04 image couldn't be found anymore; i'm using SPREAD_NESTED_SYSTEM=bionic with google-nested:ubuntu-18.04-64 which works but upgrades grub and some other packages on every run
<cachio> pstolowski, thanks for the headsup
<cachio> I'll do it ones the issue with gce account is fixed, I hope today
<cachio> once
<sil2100> mvo: should we revert the core18 change for /var/lib/jenkins then?
<sil2100> mvo: I'm asking because I'd like to spin the first .2 core18 candidate images
<sil2100> mvo: is it safe to use the current core18 + snapd 2.37.1?
<mvo> sil2100: I think reverting adding /var/lib/jenkins is the right move
<sil2100> mvo: let me do that then, I'll try to fast-track the new core18 to stable ASAP
<mvo> sil2100: \o/
<niemeyer> cachio: I've recreated the role.. can you please give it a shot when you have a moment?  I'll likely have missed something
<cachio> niemeyer, hey, ready
<cachio> niemeyer, do we need a new sa.json file?
<pedronis> zyga: mvo: the two PRs I was mentioning were #6111 and #6410
<mup> PR #6111: packaging/opensuse: move most logic to snapd.mk <Created by zyga> <https://github.com/snapcore/snapd/pull/6111>
<mup> PR #6410: release-tools: add debian-package-builder <Created by zyga> <https://github.com/snapcore/snapd/pull/6410>
<niemeyer> cachio: No, I've just lost the roles
<niemeyer> cachio: Sorry, the permissions of the role actually
<cachio> niemeyer, nice
<cachio> niemeyer, I'll try again in that case
<niemeyer> cachio: Google replaced the permissions instead of updating, due to some kind of error in the console
<niemeyer> cachio: So I had to come up with the permissions again, which of course will likely be wrong
<mvo> pedronis: ok
<cachio> niemeyer, :(
<cachio> niemeyer, I am running a task now
<niemeyer> Thanks
<cachio> I'll let you know if it goes well
<pedronis> mvo: we also need to remove /var/lib/jenkins from core, right?
<pedronis> mvo: can we though? will it break 2.37.1 using things?
<mvo> pedronis: yeah, sil2100 is working on removing /var/lib/jenkins
<pedronis> mvo: from core18, there is also core
<mvo> pedronis: it should not break, we need to double check but its marked as "optional" in the snap-confine
<mvo> pedronis: we need to double check if that "optional" checks both sides of the bind mount
<pedronis> yes
<pstolowski> cachio: hey, one question, is it possible to re-run individual beta validation tests with the scripts? or only manually without help of the scripts (SPREAD_EXTERNAL_ADDRESS=...) ?
<pedronis> mvo: seems either side can be missing afaict
<mvo> pedronis: ok, if thats the case we should be good by just removing it from the core snap with no ill effects
<cachio> pstolowski, yes
<cachio> pstolowski, SPREAD_TESTS=external:ubuntu-core-16-arm-64:tests/main/interfaces-hostname-control
<cachio> will run just that test
<cachio> pstolowski, SPREAD_TESTS=external:ubuntu-core-16-arm-64:tests/main/interfaces-hostname-control,external:ubuntu-core-16-arm-64:tests/main/snap-logs
<cachio> will run both
<cachio> pstolowski, it is possible to skip tests too with SKIP_TESTS=tests/main/revert-devmode
<kjackal> Hey snappy people. I get a "Revision 410 is not approved." when trying to release microk8s on arm64. Why? How can I see what is wrong?
<roadmr> kjackal: why - it's still pending automated review. what's wrong? nothing, you just need to wait a bit for it to finish review :)
<kjackal> Ah, ok, where did you see that?
<kjackal> (I was afraid i broke something in the builders)
<roadmr> kjackal: in the dashboard.snapcraft.io page for microk8s; you'll notice (on the left side) that revision 410 has a clock next to it, indicating it's awaiting review
<roadmr> kjackal: if you click on it, you'll see "automated review not yet completed" and "task xxxxxx awaiting execution"
<kjackal> Ahh dashboard! I was only looking at the https://snapcraft.io/microk8s/releases
<kjackal> thank you roadmr
<Chipaca> pedronis: so, wrt macaroon expiry, indeed the refresh endpoint is ok and the download endpoint 401's
<diddledan> another thing to remember (if I'm right) is that automated tests are sequentrial, so if you have two builds ready for testing they will be done one-at-a-time
<diddledan> --r
<roadmr> kjackal: np. Usually if something breaks we let you know about it; if you have no news, it usually means things are going well
<kjackal> no news is good news!
<diddledan> ... unless Trump has gone quiet :-o
<roadmr> if you wish upon a star...
<mvo> pedronis: I addressed the remodel feedback now
<cachio> niemeyer, https://paste.ubuntu.com/p/mc3SttFRwv/
<cachio> this permission is missing
<niemeyer> cachio: Added
<cachio> niemeyer, tx
<pedronis> mvo: thanks, I will again
<pedronis> Chipaca: ok,  can we do something only snapd side or do we need store changes?
<mvo> ta
<cachio> niemeyer, images are being created now
<cachio> niemeyer, thanks for the support
<niemeyer> cachio: Nice, phew
<Chipaca> pedronis: there's nothing to tell snapd the macaroon is expired until suddenly download 401s
<Chipaca> hmmm
<Chipaca> pedronis: we could add code to just retry without the macaroon?
<mup> PR snapd#6486 closed: interfaces/hotplug: renamed RequestedSlotSpec to ProposedSlot, removed Specification <Hotplug ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6486>
 * Chipaca tries that
<pstolowski> pedronis: #5962 updated
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<vorlon> mwhudson, mvo: yes, cosmic-proposed version released now
<pedronis> Chipaca: can't we know we don't need to send the macaroon upfront ? do we produce an error early if it's just "snap refresh one-snap"
 * zyga waits for the final paperwork to go home from hospital
<zyga> I may be back to work some more later tonight but I think I will really be back tomorrow, this is a good time as any to EOD
<Chipaca> pedronis: wrt sending the macaroon, we can check private==false, and maybe there's code to check payment
<Chipaca> not sure we have all the bits for the latter but we might
<pedronis> Chipaca: there'a  Paid flag
<Chipaca> pedronis: where?
<pedronis> not sure if we keep around or not
<pedronis> Chipaca: on Info for sure
<Chipaca> pedronis: ah, details_v2 sets it from prices
<Chipaca> ok
<Chipaca> zyga: yeah, take family time
<Chipaca> pedronis: is this what we want to do?
<pedronis> Chipaca: possibly,  but best if to discuss this in Malta with the store?
<pedronis> Chipaca: does the test I mentioned btw passes or fail (on staging) ?
<Chipaca> pedronis: I don't know
<pedronis> Chipaca: could you try it ?
<mvo> vorlon: thank you, I will do a .2 soonish then
<Chipaca> pedronis: I don't know :-)
<Chipaca> pedronis: i don't know how to run spread against staging, do you know where that's documented / explained / described?
<pedronis> mvo: will do the PR to remove /var/lib/jenkins from core
<mvo> pedronis: thank you, please check with sil2100 to avoid duplication
<pedronis> mvo: sorry
<pedronis> mvo: I meant to ask will you do?
<pedronis> Chipaca: not sure it's documented, cachio should be able to tell you
<mvo> sil2100: hey, are you on the /var/lib/jenkins dir removal from core/core18 PR? asking because pedronis is keen to get rid of it and we want to avoid duplication of effort
<Chipaca> cachio: hiya. I'd like to run a spread test against the staging store. How do I do that?
<Chipaca> cachio: one of the ones that use SPREAD_STORE_USER and _PASSWORD
<cachio> Chipaca, you need to check a PR?
<Chipaca> cachio: master
<cachio> Chipaca, we ran today against master
<cachio> Chipaca, this is the log
<cachio> Chipaca, https://travis-ci.org/snapcore/spread-cron/builds/491457033
<Chipaca> pedronis: is system-files meant to be used to give you access to things in /sys?
<Chipaca> cachio: thanks!
<sil2100> mvo: I reverted the change in core18, I guess the packages are now in testing
<cachio> Chipaca, this is the config we use to run it https://github.com/snapcore/spread-cron/blob/snapd-staging-store/run-checks
<pedronis> Chipaca: in which sense?  it can be used for that, but a proper interface would be better
<Chipaca> pedronis: https://forum.snapcraft.io/t/snap-manual-review/9923 sense
<Chipaca> cachio: hmm
<pedronis> Chipaca: that's gpio stuff, it should use the gpio interface
<pedronis> unless they are trying to do something about more than one gpio
<pedronis> but anyway, it's not a use case for system-files
<sil2100> mvo: I mean, maybe I misunderstood, but is anything else required besides just reverting the dir-addition change? Do we have to somehow handle the removal on runtime? I don't think so, right?
<mvo> sil2100: just reverting the change in core/core18 should be enough indeed
<mvo> sil2100: sorry for the slow reply
<Chipaca> cachio: and where do the users come from? in particular the stg-dummydev user, whoever that is
<Chipaca> actually, pedronis ^ that user's only mentioned once in a change with your name on it
<pedronis> Chipaca: the secrets, sorry I need to reload state on this
<Chipaca> sergiusens: o/
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98
<pedronis> cachio: I reviewed #6320, small nitpick, I also changed the summary
<mup> PR #6320: tests: pre-cache core on core18 systems <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6320>
<cachio> pedronis, nice
<cachio> I'll take a look no
<cachio> w
<cachio> pedronis, thanks for reviewing this, fix will be ready in 1 minutes
<mup> PR snapd#6489 opened: tests: improve snaps-system-env test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6489>
<mup> PR snapd#6490 opened: tests: fix NFS home mocking <Created by stolowski> <https://github.com/snapcore/snapd/pull/6490>
<pstolowski> cachio: sorry, missed your erlier message. that's great, thanks! i'll propose a PR to add it to doc
<oneguynick> 2/join #raspberrypoi
<oneguynick> sorry
<oneguynick> wireless keyboard is dying
<cachio> pstolowski, nice
<cachio> thanks
<mup> PR snapd#6491 opened: interfaces: hotplug nested vm test, updated serial-port interface <Created by stolowski> <https://github.com/snapcore/snapd/pull/6491>
<pstolowski> np
<pstolowski|afk> cachio: i've just proposed the test for hotplug based on nested vm ^
<pstolowski|afk> cachio: since you split classic and core, we will need to have a separate one i suppose
<pstolowski|afk> cachio: (for core)
<cachio> pstolowski|afk, I'll take a look to that one
<sil2100> cwayne: hey! I'd like to promote the current core18 ASAP once it passes automation, how are things looking so far?
<sil2100> cwayne: I see some tests are still 'running', with some failures marked?
<cwayne> We gave the +1 to the last one but it got overwritten
<cwayne> Will take a look
<mup> PR snapcraft#2467 opened: [legacy] ruby plugin: support new download URL (#2466) <Created by kyrofa> <https://github.com/snapcore/snapcraft/pull/2467>
 * zyga is home with the rest of the family now :)
 * Chipaca EODs like a boss
 * Chipaca looks at mvo 
<Chipaca> ok, like a different boss
<sil2100> cwayne: I see the rpi3 tests are still running for core18, right?
<cwayne> sil2100: yes
<cwayne> You'll be the first to know when they're done
<cwayne> sil2100: I think we need to refine this process a bit though, we've already given a bunch of +1s for snaps in beta that then got immediately overwritten
<cwayne> IMHO a snap shouldn't really start this process unless it's meant to make it to stable
<mup> PR core#101 opened: Revert "Merge pull request #100 from mvo5/add-jenkins-dirs" <Created by pedronis> <https://github.com/snapcore/core/pull/101>
<pedronis> mvo: I went ahead and created this ^
<sil2100> cwayne: yeah, even without rebuilding it on every new ubuntu-base tarball, the velocity is still too high, since basically if any seeded package changes it (by design) triggers a rebuild
<sil2100> cwayne: I guess the base idea was that snaps in the pipeline would just stay in the pipeline and go forward
<sil2100> cwayne: but then there's still the thing about bandwidth usage
<sil2100> Of not-always-necessary constant updates
<cwayne> Yeah
<cwayne> IMHO it should be something like weekly + critical cves
<mvo> pedronis: thank you
<cwayne> sil2100: good to go
<mup> PR snapcraft#2456 closed: plugins: add colcon plugin <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2456>
<mup> PR snapd#6320 closed: tests: pre-cache core on core18 systems <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6320>
<mup> PR core#101 closed: Revert "Merge pull request #100 from mvo5/add-jenkins-dirs" <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/core/pull/101>
<mup> PR snapd#6489 closed: tests: improve snaps-system-env test <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6489>
<sil2100> cwayne: thanks!
#snappy 2019-02-12
<mup> PR snapcraft#2468 opened: [WIP] many: support for stage-snaps <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2468>
<zyga> Good morning
<zyga> hello mvo
<pstolowski> heyas
<zyga> hey, how are you?
<zyga> https://github.com/opencontainers/runc/commit/0a8e4117e7f715d5fbeef398405813ce8e88558b is fun
 * dot-tobias says hi
<pstolowski> hey zyga, i'm fine, thanks, you? wife and baby back home?
<zyga> pstolowski: yes, we are all home now :-)
<pstolowski> great :)
<mvo> zyga: yay, great news!
<mvo> pstolowski: and good morning to you as well
<mvo> and hello dot-tobias
<pstolowski> hey mvo!
<pstolowski> i feel like i'm ready to tackle selinux PRs today
<pedronis> mvo: hi, I landed a couple things that were green etc and seemed innocent enough, hope it's ok
<mvo> pedronis: yeah, that sounds good
<pedronis> mvo: Chipaca has a couple PRs that need 2nd reviews
<Chipaca> yes, yes I do
<pedronis> Chipaca: one has a couple nitpicks from me as well
<Chipaca> pedronis: yes. I will address them, but am waiting for a review
<Chipaca> maybe i should say as much
<mup> PR snapd#6492 opened: snapstate: restart into the snapd snap on classic <Created by mvo5> <https://github.com/snapcore/snapd/pull/6492>
<mvo> pedronis: good timing, just finished my current task, I have a look now
<mvo> Chipaca: 6034 and 6356?
<Chipaca> mvo: ye
<pedronis> mvo: I answered a couple of nitpicks for Chipaca
<mvo> pedronis: ta
<pedronis> mvo: what can we do about https://github.com/snapcore/snapd/pull/6252  it seems to have hit some weirdness where now there's a lot of conflicts ?
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<mvo> pedronis: mbozecki was looking at the test, let me see
<mvo> pedronis: uh, I think ken has pushed something incorrec,t it says 10k+ commits
<mvo> pedronis: this needs some manual surgery it seems, I can look at this after lunch
<Chipaca> zyga: is #1814450 something you know about?
<mup> Bug #1814450: subsync - error: signal: segmentation fault <snapd:New> <https://launchpad.net/bugs/1814450>
<zyga> Chipaca: the bug in general, no
<Chipaca> zyga: the 'annot use "/snap/gtk-common-themes/818/share/icons/Suru" as bind-mount source: not a directo'?
<zyga> https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/1
 * Chipaca is bad at cut-n-paste
<zyga> that's been open for a while
<zyga> I meant to ping will about it yesterday but then the return happened
<Chipaca> zyga: aha! i'll update the bug with this info
<mup> PR snapd#6493 opened: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by mvo5> <https://github.com/snapcore/snapd/pull/6493>
<Chipaca> abeato: ping
<Chipaca> wait, probably unping
<Chipaca> yeah, wrong person, sorry
<zyga> kenvandine: hey, can we bump https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/issues/1 somehow?
<Chipaca> pstolowski: got a sec?
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98
<pstolowski> Chipaca: in 15
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98
<abeato> Chipaca, haha, nw
 * Chipaca â lunch
<Chipaca> mvo: #1814484 should be fixed, right?
<mup> Bug #1814484: wal-e no longer works as of snapd 2.37 <canonical-is> <PostgreSQL Charm:Confirmed> <snapd:New> <https://launchpad.net/bugs/1814484>
<Chipaca> popey: might #1814242 be something you can look into?
<mup> Bug #1814242: Remmina snap package review <snapd:New> <https://launchpad.net/bugs/1814242>
<popey> thanks Chipaca will take a look
<Chipaca> mvo: did the latest change wrt --classic for strict land in .2?
<pedronis> Chipaca: yes
<Chipaca> degville: when you have a bit, could you see if you have suggestions wrt #1811276 ?
<mup> Bug #1811276: Installing an already-installed snap docs could be more helpful <snapd:Confirmed> <https://launchpad.net/bugs/1811276>
<degville> Chipaca: yep, or course.
<Chipaca> pedronis: #1811063 for your consideration
<mup> Bug #1811063: "snap refresh" does not report failure to update because snap switched to classic confinement <snapd:New> <Snappy:Invalid> <https://launchpad.net/bugs/1811063>
<Chipaca> pedronis: also #1810982
<mup> Bug #1810982: Preseeding Snaps Broken for Trusty <snapd:New> <https://launchpad.net/bugs/1810982>
<diddledan> did I share this in here yet? https://snapstats.org/
<pedronis> Chipaca: isn't the first bug a matter of using warnings appropriately?
<pedronis> the user marked it invalid
<Chipaca> pedronis: invalid in snappy, not in snapd
<Chipaca> pedronis: I think so, warnings would make it better
<Chipaca> pedronis: I'll explain on the bug
<Chipaca> pedronis: and assign it to me because why not
<pedronis> the trusty one we are aware from other channels, nobody had time to dig into it
<pedronis> so far
<Chipaca> pedronis: ah ok
<Chipaca> pedronis: maybe tweak the bug so that much is clear?
<pstolowski> Chipaca: hey, sorry, had to bring my daughter from school, i'm in now, what's up?
<Chipaca> pstolowski: I've got a question about 'snap get' vs 'snapctl get', and thought you might know
<Chipaca> pstolowski: 'snapctl get' always returns a document?
<Chipaca> pstolowski: or is it only if the thing is documentish
<Chipaca> ah, yes
<Chipaca> pstolowski: so, sorry, my actual question is: why don't we support a bare -d in snapctl get? any strong reason?
<pedronis> mvo: are you ok to get https://bugs.launchpad.net/snapd/+bug/1810982 assigned, it involves livecd-rootfs which I don't think anybody else is familiar with
<mup> Bug #1810982: Preseeding Snaps Broken for Trusty <snapd:New> <https://launchpad.net/bugs/1810982>
<pstolowski> Chipaca: hmm, i'm looking at ctlcmd/get.go and it has '... short:"d" description:"always return document, even with single key"'
<pedronis> pstolowski: I think Chipaca is asking about "snapctl get -d"  with no key
<pedronis> which I think maybe you mentioned in your open PR
<pstolowski> pedronis: ah
<Chipaca> yep, -d with no key
<Chipaca> #1814876
<mup> Bug #1814876: snapctl get -d doesn't allow returning full config <snapd:New> <https://launchpad.net/bugs/1814876>
<pstolowski> Chipaca: right. I *think* (i wasn't yet in the team when snapctl was implemented) the idea was the "snap get" is user facing tool, so it's desirable to return entire document to discover options; snapctl is queried programatically, the snap knows its options so it just retrieves specific keys
<pstolowski> Chipaca: i vaguely remember hearing that reasoning from someone.. but it's possible i made it up ;)
<Chipaca> I agree the primary use case is that one, but developers still like to debug their things :-)
<Chipaca> allegedly
<pstolowski> Chipaca: not disagreeing
<dot-tobias> Is it possible to delete old revisions of a snap in the store?
<pedronis> Chipaca: pstolowski: fwiw I'm not against making -d without key work until we have finished other stuff. I think arbitrary differences between snapctl and snap are mostly not worth it
<pedronis> s/until/after/
<pstolowski> +1
<diddledan> dot-tobias: no, you can only remove them from any channels
<dot-tobias> diddledan: ok, thanks!
<pedronis> pstolowski: I did a first pass over #5962, didn't quite look at everything yet
<pedronis> some questions there
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<pstolowski> pedronis: thanks
<pstolowski> cachio: proposed a trivial PR https://github.com/sergiocazzolato/snappy-qa-jobs/pull/2
<mup> PR sergiocazzolato/snappy-qa-jobs#2: Added doc about SPREAD_TESTS and SKIP_TESTS vars <Created by stolowski> <https://github.com/sergiocazzolato/snappy-qa-jobs/pull/2>
<pedronis> mvo: should we close #6252 now that you made 6493 ?
<mup> PR #6252: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <https://github.com/snapcore/snapd/pull/6252>
<pedronis> pstolowski: also reviewed #6490 with a small comment
<mup> PR #6490: tests: fix NFS home mocking <Created by stolowski> <https://github.com/snapcore/snapd/pull/6490>
<cachio> pstolowski, nice, I'll take a look
<cachio> thank
<mvo> pedronis: yeah, let me close it now, its not useful in its current form
<zyga> mvo: hey, there are some milestones on https://launchpad.net/snapd/trunk that feel stale, would you mind if I closed them? (2.36.x)
<pstolowski> pedronis: thanks
<mup> PR snapd#6252 closed: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by kenvandine> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6252>
<kenvandine> mvo: thanks!
<mvo> kenvandine: if you could quickly double check
<kenvandine> mvo: looking
<zyga> oh
<zyga> standup
<mvo> kenvandine: thanks
<zyga> kenvandine: hey :)
<zyga> kenvandine: I sent a ping earlier today, not urgent but please confirm that you saw it
<kenvandine> zyga: i did see it
<kenvandine> i think jamesh might have submitted a fix to Yaru instead
<zyga> great, thank you
<zyga> kenvandine: I think it's still out in the wild so I wonder if it's a matter of publishing something to stable
<kenvandine> zyga: that should be fixed by https://gitlab.gnome.org/Community/Ubuntu/gtk-common-themes/merge_requests/8
<zyga> should the issue be closed then?
<zyga> people still report it
<kenvandine> it's still waiting for feedback
<t1mp> hello
<t1mp> looks like snapcraft broke backwards compatibility for me, without warning
<t1mp> Failed to get part information: Cannot find the definition for part 'desktop-gtk3', required by part 'app'.
<t1mp> Remote parts are not supported with bases, so make sure that this part is defined in the `snapcraft.yaml`.
<t1mp> the same snapcraft.yaml was working before
<popey> snapcraft 3.x did indeed disable remote parts
<t1mp> also, version: 2 is no longer accepted (but version: "2") works
<t1mp> is there some manual on how to migrate? What should I use instead of the remote part?
<diddledan> 2 is a number. '2' is a string. if it accepted 2 before that was a bug
<popey> t1mp: https://paste.ubuntu.com/p/jdMWkMJKhF/
 * diddledan pastes his link again for anyone who missed it - go look :-p https://snapstats.org/
<t1mp> popey: thanjsk!
<t1mp> -j
<popey> njp
<diddledan> :-p
<diddledan> popey: yeejit :-p
<t1mp> why do I need to remove the base: core18 line?
<t1mp> that's what I'm using for my snap too
<popey> because snapcraft define wont work with it
<popey> you dont need to remove it in *your* yaml, only in the tmp one
<diddledan> it won't expand the definition with it in place - the base: core18 triggers snapcraft to use new features and remove old ones
<diddledan> of course you can add it back as soon as you've run `snapcraft define`
<t1mp> ok
 * cachio lunch
<t1mp> popey, diddledan: okay, thanks. I'm rebuilding my snaps (with snapcraft 3.. and 2 on jenkins. I hope that one still works after my changes).
<t1mp> I get some errors,
<t1mp> Staging desktop-gtk3
<t1mp> rm: cannot remove '/var/cache/apt/archives/partial/*.deb': Permission denied
<t1mp> but the pull seems to continue after that
<t1mp> I require coffee. brb
<t1mp> An error occurred when trying to execute 'sudo -i snapcraft prime' with 'multipass': returned exit code 2.
<t1mp> ah. I have a version-script, and I guess before snapcraft wasn't building the stuff in a vm. Now it is and my script is not available there.
 * zyga is eating lunch
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117
<mup> PR # closed: core18#43, core18#63, core18#72, core18#90, core18#98
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117
<mup> PR # opened: core18#43, core18#63, core18#72, core18#90, core18#98
<diddledan> mup seriously needs educating about what "closing" means - it keeps on with things like ^^^^^ where it says "foo is closed" immediately followed by "foo is new and just been opened!!!! OMGZOR IT'S BRAND NEW!!!!"
<Chipaca> diddledan: github api hiccups
<Chipaca> and mup-side state
<Chipaca> afaik
<Chipaca> ikn
<Chipaca> ikr?
<Chipaca> wtf
<diddledan> oh dear. stack smashing in a quit message?
<diddledan> ref: 15:25:04 â mdeslaur quit (~mdeslaur@ubuntu/member/mdeslaur) Quit: *** stack smashing detected ***
<diddledan> that sounds nasty
<pstolowski> pedronis: re your comment about why do i only log error on from addHotplugSeqWaitTask(chg, key) - it's a good point - i wonder what's the right thing to do; is chg.Abort() the right way of dealing with this? we have change and tasks already created in the state, but we shouln't run them if seq task couldn't be added
<pedronis> pstolowski: need to think a bit
<pedronis> pstolowski: I think is doing things with a patter that we don't use
<pedronis> *pattern
<pedronis> pstolowski: we usually have all the tasks, and then add them to the change
<pedronis> pstolowski: we might have to tweak the helper
<pstolowski> pedronis: btw, error here is if things go really bad (failure other than NoState from st.Get("hotplug-seq"..))
<pedronis> pstolowski: I understand but see my comment here
<pstolowski> pedronis: i'd move allocHotplugSeq out of the helper, so it needs to be allocated by the caller and passed to the helper. that way it can be allocated (or fail) early before creating change and tasks. wdyt?
<pedronis> pstolowski: yes, something like that
<pedronis> pstolowski: we should follow other places and create the change last
<pstolowski> pedronis: i see
<Chipaca> fun things to do: run out of space on /tmp  ð¹
<mup> PR snapd#6490 closed: tests: fix NFS home mocking <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6490>
<pedronis> Chipaca: just a reminder that #6034 description/commit needs updating, it still using the original names of things
<mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<Chipaca> pedronis: thanks
<Chipaca> pedronis: I'm waiting for an answer from mvo, but I'd already forgotten about the desc
<pedronis> Chipaca: about the test?
<Chipaca> pedronis: yes
<Chipaca> pedronis: (description updated)
<pedronis> thx
<pstolowski> pedronis: thanks for catching a few issues in the hotplug PR; i think i've addressed all your 1st pass comments
<mup> PR snapd#6493 closed: userd: handle help urls which requires prepending XDG_DATA_DIRS <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6493>
<pedronis> mvo: I looked again at #6418, I am a bit confused because the code you changed in snap-confine looks like it was originally buggy?
<mup> PR #6418: many: allow core as a fallback for core16  <Created by mvo5> <https://github.com/snapcore/snapd/pull/6418>
<mvo> pedronis: thanks, let me check
<mvo> pedronis: I remember I fixed something in there, yes
<mvo> pedronis: let me check, you mentioned the new code looks also a bit strange, let me open it
<pedronis> mvo: mind not buggy, just strange
<pedronis> the new code
 * mvo nods and looks
<mvo> pedronis: yeah, the triple access is strange, I have a look what can be done
<pedronis> mvo: going to eod, I'll continue with your other PRs in the morning
<mvo> pedronis: thank you!
<jdstrand> mvo: hey, I can't recall the details, but I feel like you said something like this would break snapd: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906
<jdstrand> mvo: (server team is adding a syscall to bionic's libseccomp)
<mvo> jdstrand: thanks, let me check
<mvo> jdstrand: hm, I don't recall having said this, zyga was working on statx, maybe he remembers more -^
<jdstrand> mvo: I thought you said that the act of adding syscalls to trusty's libseccomp complicated things for you
<mup> PR snapcraft#2467 closed: [legacy] ruby plugin: support new download URL <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2467>
<jdstrand> mvo: or maybe that was vivid. like I said, I do not recall the details :)
<mvo> jdstrand: I don't remember .( I will double check with -proposed tomorrow
<mup> PR snapcraft#2469 opened: cli: clean up snapcraft push output <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2469>
<mwhudson> hm i want to capture communication between snap and snapd for testing later
<mwhudson> i wonder how many recording proxies support unix sockets :)
<mwhudson> and then i guess i'd need to coerce snapd to talk to it anyway
<mwhudson> er snap
<Chipaca> mwhudson: you can have snapd take arbitrary sockets by tweaking its .socket unit
<mwhudson> hmm
<Chipaca> mwhudson: even, gasp, ip
<Chipaca> mwhudson: (but good luck getting unix credentials)
<mwhudson> probably easier just to hack my own snapd binary that writes all requests and responses somewhere?
<mwhudson> argh snap binary
<Chipaca> mwhudson: either would work -)
<mwhudson> i can't type 'snap' without the 'd' apparently
<Chipaca> mwhudson: I'm going to write a tool and call it 'snadp', just for you
<mwhudson> Chipaca: i hope you feel bad
<Chipaca> pretty good actually
<Chipaca> my mum sent triple-choc brownies
<mwhudson> i guess this Client.Hijack method might be useful for this
<mwhudson> other question
<mwhudson> is there a snapd api i can use to ask if there is an update available for a particular snap?
<mwhudson> iirc i could only ask about all installed snaps which i guess is ok too
<mwhudson> basically i'm working on adding support for triggering a self refresh to subiquity and am wondering about how to test it
<Chipaca> mwhudson: snap refresh --list ?
<Chipaca> mwhudson: (sorry I didn't see your question)
<Chipaca> mwhudson: wrt logging, I'd look at (*client.Client).do
<Chipaca> actually, this sounds useful
 * Chipaca looks
<mwhudson> i would actually like it for my other thing so i can see which api snap refresh --list is hitting :)
<Chipaca> mwhudson: http snapd:///v2/find select==refresh
<mwhudson> Chipaca: thanks
<Chipaca> mwhudson: niets te danken
<Chipaca> mwhudson: but
<Chipaca> mwhudson: snapd is already logging that :-)
<Chipaca> Feb 12 21:32:20 fleet snapd[6262]: daemon.go:296: DEBUG: pid=26464;uid=1001;socket=/run/snapd.socket; GET /v2/find?select=refresh 244.125698ms 200
<Chipaca> I thought you were looking at POSTs
<mwhudson> only if you turn up logging right?
<Chipaca> mwhudson: just SNAPD_DEBUG=1
<Chipaca> yes
<Chipaca> DEBUG
<mwhudson> but yes i want post and response bodies in general
<Chipaca> ok, I'll play with that in a bit
<mup> PR snapd#6494 opened: interfaces/builtin/udev: add spec to disable udev + device cgroup <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/6494>
<mwhudson> would be great
<mwhudson> i can hack something for my own use but i'm sure your version would be cleaner :)
<Chipaca> mwhudson: http://paste.ubuntu.com/p/RN5xYkwf3c/
<Chipaca> mwhudson: that still won't log the body of the request, but I can add that if this would work
<Chipaca> I also have a delogger.py you might find useful
<Chipaca> mwhudson: https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537
<Chipaca> delog.py
<mwhudson> +			Key: "SNAPD_DEBUG_HTTP",
<mwhudson> -D?
<mwhudson> but thanks
<mwhudson> Chipaca: where would that log to?
<Chipaca> mwhudson: yeah, it's not pretty
<Chipaca> that logs to the log :-/
<Chipaca> as in
<Chipaca> SNAPD_DEBUG=1 SNAPD_DEBUG_HTTP=7 /tmp/snap refresh --list
<Chipaca> *** here
<Chipaca> 2019/02/12 21:44:33.361905 logger.go:67: DEBUG: > "GET /v2/find?q=&select=refresh HTTP/1.1\r\nHost: localhost\r\nUser-Agent:
<Chipaca> etc etc
<mwhudson> oh you need SNAPD_DEBUG=1 as well
<Chipaca> there's probably some standard for logging http requests that is weeping
<Chipaca> also whoa what's with tht funky date format
 * Chipaca hopes it'll make sense in the morning
<Chipaca> o/
<kyrofa> Hey jdstrand, how is the docker (not docker support) interface being used these days? Reading the code, it kinda looks like I can't even install a snap that plugs it, is that true? (allow-installation: false)
<jdstrand> kyrofa: you can do an unasserted install with --dangerous. you need a snap decl to distribute via the store
<jdstrand> the docker socket gives you device ownership, just like docker-support since it gives you access to the socket whose listener has docker-support and there aren't acls on the api
<kyrofa> Ah, so nothing random folks can really use, then
<jdstrand> correct
<jdstrand> I mean, if it is legitimate use, that is one thing
<jdstrand> eg, k8s or something, but it is superprivileged
<kyrofa> I just want to be able to fire up a docker container from within a confined snap. Bundling docker would require super plugs, and it seems using docker ALSO requires super plugs
<kyrofa> Decent confinement would require mediation, basically?
<ijohnson_> kyorfa: the "designed" way to do this with the docker snap is to plug the docker:docker-executables slot in your snap and then use the docker binary from the docker snap in your snap
<ijohnson_> kyrofa: ^
<kyrofa> ijohnson_, what if I want to use the API instead of shelling to a binary?
<ijohnson_> then you would plug docker:docker-daemon also slotted by the docker snap (which is the "docker" interface which allows access to the unix socket)
<kyrofa> That one isn't a super plug?
<ijohnson_> no, the "docker" interface is explicitly not slotted by the core snap, only docker-support is slotted by the core snap
<ijohnson_> as jdstrand pointed out you will have a hard time getting an auto-connection for the docker-support interface if you aren't actually docker or k8s, etc.
<ijohnson_> this is the "designed" way to launch docker containers from a different snap, which is admittedly quite awkward and not well supported at the moment
<ijohnson_> it should work though, please let me know if it doesn't
<kyrofa> ijohnson_, who is maintaining that snap these days, you?
<jdstrand> it is super
<jdstrand> err
<jdstrand> it is super for the slot
<jdstrand> but the docker snap has a snap decl that allows connecting to it
 * jdstrand forgot about that
<jdstrand> so if you use the docker snap, you can plugs it
<jdstrand> but it won't autoconnect
<kyrofa> Heh, yeah I didn't even think to see if core provided a docker slot, of course it doesn't
<jdstrand> someone else couldn't slots docker or plugs it
<kyrofa> Indeed, that makes sense
<ijohnson_> hey also jdstrand while you're here talking about the docker snap, there was a CVE published yesterday concerning a bad actor being able to overwrite the runc binary which docker runs as root to start containers. The snap wasn't affected because the runc binary is mounted read-only (cause squashfs), but looking through the apparmor we allow writes to /proc/[0-9]*/fd/[0-9]* (which is what I think /proc/self/exe resolves to
<ijohnson_> anyways)
<ijohnson_> is mounting as read-only the only way we can prevent similar attacks overwriting a binary using /proc/self/exe?
<jdstrand> so, I'll revise my answer. if you have the docker snap installed, you can plugs docker and manually connect and go on your way
<jdstrand> ijohnson_: apparmor protects us as well
<jdstrand> it is a symlink so it resolves to the binary and the policy doesn't allow arbitrary writes
<ijohnson_> hmm when I was looking yesterday it seemed to allow it
<ijohnson_> err wait you mean don't allow arbitrary writes to $SNAP ?
<jdstrand> ijohnson_: as for programmatically fixing this for a container management system that doesn't use apparmor, you can do something like what the runc devs did
<jdstrand> they have an ingenious approach. I suggest reading https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/runC
<ijohnson_> good to know, thanks for the link
<ijohnson_> I meant that https://github.com/snapcore/snapd/blob/master/interfaces/apparmor/template.go#L306-L313 allows writes to /proc/*/fd/* doesn't it?
<jdstrand> ijohnson_: if you can write to what /proc/self/exe is pointing to, then you can use the same technique. but, you don't need to use the technique because you already have write access to it. the difference is that with runc you were able to escalate privileges and write to somewhere you weren't supposed to
<ijohnson_> ah I see, okay
<ijohnson_> thanks for confirming
<jdstrand> so for snapd, it isn't an issue on several fronts. $SNAP is ro squashfs, apparmor doesn't allow it, apparmor doesn't allow strict mode snaps to write to /var/lib/snapd/hostfs, etc. in forced devmode, it is wide open. we aren't providing file restrictions so no priv escalation
<ijohnson_> yep that all makes sense now
<jdstrand> ijohnson_: to specifically answer your /proc/*/fd/* question. we do allow reads there and writes to [0-9]*, but importantly, those are symlinks that apparmor will resolve
<ijohnson_> ack
#snappy 2019-02-13
<zyga> hello
<mvo> hey zyga
<pstolowski> morning
<kjackal> Hi, is there something wrong with the snap store? "error: unable to contact snap store " from my local machine and from aws when installing microk8s
<mvo> kjackal: yeah, the store is not fully operating right now, see https://status.snapcraft.io/
<zyga> kjackal: I'm seeing timeouts
<pstolowski> kjackal: indeed - https://status.snapcraft.io
<nekoseam> api.snapcraft.io is coming back up when?
<mbeneto> Hi, is the Global Store down?
<zyga> mbeneto: see status.snapcraft.io please
<mbeneto> zyga: thanks, I didn't know about that
<mup> PR snapd#6495 opened: many: collect time each task runs and display with `snap change <id>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/6495>
<sparkiegeek> we're actively working on bringing the store back up, please be patient with us
<zyga> sparkiegeek: thank you :)
<mvo> zyga: did you see that the statx syscall is getting backported to libseccomp in bionic? do you think this affects us?
<zyga> mvo: it will affect us as follows:
<zyga> (I saw some chatter over email)
<zyga> mvo: statx is present in the default seccomp templatte
<zyga> mvo: statx will no longer resolve to unknown system call
<zyga> mvo: statx will become present in seccomp profiles
<zyga> mvo: some tests may start passing  unexpectedly
<mvo> zyga: thanks! but no ill effects for real-world workloads except tests?
<zyga> no, things will only be better
<mvo> I like the sound of that :)
<pedronis> mvo: I marked #6495 blocked because I should review older things first, I don't think it can go in as is (I'm mostly worried that is a bit premature to put this in the main commands/API)
<mup> PR #6495: many: collect time each task runs and display with `snap change <id>` <â Blocked> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6495>
<mvo> pedronis: fair enough, would it help if I remove the client bits and move them into debug? or would you prefer to leave this all alone ?
<pedronis> mvo: it's probably best to have a chat about this first
<mvo> pedronis: ok
<zyga> Chipaca, pedronis: can you please double check that this is what we want: https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/35?u=zyga
<mup> PR snapd#6495 closed: many: collect time each task runs and display with `snap change <id>` <â Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6495>
<zyga> FYI https://twitter.com/slpnix/status/1095640072999915520
<zyga> pedronis: ^
<Chipaca> zyga: what do you mean we can't return a synchronous error because we refresh assertions?
<zyga> Chipaca: befure we  get to UpdateMany we block for a long time to do assertion refreshes
<Chipaca> zyga: yes
<zyga> I'm not an expert on this  part of the stack but this is what I found yesterday
<Chipaca> zyga: but that's in the synchronous bit
<zyga> ?
<zyga> that is before we create tasks
<zyga> and while the client waits for the response?
<Chipaca> yes
<pstolowski> hmm i'm still getting net/http: request canceled while... on api.snapcraft.io every time i run a spread test, even though status of the store is all green
<zyga> Chipaca: that's unexpected and contrary to my assumptions about what should go where
<Chipaca> pstolowski: yeah, store is not out of trouble yet
<Chipaca> 'snap find' takes ages even when it works
<Chipaca> zyga: ok
<pstolowski> Chipaca: ack, thanks for confirming
<Chipaca> zyga: I wasn't giving an opinion :-)
<Chipaca> zyga: I was just stating a fact
<Chipaca> zyga: now, ideally it would either be a lot faster, or be done in a task, but if moved to a task we lose the ability to error out entirely
<Chipaca> the speed of refreshing assertions sucks
<zyga> Chipaca: here I'm specifically after one aspect; gustavo wanted to have the refresh bail out synchronosuly (quickly)  when we can check that a snap is busy
<Chipaca> zyga: yes
<Chipaca> zyga: so check before the assertion refresh
<pedronis> Chipaca: zyga: is something that we need to fix/improve but is not trivial and cannot be done before we have fixed other issues
<zyga> AFAIK this is not possible today
<Chipaca> zyga: why?
<zyga> Chipaca: yesterday you or pedronis commented it should be even later, but perhaps I misunderstood
<pedronis> zyga: fast is a relative concept, what is your concern?
<zyga> Chipaca: that is  even before update is called, unless I'm missing something
<pedronis> anything done in the sync part is considered "fast"
<zyga> pedronis: synchronous error before we do anything
 * pstolowski errand
<zyga> pedronis: if I can place it before the assertion check that would be enough
<Chipaca> zyga: if by fast you mean synchronous, snapstate.Update can and does do things before starting the change
<pedronis> zyga: what is the problem putting it after?
<zyga> pedronis: it's noticeably slow and feels like bad user  experience
<pedronis> zyga: sorry, not relevant, other things are checked at that point
<pedronis> as I said, not something we can fix *now"
<zyga> sure, that's fine
<zyga> so what is the design I should  pursue, is the one I drafted in the forum post acceptable?
<Chipaca> zyga: so, as i was saying, if by fast you meant synchronous, snapstate.Update
<pedronis> any point that is reasonable and not bug introducing is fine in Update
<pedronis> we need to speed it up
<zyga> ok
<pedronis> but as I said it's orthogonal, not easy problem
<zyga> Chipaca: I meant as in not involving any network IO but as I understand that is difficult now, we can improve it later
<Chipaca> zyga: if by fast you meant *actually* fast, you can call something from daemon
<Chipaca> er
<Chipaca> zyga: you can't mean without any network io
<Chipaca> without network you can't know if there is an update available
<pedronis> Chipaca: please, don't suggest horrible things
<zyga> Chipaca: yes, without any at all, if you say "snap refresh foo" you can bail out knowing that foo ruuns
<Chipaca> zyga: there might not be any updates for foo
<zyga> Chipaca: it obviously applies to a subset of cases
<Chipaca> zyga: why would you bail in that case?
<Chipaca> "close all your open windows for the update" "k" "no updates available" "HULK SMASH"
<pedronis> let's not be silly here
<zyga> Chipaca: I was trying to convey the discussions from cape town, in the case where you can check that nothing can be done locally, you can provide an appropriate message that teaches the uses about this mechanic
<pedronis> zyga: I can only repeat  conceptually any point in Update is considered "fast"
<zyga> OK
<zyga> I think the draft I wrote now is actionable and in line with what we want
<zyga> if you can give me a +1 on that I will carry on working towards that
<Chipaca> pedronis: zyga: I'd suggest putting it at the top of `doUpdate`, fwiw
<Chipaca> zyga: is the draft the forum post from where I came?
<pedronis> Chipaca: that would be fine with me
<zyga> Chipaca: yes, after iterating on this yesterday and today I moved all the logic into one helper that can be called from doUpdate
<Chipaca> I somehow missed that we wanted to do this before knowing there was an update available and would like to express my concern about the ux of that
<pedronis> Chipaca: I don't think that was the plan
<pedronis> that doesn't make sense
<pedronis> even
<Chipaca> IKR
 * pedronis -> lunch
<zyga> hm
<zyga> so +1 or -1?
<pedronis> to what?
<pedronis> checking in doUpdate ?
<pedronis> +1
<pedronis> afaiu right now
<zyga> to all of https://forum.snapcraft.io/t/bug-saves-are-blocked-to-snap-user-data-if-snap-updates-when-it-is-already-running/3226/35
<pedronis> ah, that's new
<Chipaca> zyga: there are conceptual errors in that, which is what I opened with, so -1
<pedronis> I need to read it :)
<zyga> ok, please comment on it with clarifications
<zyga> I will carry on with tests
<zyga> the way I structured this is easy to change
<zyga> so any changes are OK
<Chipaca> zyga: nothing in /34 where you describe the thing implies "before checking the store for updates"
<zyga> Chipaca: I tried to capture it in 'snap refresh s2' case
<zyga> but I was aware of the logic around assertions so I made it clear that this is not happening
<sparkiegeek> store is fully operational again
<Chipaca> sparkiegeek: woo, thank you
<sparkiegeek> Chipaca: np, repair work was handled by rest of the team
<sparkiegeek> but if you could please give us batched assertion requests we would have a better chance of coming back up quicker :)
<Chipaca> er
<Chipaca> sparkiegeek: will do
 * Chipaca puts a bow on it
<Chipaca> or was that lipstick
<Chipaca> eh
<sparkiegeek> â
<Chipaca> mvo: did you see my question on https://github.com/snapcore/snapd/pull/6034#discussion_r256025287 ?
<mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<audiophilo> Hi, i'm using rhytm ferret extensively on acoustic drums. If i pick bass drum and snare drum as a reference for splitting i can have a problem when they are played at the same time by the drummer. Since it's unlikely that bass and snare are hit  at the very exact moment, rhytm ferret will create 2 very-close and unusefull regions (Attachment 1: https://imgur.com/pYpnYLd) that will create a more annoying behaviour when using P
<audiophilo> osition -> Snap position to grid (Attachment 2: https://imgur.com/l5uwFmr). I thought that it would be great to add an option  in rhytm ferret where you can add a value in ms to determine a minimum distance from a cut to the other. Do you think this could be a nice idea?
<Chipaca> audiophilo: are you in the right channel?
<audiophilo> nope. LOL
<Chipaca> audiophilo: phew
<audiophilo> :D
<Chipaca> for a moment I thought I'd lost it
<audiophilo> too many tabs, i got confused. Sorry
<Chipaca> audiophilo: good luck with your â¦ ferret â¦ snaring?
<Chipaca> sounds like fun anyway
<audiophilo> Chipaca, thank you very much. Well it's not very funny actually. But very usefull :D
<cachio> mvo, hey
<cachio> mvo, I am going to promote the snapd snap
<cachio> I would like to know why those versions are not in beta right now
<mvo> cachio: thank you
<mvo> cachio: we can discuss why 2.37.2 is not in beta after lunch, gtg now, sorry. will be back soon
<cachio> mvo, np, enjoy lunch
<mup> PR snapd#6496 opened: many: collect time each task runs and display with `snap debug change-timings <id>` <Created by mvo5> <https://github.com/snapcore/snapd/pull/6496>
<pedronis> mvo: could you merge master in #6404, it seems to still require old deps
<mup> PR #6404: snapstate: auto transition on experimental.snapd-snap=true <Created by mvo5> <https://github.com/snapcore/snapd/pull/6404>
<zyga> brb, taking a small break now
<cachio> pstolowski, hey, yesterday I was running the hotplug test
<cachio> I left a comment on the PR about the results
<pstolowski> cachio: yes, thank you i saw it. i was trying to debug it today but store was mostly offline
<pstolowski> cachio: did you run that test only on 16.04?
<mup> PR snapd#6497 opened: features,cmd/libsnap: add new feature "refresh-app-awareness" <Created by zyga> <https://github.com/snapcore/snapd/pull/6497>
<mup> PR snapd#6498 opened: cmd/libsnap: add cgroup-pids-support module <Refresh Awareness> <Created by zyga> <https://github.com/snapcore/snapd/pull/6498>
<zyga> two early branches from the refresh app awareness work
<cachio> pstolowski, yes, only on 16.04
<mvo> pstolowski: 6404> sure
<pstolowski> cachio: i've just run it on 16.04 (failed) and 18.04 (passed). i wonder if it's something qemu-related. it seems as unplugging and then re-plugging device back in qemu doesn't trigger the udev add event on 16.04, but i'll need to investigate this closer. qemu on 16.04 is 2.5, in 18.04 - 2.11
<pstolowski> cachio: nb, running nested 16.04 vm under 18.04 (to have newer qemu) doesn't seem possible since we build snapd deb on the host, so dependencies are wrong
<cachio> pstolowski, yes
<cachio> pstolowski, how are you running this?
<pstolowski> cachio: SPREAD_NESTED_TYPE=classic SPREAD_NESTED_ARCH=amd64 SPREAD_NESTED_SYSTEM=bionic spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug
<pstolowski> cachio: SPREAD_NESTED_TYPE=classic SPREAD_NESTED_ARCH=amd64 SPREAD_NESTED_SYSTEM=xenial spread -debug google-nested:ubuntu-16.04-64:tests/nested/classic/hotplug
<pstolowski> cachio: i once mixed that up accidently and that didn't work because of what i said above
<Chipaca> zyga: wrt getting the apps from the check, earlyEpochCheck is already loading them, we can change it to either return or have it passed in
<cachio> jdstrand, hey, could you please take a quick look to #6376?
<mup> PR #6376: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
<cachio> thanks
<jdstrand> cachio: I will not be able to look at it for a little while, but will today. sorry for the delay
<cachio> jdstrand, thanks
<pstolowski> cachio: what's the new simple syntax for nested vm tests?
<zyga> Chipaca: thanks for the hint, let me look :)
<cachio> pstolowski, for xenial
<cachio> spread -debug google-nested:ubuntu-16.04-64:tests/nested/classic/hotplug
<cachio> for bionic
<cachio> SPREAD_NESTED_SYSTEM=bionic spread -debug google-nested:ubuntu-18.04-64:tests/nested/classic/hotplug
<pstolowski> cachio: thanks
<cachio> pstolowski, taw
<cachio> yaw
<zyga> Chipaca: interesting, that is perfect
<mup> PR snapd#6499 opened: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
<zyga> jdstrand: hey
<zyga> jdstrand: not sure if you are around but https://github.com/snapcore/snapd/pull/6499/files :)
<mup> PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
 * cachio lunch
<mup> PR snapd#6500 opened: dirs: add PidsCgroupDir <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6500>
<mup> PR snapcraft#2468 closed: many: support for stage-snaps <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2468>
<zyga> Chipaca: can you please review the dirs change quickly
<zyga> I can then propose more useful stuff
<Chipaca> zyga: I've got to agree with mvo, no point to the pr on its own
<zyga> there is a hidden point, I love reusing commit messages
<zyga> no need to write "branch" description
<zyga> but I can close it and merge it into the bigger one
<pedronis> Chipaca: https://github.com/snapcore/snapd/pull/6501
<mup> PR #6501:  tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <https://github.com/snapcore/snapd/pull/6501>
<mup> PR snapd#6501 opened:  tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <https://github.com/snapcore/snapd/pull/6501>
<mup> PR snapd#6500 closed: dirs: add PidsCgroupDir <Simple ð> <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/6500>
<mup> PR snapd#6502 opened: dirs,overlord/snapstate: add Soft and Hard refresh checks <Created by zyga> <https://github.com/snapcore/snapd/pull/6502>
<zyga> Chipaca: ^ :)
<zyga> Chipaca: I mainly wonder if you will ask me to use a different type for PID
<Chipaca> zyga: it's an int32, right?
<zyga> int
 * Chipaca looks
<zyga> (because it was the easy choice)
<zyga> we only read it from text files
<zyga> and print
<mup> PR snapcraft#2470 opened: Enable support for strictly confined multipass <Created by gerboland> <https://github.com/snapcore/snapcraft/pull/2470>
<Chipaca> zyga: I'd be a teeny tiny bit happier if they were int32, mostly because that signals intentional...ness?]
<zyga> do we have a type for that
<Chipaca> zyga: 'int' in go often means "yeah it's a number but i didn't think too much about it'
<zyga> so that I don't have to spell it everywhere?
<Chipaca> zyga: no
<Chipaca> zyga: grep -ri pid.int32 tho
<t1mp> hello. I have a python+Qt app that works fine, but after snapping it, some dialogs don't open when I click the button to open them.
<t1mp> How can I debug this? For example, how do I enter the snap container and then launch python inside?
<pedronis> mvo: pstolowski: I did another pass over some of your PRs
<pstolowski> pedronis: ty!
<mvo> pedronis: \o/
<zyga> t1mp: hey
<t1mp> hello zyga
<zyga> t1mp: you can run "snap run --shell snapname"
<t1mp> I just did snap run --shell qmenta-uploader :)
<zyga> and then look at wrapper scripts typically generated by snapcraft in $SNAP directory
<t1mp> but I guess some env vars are missing
<zyga> yeah
<zyga> those are in the wrappers
<t1mp> right :)
<zyga> eventually it will all be inside a delcarative system but that's not done yet
<t1mp> I think you told me once, last year, but I forgot since in the meantime I didn't have to worry about it
<mvo> pstolowski: btw, I see a lot of "udev monitor observed ... event for ..." in my snapd from git - should we make this a debugf instead of a noticef
<t1mp> strange. I am opening a QtQuick.Dialogs.FileDialog. It works when I run the app 'locally', but not when I run it from a snap.
<pedronis> mvo: I think some of the new PRs turn some Noticef into Debugf, not sure if that is one of those
<zyga> any denials/
<zyga> I'm about to EOD (or at least break for dinner) but I can look later
<mvo> pedronis: aha, thanks
<t1mp> zyga: no errors/warnings at all. (I did get a bunch before, but I fixed them all and it still doesn't work, so that doesn't seem to be the problem).
<t1mp> zyga: thanks, enjoy your dinner :)
<t1mp> Speaking of which, I need to eat too.
<pstolowski> cachio: ping
<cachio> pstolowski, yes
<mup> PR snapd#6503 opened: tests: use snap which takes 15 seconds to install on retryable-error test <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6503>
 * cachio afk
<pstolowski> cachio: hey, sorry, fyi when you're back:
<cachio> pstolowski, hey
<pstolowski> cachio: i've made a quick hack to use qemu-virgil in nested.sh, but it needs more work - https://paste.ubuntu.com/p/t8tdRFCdyY/
<pstolowski> cachio: hey
<cachio> pstolowski, nice, test is passing with that change?
<pstolowski> cachio: no, i think the failure on 16.04 is actual bug in hotplug code, i found one specific issue in the code and now checking a fix
<pstolowski> cachio: i'm not sure if we will need newer qemu or not
<cachio> pstolowski, ah, nice, that test worked in that case
<pstolowski> cachio: if so, then it will need more work. the snap uses strict mode by default, but it's problematic because we use /dev/tty* for our virtual devices, so i used devmode. also i'm not sure if qemu-system-i386 is supported, there snap doesn't have binary for that
<pstolowski> cachio: (the snap = the qemu-virgil snap)
<pedronis> mvo: this is the question Chipaca was referring to in the standup:  https://github.com/snapcore/snapd/pull/6034#discussion_r255888988
<mup> PR #6034: many: save media info when installing, show it when listing <Squash-merge> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6034>
<cachio> pstolowski, ah, ok
<cachio> pstolowski, otherwise we could continue using the current way
<pstolowski> cachio: yes, i'll know by tomorrow if old qemu is ok
<pstolowski> cachio: ok, 1 bug fixed and i hit another one, interesting those happened on 16.04! good! eod
<mvo> pedronis: thank you, looking
<cachio> pstolowski|afk, nice, thanks for fixing those ones, see you tomorrow
 * Chipaca takes the walk for a dog
<mup> PR snapd#6504 opened: tests: not checking 'tracking channel' after refresh core on nested execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6504>
<Wimpress> Snapcraft pro tips is live streaming now!
<Wimpress> https://www.youtube.com/watch?v=DtZySQgBxmM
<t1mp> I guess that's useful, since the snapcraft docs are outdated. https://docs.snapcraft.io/debugging-building-snaps/6274 with snapcraft 3, there is no prime/ dir so those docs are not helpful
<Wimpress> @degville ^
<ijohnson> do we have a list anywhere of which distros enable re-exec for the core snap and which don't?
<degville> thanks Wimpress. noted.
<mup> PR snapcraft#2471 opened: test: test-beta <do-not-merge-yet> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2471>
<t1mp> I can no longer let my snap open a file select dialog.. :s It works fine in my (python+QtQuick) app, but after snapping it, the new dialog simply doesn't show up any more. Did anyone else encounter this?
<Facu> Hello! I'm stuck building a snap for my project (a pure Python one: `fades`)...
<Facu> - if I try to build it in my desktop I get another weird error ( https://forum.snapcraft.io/t/the-linker-version-2-23-used-by-the-base-core-is-incompatible-with-files-in-this-snap/7430/13 )
<Facu> - if I try to build it in my laptop I get another weird error ( https://forum.snapcraft.io/t/error-you-must-give-at-least-one-requirement-to-install-when-building-a-snap/9946 )
<Facu> - if I try build.snapcraft.io to build it, I go and request it manually, it appears during some seconds the row (after past builds 7 months ago) "Number: requested" and "Build trigger: Manual build", but after those seconds that row disappears and it's as if I never tried to build it
<Facu> is there anything else I could try? thanks!
<NickZ> Facu: the first post is outdated; lxd is no longer required for building snaps. If you specify "base: core16" or "base: core18" in your snapcraft yaml, it'll build it in a VM
<Facu> NickZ, I should use "base: core18", as I'm in Bionic, right?
<NickZ> yeah, if you want your snap to target bionic, you should use that
<Facu> NickZ, I want my snap to target everything
<NickZ> Only for the build step; it makes sure that whereever you're building this snap, it will always use the bionic packages when pulling in dependencies and building
<NickZ> you can use it everywhere
<Facu> it's installing multipass now :o
<NickZ> yup
<Facu> NickZ, it's Launching a VM (retrieving an image, it seems), so I guess that unblocked the problem
<Facu> NickZ, aaaaaand it looks it worked :)
<Facu> NickZ, thanks!!!
<mup> PR snapcraft#2472 opened: project loader: do not leak a part's build-environment <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2472>
<NickZ> Facu: awesome, np man
<mup> PR snapd#6034 closed: 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>
<Odd_Bloke> I have a single shell script that I want to include in a snap that is otherwise Python-only; how do I simply copy a file from my git repo somewhere in to my snap?
<Odd_Bloke> (I've been trying to do this with arguments to the Python plugin, but perhaps this needs to be a separate part?)
<stgraber> Odd_Bloke: separate part using the dump plugin
<Odd_Bloke> Thanks!
<stgraber> you could also use an override on your existing part and then use that to cp stuff around but that's gross :)
#snappy 2019-02-14
<mup> PR # closed: snapd#5644, snapd#5915, snapd#5962, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360,
<mup> snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6472, snapd#6482, snapd#6485, snapd#6487, snapd#6488, snapd#6491, snapd#6492, snapd#6494, snapd#6496, snapd#6497, snapd#6498, snapd#6499, snapd#6501, snapd#6502, snapd#6503, snapd#6504
<mup> PR # opened: snapd#5644, snapd#5915, snapd#5962, snapd#6079, snapd#6098, snapd#6108, snapd#6111, snapd#6162, snapd#6177, snapd#6238, snapd#6258, snapd#6270, snapd#6281, snapd#6313, snapd#6322, snapd#6324, snapd#6325, snapd#6327, snapd#6329, snapd#6341, snapd#6347, snapd#6356, snapd#6360,
<mup> snapd#6367, snapd#6376, snapd#6381, snapd#6401, snapd#6404, snapd#6410, snapd#6418, snapd#6436, snapd#6472, snapd#6482, snapd#6485, snapd#6487, snapd#6488, snapd#6491, snapd#6492, snapd#6494, snapd#6496, snapd#6497, snapd#6498, snapd#6499, snapd#6501, snapd#6502, snapd#6503, snapd#6504
<NickZ> man, the arm build farm on launchpad is backed up something fierce
<NickZ> i have a 3 hour wait time on my snap packages
<zyga> Good morning
<zyga> Hey mvo
 * zyga updated his aquaris E4.5 to "16"
<zyga> guess my phone runs xenial now
<mvo> zyga: good morning
<zyga> wow, the phone says in the future it will support snaps!
<zyga> that's neat
<zyga> (though they said that it is not supported now because of upstart)
<mvo> nice
<MattJ> Hmm, is there a way to reinstall a snap with --classic without losing its data?
<mvo> zyga: btw, did you find out more from morphis about the jenkins issue he has with 2.37?
<zyga> mvo: no, we need to get more feedback about how to reproduce the issue
<mvo> zyga: thanks! so he didn't reply yet?
<zyga> I failed to reproduce it on 18.04 with lxd and classic snaps in /var/lib/test
<zyga> correct
<mvo> zyga: thanks for looking into this!
<zyga> morphis: ^ please ping us when you are up
<mup> PR snapd#6501 closed:  tests/main/auto-refresh-private: make sure to actually download with the expired macaroon <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6501>
<mvo> 6503 is an easy win
<morphis> zyga, mvo: hey!
<zyga> good morning :)
<zyga> mvo: (reviewed)
<morphis> zyga: didn't you say you can easily reproduce it?
<zyga> morphis: that was dry run mode, it is easy to reproduce conceptually but it doesn't actually happen for me
<morphis> ok
<zyga> morphis: so I started digging deeper to the point where I had lxd and the same version and it still wasn't happening
<morphis> zyga: so what do you need from me?
<zyga> morphis: in your setup, how was jenkins installed?
<morphis> good question, plars did it long time ago
<morphis> I guess via debs
<zyga> can you drop us a bug report with: os version, container installation system on host, guest container os version, snap version on both sides, jenkins installation method in guest and the name of the snap used in the CI job
<zyga> I will use that to reproduce and fix it
<zyga> I mean, we kind of feel the fix is a one liner
<zyga> but without a regression test
<zyga> it's a hand-wave-y one
<morphis> zyga: where do you guys file bugs these days? github?
<pstolowski> morning
<zyga> morphis: still on lp
<morphis> zyga: ok
<zyga> launchpad.net/snapd
<morphis> zyga: the snap isn't from the store but I will drop it by mail
<zyga> morphis: it is probably sufficient to classify it (strict or classic)
<zyga> the denial was not related to the snap but to snap-confine
<morphis> it's a classic snap
<zyga> perfect
<zyga> ok
<pedronis> zyga: does this rings any bell:   cannot perform readlinkat() on the mount namespace file descriptor of the init process: Permission denied
<zyga> yes
<zyga> phone
<morphis> zyga: https://bugs.launchpad.net/snapd/+bug/1815869
<mup> Bug #1815869: Command of classic snap fails with denial when output is redirected <snapd:New> <https://launchpad.net/bugs/1815869>
<mvo> pedronis: do we have dmesg output with the appamror denials for this one?
<pedronis> mvo: I don't know, it was on a server
<pedronis> mvo: I'm asking
<zyga> One sec, home stuff
<zyga> re
<zyga> pedronis: it is an issue that surfaces once in a while, typically on older kernels
<zyga> pedronis: it doesn't affect anything, that I'm aware of, is in production
<zyga> morphis: thank you
<pedronis> zyga: a service died on it
<pedronis> but there were other denials before as well
<pedronis> then it restarted
<pedronis> I mean snap-confine denials
<zyga> do you have the log?
<pedronis> yes
<zyga> morphis: I asked one more question on the bug
<morphis> zyga: answered
<zyga> morphis: I'm not familiar with lxd that much, how do I set up nesting + privileged
<zyga> morphis: is lxd on the host a snap?
<morphis> yes
<morphis> lxc launch ubuntu:x test -c security.nesting=true -c security.privileged=true
<zyga> thank you!
<morphis> yw
<zyga> launching now
<zyga> I suspect it is an unsupported configuration in some form, I will confirm soon :/
<zyga> https://www.irccloud.com/pastebin/3G9BKJuL/
<zyga> morphis: ^ this is from installing core in that system
<zyga> Feb 14 08:41:18 xenial snapd[378]: 2019/02/14 08:41:18.178394 backend.go:303: cannot create host snap-confine apparmor configuration: cannot synchronize snap-confine apparmor profile: open /var/lib/snapd/apparmor/profiles/snap-confine.core.6350.Ll210MNsYGb3~: no such file or directory
<zyga> I'm installing core now
<zyga> mvo: will xenial get SRU for newer snapd?
<morphis> zyga: that one is new, I am running snapd in various LXD containers for a long time now
<mvo> zyga: for 2.37.2 ? yes
<zyga> mvo: perfect, thank you
<mvo> zyga: I think its even in the unapproved queue, I need to check
<morphis> zyga: hm, that doesn't happen in a unprivileged container
<mvo> zyga: is that the fix?
<mvo> zyga: if so I will push a bit harder for that
<zyga> morphis: specifically apparmor stacking but please hold on, I don't know the key part yet
<zyga> mvo: no, just curious
<morphis> zyga: unprivileged does not mean there is no apparmor profile for the LXD container
<morphis> s/unprivileged/privileged/
<zyga> installing strictly confined snap in xenial container with privileged/nesting enabled https://www.irccloud.com/pastebin/ghbLQFrn/
<zyga> morphis: ^ I cannot even install a snap in this container
<zyga> morphis: but I managed to reproduce the issue
<zyga> lut 14 09:50:40 crusty kernel: audit: type=1400 audit(1550134240.752:161): apparmor="DENIED" operation="file_inherit" namespace="root//lxd-xenial_<var-snap-lxd-common-lxd>" profile="/snap/core/6405/usr/lib/snapd/snap-confine" name="/home/ubuntu/foo" pid=15267 comm="snap-confine" requested_mask="w" denied_mask="w" fsuid=1000 ouid=1000
<zyga> at least that much is good
<zyga> I will investigate
<morphis> zyga: then the initial snapd setup broke at some point. This container is running for ~1.5y now
<morphis> zyga: great!
<zyga> I updated the bug report again
<zyga> morphis: unsupported may not be broken for some time but may still be unsupported, I'm trying to get to the bottom of what that container setup does
<morphis> zyga: security.privileged=true means the container is not running in a UI namespace
<morphis> security.nesting=true allows processes inside the container to use a stacked AppArmor profile which is otherwise  forbidden by the default LXD AppArmor policy
<zyga> UI namespace?
<morphis> s/UI namespace/UID namespace/
<zyga> ah
<zyga> isn't security.nesting the default? otherwise snaps would just be permanently broken inside containers
<morphis> no
<zyga> that's unexpected, are you sure?
 * zyga tries another container
<morphis> security.nesting=false is the default
<morphis> check https://lxd.readthedocs.io/en/latest/containers/
<morphis> that is why you need security.nesting=true if you want to run snaps inside LXD containers
<zyga> we never set that in our lxc tests
<morphis> lxc or LXD?
<morphis> zyga: looks like snapd works without security.nesting=true too
<zyga> snapd works correctly then
<zyga> the whole container has nesting
<zyga> perhaps that option controls the ability to use nested apparmor inside the container
<zyga> so more nesting
<zyga> otherwise we do get nesting
<morphis> no, you still can't run nested LXD or docker inside a container without security.nesting=true
<zyga> the whole profile is namespaced
<zyga> (ie: nested)
<zyga> that's different
<zyga> lxd does nesting
<zyga> so you need security.nesting to run lxd inside lxd
<zyga> snapd doesn't do nesting
<morphis> yes
<zyga> it just requires a clean slate (nested setup as lxd does automatically)
<morphis> see https://github.com/lxc/lxd/blob/a6b780703350faff8328f3d565f6bac7b6dcf59f/lxd/apparmor.go#L418
<zyga> so a non-privleged container without extra nesting support works OK
<zyga> I ran a busybox snap inside a default container
<zyga> zyga@crusty:/proc/19399$ cat attr/apparmor/current
<zyga> lxd-xenial-default_</var/snap/lxd/common/lxd>//&:lxd-xenial-default_<var-snap-lxd-common-lxd>:snap.snapd-hacker-toolbelt.busybox (enforce)
<zyga> it has a nested profile applied
<zyga> ok, so that much is good
<zyga> lxd nowadays also uses zfs
<zyga> man, all of those are not tested by us :/
<popey> degville: when you have a moment, I have some PRs for the tutorial :)
<degville> popey: awesome, thanks!
<zyga> pstolowski: hey
<zyga> sudo snap remove gnome-3-26-1604 gnome-calculator gnome-characters gnome-logs gnome-system-monitor gtk-common-themes
<zyga> this takes forever on 18.04
<zyga> conflicts
<morphis> zyga: it uses ZFS for quite a long time, if I remember right even 2.0 used it
<zyga> pstolowski: conflicts https://www.irccloud.com/pastebin/fgPcJpHn/
<zyga> pstolowski: is this expected?
<pedronis> zyga: yes, known bug
<pedronis> there's actually a fix up
<zyga> aha, good
<pedronis> but needs to land early in 2.39 cycle
<pedronis> because is delicate
<pstolowski> yep
<pstolowski> zyga: it should succeed after w (long) while
<pstolowski> pedronis: found intersting bug around hotplug and disconnect thanks to my spread test
<zyga> morphis: a container using lxc launch ubuntu:x xenial -c security.nesting=true works OK
<zyga> morphis: I can install more snaps but I still get the denial
<zyga> morphis: I should be able to fix that this way
<Chipaca> o/
<zyga> morphis: but using privileged containers is (for whatever reason) not supported now as things break on installation
<zyga> hey Chipaca :)
<Chipaca> zyga: dunno if you've seen https://forum.snapcraft.io/t/9927/5
<mup> PR snapd#6505 opened: packaging: avoid race in snapd.postinst <Created by mvo5> <https://github.com/snapcore/snapd/pull/6505>
<morphis> zyga: it was working until 2.37.*
<zyga> morphis: that's unrelated
<mvo> hey Chipaca - good morning
<zyga> I'm saying _supported_
<zyga> it may work by accident
<Chipaca> mvo: suuuup
<zyga> Chipaca: I haven't
<pstolowski> pedronis: almost at the end of the test after a series of succesful plugin/replugging i re-plug the device, snap interfaces is happy, connection is restored, but "snap disconnect .." creates an empty change with no tasks (status=Hold). adding an artificial sleep in the test just before disconnect makes it happy. the disconnect bit in api.go looks suspicious, we query repo a few times but there is no locking, so in theory
<pstolowski> we may get inconsistent view of things. ionterestingly it happens all the time on 16.04, but not on 18.04 (in nested vm)
<morphis> zyga: is it documented anywhere which configuration is supported and which not?
<Chipaca> zyga: any snap app gets "cannot create lock directory /run/snapd/lock: Permission denied"
<zyga> morphis: only what we test
<morphis> that is pretty hard to dig out
<zyga> morphis: regular and cloud versions of ubuntu + several other systems
<zyga> morphis: lxd on ubuntu with default config
<mvo> Chipaca: more fun with .37
<zyga> morphis: that's that, anything more may work or not but is not something we test for
<zyga> morphis: but I'm not saying it's hopeless :)
<zyga> morphis: just clarifying why we have not caught that
<morphis> sure
<zyga> morphis: do you need to run a privileged container in your case or was that just a convenience/accident?
<Chipaca> mvo: in what shape, this time?
<pedronis> pstolowski: ah, interesting
<zyga> hmm, I opened a forum topic for unsupported features
<zyga> and I cannot find it
<Chipaca> zyga: finding forum topics for unsupported features is an unsupported feature
<pedronis> pstolowski: ok, I'm not surprised we found issues around our use of the repo, it has an internal lock, doesn't mean it be consulted many times without an external one
<pstolowski> pedronis: yes
<zyga> pedronis: yes, that's true
<zyga> pedronis: in all the cases that we need consistency we should craft a method that uses private unlocked versions while holding the lock for the repo
<pstolowski> pedronis: although what's puzzling me is the fact that snap interfaces check done before disconnect reports the connection, so in theory things should be settled at this point
<pstolowski> but clearly the need for short "sleep" before disconnect contradicts it
<mvo> Chipaca: apparently the catalog update is a bit too non-random and causes store issues
<pedronis> mvo: I'm discussing that with Chipaca
<mvo> ta
<mvo> I was about to say - pedronis knows the details better :)
<pstolowski> zyga: re the waiting.. issue you asked about earlier - https://github.com/snapcore/snapd/pull/6472
<mup> PR #6472: overlord: fix ensure before slowness on Retry <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6472>
<zyga> pedronis: is that overlord change so risky that we cannot just land it for .38?
<Chipaca> mvo: I was hoping it was the same thing =)
<pedronis> zyga: we can reevaluate, remember in theory we should haved cut 2.38 already
<pedronis> but here we are
<zyga> yeah
<zyga> I would vote on landing it to master and reverting if we need to release and feel uneasy about it
<pstolowski> zyga: it looks innocent but is of high risk. if there is anything wrong around this area you may end up with snapd getting stuck and not picking tasks (been there while working on this fix)
<zyga> pstolowski: hence edge
<pedronis> pstolowski: we could probably mitigate the risk of getting totally stuck doing something in the Loop
<pstolowski> pedronis: i can look at it ~next week if time on sprint permits as this week i'd like to address hotplug PRs. i wouldn't rush this fix though given that we don't hear many complaints about it (do we?)
<pedronis> zyga: pstolowski: I don't think we risk getting totally stuck actually, because of the PruneTicker
<morphis> zyga: I currently trying to figure out what the reason was for that
<pstolowski> pedronis: getting stuck was most likely specifically related to my attempts to read from timer channel, so you may be right
<pedronis> pstolowski: yes, that we don't do
<pedronis> we have one place doing that
<zyga> morphis: so I applied a simple fix
<zyga> but ... it has no effect?
<zyga> digging
<zyga> ah, sorry
<zyga> all good
<zyga> morphis: I will have a fix and a regression test
<zyga> mvo: ^ CC, low risk patch re-introducing /var/lib/** rw,
<mvo> zyga: that sounds good
<mvo> zyga: so re-adding this fixed morphis bug?
<zyga> mvo: yes, as expected
<zyga> it is interesting that lxd is a factor
<pedronis> do we have a +1 from jdstrand?
<zyga> because of how profile transitions work
<pedronis> is the setup supported anyway?
<zyga> pedronis: he said as much yesterday in snappy-internal
<zyga> pedronis: lxd is supported, home in /var/lib is not but this was working before so we can keep it working until apparmor grows the delegation features jdstrand described
<zyga> pedronis: the specific case of lxd with stock profile, snapd with classic snaps and home in /var/lib/* will work
<pedronis> zyga: can we make a test?
<zyga> pedronis: certainly, I'm on it now :)
<zyga> pedronis: that's why I ask for bug reports
<zyga> then I can make a regression test and have a matching bug number with more details
<pedronis> pstolowski: mvo: I removed the blocked on #6472 with a comment
<mup> PR #6472: overlord: fix ensure before slowness on Retry <Created by stolowski> <https://github.com/snapcore/snapd/pull/6472>
<mvo> thanks
<pstolowski> pedronis: k, thanks
<pstolowski> it needs 2nd review still
<pstolowski> pedronis: i've addressed/replied to your comments on https://github.com/snapcore/snapd/pull/5962
<mup> PR #5962: ifacestate/hotplug: hotplug handlers <Complex> <Hotplug ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/5962>
<pedronis> pstolowski: do we know already an example that would produce different interfaces at the same devpath?
<pstolowski> pedronis: now, but i was thinking about an "foo-observer" and "foo-controller" type of interfaces
<pstolowski> *no
<pedronis> ok, I see
<pstolowski> so, read-only or full control
<pedronis> pstolowski: did you not push some changes?
<pstolowski> pedronis: ah, of course
<pedronis> or is github confusing me
<pstolowski> pedronis: sorry, now
<pstolowski> pedronis: aaa, we have err shadowed in api.go disconnect - this is the reason of earlier disconnect issue i talked about: error: snap "serial-port-hotplug" has "hotplug-add-slot-serial-port" change in progress
<pstolowski> repo access wrt locks is a separate potential problem, but not in this case i think
<mup> PR snapd#6506 opened: overlord/snapstate: add some randomness to the catalog refresh <Created by chipaca> <https://github.com/snapcore/snapd/pull/6506>
<Chipaca> pedronis: ^ Ã  votre santÃ©
<zyga> ok, that should do it :)
<mup> PR snapcraft#2472 closed: project loader: do not leak a part's build-environment <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2472>
<pedronis> pstolowski: +1 on 5962 but with some requests of tweaks
<pstolowski> pedronis: yay! thank you, will do
 * pstolowski runs malta-related errand
 * pstolowski runs malta-related errand (not a haircut)
 * marcustomlinson loves pstolowski's beautiful long locks
<pstolowski> marcustomlinson: lol
<mup> PR snapd#6507 opened: cmd/snap-confine: allow writes to /var/lib/** <Created by zyga> <https://github.com/snapcore/snapd/pull/6507>
<zyga> morphis: https://github.com/snapcore/snapd/pull/6507
<mup> PR #6507: cmd/snap-confine: allow writes to /var/lib/** <Created by zyga> <https://github.com/snapcore/snapd/pull/6507>
<zyga> popey: nice talk at fosdem!
<zyga> popey: I asked one question https://www.youtube.com/watch?v=UAEdSjou3c4&lc=UgwCtVt0IXrkcLD1jLB4AaABAg
<popey> thanks
<zyga> mvo, pedronis ^ (jenkins regression fix)
<popey> zyga: answered there, but the question came from an endless developer who wanted to see how multiple versions of the same app was presented to the desktop (desktop files) compared to flatpak
<zyga> ah
<zyga> neat
<zyga> I think making desktop icons smarter would be great
<zyga> to add some disambigution in gnome shell
<zyga> (classic, snap, flatpak, etc)
<zyga> or version informationi
<zyga> my wonky "i" make me type like some fake italian
<mvo> zyga: thank you
<mup> PR snapd#6505 closed: packaging: avoid race in snapd.postinst <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/6505>
<pedronis> Chipaca: spread tests for catalog are now failing on that PR :/
<pedronis> not too unexpectedly
<Chipaca> pedronis: :-)
<pedronis> Chipaca: one test doing: test -s /var/cache/snapd/commands.db
<ijohnson> hey zyga, mind pointing me to the spot in snap-confine where nvidia specific udev stuff is run? I only see udev setup from https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/snap-confine.c#L354 AFAICT which won't run if we turn off udev tagging from snapd
<zyga> ijohnson: hey
<zyga> one sec
<ijohnson> thanks
<zyga> ijohnson: https://github.com/snapcore/snapd/blob/master/cmd/snap-confine/udev-support.c#L237
<zyga> but looking at this now I think you are good
<ijohnson> okay, cool. I tested this with my machine with nvidia on it, and still didn't see any udev setup with my PR so it looks good in empirical testing too
<ijohnson> I'll add a comment to the PR
<mup> PR snapd#6508 opened: packaging: avoid race in snapd.postinst <Created by mvo5> <https://github.com/snapcore/snapd/pull/6508>
<zyga> pstolowski: hey
<zyga> do you have a sec for a quick discussion
<zyga> pstolowski: the context is this bug https://bugs.launchpad.net/snapd/+bug/1815722
<mup> Bug #1815722: Namespaces for failed snap installations are not discarded <snapd:In Progress by zyga> <https://launchpad.net/bugs/1815722>
<zyga> pstolowski: I'm trying to figure out where the code for this should live
<zyga> pedronis, Chipaca: ^ CC
<zyga> when the install hook fails we will undo the whole change
<zyga> but it's unclear which task should be responsible for discarding the mount namespace
<zyga> should we encode that as an undo task for the install hook
<zyga> should we encode that as special logic inside the implementation of that specific task (in the do path, when it fails just discard)
<zyga> or should we do something entirely different
<pedronis> zyga: can this happen in some form on a refresh as well?
<zyga> pedronis: install hooks don't run then, if any other hook fails we just restore the old revision and that's handled correctly
<zyga> this feels like a special case
<pedronis> is it handled correctly also if layout related stuff fails?
<zyga> pedronis: it depends on what you mean by fine, if layout application fails we fail loudly (commands and hooks cannot run), then proceed to undo; any changes made to the mount namespace remain intact and are accounted for
<zyga> the subsequent call to snap-update-ns will attempt to change the mount namespace in accordance to what is the new desired format
<zyga> but in either case we never discard the namespace in such situation
<pstolowski> re
<morphis> zyga: thanks
<zyga> any advice?
<pedronis> zyga: we have the same problem on install if starting services fails, no?
<zyga> pedronis: anything that causes a freshly installed snap to fail to install
<pedronis> and runs something potentially
<zyga> yeah,
<pedronis> just saying that I don't think concetrating on install-hook
<pedronis> makes sense
<pedronis> zyga: anyway it seems something to do in the undo of link snap if the situation is a first install attempt?
<zyga> yes, I was thinking about anything that is special to first-install
<zyga> I agree
<zyga> perhaps link is the right place
<zyga> it's also annoying because this is cross manager
<zyga> but I think we have handlers for that
<pedronis> zyga: well , we need to merge bits of tasks of ifacestate and snapstate anyway
<zyga> yes but hopefully not for this fix :)
<pedronis> zyga: where do we discard the namespace for remove ?
<zyga> there's a dedicated task for that IIRC
<zyga> let me look
<pedronis> zyga: it's done in discard-snap
<pedronis> so that's already snapstate afaict
<pedronis> zyga: pstolowski: my impression is basically there might be more bits done in discard-snap
<pedronis> that we also need to do in undo link-snap
<pedronis> if it's a first install
<pstolowski> reading the backlog
<pedronis> pstolowski: do we need to remove the config as well for example?
<pedronis> pstolowski: zyga: basically compare  the code under https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L1387 vs https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L1084
<pedronis> what does make sense for both
<pedronis> do the 2nd seems to have more len(seq) == 1 sections
<pstolowski> pedronis: indeed, we have a problem with config too, we should remove it in undo of link-snap
<pstolowski> pedronis, zyga and i agree, undo of link snap is a good place for the namespace cleanup
<pedronis> pstolowski: there is a call to config.RestoreRevisionConfig with an XXX later there
<pedronis> pstolowski: not sure what it does? are we missing a test?
<zyga> pedronis: indeed, thank you, I'm looking at this now
<pstolowski> cachio: i pushed fixes to hotplug-nested-vm, it's now passing for me on 16.04. old qemu is not a problem.
<cachio> pstolowski, nice, I'll give a run again
<cachio> thanks for fixing it
<pstolowski> pedronis: RestoreRevisionConfig would restore configuration of previous revision of the snap, but that's not going to help on undo of new install, we will leave config behind. yes i think undo is missing a test for this
<pedronis> pstolowski: yea, that code looks broken, like the condition should be the reverse?
<pedronis> != 1
<Chipaca> pstolowski: pedronis: that's one of the places I added an XXX i think
<Chipaca> as the logic didn't seem to make much sense
<pedronis> Chipaca: yea, seems there is a bug lurking there and missing tests
 * zyga breaks for a walk with the dog
<pstolowski> pedronis: yes i think you're right
<Chipaca> https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L1125 <- that's the one i meant
<pstolowski> pedronis: i can add it to my todo list and address soon
<pedronis> pstolowski: thx
<Chipaca> pedronis: it's a different one -- with possibly the same logic
 * Chipaca â lunch
<pedronis> Chipaca: heh
<popey> degville: fyi, I edited "Installing snap on kde neon" and replaced your dark theme screenshots with default theme ones :)
<popey> (at the kind and friendly request of upstream) :)
<degville> popey: thanks! you're absolutely right... I've used it so long I forget it's not default.
<popey> I think the words were "Which nerd uses the dark theme?" :)
<popey> (I do too)
<popey> I <3 KDE Neon
<degville> ahaha... yeah. Arc Dark and Papirus ftw.
<mup> PR snapd#6509 opened: overlord/snapstate: discard mount namespace when undoing 1st link snap <Created by zyga> <https://github.com/snapcore/snapd/pull/6509>
<zyga> pedronis: ^ thank you for the idea again
<Chipaca> hmmm
 * Chipaca hmms
<t1mp> How do I downgrade to snapcraft2 with snap? On https://snapcraft.io/snapcraft I can only find 3.x versions
<pstolowski> zyga a question there
<Chipaca> t1mp: snapcraft3 ships 2 as well
<Chipaca> t1mp: if your snapcraft.yaml doesn't have a base, you get 2
<t1mp> I use core18 as base. But snapcraft3 broke some things (probably I can fix them, but it takes more time which I don't have right now)
<Chipaca> t1mp: which things? (maybe the fix is easy)
<Chipaca> sergiusens: ^
<t1mp> some things were easy, like the version should be "2" instead of 2 (int).
<popey> version is indeed a string
<t1mp> I worked around the cloud parts that I couldn't use any more
<t1mp> and now, I have this:
<t1mp> version-script: python3 ../qmenta_gui/python/qmenta/gui/version.py
<popey> it was a bug that it allowed int
<t1mp> so when I build the package now, that cannot be executed. I don't have those files in the vm that multipass created. I guess with snapcraft2 it was not executed in a vm.
<popey> one thing you might want to try is "snapcraft --shell-after" which drops you into the vm post-build, which allows you to debug these things
<popey> I have started using adopt-info: partname, and using "snapcraftctl set-version '$(something)'" to set the version in override-build: | section in the part
<popey> (there's some examples of this in the snapcrafters repo)
<mvo> zyga: https://github.com/snapcore/snapd/blob/master/sanity/apparmor_lxd.go#L33 <- this is what we have currently for testing inside containers
<t1mp> debugging is a bit of a hassle, because every time I rebuild the snap it takes 10 minutes or so
<popey> the handy thing about debugging with --shell-after, is you get dropped in the VM, and can cd project/ and then run snapcraft *in* the VM
<popey> which will save time
<t1mp> I'll try that in the next re-run :)
<zyga> mvo: right, we would have to have some more logic to check if we are running without pid namespace
<zyga> mvo: er, uid namespace
<zyga> mvo: this is not sufficient (separate issue)
<t1mp> hmm.. The snap I create locally works as expected. But the snap created from the same source, on jenkins, has a bug.
<t1mp> I can try to install snapcraft 3 there. But then I have Google VM -> Docker Ubuntu 18.04, with snapcraft 3 snap package, creating a qemu (?) vm to build the snap package..?
<t1mp> if I am already in an ubuntu 18.04 docker image, do I really need a VM for creating snap packages?
<Chipaca> t1mp: no, if you're in docker, you can tell snapcraft to chill about the vm
<popey> there's a way you can do that, yes.
<Chipaca> if you're already in an ad-hoc vm that is
<t1mp> yeah, I'm in a container
 * Chipaca nods
<Chipaca> it wasn't --chill-about-the-vm-already
<popey> I can't for the life of me remember what it is
<t1mp> the container is only created to run tests and build the package
<popey> sergiusens: ^ what's the "let me do dangerous things" parameter for snapcraft? (to build on a host)
<Chipaca> t1mp: popey: --destructive-mode
 * Chipaca hugs grep
<popey> ð£
<Chipaca> fwiw: grep -hor --include '2019*' 'snapcraft.*--[a-z_-]*' ~/.config/hexchat/logs/
<t1mp> Chipaca: I guess that is not printed on purpose when I do --help?
<t1mp> Chipaca: anyway, thanks :)
<Chipaca> t1mp: your guess is as good as mine
<Chipaca> t1mp: it's probably supposed to only be internal
<popey> bugs.launchpad.net/snapcraft :)
<Chipaca> t1mp: as it's what snapcraft uses to launch snapcraft inside the vm, afaik
<t1mp> ah. snapcraft help build shows it.
<mup> PR snapd#6510 opened: tests: stop catalog-update test for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6510>
<sergiusens> Chipaca: popey t1mp it is printed with `snapcraft <pull|build|stage|prime|snap> --help`
<sergiusens> snap is the default param for snapcraft, I wish we did not have a default, life would be simpler
<sergiusens> popey: when inside the VM, no need to `cd project`, you can run snapcraft from whatever PWD
<popey> TIL
<jdstrand> mvo: I commented on https://github.com/snapcore/snapd/pull/6508. I think the access() is unneeded...
<mup> PR #6508: packaging: avoid race in snapd.postinst <â  Critical> <Created by mvo5> <https://github.com/snapcore/snapd/pull/6508>
<t1mp> is snapcraft using qemu instead of lxd to be compatible with windows/macos?
<sparkieg`> t1mp: essentially, yes
<zyga> for all the meetings https://twitter.com/garabatokid/status/1016240967702204416 ;-)
 * cachio lunch
<jdstrand> mvo: oh, I misread. sorry, nm
<mvo> jdstrand: thank you
<mvo> jdstrand: maybe I should have added a comment there or rewrite the code, its definitely not obivous (which is why this is buggy :(
<jdstrand> mvo: maybe an added comment "If after the rewrite we are still not ok, die" or something
<jdstrand> mvo: but pr approved as is
<Chipaca> jdstrand: very low priority ping about icdiff
<mvo> jdstrand: \o/ thanks, I will add the chnage
<pedronis> mvo: why the mount-support.c change there ?
<pedronis> I mean I mentioned that issue in another PR
<pedronis> but why mixing it with that?
<mvo> pedronis: the upgrade test from 2.15.2 fails without it
<mvo> pedronis: it will die because it claims it can't find ubuntu-core
<mvo> pedronis: 2.15.2ubuntu1 is still using ubuntu-core as base
<jdstrand> Chipaca: you wouldn't know it because I haven't been transparent, but I've been working hard on a review-tools update to support that
<jdstrand> they had some old janky code that was brittle and I rewrote it. should be committing today, at which point I'll add the aliases
<jdstrand> (and ask for a store pull, etc)
<pedronis> mvo: can put it in a comment somewhere in it
<mvo> pedronis: sure, adding it now
<pstolowski> zyga: i see that repo.ResolveDisconnect is only used by api - disconnect; i'm going to change it to return []*Connection instead of []*ConnRef to remove the need for second call to repo. do you see any problem with that?
<mvo> pedronis: updated the comment
<zyga> pstolowski: I honestly don't know, is it tricky?
<zyga> looking at the code now
<pstolowski> zyga: no, not really
<pstolowski> zyga: and it's easy to get ConnRef from Connection, if needs be
<pstolowski> zyga: this will just let avoid ping-pong with the repo for disconnect case
<zyga> yeah, looks ok
<zyga> I wonder if connref should grow something
<zyga> to detect unexpected changes colliding
<pstolowski> zyga: connref? can you elabortae
<pstolowski> *elaborate
<zyga> a cookie derrived from the number of changes to the repo
<zyga> so you can get a conn ref in one place
<zyga> pass it elsewhere
<zyga> and use it if it is still "fresh'
<zyga> your desire to change the return type, is it to avoid a race?
<pstolowski> ah, a "smart pointer" ;)
<pstolowski> zyga: yes, to avoid repo.Connection() on a connref returned by repo.ResolveDisconnect(), that may no longer be there
<pstolowski> on the other hand, i'm not sure it's worth fixing
<pstolowski> it's basically for the cases where you don't fully specify plugs or slots, and let resolve compute the list
<pekkari> hI #snappy, I hit an error with juju snap, cannot create user data directory, Permission denied, can anybody help?
<zyga> pekkari: can you be more specific please
<pekkari> I see -> cannot create user data directory: /path_to_my_home_folder/snap/juju/6362: Permission denied when I execute anything in juju
<zyga> what is your home folder path?
<pekkari> for some reason, it's decided to be under /var/lib/home/my_user, I cannot tell who was having that great idea :$
<zyga> pekkari: that location is not supported by snapd
<pekkari> nevertheless the folder ~/snap/juju/6362 exists
<pekkari> hummm... unfortunately I cannot decide on the folder path zyga, customer stuff
<mup> PR snapd#6511 opened: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>
<zyga> pekkari: we cannot support arbitrary folder names either
<pekkari> I'll need to try to bind mount the folder on /home/my_user
<zyga> pekkari: I'm curious what was the motivation to store the home folder in /var/lib/ rather than in /home, is it a service (e.g. jenkins) or just some specific customer convention?
<pekkari> zyga: customer convention, no service, but shared account for a team
<Chipaca> jdstrand: thanks for the update! no worries about the rest of it
<pekkari> have you any experience using mount --move zyga? seems to be the way to go as long as bind still resolves the /var/lib/home/blah folder
<pekkari> I just never happen to use it
<zyga> pekkari: using it in which sense? yeah it works and snapd used to use it internally for one specific case
<zyga> pekkari: but I'm not using the feature myself much
<pekkari> well, use it to solve the path problem without screwing the home folder where I have the sensitive info
<zyga> pekkari: I don't understand, can you explain what you mean?
<pekkari> I just want to know it's a safe operation, ta
<zyga> perhaps? I don't know for sure
<zyga> on a live production system?
<pekkari> no, testing env, but still I have an fce workspace there that I'm taking backups just in case
<pekkari> grrrr. shared mount...
<Pharaoh_Atem> zyga: does that mean that home directories on Silverblue don't work either?
<Pharaoh_Atem> they're in /var/home rather than /home
 * cachio afk
<zyga> Pharaoh_Atem: correct
<zyga> Pharaoh_Atem: we cannot support all the random locations people come up with
<Pharaoh_Atem> well, it's symlinked to /home
<zyga> Pharaoh_Atem: we can add support for /var/home perhaps but not for every single random combination :)
<zyga> Pharaoh_Atem: with mount namespaces, symlinks don't matter sadly
<Pharaoh_Atem> well /var/home is used by Atomic Fedora and SUSE MicroOS
<zyga> well, they should have just used home
<zyga> it's just a location after all
<zyga> they can mount there
<Pharaoh_Atem> it's when there isn't separate partitions
<zyga> we can support /var/home eventually
<zyga> just weird
<zyga> I don't see how this is related to partitions
<Pharaoh_Atem> the standard layout has two partitions, one managed by OSTree and another umanaged
<Pharaoh_Atem> *unmanaged
<Pharaoh_Atem> they've moved all the written stuff to there by default
 * Pharaoh_Atem shrugs
<zyga> if your ostree has /home you can mount there, right?
<Pharaoh_Atem> yes
<Pharaoh_Atem> and people do if they have a separate /home partition
<zyga> so what's the need for /var/home?
<Pharaoh_Atem> if when they don't have it
<zyga> you don't need a separate home partition
<Pharaoh_Atem> usually it'd be / if you don't have a separate /home
<zyga> you can bind mount /home or even each /home/whatever
<zyga> you can mount subtrees
<Pharaoh_Atem> I know
<Pharaoh_Atem> but they do it by symlink right now
<zyga> so /home/foo is a symlink to /var/home/foo?
<zyga> I guess snapd could learn a trick to make /var/home/$LOGNAME a way to access user's (whatever) home directory
<zyga> but dragons apply :)
<zyga> anyway
<zyga> I meant to thank you for the release coordination the other day
<zyga> I'm sleepy as hell now
<zyga> I was meant to say I'll EOD now
<mup> PR snapd#6510 closed: tests: stop catalog-update test for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6510>
<Chipaca> niemeyer: could spread error if you told it to run on a system that doesn't exist?
<niemeyer> Chipaca: Hmm.. doesn't it?
<Chipaca> niemeyer: not with globs
<Chipaca> niemeyer: just spotted a test that had systems: [ubuntu-16-*, ubuntu-18-*]
<Chipaca> (neither of those matches anything)
<niemeyer> Chipaca: Yeah, it's definitely plausible since we have the full real set in memory.. we ought to do that.
<niemeyer> Chipaca: ah, wait
<niemeyer> Chipaca: I misunderstood.. I thought you were asking for it to run on the cmdline and didn't match anything
 * Chipaca feels misunderstood
<niemeyer> Chipaca: Maybe it should warn in those cases you mention
<niemeyer> Chipaca: Not sure if error as it could make a refactoring pretty boring
<niemeyer> Chipaca: Or maybe let's just do it and see if people get mad at us
<niemeyer> Erroring on the safe side can't go too wrong
<Chipaca> niemeyer: a warning would've helped indeed
<Chipaca> niemeyer: and yeah there're probably people depending on the behaviour :-)
<pedronis> Chipaca: see mvo find on the PR, we need to use int64 and corresponding rand helper
 * Chipaca looks
<Chipaca> pesky puny computers
<Chipaca> I'm going to EOD now before I break something important
<Chipaca> o/
<mup> PR snapd#6507 closed: cmd/snap-confine: allow writes to /var/lib/** <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6507>
<mup> PR snapd#6509 closed: overlord/snapstate: discard mount namespace when undoing 1st link snap <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6509>
<mup> PR snapcraft#2471 closed: test: test-beta <do-not-merge-yet> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2471>
<pedronis> Chipaca: surprisingly butn not, catalog-update passes also with /names down
<pedronis> so we shouldn't turn it off
<Chipaca> pedronis: yes I noticed that locally, assumed mvo saw it fail
<pedronis> Chipaca: we should push to turn it on
<pedronis> again
<Chipaca> pedronis: push who?
<pedronis> Chipaca: you were pushing stuff recently? can you otherwise I can try to do it
<mvo> how come this works when /names is down? just curoious haven't looked at the details of the test
<pedronis> mvo: it doesn't really check that we got date, it checks that we tried
<Chipaca> mvo: because all it does is check that catalog refreshes was attempted
<Chipaca> yeah
<pedronis> data
<Chipaca> "at least you tried" golden star
<pedronis> the other two do check data
<pedronis> apt-hooks
<pedronis> and snap-advise-command (except that it was not run)
<pedronis> Chipaca: are you working on turning it back on? otherwise I'm close myself
<pedronis> Chipaca: mvo: pushed to turn catalog-refresh back on
<pedronis> *catalog-update
<mvo> pedronis: ta
<mup> PR snapd#6508 closed: packaging: avoid race in snapd.postinst <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6508>
<Chipaca> pedronis: sorry, was afk for a bit
<pedronis> Chipaca: it's ok
<pedronis> we should all be eoded really
<mvo> pedronis: yes, I need to go
<mvo> 5606 should be squashed
<mvo> I will merge tomorrow into 2.37
 * mvo waves
#snappy 2019-02-15
<zyga> Hey
<zyga> I will be partially away for errands
<pstolowski> mornings
<luk3yx> Is there any way I can access the system's locale directory from a snap (with the "strict" confinement)?
<Chipaca> luk3yx: no
<luk3yx> Shouldn't there be a way to do that?
<Chipaca> luk3yx: ...no?
<Chipaca> luk3yx: what for?
<luk3yx> gettext() I think
<Chipaca> luk3yx: what are you l10n'ing?
<luk3yx> Minetest
<Chipaca> luk3yx: how would the system's locale directory have minetest strings in it?
<luk3yx> Maybe it's a bug in Minetest then, it doesn't show certain text when it can't access the locale directory
<Chipaca> luk3yx: it doesn't show it translated, or it doesn't show it at all?
<luk3yx> It doesn't show certain text (such as the title) at all
<luk3yx> Oh, I can disable gettext
<Chipaca> luk3yx: gettext will print the msgid if it can't find a translation
<Chipaca> luk3yx: that is, gettext("house") will return "house" if it can't find the locale to print "casa"
<Chipaca> s/print/return/
 * Chipaca still having breakfast
<Chipaca> luk3yx: so it's probably something else
<luk3yx> Okay, thanks
<Chipaca> luk3yx: now, you can ship your localisation strings inside the snap
<Chipaca> luk3yx: IIRC there's even helpers for that
<luk3yx> It should be doing that anyway
<Chipaca> luk3yx: ok
<luk3yx> Oh, it's probably looking in the wrong place
<ackk> hi, has something changed recently in the way snapcraft handles the env? I used to be able to override-build and change PATH, but it seems it's not working anymore
<Chipaca> ackk: my suggestion would be to ask later, or open a forum topic
<Chipaca> ackk: most snapcraft proper is asleep
<Chipaca> and
<Chipaca> we're off to a conference next week, so async communication will work best
<ackk> ok, thanks
<abeato> mvo, morning! I have just noticed that core18 does not have initramfs, I'm curious, why that decision?
<mvo> abeato: no initramfs package you mean? we stripped everything out and added only the bits needed, if you need it back we can add it back
<mvo> abeato: or am I misunderstanding? do you mean the initramfs bits that are in the core snap and used by the kernel?
<abeato> mvo, well, it is used when building the kernel snap - that means that we would use the initrd that is shipped with core even in pure core18 devices
<abeato> mvo, that is correct
<abeato> mvo, snapcraft downloads core and gets the initrd from there in the kernel plugin
<Chipaca> mvo: wrt 6506, I'm puzzled about having to do https://github.com/snapcore/snapd/pull/6506/commits/49b86259568abe1bce74fb625b479417c46e3fa4
<mup> PR #6506: overlord/snapstate: add some randomness to the catalog refresh <Squash-merge> <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6506>
<pedronis> that needs to change somehow
<mvo> abeato: I see, we have not defined the new process for this, note that our kernel snap is not using that initrd, its pulling it from our ppa/image
<pedronis> core18 is a base now
<abeato> mvo, in fact snapcarft woule need to be modified to address this too
<mvo> abeato: yeah, sounds like somehting we should discuss in malta
<pedronis> in theory the developent image coresponding to a base can have more stuff than the base
<abeato> mvo, right, probably it would be better if simply core did not ship initrd and snapcraft pulled it from the right place depending on the base for the kernel snap - which I do no know if can be defined for a kernel snap anyway
<abeato> pedronis, I had not heard about development images, is that something new?
<pedronis> when you build with a base  snapcrat gets a corresponding multipass image
<pedronis> which is not just the base snap
<pedronis> or at least that was the plan afaik
<abeato> aha, interesting - would be something good to discuss in Malta
<mvo> abeato: yes, I think we need to define a better process
<mvo> abeato: hence malta :)
<abeato> yeah, sure thing
 * dot-tobias says hi
<Chipaca> augh
<Chipaca> pedronis: please let me know you're editing a pr i'm working on
<Chipaca> mvo: I'm off to prep for the trip; telegram works
<mvo> Chipaca: thanks
<zyga> Re
<zyga> Just getting coffee, cannot wake up today. Paperwork for Lucy is done. I will work on the patches mvo knows about now
<zyga> ok back now
<zyga> mvo: anything urgent to jump at instead of the patches?
<zyga> guess not
<zyga> pstolowski: hey
<zyga> on 2nd though, about your question on ConnRef
<zyga> I was wondering if this is really the tip of a larger problem to address
<zyga> let's not change that method yet please, we can discuss on Sunday, ok?
<pstolowski> zyga: hey. yes, indeed i had same thoughts, that's why i proposed an obvious fix for api bug first (https://github.com/snapcore/snapd/pull/6511);
<mup> PR #6511: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>
<pstolowski> zyga: i've a change for repo ready in a separate branch (worked on this morning), but yeah, i'm kinda unsure about this
<pstolowski> zyga: the fix for api should land though
<zyga> +1
<zyga> pstolowski: my feeling is that repo needs to become transactional OR we need to change locking semantics entirely
<zyga> (caller locks)
<pstolowski> zyga: yes
<pstolowski> zyga: it was all kinda ok when we only acessed repo from tasks and all accesses were locked by state
<zyga> yeah
<zyga> I agree
<pstolowski> zyga: then i introduced repo access in api, for disconnect and hooks
<pstolowski> zyga: so yeah, let's talk in malta
<mup> PR snapd#6512 opened: overlord: fix random typos <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6512>
<zyga> quick trivial ^
<mvo> zyga: thank you!
<zyga> hey mvo :)
<mvo> zyga: patches are the most important thing right now
<mvo> pedronis: lp-1813963 failed, I saw this before, I think we should disable this test, it seems to be unreliable
<zyga> oh?
<zyga> how does it fail?
<zyga> mvo: ?
<mvo> zyga: https://paste.ubuntu.com/p/fB35ntFNFv/
<mvo> zyga: we can investigate in a bit but probably simply a dirty dmesg
<zyga> hmmmm
<zyga> it's unlikely
<zyga> I clean dmesg explicitly
<zyga> feels like worth having a look to just get the denials
<zyga> did you get the debug part as well?
<mvo> zyga: let me see if I find it
<mvo> zyga: for reference full log is https://api.travis-ci.org/v3/job/493672747/log.txt
<mvo> zyga: it dies in prepare
<mvo> zyga: [ 1176.079662] audit: type=1400 audit(1550229169.481:649): apparmor="DENIED" operation="signal" profile="snap-update-ns.test-snapd-simple-service" pid=12178 comm="4" requested_mask="send" denied_mask="send" signal=term peer="snap-update-ns.test-snapd-simple-service"
<zyga> thanks, let me look at one thing quickly
<zyga> hmmmm
<zyga> interesting
<zyga> it's a real bug, the fix is simple but this is curious
<zyga> mvo: something like this
<zyga> https://www.irccloud.com/pastebin/bxOqgLJE/
<mvo> zyga: makes sesne, isn't that kind of central to how alarm() works, makes me wonder why we did not hit this earlier - oh well
<mvo> zyga: or am I missing things?
<zyga> mvo: it's not in snap-confine
<zyga> look at the profile name
<zyga> it's sun
<mvo> zyga: its snap-update-ns, right?
<zyga> probably the mocked sun binary
<zyga> your simplification I suspect
<mvo> zyga: aha
<zyga> but I don't recall what was done there in the end
<mvo> zyga: its a simple time.Sleep(31s)
<zyga> hmm
<zyga> so real sun doesn't need this
<zyga> so we're back to changing things for a test
<zyga> but at  the same time I think this is super safe
<zyga> it's self-signaling
<zyga> should be allowed
<zyga> we're not allowing it only becaue we're not using any of the typical abstractions
<mvo> zyga: we could just extend the profile in the test, yes?
<zyga> nah, just extend the template
<zyga> it's way less headache
<zyga> (see what I did to make the template different just for the test before)
<mvo> zyga: true
<mvo> zyga: I have a meeting in a bit and need some lunch before, I can look at this after the meeting or maybe someone else can help? pstolowski  could probably proposehttps://www.irccloud.com/pastebin/bxOqgLJE/  maybe?
<mvo> zyga: does that make sense?
<mvo> zyga: then you can focus on the other thing you work on right now :)
<mvo> ETOOMUCH
<zyga> yes
<zyga> I'm not interrupting the other patches I'm working on
<zyga> but I can propose this by EOD  if nobody does
 * mvo vanishes for lunch for some minutes
<mvo> zyga: thanks
<pstolowski> zyga, mvo i can do that
<zyga> pstolowski: some food for thoght
<zyga> pstolowski: no device cgroup
<zyga> pstolowski: no udev tagging for any device assignment
<zyga> pstolowski: (scratch that, no udev tagging like we currently do, we can keep the tagging part)
<zyga> pstolowski: udev tagging invokes small binary that modifies certain persistent kernel objects
<zyga> pstolowski: device filtering only as eBPF programs
<zyga> mvo: I replied on the patches thread
<zyga> mvo: please advise on preferred approach
<zyga> pstolowski: in my head this is working as follows: we create and update, on demand, kernel objects representing access permissions for a given snap
<zyga> pstolowski: all snaps launch with a eBPF program that controls device access
<zyga> pstolowski: snap-device-helper mostly goes away (would need to be rewritten as a small C program)
<pstolowski> zyga, interesting!
<zyga> pstolowski: alternatively, as a snapctl thing but I think that is problematic (early boot)
<zyga> pstolowski: the persistent objects are described by bpf(2) man page
 * zyga  AFK  for more errands
<pstolowski> zyga: looks extremely interesting, thanks
<pstolowski> will take a look
 * pstolowski lucnh
<mup> PR snapd#6513 opened: [RFC] many: support `snap install --skip-service-start` <Created by chipaca> <https://github.com/snapcore/snapd/pull/6513>
<Chipaca> mvo, pedronis, popey & Wimpress: ^?
<Chipaca> pedronis: it's a very minor complication to doInstall, IMHO, and it'll help people that're currently suffering
 * Chipaca goes back to trip prep
<pedronis> Chipaca: it seems a bit too specific, a commented a bit
<pedronis> I commented
<kjackal> Hi snappy people this page from the official docs seems to be missing https://docs.snapcraft.io/1239
<mvo> Chipaca: nice!
<Chipaca> kjackal: where did you get that link?
<Chipaca> kjackal: that's not part of the official docs, and it shouldn't be linked to from the official docs
<Chipaca> kjackal: that's https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239
<degville> Chipaca / kjackal: all those posts are published currently - it's probably not linked anywhere. But there's an issue for removing them.
<Chipaca> yeah the docs thing should only be serving 'docs'
<Chipaca> Â¯\_(ã)_/Â¯
<degville> kjackal: I think we can add to that page though to make it clearer.
<degville> kjackal: (with info from the responses to the question - and thanks for the question)
<kjackal> degville: Chipaca: I go to this page from the official docs by searching for "schedule". First link.
<mup> PR snapd#6503 closed: tests: use snap which takes 15 seconds to install on retryable-error test <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6503>
<kjackal> So where is the official docs for snap refresh scheduling?
<degville> kjackal: https://docs.snapcraft.io/keeping-snaps-up-to-date/7022
<kjackal> Awesome, thank you
<degville> np. thanks for flagging the issue.
<mup> PR snapd#6376 closed: tests: split the test interfaces-many in 2 and remove snaps on restore <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6376>
<zyga> pstolowski: did you push that one-liner by any chance?
<zyga> it will fix master
<kenvandine> zyga: in case i haven't said this before... thanks for layouts!
<kenvandine> sooooooo useful
<zyga> :love: :)
<zyga> thank you
<zyga> I'm making them better
<zyga> just slow to land stuff
<kenvandine> so many snaps with the same copy and pasted parts to for handling relocation
<kenvandine> that i can remove now
<kenvandine> like iso-codes
<tomwardill> hi all, if I've got an Ubuntu Core image, is it possible to enable some form of verbose debugging on a `snap install` command, so I can see HTTP requests snapd is making?
<Chipaca> tomwardill: yes
<Chipaca> 1 sec
<Chipaca> tomwardill: sparkiegeek's description of how to enable debug in snapd remains the best one I know: https://forum.snapcraft.io/t/extremely-slow-snap-downloads/4668/2?u=chipaca
<pstolowski> zyga: pushing
<tomwardill> Chipaca: ah, that will do nicely, thanks!
<mup> PR snapd#6514 opened: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <https://github.com/snapcore/snapd/pull/6514>
<pstolowski> pedronis, zyga, mvo : good news about daemon/api - disconnect - we already lock state early, so there is no problem after all \o/ and #6511 is really the only fix needed
<mup> PR #6511: daemon/api: fix error case for disconnect conflict <Created by stolowski> <https://github.com/snapcore/snapd/pull/6511>
<pstolowski> zyga: pushed #6514
<mup> PR #6514: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <https://github.com/snapcore/snapd/pull/6514>
<zyga> thnx
<zyga> pstolowski: you have feedback on your PR
<pstolowski> updated
 * cachio lunch
<Chipaca> tomwardill: ah, also, https://gist.github.com/chipaca/5d0f0e2b7fecd2df87f25b798a6c6537
<tomwardill> Chipaca: ooh, excellent. I was just having 'fun' with trying to human parse the journal logs :)
<Chipaca> yeah
<mup> PR snapd#6515 opened: tests: fix upgrade-from-2.15 with kernel 4.15 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6515>
<mvo> pedronis, zyga: test passed here with 4.15.0-1026-gcp but [  352.490101] audit: type=1400 audit(1550243833.895:40): apparmor="DENIED" operation="file_mmap" profile="snap.go-example-webserver.webserver" name="/usr/lib/snapd/snap-exec" pid=22902 comm="snap-exec" requested_mask="m" denied_mask="m" fsuid=0 ouid=0
<mvo>  
 * mvo runs again
<mup> Bug #1816073 opened: snap info does not scope to brand store <Snappy:New> <https://launchpad.net/bugs/1816073>
<zyga> mvo: that makes no sense, it passed but was denieid
<zyga> it makes me feel that the test is flawed and cannot detect service being broken correctly
<mvo> zyga: I don't think the test is broken, something else is strange
<zyga> I agree with strange
<BjornT> hi. i have a problem running a snap inside a container. it's unusable, since snapfuse take 100% cpu for some reason. if i use 'snap try' on the prime dir, instead of install the actual snap file, it works without any problems.
<Chipaca> mvo: I'm guessing 6515 means I'm going to have to merge master again
<zyga> BjornT: snap try uses a local bind mount
<zyga> BjornT: snap install uses snapfuse
<mup> Bug #1816073 changed: snap info does not scope to brand store <Snappy:Invalid> <Snap Store:Invalid> <https://launchpad.net/bugs/1816073>
<zyga> BjornT: can you please report a bug on launchpad.net/snapd with the details of the container (how to reproduce yor setup)
<zyga> BjornT: I cannot promise any quick fix but Friday and people are about to go away for travel and errands next week
<BjornT> zyga: ah, that explains that. sure, i'll report a bug
<zyga> BjornT: note that snapd doesn't actively detect all unsupported container environments
<zyga> BjornT: tl;dr; recent versions of lxd on recent kernels work, everything else is a "maybe"
<zyga> BjornT: privileged containers don't work with snapd
<BjornT> zyga: does bionic count as 'recent'?
<zyga> BjornT: yes
<zyga> 16.04+
<BjornT> ok, that's good
<zyga> mvo: gah, I think seccomp is just really more buggy
<mvo> Chipaca: maybe, lets see if my change helps
<mup> PR snapd#6514 closed: interfaces/apparmor: allow sending and receiving signals from ourselves <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6514>
<mvo> zyga: just fyi - adding "/usr/lib/snapd/snap-exec m,
<mvo> " seems to be not helping :/
<mvo> zyga: hold on, silly me
<zyga> what are you getting?
<mvo> zyga: sorry, it does fix it
<mvo> zyga: so 6515 is the workaround for the test fix
<zyga> ok
<zyga> I'm doubting libseccomp
<zyga> the pfc program is garbage
<zyga> I'm using the disassembler from the kernel to check
<zyga> sanity testing on other arches now
<DonAlex> OK can someone tell me why I get launch failed: instance "<snap-name>" already exists when I try re running snapcraft ?
<DonAlex> How do I stop the instance so i can rebuild with different options ?
<Chipaca> DonAlex: you still there?
<mup> PR snapd#6515 closed: tests: fix upgrade-from-2.15 with kernel 4.15 <Created by mvo5> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/6515>
<pedronis> I merged master again into #6506 (so get that ^)
<mup> PR #6506: overlord/snapstate: add some randomness to the catalog refresh <Squash-merge> <â  Critical> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6506>
<mvo> pedronis: great
<mup> PR snapcraft#2473 opened: cli: validate schemas before invoking provider <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2473>
<mup> PR snapd#6516 opened: interfaces/seccomp: generate global seccomp profile <Created by zyga> <https://github.com/snapcore/snapd/pull/6516>
<bdx> hello
<bdx> is there a way to include a private git repo as a git source type in snapcraft.yaml?
#snappy 2019-02-16
<returnthis> I am trying to get snapd to work on my local system and I am having an ungoogable problem. Is this where I can get help with that tool?
<returnthis> I installed snapd, then read I should have apparmor enabled first. so I uninstalled snapd, enabled apparmor and resinstalled snapd
<returnthis> The issue is that now I get errors for snap list
<returnthis> error: cannot list local snaps! cannot find publisher details: snap-declaration
<returnthis>        (buPKUD3TKqCOgLEjjHx5kSiCpIs5cMuQ; series:16) not found
<returnthis>  
<returnthis> looks like there was some left over data when I removed it
<returnthis> snapd[1960]: snapmgr.go:247: cannot read snap info of snap "hello-world" at revision 27: cannot find installed snap "hello-world" at revision 27: missing file /var/lib/snapd/snap/hello-world/27/meta/snap.yaml
<DonAlex> Can someone tell me what is happening here? The build seems ok but it barfs finding the binaries ? https://paste.ubuntu.com/p/YVrksKG9Cs/
<DonAlex> Ahh ok. figured it. the preceding / needs to be left out if you are specifying /usr/local/bin.
<cjwatson> DonAlex: Um possibly at least as relevant is that you misspelled "/usr/local/bin" as "/usr/loca/bin"
<DonAlex> Yeah I fixed that..
<DonAlex> but it was the leading /  that caused the issue..
<DonAlex> has to be usr/local/bin though that is not explained anywhere
<cjwatson> Yeah, I suppose that's what "Ensure that ... is relative to the prime directory" means
<DonAlex> Quite..
<DonAlex> Anyway.. am I right to include the missing libs in the staging part ?
<cjwatson> That I can't advise on, sorry
<DonAlex> It builds now but I am a little perturbed but that warning The 'rolisteam' part needs the following libraries that are not included in the snap or base:
<DonAlex> Well I have added them and seeing if it gives me less warning
<cjwatson> That does sound like you need to bundle the libraries, yes
<DonAlex> Have you done any multiarch building btw ?
<DonAlex> ok this makes no sense. I am getting this error. But I included libpulse0 in the stage packages ?
<DonAlex> ideas?
<DonAlex> \/snap/rolisteam/x2/usr/local/bin/rolisteam: error while loading shared libraries: libpulsecommon-11.1.so: cannot open shared object file: No such file or directory
#snappy 2019-02-17
<mup> PR snapd#6517 opened: tests: disable trusty-proposed for now <Created by mvo5> <https://github.com/snapcore/snapd/pull/6517>
<antis> Heho, anyone familiar with Snap and Qt?
#snappy 2020-02-10
<mborzecki> morning
<mborzecki> mvo:  hey
<mvo> mborzecki: hey, good morning!
<mvo> mborzecki: how is life, anything important happend on friday?
<mborzecki> mvo: iirc nothing super important, pedronis is off today
<mborzecki> mvo: the pulseaudio test seems to be causing issues on 20.04
<mvo> mborzecki: yeah, cool. no bad news is good news
<mvo> mborzecki: anything in particular needs reviews?
 * mvo is current going top-bottom
<mborzecki> mvo: i was not albe to reproduce it, but according to standup notes ian maanged to do so calling spread in loop ratehr than with -repeat
<mvo> mborzecki: hm, that's annoying, any clues?
<mborzecki> mvo: no, not really, maybe we should consider skipping the test on 20.04 until we figure it out, seems to break travis runs quite often
<mvo> mborzecki: yeah, that works for me
<mborzecki> mvo: oh, and 8077 could use a review ;)
<mborzecki> #8077
<mup> PR #8077: boot: enable base snap updates in bootstate20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
<mborzecki> mvo: and something off with autorefresh https://forum.snapcraft.io/t/snap-is-updating-off-schedule/15323/10 even though the schedule is calcualted correctly
<mvo> mborzecki: and it's not because the last update happend ages ago ? (or there was some sort of clock glitch?)
<zyga> good morning
<mvo> hey zyga
<zyga> sorry, I overslept
<mvo> zyga: no worries
<zyga> but almost on time for 9 am start
<mvo> zyga: flexible hours++
<mvo> zyga: :)
<zyga> winter holidays started for the kids today
<zyga> so no alarm clocks or anything
<mvo> zyga: sounds very nice if you ask me :)
<zyga> yeah, all quiet
<mborzecki> zyga: hey
<zyga> :)
<zyga> let me make some coffee quickly
<mborzecki> mvo: no, looking at the log there's an update on Feb 05 12:22:39 and anothr one on Feb 06 09:54:28, while the 'ages ago' thing is 60 days
<mvo> mborzecki: meh, that's annoying, thank you
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski !
<mborzecki> quick errand, back in 30
<zyga> hey pawel :)
<mup> PR snapd#8096 closed: tests: retry mounting the udisk2 device due to timing issue <Simple ð> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8096>
<mborzecki> re
<pstolowski> hmmm i need to do something about task pruning wrt pre-seeded image
<zyga> re
<zyga> pstolowski: can you tell me more please?
<mborzecki> hmm so i reproduced the problem with pulseaudio, and looks like the pulseaudio daemon is not actually listetning on any socket
<mvo> mborzecki: woah
<mborzecki> mvo: i'll try with a custom script for the server
<zyga> mborzecki: how is that possible
<zyga> mborzecki: as in misbehaving and not listening on any socket
<pstolowski> zyga: on the pre-baked image we have changes & tasks with spawn-times in the past. i wonder if prune mat abort them if the image is booted after >24h from pre-baking
<pstolowski> s/mat/may/
<mborzecki> zyga: idk, lsof clearly shows it's not listening on anyting, no logs, nothing, any action tries /run/user/12345/pulse/native and gets connection refused (cause nobody's listening)
<zyga> pstolowski: ah
<zyga> pstolowski: interesting!
<mborzecki> zyga: restarting pulseaudio magically fixes this
<zyga> pstolowski: that's tricky, do we need any extra state so that they are not pruned?
<zyga> mborzecki: is that easy to reproduce?
<pstolowski> zyga: i wonder if that isn't a general concern (but maybe i'm missing something): what if you have a change in flight, power off in the middle, turn back on after >24h. you may hit readyTime.IsZero() == true and spawnTime.Before(abortLimit) == true afaict, meaning the change gets aborted. this is if you are unlucky and the change does not finish in 10 minutes after boot (this is the prune ticker interval)
<mborzecki> zyga: not really, happened just one so far
<pstolowski> zyga: i don't think we need extra state for pre-seed case, should be enough to check if there is any "become-operational" change and if so, just block pruning for some time based on its ready-time
<pstolowski> i need a test case, this is indeed a bit tricky stuff
<zyga> pstolowski: yeah, I think we don't model suspend/off time in our system
<mborzecki> E: [pulseaudio] socket-server.c: bind(): Address already in use
<mborzecki> E: [pulseaudio] module.c: Failed to load module "module-native-protocol-unix" (argument: ""): initialization failed.
<mborzecki> heh
<zyga> mborzecki: that's interesting
<zyga> mborzecki: do we have any pulseaudio fakes?
<zyga> mborzecki: that might clobber the unix socket
<zyga> mborzecki: or perhaps it's something more silly, like stale socket being left in place
<zyga> mborzecki: I don't recall what happens if a socket is in the FS and you try to create a new one there
<mborzecki> zyga: added rm -f /run/user/12345/pulse/native just in case it's needed
<zyga> mborzecki: do we remove /run/user/12345 anywhere?
<zyga> mborzecki: I think the code that handles the test user
<zyga> mborzecki: as in, uses it
<zyga> mborzecki: could remove /run/user/12345 after each test
<mborzecki> zyga: and probably kill all processes of test user too
<zyga> mborzecki: yeah, that's a good idea
<zyga> mborzecki: too bad that doesn't scale to "root" :-)
<zyga> mborzecki: it would be easier for us
<mup> PR snapd#8108 opened: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
<mborzecki> mvo: zyga: ^^
<zyga> reading
<mborzecki> still running some tests, will force push as needed
<zyga> reviewed
<mborzecki> hmm why does paplay hang when it cannot connect after the plug was disconnected?
<zyga> mborzecki: paplay is simple, maybe it assumes too much
<zyga> mborzecki: but really, no idea
<zyga> mborzecki: does it spin or hang?
<zyga> mborzecki: can you look at https://github.com/snapcore/snapd/pull/7980
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<mborzecki> zyga: sure
<zyga> mborzecki: I've handled the review from jamie and apart from one small tweak it is ready for re-review
<zyga>   mborzecki requested a review on https://github.com/snapcore/snapd/pull/8108
<mup> PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
<zyga> er
<zyga> not on this one
<zyga> I meant 7925
 * zyga switches to https://github.com/snapcore/snapd/pull/7825
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mborzecki> zyga: some comments in https://github.com/snapcore/snapd/pull/7980
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<zyga> aha
<zyga> looking
<zyga> thank you for reviewing!
<zyga> mborzecki: updated
<zyga> mborzecki: please look again :)
<zyga> I need to take Bit out
<mborzecki> zyga: thanks!
<mup> PR snapd#8107 closed: tests/lib/prepare: use a local copy of uc20 initramfs skeleton <Simple ð> <UC20> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8107>
<mborzecki> #8081 needs a 2nd review, zyga maybe you can take a look since you did a pass before?
<mup> PR #8081: tests/main/user-session-env: add test verifying environment variables inside the user session <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8081>
<zyga> mborzecki: yes
<zyga> mborzecki: looking
<mborzecki> thanks!
<zyga> mborzecki: do you remember why [[ vs [ ?
<zyga> wow
<mborzecki> zyga: [[ is bash builtin, [ is /bin/test alias, but bash does a builtin anyway?
<zyga> tunderstorm
<zyga> thunder hit nearby
<zyga> wow, that was LOUD
<zyga> wonder if any glasses broken
<zyga> or windows or whatever
<mborzecki> zyga: had hailstorm here today :P
<mborzecki> and +9C :P
<zyga> mvo: how is your weather? do you experience the big storm that sweeps across EU now?
<zyga> mborzecki: same here +9
<zyga> it's so warm for such a windy day
<zyga> mborzecki: as for [[ vs [, I would use [ unless [[ is required,
<mborzecki> zyga:  i can push a patch htere
<zyga> because it's non obvious why [[ is used here and we use [ nearly everywhere unless we require extra semantics from [[
<zyga> mborzecki: I can apply a inline suggestion, just wanted to understand why first
<mborzecki> zyga: inline is fine, saves the checkout/commit/push cycle
<zyga> yep
<zyga> thanks
<zyga> mborzecki: no permission to push
<mborzecki> zyga: weird
<mborzecki> let me do it locally
<zyga> try applying my suggestion
<zyga> maybe it's that
<ijohnson> happy monday folks
<ijohnson> mborzecki: were you able to sort out the weirdness with pulseaudio ?
<ijohnson> I have some thoughts from my investigation on Friday that I didn't get around to putting in the SU doc
<mborzecki> ijohnson: yeah, sort of, plase look at https://github.com/snapcore/snapd/pull/8108
<mup> PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
<ijohnson> ack looking now
<mborzecki> perhaps not all of it is needed, but i suppose it won't hurt
<mborzecki> wow, thunderstorm here
<ijohnson> ahhhh okay your last line at the end explains one of the things that was very confusing to me
<ijohnson> I was constantly seeing it fail when I had restarted it in a way that it stuck around, but having your last statement kill it would make the execute not fail
<ijohnson> it was very confusing because I even put a `exit 0` at the end of the execute section and it still would say the run failed
<mborzecki> ijohnson: yeah, i believe the pulseuadio process is keeping the pty allocated by ssh still open, so either nohup with that pulseaudio start line, or su -P (?), or just kill it before leaving
<mborzecki> ijohnson: that daemon start script is superfluous, but it makes the setup simpler, eg. pulseaudio doesn't try to use bluez and so on
<ijohnson> mborzecki: great! yeah I think your PR looks good, did you try it running spread in a loop?
<mborzecki> ijohnson: i was able to get it to block on each run eventually :P
<mborzecki> btw https://news.ycombinator.com/item?id=22279585 (cc zyga)
<zyga> mvo: let me review the netlink code now
<Saviq> cachio: are "fedora-rawhide-64" images something you build? we're having trouble with GPG keys on those https://github.com/MirServer/mir/issues/1260
<cachio> Saviq, yes
<cachio> well I just update this
<cachio> apply the latest changes
<cachio> Saviq, I'll take a look
<mborzeck1> aaand no power, running on battery
<ijohnson> mborzeck1: oh no hope your power is restored soon
<zyga> mvo: I'll grab lunch/dinner and sit on that netlink PR
<zyga> mvo: I'm not super happy about it, it's very messy still (I know there are constraints)
<zyga> mvo: I'd like to make it simpler and more robust
<mup> PR snapcraft#2924 opened: cli: explicitly ensure type 'snapd' is non-legacy <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2924>
 * zyga eats
<mborzeck1> ijohnson: posted some comments in #8077
<mup> PR #8077: boot: enable base snap updates in bootstate20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
<ijohnson> mborzeck1: thanks will look after meeting
<mborzeck1> and power is backing, switching systems
<mborzeck1> s/backing/back/
<mvo> zyga: in a meeting right now
<zyga> no rush
<mvo> zyga: but yeah, thank you
<mvo> zyga: simple++
 * cachio lunch
<ijohnson> mvo: I had to add one more commit to https://github.com/snapcore/snapd/pull/8106, do you think I can merge if it goes green now?
<mup> PR #8106: tests: add "core" suite for UC specific tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8106>
<mvo> ijohnson: +1
<mvo> zyga: back now
<ijohnson> thanks mvo
<mvo> ijohnson: thank you :)
<ijohnson> also it seems mborzecki's pulseaudio changes aren't enough, I will try to merge my stuff with what he has and if it works I will push to his branch
<zyga> oh fun
 * ijohnson goes to buy another goat to sacrifice to the pulseaudio spread test gods
<mup> PR snapd#8109 opened: [RFC] o/devicestate: don't prune tasks immediediately <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8109>
<zyga> pstolowski: some instant suggestions on comments
<pstolowski> zyga: thanks, i think i'm gonna change it, just had an enlightement
<zyga> should I refrain from reviewing the rest?
<pstolowski> zyga: yep, please hold on, thanks!
<zyga> ok
<oSoMoN> jdstrand, IÂ would appreciate your input on bug #1859643
<mup> Bug #1859643: [snap] cannot use shared NSS db <snap> <chromium-browser (Ubuntu):Triaged by osomon> <https://launchpad.net/bugs/1859643>
<zyga> oSoMoN: I believe jamie is off today
<oSoMoN> zyga, ah, thanks, I'll try again tomorrow then
<mvo> zyga: I updated 8063 now
<zyga> aha
<zyga> let me read it quickly
<zyga> mvo: done
<zyga> mvo: it looks great, there are a few comment that were not responded to though
<zyga> let me update those that were quickly
<zyga> done
<zyga> mvo: can you scan through those quickly
<zyga> I think a quick line in remove-user/task.yaml will solve the first one
<zyga> the [[ can probably just become [
<zyga> the wording on snap remove user is something we can talk about (not blocking) but I think the original error is not comprehensible much
<mvo> zyga: aha, github did hide some from me, sorry for this
<zyga> mvo: the api docs can be "not documented"
<mvo> zyga: I see them now
<mvo> zyga: let me look at those
<zyga> mvo: but I wasn't sure
<zyga> mvo: I guess we ought to document this
<zyga> mvo: but not super critical
<zyga> mvo: if you rush this
<zyga> mvo: lastly since this deals with users I would love to see even a post-factum review from security
<zyga> mvo: and perhaps the test I suggested
<zyga> as it could be a nasty CVE if that were to work
<zyga> mvo: (this doesn't capture that the changes you made look great)
 * zyga hugs mvo
<mvo> zyga: thank you! I address the other bits now
 * mvo hugs zyga
<pstolowski> ijohnson: hey, will you find some time to look at #8046?
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<ijohnson> pstolowski: yes I will try to get to it today or tomorrow
<pstolowski> ijohnson: thanks!
 * zyga breaks, family is back
<mup> PR snapd#8110 opened: store: add support for resume in DownloadStream <Created by mvo5> <https://github.com/snapcore/snapd/pull/8110>
<cachio> mvo, https://paste.ubuntu.com/p/Vns7w2Jq8v/
<mup> PR core20#21 opened: Add bash-completion support <Created by xnox> <https://github.com/snapcore/core20/pull/21>
<mup> PR snapd#8111 opened: tests: Adding new backend which includes images with tpm support <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8111>
 * cachio afk
<cachio> I'll be out 30 minutes
<mup> PR core18#147 opened: Add bash-completion support <Created by xnox> <https://github.com/snapcore/core18/pull/147>
<zyga> mvo: I'm making progress on netlink code
<zyga> mvo: I will have it tonight
<zyga> ah, maciek is off already
<mvo> zyga: nice
<mvo> cachio: nice!
<mvo> cachio: cool to see this
<mup> PR snapd#8106 closed: tests: add "core" suite for UC specific tests <Test Robustness> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8106>
<zyga> I sent mvo the epoll based netlink stuff
<zyga> and will wrap up for the day
<zyga> ijohnson: I can telegram you a zip if you want to see
<ijohnson> zyga: if I want to see what?
<zyga> ijohnson: epoll based netlink listener in go
<ijohnson> oh, nah I have other things to review/look at this afternoon :-)
<ijohnson> in other news I think I have the pulseaudio spread test under control
<zyga> :)
<zyga> sure
<ijohnson> haven't hit the failure yet in 2 consecutive runs :-)
<zyga> have fun with pulseaudio there, I'd love to know what's the root problem in the end
<ijohnson> don't get your hopes up too much, my solution is just to start it, kill it violently, and restart it, but there's now at least some more information in the logs if someone wanted to file a bug upstream with pulseaudio folks
<mup> PR snapd#8112 opened: tests: move main/ubuntu-core-* tests to core/ suite <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>
<cmatsuoka> ijohnson: can I assign dimitri's snapcraft build bug to you, just as a reminder to unblock the PR once the prerequisite bugs are fixed?
<ijohnson> cmatsuoka: sure, I just updated the PR today, so it's ready as soon as snapcraft is ready
<cmatsuoka> ijohnson: thanks, hopefully we'll have this fixed soon
<zyga> ondra: wrote regression test, fix coming up tomorrow
<mup> Issue core20#20 closed: Unpublish the core20 snap for i386 <publication> <Created by anonymouse64> <Closed by xnox> <https://github.com/snapcore/core20/issue/20>
<NickZ> Has anyone tested on Fedora 31 recently? It appears that it's broken and has been for a while
<NickZ> https://forum.snapcraft.io/t/error-system-does-not-fully-support-snapd/14911/14
<mup> PR snapcraft#2920 closed: meta: initialize Snap at once in from_dict() <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2920>
<NickZ> Snapd, that is
<cachio> Saviq, I left a message in the issue
<cachio> with that the problem should be fixed
<Saviq> cachio: thanks!
<cachio> Saviq, yaw,
<Saviq>  cachio: while we could do this, shouldn't an image rebuild fix this? It feels wrong to ignore gpg errors?
<mup> PR snapcraft#2919 closed: sanity_checks: fix sanity check on Windows <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2919>
<cachio> Saviq, we have these error often on rolling systems
<cachio> in opensuse we already and usign the same option
<cachio> on tumbleweed
<cachio> Saviq, I can try tomorrow to fix that
<mup> PR snapcraft#2925 opened: project loader: use get_build_base() to assign plugin handler base <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2925>
<zyga> ondra: https://github.com/snapcore/snapd/pull/8113
<mup> PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113>
<mup> PR snapd#8113 opened: cmd/snap-confine: bring /var/lib/dhcp from host, if present <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113>
<mup> PR snapcraft#2924 closed: cli: explicitly ensure type 'snapd' is non-legacy <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2924>
#snappy 2020-02-11
<mup> PR snapd#8114 opened: boot: use variables for boot status values <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8114>
<mborzecki> morning
<mborzecki> https://github.com/snapcore/snapd/pull/8108 needs a 2nd review
<mup> PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
<mborzecki> same #8114
<mup> PR #8114: boot: use variables for boot status values <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8114>
<mborzecki> quick round trip to school, back in 30
<mborzecki> re
<pstolowski> morning
<mborzecki> pstolowski: hey
<mborzecki> wow, firefox 73 finally handles hidpi correctly
<mup> PR snapd#8114 closed: boot: use constants for boot status values <Simple ð> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8114>
<mborzecki> pedronis: hey, thanks for merging 8114, i'll proceed updating 8077
<abeato> mborzecki, hey, do you know if the support for default tracks in snapd is already merged?
<pedronis> abeato: it is in master, it will be in 2.44
<mborzecki> abeato: iirc it was, but rather recently, within last 2-3 weeks, pedronis probably has all the details
<abeato> pedronis, mborzecki ok, thanks
<mup> PR snapd#8111 closed: tests: add new backend which includes images with tpm support <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8111>
<pedronis> jamesh: hi, have you seen the questions in #7588 ?
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<pedronis> mborzecki: we should probably rename the signature in bootState as well to match what we used now in the implementations
<sdhd-sascha> Hi, anything new about #7927
<mup> PR #7927: interfaces: x11 allow apparmor on classic <Created by sd-hd> <https://github.com/snapcore/snapd/pull/7927>
<mborzecki> pedronis: right, good idea
<pedronis> thx
<mup> PR snapd#8115 opened: overlord/devicestate: fix preseed unit tests on systems not using /snap <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8115>
<mborzecki> pstolowski: ^^
<jamesh> pedronis: sorry.  I've been working through some changes on my other branch.  I'll answer those q's now.
<tomwardill> What would be preventing my snap from reading files from /usr/share (inside the confinement)? Getting pandoc template errors as it can't read the default templates, which are installed in the snap.
<zyga> tomwardill: are you reading them from $SNAP/usr/share or from /usr/share?
<tomwardill> zyga: /usr/share (prebuild application that I can't change)
<zyga> tomwardill: then they are not installed in the snap
<zyga> tomwardill: are they really in /usr/share from the perspective of the snap? In other words, are they in the base snap used by your application snap?
<tomwardill> zyga: pandoc is apt installed during build
<tomwardill> extracting the squashfs shows the files
<ogra> thats $SNAP/usr/share then
<tomwardill> (it's the pandoc templates I'm tyring to read)
<zyga> tomwardill: again, then your snap contains those files but the application is not using them
<zyga> tomwardill: it is attempting to use files from /usr/share
<zyga> tomwardill: I'm trying to explain the crucial difference
<mborzecki> layouts to the rescue?
<ogra> yeah
<zyga> tomwardill: your application is not the root filesystem of the snap application process
<tomwardill> oh, right, I see.
<ogra> a layout can fake $SNAP/usr/share to look like /usr/share to your application
<zyga> tomwardill: you can ship and access arbitrary files but they are in a runtime-variable location at $SNAP
<zyga> tomwardill: you can use one of the mechanism we have to alleviate that, but it depends on circumstances
<zyga> tomwardill: usually layouts are a good first try
<zyga> tomwardill: they are documented on the snapcraft website, let me know if you need a link
<tomwardill> I've seen the docs for that, I'll give it a try
<tomwardill> thanks for the help :)
<zyga> tomwardill: pleasure :) let me know if it worked in the end :)
<pedronis> mborzecki: not urgent but I made a suggestion about how to try to close #6708
<mup> PR #6708: packaging/ubuntu: enable PIE hardening flags <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<mborzecki> cachio: hi, do you know when was the last time centos 7 images were updated?
<kbroulik> Hi, does the snap sandbox prevent dbus activation of services? If I call e.g. notifications service when it isn't running, my snap says "name has no owner" and fails. With a git build running regularly it launches the service and continues
<mup> PR snapd#8116 opened: test/lib/user: add helper lib for doing things for and as a user <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8116>
<mborzecki> kbroulik: is that on ubuntu?
<kbroulik> yes
<kbroulik> it appears an "Introspect" call to a dbus service isnt allowed?
<mborzecki> kbroulik: right, so there's a known (is it?) problem that the policy allows for a snap app to talk to an 'unconfined' service over dbus, but until the service has actually launched, dbus does not know what context that service would have
<kbroulik> okay
<mup> PR snapd#8117 opened: tests: add preseed test for classic <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8117>
<kbroulik> mborzecki: also "ListActivatableNames" isnt allowed either, so I cant have my app check for that either
<mborzecki> kbroulik: so the dbus *.service files of your host services need to have `AssumedAppArmorLabel=unconfined` or the service must be already running
<mborzecki> kbroulik: if it's a particular service in ubuntu then maybe you could file a bug, i know that the desktop team added that snippet to some of the portal services upstreams
<kbroulik> it's a weird kde plasma specific
<cachio> mborzecki, 1 week ago
<kbroulik> I mean, the service is standard (freedesktop notifications) but plasma does something mental with it
<cachio> mborzecki, hi
<kbroulik> you mean LinuxSecurityLabel?
<cachio> mborzecki, feb-3
<mborzecki> kbroulik: no, `AssumedAppArmorLabel=unconfined`
<kbroulik> okay
<cachio> mborzecki, I just retrigger again the update
<kbroulik> mborzecki: will this be ignored by others not supporting it?
<mborzecki> kbroulik: afaik for gnome-shell the notification service is part of the shell process, so it's up already before one even starts snap apps
<kbroulik> mborzecki: yeah in plasma it's not, and with recent startup improvements we now start autostart so fast the apps come up before the desktop is fully ready :)
<mborzecki> kbroulik: haha must be fun
<kbroulik> normally it wouldnt be a problem if people stopped using stupid QDBusInterface class
<mborzecki> kbroulik: the key is part of upstream spec, https://dbus.freedesktop.org/doc/dbus-specification.html see `Mediating Activation with AppArmor`
<kbroulik> I looked at that document and Ctrl+F'd for it... :)
<kbroulik> oh well, thanks, I'll discuss it with my fellow devs
<kbroulik> so, that "assumed" means, when you call something anyone can do it but once launched regular policies still apply?
<kbroulik> *when you call when it's not running, I mean
<mborzecki> kbroulik: i'm no expert on this, but yeah, that'd be my guess
<kbroulik> ok I'll give it a go
<kbroulik> thanks very much
<mborzecki> cachio: cool, i got a notification about that https://bugs.centos.org/view.php?id=16441#c36261 so maybe it'll work this time
<cachio> mborzecki, yesterday failed because an error with a mirror trying to update
<cachio> mborzecki, lets wait a bit to see the results today
<cachio> hopefully the systemd error is gone
<mborzecki> cachio: btw. noticed your note in https://github.com/snapcore/snapd/pull/8058 do yout want to discuss that in/after the standup?
<mup> PR #8058: run-checks, travis: allow skipping spread jobs by adding a label <Skip spread> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8058>
<mborzecki> (or before whatver's more convenient)
<cachio> mborzecki, during
<mborzecki> ok
<cachio> we decided that last friday but then I forgot it
<mborzecki> ok, np
<mborzecki> huh google:arch-linux-64:tests/main/static failed ?
<kbroulik> mborzecki: hmm doesnt work in my case.. I believe the "Introspect" call isnt allowed, or does "unconfined" allow any call to that service?
<mborzecki> kbroulik: isn't Introspect part of the org.freedesktop.DBus inteface?
<kbroulik> mborzecki: it's on the org.freedesktop.DBus.Introspectable
<mborzecki> kbroulik: hmm but that would still be a traffic that does to the service, wouldn't it? can you try adding that snippet to *.service locally?
<kbroulik> I added it, to no effect
<kbroulik> I dont see a DENIED introspect call in dmesg either, though
<kbroulik> oof why cant we have nice things :/
<mborzecki> kbroulik: was dbus reloaded/restarted ?
<kbroulik> ah, yeah the introspect call was denied
<kbroulik> An AppArmor policy prevents this sender from sending this message to this recipien
<kbroulik> mborzecki: I thought that was automatic? I did send a SIGHUP to dbus-daemon though
<kbroulik> "There is no way to cause the D-BUS daemon to reload its configuration file" heh
<zyga> mvo: reported as https://bugs.launchpad.net/snapd/+bug/1862761
<mup> Bug #1862761: core systems using core18 boot base cannot unmount writable cleanly <snapd:New> <https://launchpad.net/bugs/1862761>
<mborzecki> kbroulik: systemctl restart --user ? iirc dbus also had inotify on the service directories, so maybe it's already reloaded ?
<mborzecki> kbroulik: this is how your plasma service should look like https://paste.ubuntu.com/p/MsrhGFv9gX/
<mborzecki> oh, and arch updated glibc to 2.31 and master is thus broken ;P
<mup> PR snapd#8118 opened: tests/main/static: ldd in glibc 2.31 logs to stderr now <Simple ð> <â  Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8118>
<mborzecki> this should fix it ^^
<kbroulik> mborzecki: heh, well, my system didnt like that at all :D so now I'm going to have to log out
<mborzecki> kbroulik:hah ;)
<kbroulik> mborzecki: yeah think that didnt help. It's probably that Introspect call being denied. *but* since nobody should ever use QDBusInterface: if that is ported away and done properly, ideally we'd just do a GetCapabilities call and see if that works or fails and call it a day
<kbroulik> a call which we do later anyway
<kbroulik> i.e. when using dbus one should never check for services, just call and see what happens
<mborzecki> corba of the desktops
<cachio> mborzecki, centos updated
<mborzecki> cachio: thanks!
<cachio> lets see now how it works
<mvo> zyga: \o/ in a meeting - thank you!
<cachio> mborzecki, to you
 * zyga goes to make coffee
<zyga> mborzecki: do you think the user helper could become a non-source but execute helper?
<zyga> mborzecki: to again put boundaries on dependencies
<zyga> mborzecki: it would also make it easier to use from things like retry-tool
<mborzecki> zyga: maybe, depends on how much time we want to put in it tbh
<zyga> mborzecki: just add a switch statement at the bottom
<zyga> mborzecki: and run the functions you wrote
<zyga> mborzecki: then it becomes user stop-session|start-session etc etc
 * zyga breaks for coffee and some food
<mborzecki> hmm https://forum.snapcraft.io/t/updating-the-current-link-in-the-home-directory-does-not-work/15406/7 i think it'd be weird if snapd started updating that randomly
<mborzecki> and certainly there'd be more user drama
<mup> PR snapcraft#2925 closed: project loader: use get_build_base() to assign plugin handler base <Created by cjp256> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/2925>
<mup> PR snapcraft#2926 opened: plugin handler: process elf files only if base is specified <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2926>
<cjp256> ijohnson: https://github.com/snapcore/snapcraft/pull/2926 is the workaround you're looking for :)
<mup> PR snapcraft#2926: plugin handler: process elf files only if base is specified <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2926>
 * ijohnson didn't know cjp256 knew the ways of the force
<pedronis> has anybody seens this kind of error: https://api.travis-ci.org/v3/job/648850614/log.txt
<cjp256> i'm quite adept at force pushes
<pedronis> ijohnson: ^
<ijohnson> pedronis: will look after SU
<zyga> pedronis: I haven't seen that error
<ijohnson> pedronis: I've seen that "in the wild" on my UC20 test machines
<mup> PR snapd#8119 opened: [RFC] httputil: add NoNetwork(err) helper and spread test <Created by mvo5> <https://github.com/snapcore/snapd/pull/8119>
<zyga> jdstrand: hello
<zyga> jdstrand: I've updated https://github.com/snapcore/snapd/pull/7980 -- would love to know if you can look at the changes
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<zyga> jdstrand: there are two more PRs that are ready for review but I'll hold on until you ping me you can do those
<mborzecki> ijohnson: got they impression, they access some snap user data via $HOME/snap/<name>/current, which becomes broken when snap gets updated but a given user runs it rarely
<mup> PR snapd#8058 closed: run-checks, travis: allow skipping spread jobs by adding a label <Skip spread> <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8058>
<mborzecki> yay
<mup> PR snapd#8120 opened: cmd/snap-preseed: snapd version check for the target <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8120>
<mup> PR snapcraft#2918 closed: elf: ensure _GNU_VERSION_R section is of type GNUVerNeedSection <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2918>
<zyga> brb, 2nd coffee and a hunt for a memory card adapter
<abeato> jdstrand, hey, there is this new 'primed-stage-packages' section in the manifest generated by snapcraft. This is a list of the packages that were really primed into the snap. Is there any plan to leverage this on review tools and use it instead of 'staged-packages'?
<abeato> cjp256, ^^
<mup> PR snapd#8118 closed: tests/main/static: ldd in glibc 2.31 logs to stderr now <Simple ð> <â  Critical> <Created by bboozzoo> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8118>
<zyga> mvo: I pushed extra test data to https://github.com/snapcore/snapd/pull/8113 after your approval - if you want to re-view please do
<mup> PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113>
<zyga> mvo: (mount-ns test changes reflecting the new mount)
<mvo> zyga: thank you, looking
<mvo> zyga: that should be fine
<mborzecki> ijohnson: some comments in #8077, my head goes round with bootState20* things :)
<mup> PR #8077: boot: enable base snap updates in bootstate20 <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
<ijohnson> mborzecki: thanks, I see I forgot to actually push that revert thanks for doing so :-)
<mborzecki> ijohnson: no problem, reverted it and pushed with some other updates
<ijohnson> mborzecki: thanks will take a look in a little bit, trying to finish review of pstolowski's PR
<ijohnson> mborzecki: will you merge master to #8108 ?
<mup> PR #8108: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
<ijohnson> also should probably get another +1 from somebody other than me as I changed the PR a bit
<mborzecki> ijohnson: right, pushing now
<mborzecki> and off to do some groceries
<ijohnson> thanks mborzecki
<jdstrand> abeato (cc cjp256): there is. the review-tools should be updated soonish
<abeato> jdstrand, cool, that's great news
<jdstrand> zyga: ack. for now make sure that whatever is needed for 2.44 is milestoned for that. (7980 is on that list)
<zyga> jdstrand: thank you!
<abeato> sergiusens, cjp256, jdstrand I was also wondering if there could be an option in snapcraft to inject entries in 'primed-stage-packages'. In snaps that we build based on the deb sources, but recompiling (like network-manager) with patches on top, we would like to still receive CVEs without needing to hack review tools
 * cachio lunch
<cjp256> abeato: interesting case
<abeato> some times we were putting packages in 'stage-packages' but not really priming them . with this change that technique is not going to work anymore
<sergiusens> abeato: the alternative is to allow for reporting of the current stage-packages as a fallback... the solution you are using is quite hackish though
<ijohnson> abeato: did you ask awe about his plan for doing that? I proposed exactly what you were saying to him a long time ago and he said there was a better way, I don't recall the details however
<abeato> sergiusens, that's why I'd like a snapcraft option ;) - like report-packages
<sergiusens> abeato: seems like a very specific workaround for a very specific scenario you have
<sergiusens> abeato: why not track the udd (or equivalent) of the source package and get auto builds for those?
<sergiusens> we still keep both in manifest.yaml, at the end of the day, the reporting tool should allow you to toggle that if you want
<abeato> sergiusens, that's an alternative...
<ijohnson> pstolowski: I reviewed #8046, is the next one I should look at #8102 ?
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<abeato> but maybe adding packges for CVE notifications can be useful in other scenarios. not sure...
<abeato> ijohnson, hm, I do not think there was an alternative to the staging hack
<pstolowski> ijohnson: thanks! sure that will help too, it's for snap disconnect --forget
<sergiusens> abeato: would rather have a generic "subscription" mechanism for this
<ijohnson> abeato: perhaps I am mis-remembering
<ijohnson> ack pstolowski
<sergiusens> but this is something for the security team to drive
<abeato> right
<jdstrand> the thing to keep in mind is that the review-tools don't know that the git source you are using is coming from ubuntu
<jdstrand> so we have to hint it somehow. one way is the review-tools that we currently do. another is to shove something into stage or prime or something
<jdstrand> a different key could be introduced in the manifest.yaml that it could consider
<abeato> jdstrand, lately we are using the auto-imported branches. Like
<abeato>     source: https://git.launchpad.net/ubuntu/+source/network-manager
<abeato>     source-type: git
<abeato>     source-branch: applied/1.10.6-2ubuntu1.2
<abeato> would that be manageable from review-tools?
<jdstrand> abeato: that's great!
<jdstrand> abeato: maybe. it kinda feels like the wrong level though
<mup> PR snapcraft#2927 opened: requirements: uprev lxml to 4.5.0 <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2927>
<jdstrand> abeato: I'll take a look at the nm manifest.yaml and think about it
<abeato> jdstrand, ok, note that this is for the 1.10 branch - let me find the link
<abeato> jdstrand, https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/network-manager/tree/snap/snapcraft.yaml?h=snap-1.10
<abeato> jdstrand, also: https://git.launchpad.net/~snappy-hwe-team/snappy-hwe-snaps/+git/modem-manager/tree/snapcraft.yaml?h=snap-1.10
<jdstrand> ok, thanks
<pedronis> jdstrand: hi, have you seen this discussion https://github.com/snapcore/snapd/pull/7588#discussion_r377526563? it's about which interface should offer access to network status when running with portals
<mup> PR #7588: cmd/snap: add a "snap routine portal-info" command <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/7588>
<pedronis> pstolowski: do you have time to quickly check about the prune issue now?
<pstolowski> pedronis: yes
<pstolowski> let's
<pedronis> pstolowski: ok, let's use the standup
<jdstrand> pedronis: I see it in my inbox, new today. I haven't read it yet
 * zyga goes for dinner 
<zyga> pstolowski, pedronis: https://github.com/snapcore/snapd/pull/8102#discussion_r377770429
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<mup> PR snapcraft#2921 closed: storeapi: remove exposure of series <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2921>
<pstolowski> zyga: good question!
<pstolowski> i need to think
<pstolowski> eod, cu
<zyga> I will EOD soon but want to inspect one more time this weird bug I found
<zyga> mvo: some early ideas on oom
<zyga> mvo: snap set system oom-order=snap-a,snap-b,snap-d
<zyga> would protect snap-a from oom more than snap-b, snapd-d and other parts of the system
<zyga> mvo: (the name should probably oom-protect instead of oom-order but I wanted to imply there's an order)
<zyga> mvo: another idea is to provide a privileged interface that allows smart snaps to set up oom protection using any current kernel features
<zyga> mvo: the burden and responsibility shifts
<zyga> mvo: I'll explore two more ideas tomorrow
<zyga> for now I'm off
<ijohnson> pedronis: if you're still around quick question about cleaning the boot variables... is it reasonable to assume in the `commit()` implementation for markSuccessful that it will always be called with both kernel + base snaps markSuccessful() called on the bootStateUpdate ?
<ijohnson> pedronis: if so then the auto-cleaning logic is much simpler and we can get rid of one of the return values from genericMarkSuccessful I think
<pedronis> ijohnson: yes, in the sense that's controlled by code inside the package, MarkBootSucceful in boot.go
<ijohnson> ok, thanks that simplifies things
 * ijohnson lunches
<pedronis> ijohnson: please double check the code there matches you expect
<pedronis> *what you
<ijohnson> pedronis: yes it does match, my question was more about whether the current implementation of MarkBootSuccessful in boot.go can be relied on in bootstate20.go
<pedronis> ijohnson: yes, they are within the same package, feel free to add comments though if helps somebody doing changes down the lien
<pedronis> *line
<ijohnson> I'll add comments as to what the assumptions I'm making
<ijohnson> err that was awkwardly phrased ... I'll add comments about it there :-)
<zyga> jdstrand: if you want to chat about any of my branches I'm available
<techalchemy> zyga, jdstrand just told me to file this bug and ping you: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1862832
<mup> Bug #1862832: Latest snapd triggers apparmor denials on 'sendmsg' name=/run/nvidia-xdriver-xxxx <snapd (Ubuntu):New> <https://launchpad.net/bugs/1862832>
<zyga> aha
<zyga> looking
<zyga> techalchemy: thank you, I'll look at reproducing that back in the office tomorrow
<techalchemy> thanks, I haven't noticed any issues besides the logs
<zyga> techalchemy: does the application still operate correctly?
<zyga> aha
<techalchemy> the one we were looking at doesn't but that was because I built it with an old version of electron builder and it plugs pulseaudio
<techalchemy> incidentally I looked at the second snap causing the issue and it also still plugs pulseaudio, it seems unlikely that would be  the cause but I guess I've seen stranger things
<zyga> it's a shame the peer addr is ... whatever it is
 * zyga wonders
<techalchemy> it's the same socket as is mentioned elsewhere in the logs
<techalchemy> (sorry for the highlights) <jdstrand> Decoded: var/run/nvidia-xdriver-f8177d9f
<jdstrand> techalchemy: note, the pulseaudio stuff is unrelated to the nvidia stuff. I hadn't seen the logs yet when we were talking about audio, shm, etc
<zyga> jdstrand: having you here, do you have an idea what that peer address represents?
<zyga> Feb 11 13:59:41 utumno kernel: audit: type=1400 audit(1581447581.792:10272): apparmor="DENIED" operation="sendmsg" profile="snap.pomotroid.pomotroid" pid=1505247 comm="pomotroid" family="unix" sock_type="dgram" protocol=0 requested_mask="send" denied_mask="send" addr=none peer_addr="@7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000"
<zyga> peer="unconfined"
<jdstrand> techalchemy: this is the pulse issue: https://forum.snapcraft.io/t/upcoming-pulseaudio-interface-deprecation/13418/10
<zyga> that's not even a pointer
<jdstrand> zyga: yeah, snap.pomotroid.pomotroid is trying to talk to @var/run/nvidia-xdriver-f8177d9f
<techalchemy> jdstrand, yeah i just noticed that the other snaps causing the issue are also still plugging the pulseaudio slot rather than the new audio-playback slot
<zyga> jdstrand: how did you derive @var/run/ from that number?
<zyga> is that some base encoding?
<jdstrand> zyga: and is being denied. there is also (in the bug) a non-abstract path in /run
<zyga> aha
<jdstrand> zyga: the aa-decode command techalchemy gave
<techalchemy> oh i didn't post the command, woops
<jdstrand> aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000
<jdstrand> but, '@' isn't accepted by that command, so you drop it to decode, then prepend it
<jdstrand> zyga: there are nuls in that string so the kernel encoded it
<zyga> hmmm
<zyga>  Jamie Strandboge aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000
<zyga> er
<zyga> aa-decode @7661722F72756E2F6E76696469612D786472697665722D66383137376439660000000000000000000000000000000000000000000000000000000000000000
<zyga> String should only contain hex characters (0-9, a-f, A-F)
<zyga> that doesn't work for me on focal?
<jdstrand> zyga: did you read my next sentence? :)
<zyga> ah, no
<zyga> missed it among the paste
<zyga> is this encoding something new? I haven't seen it before
<mup> PR snapcraft#2928 opened: logging: use .warning instead of deprecated .warn <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2928>
<zyga> but this helps a lot
<jdstrand> zyga: did you see the next sentence after that? :)
<jdstrand> zyga: it isn't new to the kernel as the string is determined by userspace
<jdstrand> zyga: so, there are two denials:
<jdstrand> /run/nvidia-xdriver-f8177d9f
<jdstrand> and @var/run/nvidia-xdriver-f8177d9f
<jdstrand> zyga: and only after upgrading to focal. it seems something changed in the nvidia driver?
<jdstrand> zyga: I asked techalchemy to ping you since I don't have nvidia hardware and I suspect there is more to this than just adjusting the two denials (there might not be...)
<techalchemy> yes, all of my nvidia packages were reinstalled i believe
<jdstrand> zyga: I commented in the bug
<zyga> Thank you
<zyga> I can check it out tomorrow
 * cachio afk
<mup> PR snapcraft#2929 opened: elf: fixes for corrupt shared objects and semi-resolved path components from ldd <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2929>
<mup> PR snapcraft#2930 opened: extensions: Handle case when user-dirs.dirs exits but not user-dirs.locale <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2930>
#snappy 2020-02-12
<mup> PR snapd#8115 closed: overlord/devicestate: fix preseed unit tests on systems not using /snap <Simple ð> <Skip spread> <Created by bboozzoo> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8115>
<mup> PR snapcraft#2926 closed: plugin handler: process elf files only if base is specified <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2926>
<mup> PR snapcraft#2928 closed: logging: use .warning instead of deprecated .warn <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2928>
<mup> PR snapcraft#2931 opened: store: improve platform detection <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2931>
<mborzecki> morning
<mvo> hey mborzecki
<mborzecki> mvo: hey
<mborzecki> mvo: looks like despite all the workarounds paplay still gets stuck
<mborzecki> quick round trip to schoold, back in 30
<mvo> mborzecki: meh, that's sad
<mvo> mborzecki: see you in 30"
<mborzecki> re
<pstolowski> morning
<mborzecki> pstolowski: hey
<mvo> hey pstolowski
<mvo> pstolowski: looks like 8102 is super close, just one question in there that smeels like a followup, I'm in favor of merging (also it's green :)
<pstolowski> mvo: hey. zyga raised a valid concern there, i need to think
<zyga> pstolowski: I think the way the code worked before was more flexible
<zyga> pstolowski: and I fear if you add the right test now we will see it is not working correctly :/
<zyga> pstolowski: perhaps we should keep it like it was before, in ifacestate but based on repo data
<zyga> pstolowski: that is a far safer 2.44 patch
<pstolowski> zyga: i could use exported GuessCoreSnap() from repo like i had initially in that branch. but i wonder if what we had before had any practical significance since we do restart into new snapd/core?
<zyga> pstolowski: that question requires analysis - I don't know
<zyga> pstolowski: but I do know the old mode reacted instantly while the new mode reacts on restart
 * pstolowski quick erran, bb shortly
<pstolowski> *errand
<mborzecki> anyone seen centos-7 fail in recent spread runs?
<mborzecki> hmm looks like it's working now
<zyga> I didn't
<mup> PR snapd#8121 opened: spread: move centos to stable systems <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8121>
<zyga> mborzecki: can you review https://github.com/snapcore/snapd/pull/8113
<mup> PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113>
<mborzecki> sure
<mborzecki> zyga: hm should this be done in interfaces/network_control.go as a mount entry?
<zyga> mborzecki: I don't think so, it feels like a standard thing you can get to with devmode
<zyga> but
<zyga> it's an idea
<zyga> perhaps?
<zyga> dunno
<mborzecki> zyga: right, but with devmode you can also access fonts and we still add a mount when desktop is connected
<mborzecki> well, absically so that it ends up in the right place
<zyga> mborzecki: that's a valid point of view
<mborzecki> zyga: ok, let me add a comment and maybe we can discuss it more
<zyga> ok
<mborzecki> zyga: if we have add a mount in MountConnectedPlug(), it should behave the same right? however, the iface is not auto connected, but even so, without the connection on AA enabled systems the process won't be able to access /var/lib/dhcp either
<zyga> mborzecki: I think so, there are subtle differences between the two
<zyga> mborzecki: but I think it could work out okay
<mvo> 8110 needs a second review (should be easy)
 * zyga looks
<zyga> mvo: reviewed, please look
<mvo> zyga: thank you
 * zyga goes to prepare the nvidia patch
<mup> PR snapd#8063 closed: cmd/snap: implement 'snap remove-user' <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8063>
<mup> PR snapd#8110 closed: store: add support for resume in DownloadStream <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8110>
<mborzecki> #8060 needs a 2nd review, should be fairly simple
<mup> PR #8060: gadget: skip update when mounted filesystem content is identical <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8060>
<zyga> booo
<zyga> I already did
<zyga> two weeks of waiting
<zyga> man
<mborzecki> same for #8047
<mup> PR #8047: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <https://github.com/snapcore/snapd/pull/8047>
<pedronis> mvo: done
<pstolowski> re
<mborzecki> mvo: hm crazy idea to consider if you're feeling brave: https://github.com/snapcore/snapd/pull/8105/files#r378169956
<mup> PR #8105: store: detect if server does not support http range headers <Created by mvo5> <https://github.com/snapcore/snapd/pull/8105>
<mvo> mborzecki: yeah, love this
<mborzecki> mvo:  no need to truncating and overwriting what's already there
<mup> PR snapd#8108 closed: tests/main/interfaces-pulseaudio: use custom pulseaudio script, set kill timeout <Test Robustness> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8108>
<pedronis> pstolowski: hi, https://github.com/snapcore/snapd/blob/master/overlord/snapstate/handlers.go#L1351
<pedronis> sorry
<pedronis> pstolowski: I meant, https://github.com/snapcore/snapd/pull/8102#discussion_r378175775
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<mvo> thanks pstolowski, ijohnson, mborzecki and pedronis for your suggestions in 8119! much appreciated your excellent feedback
 * mvo waits for it to become green
<zyga> re
<zyga> sorry, had a small unexpected errand at home (drilling)
<zyga> reproduced nvidia issue
<zyga> working on a fix
<mborzecki> zyga: through drilling?
<zyga> mborzecki: $wife needed to install new baby gate thing (we have few doors in our house so everything is unprotected and open) and the gate arrived now instead of next week
<pstolowski> pedronis: thank you. i thought we always restart but wasn't sure if it answers the concern, and if that's all there is to it
<mvo> zyga: nice, thank you!
<pedronis> pstolowski: I actually think we might have a bug, but in the other direction, repo thinks we are using snapd too early
<pstolowski> pedronis: hmm you might be right
<mup> PR snapd#8122 opened: interfaces/opengl: allow datagrams to nvidia-driver <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8122>
<zyga> mborzecki: ^
<pedronis> pstolowski: because the actuall connections don't get switch over until reloadConnections happens early at start, but the repo will think we are using snapd as soon as we do setup-profiles for it?
<mvo> mborzecki: 7972 is green now, I guess it can be merged?
<mborzecki> mvo: yes
<zyga> mvo: please consider 8122 for the point release
<zyga> mvo: it's not urgent but feels safe as it is just extra permissions for opengl specific to nvidia
<zyga> mvo: I guess you can consider it pre-reviewed by jamie as he proposed the change in the first place
<mup> PR snapd#7972 closed: overlord/snapstate, wrappers: undo of snapd on core <Remodel ð> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/7972>
<mvo> zyga: yeah, I think that's sensible
<mvo> pedronis: concerns for 8122 for 2.43.3? looks small and safe
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8121#issuecomment-585161782
<zyga> boo
<mup> PR #8121: spread: move centos to stable systems <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8121>
<mborzecki> hahah
<mborzecki> pfff but really, `spread -list google-unstable:` erorrs out right away, so there's no way to tell whetner there are any tests to run even
<pstolowski> pedronis: sorry, i had to check the code.. yes, this looks problematic
<mborzecki> zyga: pushed a workaround
<mup> PR snapd#8116 closed: test/lib/user: add helper lib for doing things for and as a user <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8116>
<zyga> mborzecki: I've reworked the dhcp PR to do what you suggested, altered appropriate tests
<zyga> fingers crossed :)
<zyga> I'll grab some tea
<mborzecki> zyga: does it work still? :)
<zyga> mborzecki: should, I'll know in 30 minutes
<zyga> brb
<mborzecki> haha
<mborzecki> btw. maybe i should post my cloud-init configs for prebuilding spread images
<ogra> mwhudson, are you still the go-to guy for subiquity bugs ?
<zyga> mborzecki: do!
<pedronis> pstolowski: not with urgency but we need to slowly try to reduce the need for guess* in repo and/or pass the value in from ifacestate
<zyga> mborzecki: it's a little harder than the other one but I should have an alternate PR shortly
<pstolowski> pedronis: ack, will do soon. going to land resolve-disconnect PR then (after addressing remaining comments)
<mup> PR snapcraft#2931 closed: store: improve platform detection <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2931>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8123
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<mup> PR snapd#8123 opened: interfaces/network-control: bring /var/lib/dhcp from host <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> mborzecki: some tests are still running locally but that's the rough idea
<mborzecki> zyga: thanks, will take a look
<zyga> hmm
<zyga> doesn't work ..
<zyga> (regression test failed)
 * zyga looks
<zyga> ah, I didn't connect the interface in the test
<zyga> mborzecki: it's weird that this passed in the other one
<zyga> are all tests running with --devmode?
<zyga> one more try
<zyga> mborzecki: oh boy
<zyga> update.go:85: cannot change mount namespace according to change mount (/var/lib/snapd/hostfs/var/lib/dhcp /var/lib/dhcp none rw,bind 0 0): cannot write to "/var/lib/snapd/hostfs/var/lib/dhcp" because it would affect the host in "/var/lib/snapd"
<pedronis> pstolowski: I did a pass on #8046
<zyga> got lots of - Fetch and check assertions for snap "core" (8683) (cannot get device session from store: store server returned status 400 and body "{\"error_list\":[{\"code\":null,\"message\":\"Nonce is missing or invalid.\"}],\"errors\":[\"Nonce is missing or invalid.\"],\"result\":\"error\"}\n")
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<pstolowski> pedronis: ty
<pedronis> zyga: store was redeploying something, maybe it's related
<mup> PR snapd#8105 closed: store: detect if server does not support http range headers <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8105>
<zyga> mhm
<pedronis> pstolowski: #8102 can be merged now?
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<pstolowski> pedronis: i wanted to address your remark about SystemSnapName never returning ""; but perhaps will do in a followup
<mup> PR snapd#8124 opened: tests: Fix core revert channel after 2.43 has been released to stable <Skip spread> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8124>
<pstolowski> pedronis: ok if i squash-merge #8102 in case of something unexpected and a need for revert?
<mup> PR #8102: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<zyga> mborzecki: please check https://github.com/snapcore/snapd/pull/8123
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> mborzecki: it's an interesting development
<zyga> mborzecki: if accepted we could remove more things from snap-confine
<zyga> mborzecki: and move them to the correct interface
<mup> PR snapcraft#2932 opened: elf: resolve paths in `ldd()` to purge relative path components <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2932>
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8121 is still red
<mup> PR #8121: spread: move centos to stable systems <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8121>
<zyga> mborzecki: I'd like to look at https://github.com/snapcore/snapd/pull/8121
<zyga> mborzecki: it produces some selinux denials
<zyga> mborzecki: I'll try to fix them now but I may need your eyes later
<mup> PR pc-amd64-gadget#34 opened: Makefile: add "regex" to the modules for the non-uefi grub <Created by mvo5> <https://github.com/snapcore/pc-amd64-gadget/pull/34>
<ijohnson> morning folks
<zyga> good morning
<ijohnson> hey zyga
<mborzecki> ijohnson: hey
<mup> PR snapd#8119 closed: httputil: add NoNetwork(err) helper, spread test and use in serial acquire <Squash-merge> <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8119>
<mup> PR snapd#8122 closed: interfaces/opengl: allow datagrams to nvidia-driver <Bug> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8122>
<zyga> thank you mvo!
 * cachio afk
<zyga> mvo, xnox: do you know what triggers cgroup v2 mode in systemd? will we auto-transition to v2 at some point or is that an explicit toggle?
<zyga> I'm trying to understand if ubuntu core 20 will be cg-v1 or cg-v2
<xnox> zyga:  ubuntu 20.04 LTS will be hybrid
<xnox> fedora latest is v2-only
<xnox> hybrid is the same as what bionic is, i believe
<zyga> right, but is that configuration or some kind of auto-detection in systemd
<zyga> based on something (kernel version?)
<xnox> no
<xnox> this is a build-time systemd option
<zyga> ah, I see
<zyga> thank you!
<xnox> however, a user can override it with a kernel cmdline option
<zyga> do you thin core 22 will be v2?
<zyga> *think
<xnox> so for example on focal you can test and boot in v2-only mode if you want to prepare for the future / fedora
<xnox> i think fedora/rhel/suse will be v2-only before core22 ships
<mborzecki> zyga: systemd.unified_cgroup_hierarchy=1
<zyga> mborzecki: I do know this :)
<zyga> I was wondering what kind of future is ahead
<mborzecki> xnox: do you think rhel8 will become v2 at some point, or rather rhel9?
<mup> PR pc-amd64-gadget#34 closed: Makefile: add "regex" to the modules for the non-uefi grub <Created by mvo5> <Merged by xnox> <https://github.com/snapcore/pc-amd64-gadget/pull/34>
<mborzecki> zyga: do you have any graphical snaps on TW? like gnome-logs, gnome-calculator?
<mborzecki> zyga: if so, do the fonts render correctly?
<zyga> yes
<zyga> let me check
<mup> PR snapd#8125 opened: data/selinux: unify tabs/spaces <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8125>
<zyga> mborzecki: ^ can you look at that quickly please
<zyga> booting tw
<zyga> mborzecki: gnome-calcuator runs ok
<zyga> well
<zyga> almost
<zyga> the x in the corder is broken
<zyga> (close window)
<zyga> gnome-logs also works and has the same issue
<mborzecki> zyga: hm i still get boxes instead of fonts
<zyga> back with tea
<zyga> mborzecki: hm
<zyga> I should install arch and try
<zyga> mborzecki: did you you try to debug it?
<pstolowski> oh well travis is super slow
<mvo> yeah, it's terrible when trying to make a release
 * zyga goes for lunch/dinner 
<zyga> back
<zyga> funny day - everyone had something else for dinner
<zyga> mvo: any luck with the release?
<mup> PR snapd#8126 opened: release: 2.43.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/8126>
<mvo> zyga: it's almost out
<zyga> I see the tarball
<zyga> I'll make a suse package
<mvo> I need to create the proper github release but in a meeting right now so a bit slow
<zyga> ah wait, I didn't read the github page properly
<zyga> sure
<zyga> I'll wait
<mvo> zyga: should be ready in ~15min
<mvo> zyga: please have a look
<zyga> looking
<zyga> yep
<zyga> making the package now
<zyga> thank you :)
<zyga> building
<zyga> suse updated
<zyga> there's a small patch back to master
<zyga> I'll open it shortly
<zyga> jdstrand: can you try to look at https://github.com/snapcore/snapd/pull/8113 and https://github.com/snapcore/snapd/pull/8123 (they form a either-or pair)
<mup> PR #8113: cmd/snap-confine: bring /var/lib/dhcp from host, if present (approach a) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8113>
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> huh
<zyga> Feb 12 15:50:58 feb121515-669259 systemd[5577]: snapd.service: Failed to execute command: Exec format error
<zyga> Feb 12 15:50:58 feb121515-669259 systemd[5577]: snapd.service: Failed at step EXEC spawning /snap/snapd/x2/usr/lib/snapd/snapd: Exec format error
<zyga> mvo: ^
<zyga> I'm seeing this in CI
<mvo> zyga: uh, related to the release?
<mvo> cachio: 2.43.3 snapd snap is in beta now, 2.43.3 core should be available soon
<cachio> mvo, nice, I'll start right now
<cachio> thnaks
<mvo> cachio: thank you!
<mup> PR snapcraft#2933 opened: remote-build: introduce --launchpad-snapcraft-channel option <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2933>
<pedronis> mvo: did you backport the minor nvidia version fix?
<mvo> pedronis: it's not in
<mvo> pedronis: which is slightly silly, I was too cautious before and then forgot
<pedronis> it's ok I suppose, but checked because I was confused when looking at the changelog
<mvo> pedronis: yeah, we talked about adding it
<mvo> pedronis: and I was unsure (a bit) and did not cherry pick right away and then it felt through the cracks
<mup> PR snapd#8121 closed: spread: move centos to stable systems <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8121>
<ogra> heh, funny ... "snap find 'screen recorder'" finds xonotic ... i wonder why
<techalchemy> zyga, thanks for the fix!
<jdstrand> zyga: those aren't showing up in https://github.com/snapcore/snapd/pulls/review-requested/@me (for me :)
<jdstrand> zyga: please add the 2.44 milestone if you want them there unless you are seeing these are emergency
<cachio> ijohnson, hey
<cachio> I updated the spread pr
<cachio> the problem with the tests is that there is not unit tests at all for google backend
<cachio> ijohnson, for testing what I did is to use the -vv command for spread and iterate over differnt images to see if the selected is the desired one
<cachio> ijohnson, the problem is that the images change over time
<cachio> so it is difficult to test that in a spread test d
<cachio> zyga, when you have time could you please take a look to https://github.com/snapcore/snapd/pull/7900
<mup> PR #7900: tests: do reset of tests during restore and add checks to validate the fs <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/7900>
<cachio> I remember you developed a tool
<zyga> jdstrand: ack, not an emergency, just curious choice
<zyga> techalchemy: pleasure :-)
<zyga> cachio: sure, Iâll look in an hour
<cachio> zyga, thanks
<zyga> cachio: looks very interesting, I will review it in detail first thing tomorrow
<zyga> Today is too late for a detailed review
<zyga> I have some comments but I am happy to see progress on robustness
<cachio> zyga, nice, thanks
<cachio> it needs some improvements but I think it could help
<cachio> zyga, see you tomorrow
#snappy 2020-02-13
<mup> PR snapd#8127 opened: interfaces/cpu-control: allow to control cpufreq tunables <Created by alexmurray> <https://github.com/snapcore/snapd/pull/8127>
<mborzecki> morning
<pstolowski> morning
<zyga> good morning
<mborzecki> pstolowski: mvo_: zyga: pedronis: morning guys
<mup> PR snapd#8102 closed: o/ifacestate: move ResolveDisconnect to ifacestate <Needs Samuele review> <Squash-merge> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8102>
<mup> PR snapd#8125 closed: data/selinux: unify tabs/spaces <Simple ð> <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8125>
<mborzecki> pushed snapd update to arch and updated https://src.fedoraproject.org/rpms/snapd/pull-request/8 in fedora, but i see Eight_Doctor isn't around :(
<mup> PR snapd#8124 closed: tests: Fix core revert channel after 2.43 has been released to stable <Skip spread> <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8124>
 * zyga is in the office
<zyga> I need to shift a few hours back
 * zyga grabbed quick breakfast
<mup> PR snapd#8015 closed: [RFC] daemon, store: support download resume from /v2/download <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8015>
<mborzecki> zyga: some questions in #8123
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<pedronis> pstolowski: hi, let me know when #8003 can be reviewed again
<mup> PR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <â Blocked> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
<pstolowski> pedronis: hey, it can (when becomes green)
<zyga> mborzecki: thank you, looking
 * zyga reboots
 * zyga dives into failures
<mup> PR snapd#8109 closed: [RFC] o/devicestate: don't prune tasks immediediately <Preseeding ð> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/8109>
<mborzecki> hmm in tests prepare we cache the snaps, core among them, then proceed to `snapd download --$CORE_CHANNEL core` obviously the cached version is from stable  but tests run with edge
<zyga> hmmm
<mup> PR snapd#6708 closed: packaging/ubuntu: enable PIE hardening flags <â Blocked> <Created by bboozzoo> <Closed by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<pedronis> mvo_: thanks for spotting the Println in Ian's PR, I saw them but then forgot to mention them somehow
<mup> PR snapd#8128 opened: o/devicestate: OperationalTime helper for Prune (1/2) <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8128>
<pstolowski> just saw failover test failure, does anyone remember if it's the same we saw before? https://pastebin.ubuntu.com/p/8n4GPdfp32/
<mup> PR snapd#6708 opened: packaging/ubuntu: enable PIE hardening flags <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<mborzecki> pedronis: mvo_: i've updated Ian's boot base PR
<mborzecki> i'll do one last pass in case we missed something
<mup> PR snapd#8126 closed: release: 2.43.3 <Created by mvo5> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8126>
<zyga> hmm, more snapd failover failures
 * zyga checks pawel's messages from earlier today
<zyga> https://www.irccloud.com/pastebin/8RcV0Ocb/
<mborzecki> zyga: do you have the debug log?
<zyga> nope :/
<zyga> mvo_: we should update https://salsa.debian.org/debian/snapd
<mvo> zyga: yes
<mborzecki> the fonts in snaps seem to be rendered correctly on fedora, why do they render as boxes on arch?
<mborzecki> cachio: hi, can you enable epel8 in our centos-8 images? should be as simple as `dnf install -y epel-release`
<cachio> mborzecki, sure
<zyga> I'm seeing a failure on core 16
<mborzecki> cachio: thanks!
<zyga> likely unrelated to the PR
<zyga> did we change anything core prepare/restore lately?
<mborzecki> zyga: what failure?
<zyga> + mount --bind /home/gopath/src/github.com/snapcore/snapd/tests/regression/lp-1805838/bad-snap-seccomp /snap/snapd/current/usr/lib/snapd/snap-seccomp
<zyga> mount: mount point /snap/snapd/current/usr/lib/snapd/snap-seccomp does not exist
<zyga> this is the final error
<zyga> we try to bind mount test file over snap-seccomp from snapd snap
<zyga> but it's not there
<zyga> debug output shows
<zyga> https://www.irccloud.com/pastebin/Ilmc7Kxz/
<zyga> which confirms that we don't have snapd snap
<mborzecki> but $SNAP_MOUNT_DIR/snapd exists
<mborzecki> weird
<mborzecki> zyga: maybe a snapd on core failover left something? this landed ~2 days ago
<zyga> aha
<zyga> I suspect so
<zyga> let me run my mount detector :P
<zyga> which test was that? test/failover?
<zyga> tests/main/failover?
<mborzecki> zyga: i mean, maybe a directory /snap/snapd is left behind
<zyga> aha
<zyga> indeed, this is core 16 so probably no snapd snap
<zyga> but the directory may be enough to fool the logic
 * zyga checks
<zyga> thanks!
<mborzecki> zyga: tests/main/ubuntu-core-snapd*
<zyga> mborzecki: hmm
<zyga> mborzecki: the comment there talks about REBOOT and restore
<zyga> cannot we reboot in restore?
<zyga> mborzecki: what removes snapd.snap in that restore code?
<vidal72[m]> hi, what's the reason https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0#diff-2bc16f6bf7e15ff07cc61fb337428314 didn't make it to any 2.43.x release?
<mborzecki> zyga: iirc restore on core does not expect snapd snap and any of the 'trickery' that we do there
<zyga> mborzecki: I don't understand how that is related
<zyga> mborzecki: can restore do REBOOT?
<zyga> anyway, I'm running the test
<zyga> I suspect it is broken as it doesn't seem to clean up after itself
<zyga> thanks for the tip, I would chase this for a while without success
<mborzecki> zyga: idk, probably it can, but the problem ehre was that project restore has assumptions about the state of the system at that point
<zyga> mborzecki: that may be but task-level restore runs before
<zyga> so it can do whatever, reboot, and then hand off to suite code
<ppd1990> Hi. I have a question concerning glvnd in spand: As far as I can see (snap-confine/mount-support-nvidia.c#L555), snapd mounts the host's glvnd dir to /var/lib/snapd/lib _if_ the nvidia module is loaded. Why not for mesa though? Some apps need that for their GL context on wayland.
<zyga> ppd1990: hey
<zyga> ppd1990: we never knew about that, can you tell us more please
<zyga> ppd1990: but also because nvidia binary driver is usually abi compatible with everything
<zyga> ppd1990: and FOSS libs are more or less random
<zyga> ppd1990: so it's more of an exception than the rule
<pstolowski> pedronis: in the followup to #8128 i'm using release.PreseedMode in the overlord to avoid prung when preseeding, is that ok for now? i'd like to attack release.preseedmode after remaining preseed PRs land
<mup> PR #8128: o/devicestate: OperationalTime helper for Prune (1/2) <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8128>
<zyga> ppd1990: FOSS graphics is usually bundled into the app snap (bad but common) or into one of the helpers (like gnome content snap)
<vidal72[m]> zyga: do you know when https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0 will land in 2.43.x?
<pedronis> pstolowski: it's ok, we need to rediscuss what exactly we want to do about release.PreseedMode, my original plan doesn't entirely work
<pedronis> but release is still a slightly horrible place for it
<zyga> vidal72[m]: my guess would be never
<zyga> vidal72[m]: it will be in 2.44
<zyga> vidal72[m]: unless it is in 2.43 release branch
<zyga> but if it were you would not be asking
<ppd1990> zyga: Hey :). Yes, that's true. I'm mostly only concerned with /usr/share/glvnd/egl_vendor.d/50_mesa.json. If that's not in __EGL_VENDOR_LIBRARY_DIRS, gdk throws something like this on wayland: "No GL implementation is available"
<pstolowski> pedronis: sure. you mean the original plan of DeviceContext-like approach?
<pedronis> pstolowski: yes
<pedronis> pstolowski: anyway, let's talk about it when you reach a point where you want to attack it
<zyga> ppd1990: can you give me an example on how to reproduce this
<zyga> ppd1990: ideally as a bug report so that I can track it as well
<zyga> ppd1990: including host distro / gpu / snap app
<zyga> ppd1990: but the short answer is that the dots are not connected there
<zyga> ppd1990: we had some plans but they never materialized
<ppd1990> zyga: Take solvespace, an app that uses the gnome-extension. Simply pointing __EGL_VENDOR_LIBRARY_DIR to $SNAP/gnome-platform/usr/share/glvnd/egl_vendor.d is enough. So almost everything is set up and working
<pstolowski> pedronis: ok, will do, thanks
<zyga> ppd1990: should that be handled by the gnome extension? it can influence the environment
<zyga> also is __EGL_VENDOR_LIBRARY_DIR an implementation detail or something we can rely on long term?
<ppd1990> zyga: It does indeed. But only if it finds /var/lib/snapd/[...]/egl_vendor.d
<ppd1990> zyga: Which brings me back to "why is that mounted on nvidia only" :)
<zyga> ppd1990: because that belongs to extended nvidia support which as a rule takes libraries from the host
<zyga> ppd1990: and ... thats that
<zyga> no nvidia - dormant code path
<vidal72[m]> zyga: what's the policy about what lands in releases then? That commit was done about one month before 2.43 release and isn't in release while similar commits done in recent days are already there: https://github.com/snapcore/snapd/commits/2.43.3/interfaces/builtin
<ppd1990> zyga: I see. So that's more of a snapcraft thing then
<zyga> vidal72[m]: this is a question for our release manager, mvo
<cachio> mborzecki, hey
<cachio> https://paste.ubuntu.com/p/cxmZjbq4JM/
<cachio> I see this error when I try to install depdencies in centos8
<zyga> ppd1990: I would personally like to remove nvidia support entirely
<zyga> ppd1990: and ship those files via snaps
<cachio> I am trying to install the snap dependencies
<zyga> ppd1990: (shared snaps)
<mborzecki> vidal72[m]: looks like we forgot to set a milestone and do a cherry-pick
<zyga> ppd1990: but that's not moving forward
<cachio> mborzecki, but it works when we run tests on travis, right?
<ppd1990> zyga: It's almost like you guys are solving non-trivial problems :D
<zyga> ppd1990: it's a combination of lack of experience and known-how as to how mesa is moving
<zyga> ppd1990: and lack of time on our side to dive into it and commit
<mborzecki> mvo: can you cherry pick https://github.com/snapcore/snapd/commit/a836400012b70541a20de058b2a951f9386dddf0 to 2.43 in case we do another patch release?
<zyga> ppd1990: if you'd like to help by drafting how that ought to look like we can help
<mborzecki> cachio: yes, the set of packages for centos-8 is bit differnt, more like fedora, look at the changes in https://github.com/snapcore/snapd/pull/8083
<mup> PR #8083: spread: add CentOS 8 <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8083>
<zyga> ppd1990: ideally we'd ship a set of userspace libs as snaps, one per "driver" whatever that means
<zyga> ppd1990: snapd would figure out which to install
<zyga> ppd1990: possibly a matrix of driver and base snap used which defines the ABI
<cachio> mborzecki, ok
<zyga> ppd1990: and snapcraft would cull the libraries that belong to the driver from built snaps
<mborzecki> zyga: where 'driver' means a mesa snap probably or sth
<zyga> ppd1990: there's also some configuration as defined by magic environment and random files
<zyga> ppd1990: and that _should_ be it
<cachio> mborzecki, in that case I'll not install the dependencies yet
<zyga> ppd1990: assuming the host provides the kernel and any services that the driver needs
<zyga> ppd1990: matching the host driver (userspace side) is possible in the realm of snaps
<zyga> ppd1990: but none of this is implemented
<zyga> mborzecki: hmmm, -shell-after shows we have snapd
<mborzecki> zyga: snap or directory?
<zyga> mborzecki: everything
<zyga> mborzecki: working mounted and all that
<zyga> mborzecki: when you wrote this test, how were you expecting the recovery to work?
<zyga> ppd1990: btw, if my idea of how this ought to work is wrong based on your experience, please do tell
<mborzecki> zyga: mvo wrote the test iirc :P let me see what's happening there
<zyga> oh?
<zyga> mborzecki: commit 31312f02c18660a71c856f7c0f413e8c9c41a590
<zyga> that says you wrote it ;
<mborzecki> zyga: yeah, took over mvo's branch at some point, suashing merging, resetting, probably author got reset, nvm, i'll try to fix it
<ppd1990> zyga: I have little experience and my question was fueled by an incomplete understanding of the interface between host and the snap environment
<zyga> mborzecki: aha, I se
<zyga> *see
<zyga> mborzecki: yeah
<zyga> mborzecki: ok let me handle that for now
<zyga> I'll share my ideas in a moment
<mborzecki> zyga: ok, the problem is that we need to stop the snapd process, clean up everything it wrote to /etc/systemd/system/* and stop the hacky-mount-unit
<mborzecki> zyga: basically restore to snapd from 'core' rather than 'snapd' snap
<zyga> yeah
<zyga> I agree
<ppd1990> zyga: But your ideas are very interesting and seem to go in the direction of "more explicit interfaces" and less of "let's "mix" host & snap. Should be mostly OK"
<zyga> ppd1990: somewhere along there is the desire to stop mixing host /etc
<zyga> ppd1990: and provide a synthetic etc that is writable and snap-specific
<zyga> ppd1990: but $fonts $pam $random_stuff and others all need to be handled
<pedronis> pstolowski: +1, the summary and description needs the rename
<pstolowski> sure, thanks
<ppd1990> zyga: It reads like a very extensive problem if apps are not required to conform to a very limited "snap-platform"
<zyga> ppd1990: wild-west apps can ship and use anything
<zyga> ppd1990: but we want to provide a sensible base for the vast majority
<cachio> mborzecki, image ready
<mborzecki> cachio: thanks!
<cachio> mborzecki, yaw
<ppd1990> zyga: As a mere user/packager, I like it a lot. I feel things are moving into the right direction; that's for sure
<ppd1990> So thank you for doing what you do @snap(d|craft) team
<zyga> ppd1990: you are welcome, it's always good to get questions and opinions from the wider community :)
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/6708#pullrequestreview-358227261
<mup> PR #6708: tests/main/buildmode: verify usability of PIE hardening for deb packages <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6708>
<zyga> mvo: I'll join in 5 minutes
<mvo> zyga: ok
<mvo> pedronis: https://github.com/snapcore/snapd/pull/8078
<mup> PR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>
<zyga> cachio: I have your PR open, I'm sorry I didn't get to it yet
<zyga> I'll focus more on reviews after unblocking this bug
<cachio> zyga, np
<cachio> take your time
<roadmr> jdstrand: tools r20200211-blahblah is now in production \o/
<jdstrand> roadmr: woohoo! :)
<ijohnson> cachio: sorry I missed your ping yesterday, your explanation makes sense I don't think we need to write unit tests for that spread bit at this time, but I will try to test your PR with those commands locally
<mborzecki> zyga: hmm that snapd snap is a local repack? so rev will be unset, and the code allows removal in such scenario afaict (cc pedronis)
<zyga> mborzecki: that's probably what happens
<zyga> mborzecki: it failed to be removed after simplification
<mborzecki> zyga: do you have snap list maybe?
<zyga> mborzecki: it worked when it was broken
<zyga> not anymore
<zyga> waiting for another run
<mborzecki> zyga: hmm error: cannot remove "snapd": snap "snapd" is not removable: snapd required on core devices
<mborzecki> zyga: maybe it was the failover test?
<zyga> no, it was the non-failover one
<zyga> hold on
<mborzecki> zyga: ubuntu-core-snapd installs snapd snap from the store
<mborzecki> zyga: while the other one does magic hackery
<mup> PR snapcraft#2930 closed: extensions: Handle case when user-dirs.dirs exits but not user-dirs.locale <Created by galgalesh> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2930>
<mup> PR snapcraft#2929 closed: elf: fixes for corrupt shared objects <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2929>
<ijohnson> mvo: is #8077 ready then?
<mup> PR #8077: boot: enable base snap updates in bootstate20 <Squash-merge> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8077>
 * cachio lunch
<zyga> mborzecki: maybe this
<ijohnson> pstolowski: mind giving a quick re-review to https://github.com/snapcore/snapd/pull/7904 ? we should have a version of snapcraft that supports using `build-base: core` _without_ `type: snapd` released soon so it would be good to be ready to land this PR when that happens so we can make xnox happy :-)
<mup> PR #7904: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
<zyga> mborzecki: 8129
<mup> PR snapd#8129 opened: tests: remove snapd in ubuntu-core-snapd <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>
<mup> PR snapcraft#2934 opened: meta: fix for missing content slot's 'content' property <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2934>
<pstolowski> ijohnson: yay, sure!
<mup> PR snapcraft#2935 opened: build providers: remove tzdata workaround <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2935>
<zyga> mborzecki: what do you think?
<mup> PR snapd#8077 closed: boot: enable base snap updates in bootstate20 <Squash-merge> <UC20> <Created by anonymouse64> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8077>
<mborzecki> zyga: i'm surprised that snap remove snapd line works
<zyga> because it is broken
<mup> PR snapcraft#2936 opened: build providers: clean up LXD startup message <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2936>
<zyga> but I believe this does fix master
<zyga> I added robustness and critical labels to it
<zyga> mborzecki: I updated the description to be meaningful
<zyga> force pushed to squash and fix shellcheck
<zyga> mborzecki: please review :)
<zyga> it's really annoying when master is broken
<ijohnson> zyga: which PR ?
<zyga> https://github.com/snapcore/snapd/pull/8129
<mup> PR #8129: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>
<ijohnson> thanks looking now
<zyga> thank you!
<zyga> I should make some coffee
<pedronis> ijohnson: I reviewed #8112
<pedronis> thanks for it
<mup> PR #8112: tests: move main/ubuntu-core-* tests to core/ suite <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>
<ijohnson> thanks pedronis
<om26er> roadmr hey! can you please check if flatbuffers snap has any issues in the store. The publisher has been getting some build failure notifications due to wrong version string; we just fined that https://github.com/google/flatbuffers/pull/5727
<mup> PR google/flatbuffers#5727: [snap] Fix versioning <Created by om26er> <Merged by aardappel> <https://github.com/google/flatbuffers/pull/5727>
<ijohnson> pedronis: I'll change those things and then merge when it's green
<pedronis> thx
<pedronis> ijohnson: it might conflcit with #8129 ?
<ijohnson> hmm
<mup> PR #8129: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>
<ijohnson> pedronis: oh yes it might, but it's just a file rename so I can merge master to resolve that easily enough I think
<roadmr> om26er: I'll check in a bit
 * zyga combines coffee with dinner
<roadmr> om26er: latest upload/build was 17h ago, still getting this bogus version string ".11.0+git226.gcc08c083"
<om26er> roadmr we just landed the new PR, I am hoping that will trigger a new build then
<om26er> though I don't see anything here https://launchpad.net/builders
<om26er> roadmr are you able to force a build ?
<roadmr> om26er: might take a bit to kick off the build, I'd suggest waiting a few mins
<om26er> alright, sounds good
<roadmr> om26er: do let me know if it hasn't built in a couple of hours
<om26er> roadmr, I will, thanks
<mup> PR snapd#8130 opened: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130>
<pedronis> pstolowski: I think we can close 7836 ?
<mup> PR snapd#7836 closed: o/ifacestate: fix binding of implicit hooks to implicit slots on core snap <Bug> <â Blocked> <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/7836>
<pstolowski> pedronis: yes, done, i may pick it up again at a later time
<pstolowski> if needed
<pstolowski> ijohnson: we want build-base:core in https://github.com/snapcore/snapd/pull/7904, no? I don't see any change to the PR since I last reviewed it
<mup> PR #7904: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
<ijohnson> pstolowski: oh I must have mis-force-pushed good catch!
<pedronis> pstolowski: didn't really do a full review, but I made a comment on 8130
<pstolowski> ty
<ijohnson> zyga: mind if I force push the change mborzecki requested to #8129 to your PR? Also your PR will conflict with #8112, so if it's okay I would like to land that, then I can rebase that PR and apply the fixed maciej requested
<mup> PR #8129: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8129>
<mup> PR #8112: tests: move main/ubuntu-core-* tests to core/ suite <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>
<zyga> ijohnson: not at all
<ijohnson> zyga: cool thanks!
<mup> PR snapcraft#2934 closed: meta: fix for missing content slot's 'content' property <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2934>
<mup> PR snapcraft#2937 opened: spread tests: do not attempt to remove snapd snap <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2937>
<zyga> ijohnson: thanks for restarting, macos build now passed
<om26er> roadmr flatbuffers build didn't trigger yet. Can you force it manually ?
<ijohnson> zyga: np, my PR didn't pass non-ubuntu spread so I retriggered it, I guess we will see which PR passes tests first :-)
<zyga> one of those days
<zyga> but I'm happy we're moving forward
<ijohnson> indeed
<roadmr> om26er: sorry, I cannot :( maybe the snap owner can?
<om26er> roadmr, ok, will wait it off today and will "find" him tomorrow (I guess on GitHub) ;)
<roadmr> om26er: thanks - I can check with Colin tomorrow morning about why this might not have been triggered; it should trigger on new commits to master
<zyga> ijohnson: it's merged!
 * zyga takes the dog out, ttyl
<ijohnson> zyga: ack seems your PR beat mine :-)
<ijohnson> I will include the patch in my PR
<mup> PR snapd#8129 closed: tests: remove snapd in ubuntu-core-snapd <Test Robustness> <â  Critical> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8129>
<mup> PR snapd#8112 closed: tests: move main/ubuntu-core-* tests to core/ suite <Simple ð> <Test Robustness> <UC20> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8112>
<mup> PR snapd#8131 opened: boot: add current_kernels to modeenv <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8131>
<mup> PR snapcraft#2936 closed: build providers: clean up LXD startup message <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2936>
<mup> PR snapcraft#2938 opened: remote build: default to snapcraft's stable channel <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2938>
<mup> PR snapd#8047 closed: tests: detect LXD launching i386 containers <Test Robustness> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8047>
 * cachio afk
<Marcin_PL> Hello. How can I uninstall Snap completely, including virtual 93MB drive? I am using LMDE.
<zyga> Marcin_PL: hey
<zyga> Marcin_PL: it depends on the system you are using,
<zyga> Marcin_PL: but if you are using a dpkg/apt based system "sudo apt purge snapd" is one command
<zyga> Marcin_PL: keep in mind this will remove snapd, all snap apps and their data
<zyga> Marcin_PL: in rpm world there's a similar command using either yum, dnf or zypper
<zyga> Marcin_PL: if you tell us which distribution you are on, we might help
<Marcin_PL> I got APT
<Marcin_PL> LMDE is Mint on Debian
<zyga> Marcin_PL: was there something specific that made you remove snapd?
<Marcin_PL> Huh, thanks - looks it helped. I tried as usual apt(-get) remove snapd and there was still the core package mounted as /dev/loop0; now it's gone. I hope after the reboot it will not appear again. :)
<zyga> Marcin_PL: they should be gone, barring bugs in the postrm script
<Marcin_PL> Thanks again
<zyga> Marcin_PL: you are welcome :)
#snappy 2020-02-14
<mup> PR snapcraft#2937 closed: spread tests: do not attempt to remove snapd snap <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2937>
<mup> PR snapcraft#2938 closed: remote build: default to snapcraft's stable channel <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2938>
<mup> PR pc-amd64-gadget#35 opened: grub.cfg-boot: drop compatibility mode <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/pull/35>
<mborzecki> morning
<mborzecki> Make current revision for snap "snapd" unavailable ([--root / is-active snapd.core-fixup.service] failed with exit status 3: failed
<mborzecki> seen this one before
<mborzecki> hmm maybe we should ignore the stderr/stdout when calling systemctl is-active and just look at the exit code
<mborzecki> quick errand, some utility guys coming over, hopefully they'll be gone in 30 mins or so
<mborzecki> re
<mborzecki> mvo: hey
<mup> PR snapd#8132 opened: systemd: improve is-active check for 'failed' services <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8132>
<pstolowski> morning
<mborzecki> pstolowski: hey
<zyga> snow :)
<mvo> good morning pstolowski mborzecki and zyga
<mborzecki> zyga: hey, snow? got plenty of rain here :)
<zyga> let's hope today is more productive
<pstolowski> o/
<zyga> mborzecki: yeah, there's even nice patches on the ground
<zyga> is it freezing?
<zyga> supposedly +1 so no
<zyga> oh well
<pstolowski> zyga: snow, but melting away immediately
<mborzecki> simple pr to start your morning with #8132
<mup> PR #8132: systemd: improve is-active check for 'failed' services <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8132>
<zyga> mborzecki: ha
<zyga> remember when you told me about that dhcp thing
<zyga> that it failed for you
<zyga> suprirse
<zyga> it really only fails on arch, out of all the systems
 * zyga runs and see why
<mvo> pstolowski: 8128 LGTM, do you want to merge it?
<pstolowski> mvo: merged, thank you!
<mup> PR snapd#8128 closed: o/devicestate: StartOfOperationTime helper for Prune (1/2) <Needs Samuele review> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8128>
<zyga> mborzecki: can you re-review https://github.com/snapcore/snapd/pull/8123/files
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> it's updated and passes on arch
<zyga> just want to ack the new permissions
<mup> PR snapd#8133 opened: cmd/snap-confine: allow snap-confine to load nss libs <Created by zyga> <https://github.com/snapcore/snapd/pull/8133>
<zyga> mborzecki: ^ this is a RFC-ish
<zyga> more to raise awareness
<zyga> I don't expect it will land
<zyga> mborzecki: was there a bug report on https://github.com/snapcore/snapd/pull/8132?
<mup> PR #8132: systemd: improve is-active check for 'failed' services <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8132>
<zyga> pstolowski: there's a conflict on https://github.com/snapcore/snapd/pull/8120 and on https://github.com/snapcore/snapd/pull/8046
<mup> PR #8120: cmd/snap-preseed: snapd version check for the target <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8120>
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<pstolowski> zyga: thanks, i'm switching back to these PRs after de-tour with #8130 (prune tests are tricky)
<mup> PR #8130: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8130>
<zyga> sure :-)
<zyga> mborzecki: I ported parts of the desktop interface over to common
<mborzecki> zyga: nice!
<zyga> mborzecki: but only the simple parts, I'll do more once the prereq lands
<mborzecki> zyga: as for 8132, afaik there was no bug reprot, noticed that in a failed spread run today
<zyga> mborzecki: https://github.com/snapcore/snapd/pull/8134
<mup> PR #8134: interfaces: use commonInteface for desktopInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/8134>
<zyga> mborzecki: ok, I wanted to cross-reference if there was one, no worries
<zyga> mborzecki: ^ this one can be reviewed and merged separately from the rest
<mup> PR snapd#8134 opened: interfaces: use commonInteface for desktopInterface <Created by zyga> <https://github.com/snapcore/snapd/pull/8134>
<mborzecki> btw. to my surpise snapd.core-fixup.service was in failed state on 20.04, but it should `exit 0` if not running on ubuntu core
<zyga> ohhh
<zyga> that's weird
<zyga> what's the condition?
<zyga> pedronis: please review 8123 if you can
<zyga> pedronis: I applied your suggestions and I think this is the right way forward indeed
 * zyga breakfast
<mup> PR snapd#8135 opened: bootloader: make uboot a RecoveryAwareBootloader <UC20> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8135>
<pstolowski> pedronis: updated/replied on  #8046
<mup> PR #8046: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<mup> PR snapd#8131 closed: boot: add current_kernels to modeenv <UC20> <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8131>
<mup> PR snapd#8132 closed: systemd: improve is-active check for 'failed' services <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8132>
<zyga> mvo: ^ I added a comment to consider that for stable
<zyga> mvo: up to you to decide
<mvo> zyga: good point
<mup> PR snapd#8060 closed: gadget: skip update when mounted filesystem content is identical <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8060>
<mvo> zyga: cherry-picked
<zyga> thank you!
<zyga> snapd failover failed again
<zyga> is anyone looking at fixing that?
<zyga> https://www.irccloud.com/pastebin/ZHsaJSrS/
<zyga> more debug notes
<zyga> https://www.irccloud.com/pastebin/fyoWz9Pr/
<zyga> then more log spam
<zyga> https://www.irccloud.com/pastebin/HtomsMSS/
<zyga> (that last one is repeated heavily)
<zyga> mborzecki: ^ IIRC you asked for logs before
<zyga> do you want more or shall I kill this run?
<zyga> I'll make coffee
<zyga> mvo: I may skip standup today, I'll let you know
<mup> PR snapd#8136 opened: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136>
<ijohnson> thanks for the merge on 8131, I opened the followup https://github.com/snapcore/snapd/pull/8136 just now
<mup> PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136>
 * ijohnson disappears for a couple hours
<mup> PR snapcraft#2935 closed: build providers: remove tzdata workaround <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2935>
<mborzecki> cmatsuoka: hi
 * pstolowski lunch
<cachio> xnox, hi, I am trying to test the image in http://cdimage.ubuntu.com/ubuntu-core/20/pending/
<cachio> xnox, using kvm
<cachio> I can make that work
<cachio> is there any specific parameter for kvm/qemu which I need to use?
<xnox> cachio:  yes
<xnox> you need ovmf from focal; secureboot firmware; qc35 machine type; snakeoil variables
<xnox> cachio:  i use virtmanager desktop gui app to elect secureboot / tpm and override variables with snakeoil vars.
<xnox> i guess we should document this somewhere.
<xnox> otherwise from cmdline it is something like this
<cachio> nice, I'll try that and if it works I'll add that to our snapd testing docs
<xnox> sudo kvm -smp 4 -m 2048 -machine pc-q35-4.0 -global ICH9-LPC.disable_s3=1 -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on -drive file=OVMF_VARS.snakeoil.fd,if=pflash,format=raw,unit=1 -drive file=pc.img,if=none,format=raw,id=disk1 -device virtio-blk-pci,drive=disk1,bootindex=1
<cachio> xnox, owesome, thanks
<xnox> so /usr/share/OVMF/OVMF_CODE.secboot.fd is simply readonly
<xnox> bu tthe OVMF_VARS.snakeoil.fd is a "per-VM UEFI variables store" which should be started with like $ cp /usr/share/OVMF/OVMF_VARS.snakeoil.fd my-VM-VARS.fd
<xnox> cause we pre-built what the initial variables / uefi status should be
<cachio> xnox, nice
<cachio> xnox, I'll try it
<cachio> xnox, thanks
<xnox> (the vars have pre-enrolled settings to enforce secureboot, and have the keys currently used for signing enrolled)
<cachio> xnox, is it any way to get /usr/share/OVMF/OVMF_CODE.secboot.fd on bionic?
<cachio> or it is just available on focal?
<cachio> I'll create a vm with focal to test is
<zyga> mvo: I'm making good progress on OOM handling
<zyga> mvo: I'll skip standup as I'm in a car seat going with folks for lunch
<xnox> cachio:  you can download ovmf package from launchpad from focal and install it.
<zyga> mvo: I'll have some demo code on Monday, I hope, running in spread
<xnox> cachio:  it's an arch:all package with prebuilt static contents
<xnox> cachio:  why are you on bionic still instead of focal?
<zyga> mvo: I'm tweaking services so that we can regen services easily with extra entries
<cachio> xnox, I'll try that
<zyga> mvo: I still haven't thought of a better way to surface this
<zyga> mvo: so I'm going ahead with "snap set core oom-protect ..."
<zyga> mvo: I'll send two small patches that build towards that, one to snap.Info and one to wrappers
<ijohnson> hello again folks
<zyga> mvo: and other than that I'll focus on trying to set oom score and write a test that shows how a memory hog cannot kill a protected service
<zyga> mvo: and that's my update, I'll keep hacking until we arrive for dinner and then after that
<zyga> mborzecki: ^ FYI if you are interested in changes to wrappers
<ijohnson> zyga: also I saw that snapd failover test failure last night and was looking into it
<zyga> ijohnson: thank you, I am not looking into it
<zyga> ijohnson: so if you want to dive in please do
<ijohnson> yes it's on my list for today
<zyga> ijohnson: I kept a failed log on https://github.com/snapcore/snapd/pull/8133
<mup> PR #8133: cmd/snap-confine: allow snap-confine to load nss libs <Created by zyga> <https://github.com/snapcore/snapd/pull/8133>
<ijohnson> thanks
<zyga> great, thanks
<ijohnson> mvo: looking at 8135, will we need uboot to implement ExtractedRunKernelImageBootloader as well as RecoveryAwareBootloader in order to have uc20 support there?
<mvo> ijohnson: yes,  I think you are right
<ijohnson> mvo: perhaps your PR is enough to unblock foundations with setting up a uc20 gadget snap however
<mvo> ijohnson: yeah, that was my hope
<mvo> ijohnson: give them something to play with
<ijohnson> mvo: but makebootable20RunMode will fail if there's not an ExtractedRunKernelImageBootloader available, so probably the image won't get past install mode
<ijohnson> mvo: ok, if you like I can work on that with foundations when they get farther along the process ?
<mvo> ijohnson: that sounds acceptable for now, they need to first write the right uboot.env
<mvo> ijohnson: \o/ that would be most welcome
<ijohnson> ack
<mup> PR snapd#8137 opened: tests: skipping interfaces-openvswitch on centos due to package is not available <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8137>
 * cachio bank & lunch
<mup> PR snapcraft#2939 opened: pluginhandler: user directories scoped to partdir for snapcraftctl <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2939>
<mup> PR snapd#8138 opened: snap/info: add SnapRevisionFileName <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8138>
<pedronis> ijohnson: mvo: finishing the current boot stuff is probably higher priority as long as they are unblocked for a bit
<mup> PR snapd#8135 closed: bootloader: make uboot a RecoveryAwareBootloader <UC20> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8135>
<mvo> pedronis: ack
<ijohnson> ack
<zyga> maciek is off already
<zyga> ah, right
<zyga> oh well :)
<zyga> pedronis: I replied to the unrestricted path extension question https://github.com/snapcore/snapd/pull/8123#discussion_r379526244
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<pedronis> zyga: are you saying that with that change a layout can now create directories under /var in the host?
<pedronis> asked in the PR as well
<zyga> pedronis: layouts cannot create anything in /var/lib/snapd/*, which includes hostfs, it would allow a snap to create a directory on the host if that location is bridged with snap-confine's default set - this includes /var/snap (but that is black-listed from layouts), /var/lib/snapd (also black-listed), /var/tmp (allowed), /var/log (allowed) and finally /var/lib/extrausers (allowed)
<zyga> I'll paste this response to the PR
<zyga> pedronis: (to be precise, users cannot request a layout, not that layouts cannot create)
<zyga> pedronis: interestingly, /var/log snap-confine-made, fixed mount, is marked with a TODO, asking to move it to an interface
<zyga> pedronis: I think the approach is right but perhaps we need to investigate the unrestricted path more
<zyga> pedronis: here we _do_ want it (in /var/lib/dhcp) because otherwise we'll end up with a mimic
<zyga> pedronis: but the point of the interface is to expose _real_ /var/lib/dhcp to the snap, creating it if necessary
<zyga> pedronis: I would be happy with a special case that says var/lib/dhcp can be made
<zyga> and continue the investigation into what is exactly allowed per interface, akin to what Maciek hinted at
<pedronis> zyga: to be clear I'm slightly less worried about interfaces, my worry is layout, whether we have enough checks in place, not to make something odd happens
<pedronis> if we change something there
<pedronis> because the new unrestriction
<zyga> pedronis: so, users cannot request a layout to /var/lib/snapd/hostfs/* so the answer is that it is not something that interacts with layouts directly
<zyga> pedronis: and actually, thinking about it now
<zyga> pedronis: my comment was incorrect - given that layouts and snap-confine made mount points don't interact
<zyga> pedronis: this doesn't change anything layouts can make
<zyga> pedronis: I was confused because if you put a layout from $SNAP/foo to /var/lib/foo
<zyga> that feels like it might interact
<zyga> because perhaps /var/lib/foo is bridged by snap-confine to the host
<zyga> but that's irrelevant for /var/lib/snapd/hostfs/var/ that is allowed
<zyga> because /var/lib/foo is not in a prefix of hostfs, you end up with a mimic
<zyga> as such I think this is safer than I assumed, since nothing apart from snapd code can request new hostfs entries
<zyga> (I added this to the PR thread)
<pedronis> thx, I'll reread on Monday morning at this point
<zyga> thank you, that's a good idea :)
<zyga> pedronis: I would like to see a more central system for permissions
<zyga> pedronis: some of it is in layout validation
<zyga> pedronis: some in appamor on snap-confine
<zyga> pedronis: we should think about what we'd like to make explicit
<pedronis> yea, it all feels very disjoint, no clear suggestion atm though
<zyga> and also some in snap-update-ns trespassing exceptions
<zyga> yeah, spanning C, apparmor and two Go parts (one with state access one without)
<zyga> but I agree that it would be good to make it easier to see at a glance
<zyga> perhaps a shared go package that just list stuff that both snapd and snap-update-ns import and use
<zyga> and even generated .c for snap-confine
<zyga> or something along those lines
 * zyga just unblocked a lot of progress
<zyga> sssheeesh :)
 * zyga EODs
<ijohnson> cachio: do you in spread if there's an easy way to "skip" a test? for example I have a test with environment variable variants and on uc18 with one of the variants it doesn't make sense to run, so I want to skip that one
<ijohnson> cachio: what I did was just `if ...; then echo "skip"; exit 0; fi` is that a good way to do that?
<cachio> ijohnson, you want to skip a variant on a specific system right?
<ijohnson> yes
<ijohnson> what I have works, just wondering if there's a more elegant way to do this
<cachio> ijohnson, the if solution is the one we use for those cases
<cachio> as you did
<ijohnson> okay, so what I have is the right thing to do
<ijohnson> thanks!
<cachio> I have a pr for that but it is not approved
<cachio> to create run conditions
<cachio> so you write the if but just once
<cachio> here you need to add that if in the prepare, execute and restore
<ijohnson> yeah right, that would be nice
<mup> PR snapd#8139 opened: interfaces/{desktop-legacy,unity7}: adjust for new ibus socket location <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8139>
<mup> Issue pc-amd64-gadget#36 opened: Broken kernel.efi does not reboot automatically <Created by anonymouse64> <https://github.com/snapcore/pc-amd64-gadget/issue/36>
<zyga> kenvandine: FYI https://bugs.launchpad.net/snapd/+bug/1863255
<mup> Bug #1863255: Programs installed in Snap format do not detect the keyboard  <amd64> <apport-bug> <focal> <package-from-proposed> <snapd:New> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1863255>
<zyga> kenvandine: not sure if this is widespread but my 20.04 system doesn't have working keyboard input in some graphical snap apps
<zyga> kenvandine: and someone just reported a bug that's similar
<kenvandine> oh interesting
<zyga> Wimpress: ^
<kenvandine> like what apps?
<zyga> kenvandine: I tried irccloud-desktop
 * kenvandine looks at bug
<zyga> wasn't able to type my email address
<kenvandine> i'm using irccloud-desktop right now
<kenvandine> working fine
<kenvandine> weird
<zyga> the reporter tried spotify, thunderbird and superproductivity
<zyga> I suspect it depends on classic vs strict
<zyga> but something is wonky
<zyga> weird
<zyga> I had a fresh insstall
<zyga> I tried wayland and x
<zyga> all up to date
<zyga> something to chase next week
<zyga> but just wanted to give you a note
<Wimpress> zyga: I've been using 20.04 daily for weeks.
<Wimpress> And have dozens of snaps that I rely on.
<Wimpress> Not experienced that issue.
<zyga> Wimpress: hmmm hmm hmm
<zyga> must be something in fresh vs updated installs
<zyga> I wonder what could be a factor
<zyga> input stack is such a mystery to me
<zyga> Wimpress: can you create a new user account and try if they work there?
<zyga> maybe that gives you a pristine config
<Wimpress> Not right now. But I'll make a note to test.
<zyga> thanks, I'll  try some more as well
<zyga> thank you guys!
<mup> PR snapcraft#2940 opened: build providers: remove use of cloud-init <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2940>
<mup> PR snapcraft#2941 opened: [WIP] extensions: add cleanup extension <Created by galgalesh> <https://github.com/snapcore/snapcraft/pull/2941>
<mup> PR snapd#8138 closed: snap/info: add Filename <Simple ð> <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8138>
<mup> PR snapcraft#2942 opened: pluginhandler: do not search installdir or stagedir for dependencies <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2942>
<mup> PR snapd#8140 opened: [DRAFT] tests: add more UC20 tests <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8140>
<mup> PR snapcraft#2943 opened: spread: capture developer debug information <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2943>
#snappy 2020-02-15
<mpontillo> how does `/snap/bin` get added to the $PATH? (I was just talking with someone who said they tried installing a snap on Focal, but it didn't show up in their $PATH.)
<zyga> jdstrand: thank you for the review!
<zyga> mpontillo: that's a lot of sad stories and black magic
<zyga> mpontillo: PATH is sadly set in a plethora of places
<zyga> mpontillo: or reset
<zyga> mpontillo: please catch me next week for a complete answer
<zyga> mpontillo: we try to do our best to set it everywhere that matters
<zyga> mpontillo: we use environment generators, patch various startup scripts, patch sudo configs etc
<zyga> mpontillo: it's not one spot
<zyga> mpontillo: then there are bugs where some programs "just know" what the vanilla PATH is and that is lost
<mpontillo> thanks zyga - have a good weekend!
<zyga> mpontillo: in their case it is most likely they installed snapd and then installed the snap, /snap/bin will be on PATH after reboot - OR - that they expected an alias and /snap/bin was on path but did not contain the alias they expected
 * mpontillo yeah, I figured that it was probably some kind of install-order dependency
<mpontillo> though I thought snapd was installed by default now, which in my mind would have prevented the issue
<mpontillo> curiously enough, when I check my $PATH on Focal I see `/snap/bin` twice ;-)
<guiverc> Not sure if this is the correct place, I've rebooted my 20.04 box & I can't enter any keystrokes into chromium-browser windows/tabs; closing & restarting it did nothing, it works perfectly via mouse, but ignores any keystrokes (telegram is a snap too, I can use keyboard there)
<sdhd-sascha> Hi :-)
<sdhd-sascha> Has anybody experience with github actions ?
<sdhd-sascha> I try to build `snapd` with github and got this error: "https://github.com/sd-hd/snapd/runs/443747350?check_suite_focus=true"
<sdhd-sascha> Runtime of the build and tests, was greater then five hours...
<sdhd-sascha> https://github.com/sd-hd/snapd/runs/443747350?check_suite_focus=true
<sdhd-sascha> Oooh ... the `q` param was missing from wget. I was sure i had added them
#snappy 2020-02-16
<leinardi> hi, while running flatpak-builder I'm getting the error "hidapi/libusb/hid.c:47:10: fatal error: libusb.h: No such file or directory" when I try to package https://pypi.org/project/hidapi/ despite providing both libusb and hidapi. How can I see how the filesystem looks during/after the build to see if the required header is perhaps provided in another path?
<leinardi> more info here: https://github.com/flathub/flathub/issues/1375
<sdhd-sascha> hey:
<sdhd-sascha> can your yaml?
<mwhudson> sooo this bug where chromium doesn't accept keyboard input
