#snappy 2016-02-22
<mvo> kyrofa: hi, the latest os update should contain an updated snappy (iirc you asked about this last week)
<zyga> good morning
<mvo> hey zyga, good morning
<dholbach> good morning
<noizer> good morning :D
<clobrano> hi all! Is it possible to connect to webdm server from a kvm virtual machine with snappy? I tried but it does not seem to work.
<stevebiscuit> clobrano: do you have a route to port 4200 setup? I'm not using KVM myself but there's some info in the README: http://bazaar.launchpad.net/~snappy-dev/webdm/trunk/view/head:/README.md#L53
<clobrano> thanks stevebiscuit! Sure, I saw that bug and I run the KVM with this command kvm -m 768 -redir :8022::22 -redir :4200::4200 -hda snappy.img, but I still couldn't connect. I saw that the syslog shows an error like "job webdm failed with result 'dependency' http://paste.ubuntu.com/15169482/
<clobrano> stevebiscuit: but no idea about what does that mean
<ogra_> looks broken
<stevebiscuit> clobrano, ogra_: yeah, that systemd error seems ominous, looks like it might not be able to start the web app
<stevebiscuit> clobrano: is there a `snappyd` running?
<clobrano> stevebiscuit: yes systemd is running
<clobrano> stevebiscuit: well, I'm basically able to do everything I need, just can't connect to webdm
<stevebiscuit> clobrano: systemd or snappyd ?
<ogra_> how did you install it ... and is that a 16.04 or the old 15.04 ?
<clobrano> stevebiscuit: sorry a typo, snappyd is running
<clobrano> ogra_: is a kvm virtual machine with 15.04
<clobrano> ogra_: I created it with this command kvm -m 768 -redir :8022::22 -redir :4200::4200 -hda snappy.img
<ogra_> why the -hda ?
<ogra_> (i doubt it breaks anything, butu not needed)
<clobrano> ogra_: I tried also without -hda, I took it from Bug #1425021
<ubottu> bug 1425021 in Snappy "KVM instructions not setup for use of WebDM" [Medium,Triaged] https://launchpad.net/bugs/1425021
<noizer> zyga can you help for building the snappy environment with your branch?
<kyrofa> Good morning
<kyrofa> mvo, indeed, thank you!
<noizer> Does anyone know when zyga will be back?
<noizer> is it normal that i can't install webdm on 16.04?
<noizer> kyrofa?
<kyrofa> Hey noizer. Can you be more specific? How does it not install? An error? Can it not be found?
<kyrofa> What architecture are you using?
<noizer> webdm failed to install: can not open /tmp/webdm995163236: cannot open snap: unknown header: "!<arch>\ndebian-binar"
<noizer> I'm using 16.04 roling rpi2
<kyrofa> noizer, it's possible that webdm needs to be repackaged and re-uploaded after some snappy changes
<ogra_> noizer, webdm is 15.04 onlyyet ... i think stevebiscuit works on a 16.04 version
<noizer> ok xD
<noizer> thx
<kyrofa> stevebiscuit, do you know anything about that? ^^
<kyrofa> Oh, thanks ogra_
<kyrofa> I just spent far too long trying to figure out what his handle was :P
<stevebiscuit> kyrofa: that's pretty much the last piece of functionality I've to migrate over to the snapd API
<kyrofa> stevebiscuit, excellent. Is the progress feedback still a poll-only interface?
<stevebiscuit> kyrofa: the API will soon be using websockets though the front-end JavaScript will likely still poll the WebDM backend
<kyrofa> stevebiscuit, ah, okay
<kyrofa> dholbach, you know when you're an elite, dedicated member of the Snappy team when...
 * dholbach hugs kyrofa  :)
 * kyrofa hugs dholbach 
<davmor2> kyrofa: put him down you don't know where dholbach 's been ;)
<kyrofa> davmor2, don't be jealous
<davmor2> kyrofa: dholbach's awesome and he knows it, I tell him too many times for it to of not sunk in :)
 * dholbach hugs you all :)
<kyrofa> jdstrand, did you ever figure out anything more regarding bug #1467595?
<ubottu> bug 1467595 in xorg (Ubuntu) "cursor sometimes disappears on XPS 13 9343 and external monitor" [High,Confirmed] https://launchpad.net/bugs/1467595
<jdstrand> kyrofa: it stopped in later releases
<kyrofa> jdstrand, urgh... so wily it wasn't an issue?
<jdstrand> I feel like wily was good. xenial still is
<jdstrand> let me check something
<kyrofa> jdstrand, definitely reason enough to update, then
<kyrofa> jdstrand, I'm still on trusty and it's killing me
<jdstrand> yeah that bug is seriously annoying
<jdstrand> kyrofa: I have in my notes "this seems to be improved with the 4.2 kernel"
<jdstrand> kyrofa: that is what is in wily btw
<jdstrand> I also commented in the bug
<kyrofa> jdstrand, you commented to that effect with 4.1, but then you later commented saying nevermind
<jdstrand> I did
<jdstrand> I did, and I have notes that say that 4.1 was better but still happened
<kyrofa> jdstrand, and 4.2 it hasn't happened at all?
<jdstrand> I think wily was ok-- I upgraded to xenial a while ago though, so I can't recall. I never see it any more
<jdstrand> kyrofa: I *think* so
<kyrofa> jdstrand, alright, good to know
<jdstrand> you could try the wily lts kernel
<kyrofa> jdstrand, yeah good plan
<jdstrand> you might need to snag some other stuff too-- eg the bcmwl modules and maybe linux-firmware
<kyrofa> jdstrand, there's another issue that's been killing me too-- occasionally when coming back from sleep (or when initially logging in) and plugged into my external 4k monitor, X just crashes. Did that ever happen to you?
<jdstrand> I think I just needed bcmwl for my wifi and linux-firmware wasn't needed
<kyrofa> jdstrand, yeah I'll need bcmwl as well
<jdstrand> kyrofa: yes. that still sometimes happens. I feel like perhaps less on xenial, but quite sure I've seen it
<kyrofa> jdstrand, did you ever make an issue for that? Or shall I?
<jdstrand> kyrofa: this is my latest annoyance: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1547619
<ubottu> Launchpad bug 1547619 in linux (Ubuntu Xenial) "Intermittent screen blinking with 4k external mini display port with 4.4 kernels" [Medium,In progress]
<kyrofa> Ugh, that sounds awful
<kyrofa> Hahaha, 4k is so bad
<jdstrand> 4.3 didn't have that behavior
<jdstrand> (or 4.2)
<kyrofa> 4.2-4.3 is the sweet spot, eh?
<jdstrand> thus far
<jdstrand> 4.4 has been ok except for that new bug, and I'm testing bisected kernels, etc
<jdstrand> xenial should be decent in the end
<jdstrand> kyrofa: I didn't create a bug
<jdstrand> (for the crash)
<jdstrand> I couldn't find a solid reproducer
<kyrofa> jdstrand, oh man, that's easy-- unplug and plug the external until crash. I'll make one :)
<kyrofa> jdstrand, I'll make it for trusty, and then perhaps you can comment and whine about wily and xenial too
<jdstrand> I don't think I've seena crash with 4.4-- what happens is coming back from suspend the external monitor blanks and unblanks a few times and comes back. of course, the the crash is pretty infrequent for me, so I just might not have hit it yet
<jdstrand> hotplugging is the next bug I plan to file-- if I hotplug the xrandr stuff doesn't work right and I get a dialog saying so and the screen stretched all weird. if I press 'Enter' to dismiss the dialog, it all snaps back
<jdstrand> I wonder if that is the same bug and the dialog is preventing the crash by stopping before it would crash...
<kyrofa> jdstrand, huh, yeah that's interesting. I'm not sure I've ever seen a popup about that
<jdstrand> yeah, new in xenial
<jdstrand> wily didn't have it
<kyrofa> jdstrand, yeah I bet so then!
<jdstrand> (and I definitely recall crashes on wily)
<kyrofa> Veeery interesting...
 * jdstrand nods
<kyrofa> jdstrand, maybe we can compare logs. I'll get back to you when I make the bug
<jdstrand> ok
<kyrofa> jdstrand, it's nice to have someone else who can share my pain
<kyrofa> Now if you'll excuse me, I need to logout so my mouse pointer comes back from vacation
<jdstrand> kyrofa: heh, :\
<jdstrand> kyrofa: good luck!
<kyrofa> jdstrand, all good now. Time to fire everything back up now...
<Sweet5hark> snapcraft 2.2.2/xenial: I have lots of libs in stage/usr/lib/x86_64-linux-gnu and "snap: - usr/lib/x86_64-linux-gnu/*" in snapcraft.yaml. why are those not in the image
<Sweet5hark> ?
<Sweet5hark> ogra_: ^^ any hints?
<kyrofa> Sweet5hark, check the snap folder
<kyrofa> Sweet5hark, let me turn that into a question. Are you placing those libs manually?
<kyrofa> Sweet5hark, or is it via stage-packages?
<kyrofa> (or from src)
<Sweet5hark> kyrofa: https://bugs.launchpad.net/snapcraft/+bug/1548376 <- filed it as a bug. IMHO this needs a whole matrix of "in build-pkg"/"in stage-pkg"/"dep of build-pkg"/"dep of stage-pkg"/"in snap glob"/"in directory matched by snap glob" for "ends up in stage" and "ends up in snap" each ...
<ubottu> Launchpad bug 1548376 in Snapcraft "docs/snapcraft-syntax.md should explicitly name the conditions under which a file is expected to end up in stage/ and snap/" [Undecided,New]
<wigleworm> anyone around that can help with a snapcraft question
<miken> wigleworm: Hi - try just asking your question perhaps. I'm not sure if there are people around who can answer, but you'll have more chance of getting an answer if there are :)
<qengho> wigleworm: Yeah, just ask. Don't demand someone commit to answering something in advance.
<jdstrand> pindonga (and beuno): hi! can you pull the review tools? this adds all the snap v2 checks I've been working on
#snappy 2016-02-23
<jtam> Hi, recently I am playing with snappy on raspberry pi, I want to use docker to run my application. while running the command 'docker run -d --device=/dev/ttyAMA0:/dev/ttyAMA0 --device=/dev/mem:/dev/mem --privileged -ti <name>', I got this error 'open /dev/bus: permission denied ', any ideas how to solve it?
<shuduo> ogra_: ping
<shuduo> ogra_: hi, i have asked you regarding OEM snap few days ago. Now I'm generating an oem snap and snappy image on xenial environment. I refer snappy-systems code and built out oem snap but u-d-f refused to generate snappy image with msg "kylin-oem/canonical-rockchip-kylin_1.0_all.snap failed to install: open /tmp/read-file931124659/unpack/DEBIAN/manifest: no such file or directory".
<shuduo> and u-d-f refused eailer oem snap due to package.yaml can't be found. seems 15.04 use meta/package.yaml but 16.04 use meta/snap.yaml
<shuduo> i copied snap.yaml to package.yaml to make u-d-f satisfied but stuck at DEBIAN/manifest. anything wrong I made?
<shuduo> anyone help me for above issue?
<zyga> good morning
<zyga> shuduo: OEM snaps are gone right? we have kernel (or platform really as it's more than the kernel), os snap (shared among all core devices) and gadget snap
<zyga> shuduo: OEM is the old name for what 16.04 calls the kernel snap
<shuduo> zyga: morning
<shuduo> zyga: is there a doc for how to port snappy 16.04 to a new platform I can read?
<zyga> shuduo: maybe, but I don't know of one, I'd start with raspberry pi as a learning device (to see how it's made) and then try to transplant bits and pieces to a different hardware
<zyga> shuduo: so get 16.04 gadget and kernel for pi2
<zyga> shuduo: and see what's inside
<zyga> shuduo: make sure you can rebuild them
<zyga> shuduo: and iterate
<zyga> noizer: hey
<zyga> noizer: I wasn't around yesterday
<zyga> noizer: I can help you out, I'd just prefer to do it in public here, as others can benefit, ok?
<noizer> ok
<shuduo> zyga: thanks. could you pls point me where I can download gadget and kernel snap of PI2?
<zyga> shuduo: I wish I can remember, gimme a sec
<shuduo> and u-d-f command line parameters for 16.04
<shuduo> thanks
<zyga> shuduo: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/files
<zyga> shuduo: have a look at this, I haven't tried in a while but I think this is the right version
<zyga> shuduo: http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-systems/view/head:/pi2/meta/snap.yaml
<zyga> shuduo: this is the gadget snap
<zyga> shuduo: now the kernel... hmm
<noizer> zyga how can i check that I did everything correct from the core?
<shuduo> zyga: yes, i read it and thought it's OEM snap
<zyga> noizer: so what did you do so far?
<zyga> shuduo: this is a bad week to try this because of MWC and EW trade shows both allocating lots of people away from their normal work
<zyga> shuduo: but I'll try to find where the kernel lives
<zyga> dholbach: hey, do you know where the source for kernel snaps live? (pi2)
<dholbach> good morning
<dholbach> hey zyga
<dholbach> no idea - ppisati should probably know
<dholbach> or ogra_
<zyga> dholbach: we should put this into the topic of the channel
<zyga> dholbach: a small wiki page with essential snapy hacker links
<zyga> dholbach: +1/-1?
<noizer> I've done everything to the point of building
<zyga> dholbach: ogra is on EW, won't respond for a week
<noizer> zyga that was the last thing I've done
<zyga> noizer: ok cd $GOPATH/src/github.com/ubuntu-core/snappy/cmd/snap
<zyga> noizer: go build
<zyga> noizer: if that works you're 99% there
<noizer> ok done that
<zyga> noizer: built fine?
<zyga> noizer: you can try ./snap --help
<zyga> noizer: just as a sanity check
<shuduo> zyga: or i can iterate 15.04 ... but make a few sense. :)
<zyga> shuduo: no, use 16.04
<noizer> zyga that works fine
<zyga> noizer: clone my devscripts somewhere please (github.com/zyga/devscripts)
<zyga> er
<zyga> devtools
<zyga> sorry
<zyga> http://github.com/zyga/devtools
<dholbach> zyga, sounds good - feel free to add it to https://wiki.ubuntu.com/Snappy/
<zyga> dholbach: thanks, will do
<dholbach> zyga, maybe on http://people.canonical.com/~ppisati/ somewhere?
 * dholbach shrugs
<zyga> dholbach: well, _maybe_ :D
<zyga> in that pile over there ;)
<zyga> noizer: then make sure you have a compatible ssh config (look at the README.md file) -- you must be able to login to your device with ssh snappy-pi2
<noizer> zyga i've downloaded it
<zyga> noizer: if not, tweak your ssh config
<zyga> noizer: if you have to, build a new image (you can use the ubuntu-image script from the same repo to get one)
<zyga> noizer: (just make sure to build a developer image with your ssh keys inside)
<zyga> noizer: run the ubuntu-image script without arguments to do that
<noizer> zyga ow does i need to build it on my rpi2 the snappy image?
<zyga> noizer: nope
<noizer> okey :D
<zyga> noizer: on your usual computer
<noizer> where does i need to set the config for my ssh then?
<zyga> noizer: ~/.ssh/config
<zyga> noizer: you have to be able to run 'ssh snappy-pi2' and login to your device without any prompts
<zyga> noizer: https://github.com/zyga/devtools#ssh-configuration
<noizer> the ssh does need to changed on my rpi2 but what does needs to run on my rpi2?
<noizer> zyga I don't understand it completely
<noizer> Where exactly does i need to change the ssh config file?
<noizer> on my own device?
<zyga> noizer: yes
<zyga> noizer: everything I said so far happens on your host device
<noizer> zyga ok busy with it
<zyga> kk
<zyga> ppisati: hey, do you happen to know where the sources for kernel snap for pi2 are?
<ppisati> zyga: i know where the source for the kernel are
<zyga> ppisati: how are they built to a kernel snap?
<zyga> ppisati: with snapcraft or manuall?
<zyga> manually?
<ppisati> zyga: i think still manually
<zyga> ppisati: can you share that, I'm collecting the knowledge and I could use the links and simple instruction
<zyga> ppisati: plus it will help me with my skills work
<ppisati> zyga: ask mvo or sergiuns they are building these snaps
<zyga> ah, cool, will do, thanks
<noizer> ssh: Could not resolve hostname pi2-1.lan: Name or service not known
<zyga> noizer: have you read what I wrote in the readme file?
<zyga> "Put something similar to your ~/.ssh/config file. Do change bbb-1.lan and pi2-1.lan to an appropriate hostname (or IP address) that is valid in your setup."
<zyga> to quote ^^
<noizer> auwtch lol
<noizer> just read it xD
<noizer> does it need to be a raspberry pi with an os on it?
<zyga> noizer: yes, build the OS with the ubuntu-image script first
<zyga> noizer: copy it to an SD card (dd the whole image)
<zyga> noizer: and boot your pi
<zyga> noizer: make sure you can log in first
<zyga> noizer: (1) flash (2) setup ssh and login (3) use refresh-bits.sh script to do other stuff
<noizer> I need to make the devel image?
<zyga> yep
<zyga> to be able to log in without a password
<zyga> it just puts your public ssh key in ~ubuntu/.ssh/authorized_keys
<noizer> zyga wait a minute just need to install some deps first
<noizer> wtf i did make image and got very strange thing with my VM
<noizer> zyga http://imgur.com/lKrYoEK
<zyga> noizer: I have no idea what that is, maybe your machine is broken somehow
<noizer> rebooted it and try again zyga :p
<noizer> dammed the .ssh file not found
<zyga> noizer: it is a directory, just create it
<noizer> ok
<zyga> noizer: and make an ssh key
<zyga> noizer: ssh-keygen -t rsa
<zyga> mvo: hey, can you please point me to the source of pi2 kernel snap
<zyga> mvo: and perhaps instructions on how to rebuild it
<zyga> dholbach: I've added a link to https://wiki.ubuntu.com/Snappy
<dholbach> awesome :)
<mvo> zyga: here is the script that builds the kernel snap http://bazaar.launchpad.net/~mvo/snappy/mksnap-os-kernel/view/head:/mk-kernel-rpi2.sh - note that it get the actual kernelfrom  http://cdimage.ubuntu.com/ubuntu-core/daily-preinstalled/curren
<zyga> woot, thanks mvo
<mvo> zyga: could you please re-merge your two pending branches with master? this should fix the integration test failures
<mvo> zyga: ups, three
<zyga> mvo: sure
<zyga> mvo: done, pushed now
<noizer> zyga sorry for the delay but know i can ssh to my rpi2 with ssh snappy-pi2
<noizer> zyga what should i need to do now?
<noizer> i did now ./refresh-bits.sh on my host computer
<zyga> noizer: cool, so now you can do two things:
<zyga> noizer: you can use refresh-bits.sh to push new snap, snappy and snapd
<zyga> noizer: you can use setup and run-snapd to run snapd that you've built on the board
<zyga> noizer: now what you want to do is to go to $GOPATH/src/github.com/ubuntu-core/snappy
<zyga> noizer: and do this:
<zyga> git remote add zyga https://github.com/zyga/snappy.git
<zyga> noizer: git fetch zyga
<zyga> noizer: git checkout zyga/skills-demo-i2c
<zyga> noizer: with that you will have my development branch
<zyga> noizer: then re-run refresh-bits with all arguments (setup snap snappy snapd run-snapd)
<zyga> noizer: then ssh into the board and run sudo ./snap experimental
<zyga> NOTE: ./snap not snap
<zyga> noizer: then you should be good to go for the next step
<zyga> noizer: you should see a bunch of extra commands for working with skills
<noizer> something goes wrong :s will send you what I done
<noizer> http://pastebin.com/mWdaGdAx
<noizer> zyga
<zyga> noizer: refresh-bits.sh --pi2
<zyga> noizer: use --pi2 to work against a raspberry pi
<zyga> noizer: by default it tries to talk to a VM running localy
<zyga> locally
<noizer> ok that worked
<zyga> noizer: now you can add an i2c skill using:
<noizer> the snap file where is it on my rpi2?
<zyga> noizer: in ~/
<noizer> because you said I need to do sudo ./snap
<zyga> noizer: in the home directory of the ubuntu user
<noizer> ooh ok xD
<zyga> noizer: refresh bits copies it
<noizer> ist need to be in /home/ubuntu?
<zyga> noizer: ?
<noizer> the snap file to execute ./snap
<noizer> on my rpi2
<zyga> noizer: if it's not then refresh-bits didn't work
<zyga> noizer: read the code of refresh bits
<zyga> noizer: it just copies it there
<zyga> sudo ./snap experimental add-skill ubuntu-core i2c i2c --label="I2C controller" -a device=i2c-1
<zyga> noizer: ^^ this should add the i2c skill to the ubuntu-core snap
<zyga> noizer: now you need something that wants to use this skill
<zyga> noizer: ping me with more details once you have that
<noizer> zyga just it wont copy it http://pastebin.com/Fus2JEH0
<zyga> noizer: you have to use --pi2 with other arguments
<zyga> noizer: ./refresh-bits.sh --pi2 snap snappy snapd setup run-snapd
<zyga> noizer: :)
<noizer> haha fail fromme xD
<noizer> weird he does not find go
<zyga> mvo, fgimenez: do you think that https://github.com/ubuntu-core/snappy/pull/478 failure is related to the change in the branch or is that some kind of fluke
<fgimenez> zyga, mvo it seems to be the same as http://pastebin.ubuntu.com/15126149/, not related to the changes in the branch IMO
<zyga> fgimenez: thanks
<mvo> fgimenez: aha, thanks
<fgimenez> mvo, zyga i'll try to check if the sync call before installing the snaps mitigates it, otherwise i'm totally lost with this one, no idea where can it come from
<zyga> fgimenez: I wonder how two other branches I refreshed at the same time made it
<zyga> fgimenez: maybe one of the jenkins slaves is just odd
<zyga> fgimenez: integration tests passed elsewhere
<noizer> zyga got the following error :s http://pastebin.com/W5QyLwru
<fgimenez> zyga, yes it's random, in fact the tests are executed in pristine cloud instances, they should be the same for all the executions, the slaves are not involved in the results once the testbeds are up
<zyga> fgimenez: then I have no idea what might be the cause
<zyga> noizer: you need to install cross toolchain: https://github.com/ubuntu-core/snappy/blob/master/docs/cross-build.md
<zyga> noizer: just the sudo parts there, the rest is handled by the script
<fgimenez> zyga, we have also this one http://paste.ubuntu.com/15169442/ which is randomly failing too, maybe they are related, both fail trying to install a snap from the filesystem, one of them doesn't find snap.yaml and the other find it full of '\x00'
<zyga> mmmm
<zyga> maybe a race that's unfortunate somewhere
<zyga> fgimenez: how long have you been seeing those?
<fgimenez> zyga, since last thursday i think
<beuno> jdstrand, ack, will do
<pindonga> jdstrand, hi there.. I'll do the deploy today
<noizer> zyga ok everything is done xD
<noizer> So now I can acces and read the value of my gpio?
<noizer> zyga can i use snapcraft then again for building my snap with you skill?
<zyga> noizer: you can build a snap but don't use the skills syntax yet, it's not allowed for now, you can just add the skill (and skill slot) after the snap is installed
<zyga> noizer: please look at the bool-file skill
<zyga> noizer: snap experimental add-skill
<zyga> the skill can live on the ubuntu-core snap, it's not important
<zyga> noizer: the skill slot (the thing that actually uses it) needs to be on your snap
<zyga> noizer: that's snap experimental add-skill-slot
<zyga> noizer: bool-file needs the "path" attribute -a path=/sys/class/gpio/gpio123/value
<zyga> noizer: then you need to grant the skill (snap grant)
<zyga> noizer: and then snap experimental apply-skill-security
<zyga> noizer: then you can inspect the state of the system
<zyga> noizer: more in a moment
<ysionneau> http://pastebin.com/yPELZ2Bi < any idea why I get an error on this package.yaml?
<ysionneau> (I'm using snapcraft 1.0.2, snappy 15.04)
<zyga> ysionneau: looks like last line needs to change
<zyga> I don't remember the 15.04 syntax though
<zyga> look at some examples from snapcraft sources
<ysionneau> yes that's what I did
<ysionneau> http://bazaar.launchpad.net/~snappy-dev/snappy-hub/snappy-examples/view/83/hello-world/meta/package.yaml
<ysionneau> but, I kind of get it now
<ysionneau> those file need to exist before building?
<ysionneau> how can I do the same for binaries generated by the build?
<zyga> no, they don't have to exist, I think
<zyga> ysionneau: notice that there "binaries" is a list of objects
<zyga> ysionneau: so try "- hello:\n\tname: hello"
<zyga> ysionneau: so that "hello" is the binary
<ysionneau> hummm :o
<ysionneau> you mean
<ysionneau> binaries:\n\tname: hello
<ysionneau> ?
<zyga> no
<zyga> try what I said
<zyga> biaries:
<zyga>   - hello:
<zyga>     name: hello
<zyga> (perhaps more indent)
<ysionneau> Issues while validating snapcraft.yaml: [{'hello': None, 'name': 'hello'}] is not of type 'object'
<zyga> the error you got was essentially that your binary was not a python dict, you have to make the yaml look right, so that each binary is a python dict/javascript/json object
<ysionneau> oh
<zyga> can you pastebin the snapcraft yaml again
<ysionneau> yes
<ysionneau> http://pastebin.com/mkU1nFXc
<zyga> hmmm
<zyga> maybe the syntax changed again, ask sergio when he's around
<ysionneau> ack
<ysionneau> thanks! :)
<zyga> I know how it works in 16.04
<zyga> I don't remember 15.04
<ysionneau> no problem
<zyga> (BTW: Try 16.04 instead if you can)
<ysionneau> for now I prefer to stay on 15.04
<noizer> zyga I've build my snap again. but now how can i add the skill to it?
<zyga> noizer: currently only at runtime, I'm working on reading those from the snap.yaml file
<zyga> noizer: have a look at some of my notes for a quick idea:
<zyga> # Add skills, grant and apply
<zyga> sudo ./snap experimental add-skill ubuntu-core i2c i2c --label="I2C controller" -a device=i2c-1
<zyga> sudo ./snap experimental add-skill-slot pi2-piglow i2c i2c --label="I2C controller connected to piglow" --app=foreground --app=background
<zyga> sudo ./snap grant ubuntu-core:i2c pi2-piglow:i2c
<zyga> sudo ./snap experimental apply-skill-security pi2-piglow
<zyga> noizer: this works with this snap: http://github.com/zyga/snappy-pi2-piglow
<noizer> ok thx
<zyga> noizer: explore each of those commands with --help to understand what's going on
<noizer> ok
<zyga> noizer: you can also fetch the code of that snap I just linked to, enable classic mode on your pi, install git and snapcraft and build it there
<zyga> noizer: the snap is specific to piglow but the parts that deal with i2c are generic
<zyga> noizer: and you should be able to see what's going on
<zyga> noizer: note that in my branch, skills are not persistent yet so after you reboot the device they are gone
<zyga> noizer: but apply-skill-security is persistent
<zyga> noizer: though this will all change to just work as soon as some prerequisites land in 16.04
<zyga> noizer: so all the hackery won't be needed
<noizer> ok first i will try it with my snap ist just checking the value's from the gpio's
<jdstrand> sergiusens: hi! I was going to attach a suggested diff to bug #1546821, but see you may be working on it already. here is what I was thinking: http://paste.ubuntu.com/15182501/
<ubottu> bug 1546821 in Snapcraft "please add -all-root and -no-xattrs to mksquashfs options" [Wishlist,Triaged] https://launchpad.net/bugs/1546821
<jdstrand> sergiusens: adjust as necessary and thanks for working on it
<jdstrand> sergiusens: I've got a review tools update that will require squashes be created in this manner that I'll what on until there is a new snapcraft
<jdstrand> s/what/wait/
<sergiusens> jdstrand, thanks! the -all-root I have been procastinating on, you just pushed me to get it done ;-)
<jdstrand> :)
<sergiusens> jdstrand, https://github.com/ubuntu-core/snapcraft/pull/334
<jdstrand> thanks
<jdstrand> pindonga: hey, so, fyi, r594 and below is ok to pull. r595 you can pull, but the tools will add a 'warn'ing until the machine running the tools has a squashfs-tools that supports -fstime
<pindonga> jdstrand, I bumped to 592 today
<jdstrand> ok that's fine
<pindonga> but deploy didn'th appen yet
<pindonga> bc no webops coverage
<pindonga> so might happen tomorrow
<pindonga> I can bump to 594/5 if you like
<jdstrand> pindonga: but that brings up the question-- how do we get an updated squashfs-tools on the system running review tools?
<jdstrand> pindonga: (593 and 594 aren't worth an update, they can come with 595+)
<pindonga> it should be picked up automatically during the next rollout I believe, bc afaict we don't have it pinned
<pindonga> but follow whatever's there in the distro
<jdstrand> pindonga: what is that machine running? 14.04?
<pindonga> yep
<pindonga> and will do so for the foreseeable future
<jdstrand> sure
<pindonga> :)
<jdstrand> pindonga: does it pull from any other sources?
<pindonga> deb source?
<sergiusens> elopio, you might need to rebase https://github.com/ubuntu-core/snapcraft/pull/326
<jdstrand> trying to decide if I need to do an SRU or if this can be an internal thing
<pindonga> jdstrand, I think we can have some cat
<pindonga> repo
<jdstrand> pindonga: no, like internal IS archives
<pindonga> jdstrand, right, so a trusty-cat should work right?
<pindonga> jdstrand, let's get 592 out of the way first (bc the changeset is quite big already)
<jdstrand> pindonga: that is what I was thinking, but I've not done this sort of thing
<jdstrand> pindonga: yes, please push 592 outside of this
<pindonga> and then we'll see how to get squashfs-tools updated + newer revnos
<pindonga> but I think trusty-cat should work
<jdstrand> ok, let me talk to some folks
<jdstrand> and I'll see how I can get a trusty-cat going
<pindonga> jdstrand, ok, yes, we got trusty-cat available
<pindonga> so if you can land there, it should be "easy" to get it installed
<jdstrand> ok, thanks. talking to IS
<pindonga> jdstrand, which version do we need?
<sergiusens> jdstrand, I can swear I saw a comment from you here https://github.com/ubuntu-core/snapcraft/pull/334
<sergiusens> camako, https://bugs.launchpad.net/snapcraft/+bug/1541620/comments/4
<ubottu> Launchpad bug 1541620 in Snapcraft "snapcraft can't find modules installed under 'stage' dir" [Medium,Triaged]
<sergiusens> camako, sorry for taking so long; but it seems you are just missing a stage-package in there
<sergiusens> camako, also, this may mean the server needs a dep against the client-dev
<jdstrand> sergiusens: I did make one :)
<jdstrand> I don't know where it went...
<jdstrand> I re-acked it just now
<jdstrand> pindonga: ok, based on conversations with is, I'm pursuing an SRU. I'd probably want to anyway so this seems fastest overall.
<jdstrand> pindonga: fyi, bug #1548988
<ubottu> bug 1548988 in squashfs-tools (Ubuntu Trusty) "please add -fstime patch for snap v2 checks in review tools" [Undecided,In progress] https://launchpad.net/bugs/1548988
#snappy 2016-02-24
<dholbach> good morning
<zyga> good morning
<noizer> good morning
<noizer> zyga Hi i can read the value but not set my value of my gpio
<zyga> noizer: GPIO is not bi-directional, it is either output or input
<zyga> noizer: what are you talking to?
<zyga> noizer: what hardware is on the other end?
<noizer> just a led
<noizer> for starting
<noizer> zyga
<zyga> noizer: well, nothing to read then
<zyga> noizer: you don't want GPIO to do bidirectional communication
<zyga> noizer: good luck
<noizer> but its handy if you can read from it and write to it
<noizer> can i set every gpio his permissions?
<noizer> zyga
<crestcore> Hi
<crestcore> How to install Java on Ubuntu Core?
<zyga> noizer: hmn?
<zyga> noizer: can you ask that again please
<zyga> crestcore: you don't, you can put java into your snap if your application requires it
<zyga> crestcore: there are examples that do just that
<zyga> crestcore: then you can use any version of java
<zyga> crestcore: and your application will always have the java you want
<crestcore> okay
<zyga> crestcore: while other snaps may bundle other versions and you don't conflict
<zyga> crestcore: have a look at snapcraft-examples
<noizer> is it possible to set the gpio's with you skill?
<zyga> noizer: yes
<zyga> noizer: though only as output
<zyga> noizer: I'll add a full-feature GPIO later that has direction and event triggering
<zyga> noizer: having a working example is useful
<zyga> noizer: though I'm working on that as well
<noizer> ok but for now it is only reading from the gpio?
<crestcore> We want to have our java application on Local system
<crestcore> HI Zyga
<zyga> crestcore: you can put your java app along with some version of jre into a snap
<zyga> crestcore: and you will have a standlone snap
<zyga> noizer: yes, for now you can only read
<zyga> noizer: er
<zyga> noizer: WRITE
<zyga> noizer: bool-file allows you to write to gpio's
<zyga> noizer: you can add a skill of type bool-file
<zyga> noizer: with the path attribute pointing to /sys/class/gpio/gpioN/value
<zyga> noizer: you have to export it manually for now (echo N >  /sys/class/gpio/export)
<zyga> noizer: but it works
<crestcore> can we put snap on a local gateway and access from there
<zyga> crestcore: yes
<crestcore> okay
<crestcore> can you please suggest a very small foot print linux where we can install java like we do with headless ubuntu 14.04
<noizer> zyga So the best I think is wait until the write part is ready in your skill
<zyga> no, the write part is ready
<zyga> the read part is not
<noizer> ooooh ok xD
<noizer> wait i will send you some code what i do for setting my  gpio
<noizer> http://pastebin.com/mRagY6Bs
<crestcoredev> hi zyga
<crestcoredev> i have installed ubuntu snappy on a Intel NUC and i want to run a java web application.
<crestcoredev> can anyone suggest me how to install java jre7
<zyga> crestcoredev, crestcore: please look at snapcraft examples
<zyga> java is not installed
<zyga> you put java into a snap that contains your application
<zyga> and install that snap
<zyga> then your application can work
<crestcoredev> okay
<zyga> https://github.com/ubuntu-core/snapcraft/tree/master/examples/java-hello-world
<zyga> note that you need to use xenial (ubuntu 16.04)
<zyga> and snapcraft 2.x
<zyga> for this example
<crestcoredev> is there a small foot print linux where i can install java jre7 package?
<zyga> crestcoredev: snappy, you don't want to install java, you don't run java, you run apps that just happen to need java
<zyga> crestcoredev: the whole system will be tiny, consisting of basic kernel and userspace and your app
<zyga> crestcoredev: snappy updates separately from your app
<zyga> crestcoredev: just try it
<crestcore> okay thanks, we will try
<crestcoredev> after installing the app will the app work without internet connection?
<dholbach> kyrofa, sergiusens: can you debug https://bugs.launchpad.net/snapcraft/+bug/1548376 with BjÃ¶rn?
<ubottu> Launchpad bug 1548376 in Snapcraft "docs/snapcraft-syntax.md should explicitly name the conditions under which a file is expected to end up in stage/ and snap/" [Undecided,New]
<zyga> crestcoredev: internet is only required if you want to update the core os
<zyga> crestcoredev: or your app
<crestcoredev> okay
<zyga> crestcoredev: for development I recommend a 16.04 image running in kvm
<zyga> crestcoredev: (snappy image)
<zyga> crestcoredev: you can then use classic dimension to build and develop your app right inside snappy
<zyga> crestcoredev: classic dimension is like having regular ubuntu inside snappy
<zyga> crestcoredev: with apt-get and everything
<crestcoredev> is there a core linux where i can deploy a web application build using spring and hibernate
<zyga> crestcoredev:
<zyga> crestcoredev: ?
<zyga> crestcoredev: snappy
<zyga> crestcoredev: you ask on a snappy channel, the answer is snappy
<zyga> crestcoredev: because snappy can run any type of application
<crestcoredev> :)
<zyga> crestcoredev: https://github.com/zyga/devtools/blob/master/ubuntu-image
<zyga> crestcoredev: run this script to build a x86_64 image for development
<zyga> crestcoredev: everything you will need you can then add frmo the inside
<zyga> crestcoredev: https://github.com/zyga/devtools/blob/master/run-devel-vm
<zyga> crestcoredev: you can use this to run a VM
<zyga> crestcoredev: though NOTE that it DISCARDS the state of the VM after poweroff
<zyga> crestcoredev: you can remove the "-snapshot" option from the code to keep all of the state
 * zyga thinks about having persistent VMs as an interesting option for some class of development
<crestcoredev> is there a tutorial to build snap app?
<zyga> dholbach: ^^ ?
<dholbach> crestcoredev, if you follow the docs at https://github.com/ubuntu-core/snapcraft/blob/master/docs/intro.md - there's a couple of tutorials in there
<dholbach> we will move the docs above to developer.u.c today
<crestcoredev> okay ty
<zyga> woot, thanks dholbach
 * zyga also found http://developer.ubuntu.com/en/snappy/start/
<zyga> but I don't know if it talks about 16.04 or 15.04 (you really really want 16.04)
<dholbach> zyga, yes, please use the docs on github for now
<dholbach> I'll let you all know once we're done
<zyga> dholbach: cool, thanks for the tip
<noizer> zyga did you had time to look at the code?
<noizer> the export and the setdirection is set before that
<zyga> noizer: it's complicated, I know about this very well
<zyga> noizer: it's about what is available out of the box on a device
<zyga> noizer: I'll add a full GPIO skill in my branch today
<ysionneau> say when building my snapcraft.yaml package I generate parts/<pkgname>/install/usr/bin/some_binary. What do I need to declare in the snapcraft.yaml?
<zyga> noizer: that has a way to set direction too
<ysionneau> so that the some_binary can be launched in the sandboxed environment ?
<zyga> noizer: I'm also working on integrating bits from the demo branch to master
<noizer> ok I will wait then until you are ready xD
<ysionneau> (using 15.04 snapcraft.yaml syntax)
<zyga> ysionneau: an "app" of any name that has a command that runs "some_binary"
<noizer> with the next version zyga
<zyga> ysionneau: look at snapcraft examples please
<zyga> noizer: ok
<noizer> zyga thx
<zyga> ysionneau: https://github.com/ubuntu-core/snapcraft/blob/master/examples/mosquitto/snapcraft.yaml#L11
<zyga> ysionneau: look at the syntax there
<ysionneau> thanks!
<zyga> ysionneau: you can also pass arguments to your command
<zyga> ysionneau: e.g. I have a snap that uses the same binary twice: https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml#L10
<ysionneau> ok, interesting!
<ysionneau> so now that I created an apps, how can I run it?
<zyga> ysionneau: install it
<zyga> ysionneau: the executable name is $snap.$app
<ysionneau> ok, something went wrong then, I don't have it :/
<zyga> ysionneau: if "snappy list" shows it
<zyga> then look at /snaps/
<zyga> and expore
<zyga> and pastebin the snapcraft log, maybe there's something there
<zyga> ysionneau: actual excutable wrappers are in /snaps/bin
<ysionneau> hmm I don't have /snaps
<zyga> ysionneau: which image are you running?
<zyga> ysionneau: I strongly recommend a 16.04 image
<ysionneau> I'm running 15.04 rpi2
<ysionneau> http://pastebin.com/X9t6Et1b < my building the package
<zyga> ysionneau: 15.04 is quite different and all the instruction given so far are for 16.04
<ysionneau> allright
<zyga> ysionneau: i'd recommend you to reflash to a 16.04 image built with https://github.com/zyga/devtools/blob/master/ubuntu-image
<ysionneau> I'd prefer using 15.04 for now
<ysionneau> which is the version for which everything is documented on the web
<zyga> ysionneau: the syntax for 15.04 is different
<zyga> ysionneau: so follow that please
<zyga> ysionneau: and for 15.04 you cannot use xenial, you need older ubuntu and older snapcraft
<zyga> ysionneau: snapcraft 1.x series
<ysionneau> as a host I'm also using ubuntu 15.04 and I use snapcraft 1.0.2 (modified, to add my alchemy plugin)
<zyga> k
<ysionneau> I'm following this https://developer.ubuntu.com/en/snappy/guides/packaging-format-apps/
<ysionneau> to add binaries: exec etc
<Chipaca`> matiasb, are you around?
<davidcalle> dholbach, what about a hangout at 2pm for the doc plan?
<ysionneau> zyga: here is my new snapcraft.yaml and the error message I get : http://pastebin.com/psMCFYxb
<zyga> ysionneau: the syntax is not quite right, ask sergiusens about 15.04 variant for apps
<zyga> sergiusens: ^^
<ysionneau> so maybe the documentation needs updating?
<zyga> (sorry, I don't remember the older syntax now)
<ysionneau> no problem
 * ysionneau waves at sergiusens 
<zyga> ysionneau: I think the docs will reflect 16.04 soon
<ysionneau> or maybe asac you there?
<ysionneau> I had a look at the nethack package yaml that is installed on my rpi2 image via cat /apps/nethack-armhf.ogra/current/meta/package.yaml
<ysionneau> and it looks very similar to what I've done :(
<zyga> ysionneau: can you pastebtin that quickly
<zyga> ysionneau: yours failed because snapcraft found a list of objects where it expected an object
<zyga> ysionneau: perhaps you need to have foo: details of foo app/binary rather than - foo: details of foo
<ysionneau> http://pastebin.com/BBaVEhBb
<ysionneau> and my updated snapcraft.yaml http://pastebin.com/rwknkXQv
<ysionneau> err
<ysionneau> what have I done
<ysionneau> this makes no sense...
<zyga> no idea :)
<zyga> sorry
<ysionneau> makes more sense this way but still no luck http://pastebin.com/7wPTz2Jq
<ysionneau> (I switched name/exec value)
<dholbach> davidcalle, wfm... or maybe a few minutes after that
<davidcalle> dholbach: sure
<crestcore> Hi Zyga
<crestcore> How do we connect to serial port in snappy? Is there option an like terminal?
<crestcore> We were able to do pretty easy with Ubuntu LTS
<crestcore> How do we connect to serial port in snappy? Is there option an like terminal?
<matiasb> Chipaca`, o/
<crestcore> How do we connect to serial port in snappy? Is there option an like terminal?
<popey> Does anyone have an example of a snap which pulls from github and builds locally?
<dholbach> davidcalle, 1400 should be good
<crestcore> How do we connect to serial port in snappy? Is there option an like terminal?
<dholbach> davidcalle, let me know when you're free
<davidcalle> dholbach: https://plus.google.com/hangouts/_/canonical.com/daniel-holbach :)
<ysionneau> zyga: fyi the correct syntax is: http://pastebin.com/6QmC0uvE
<ysionneau> now it works :)
<zyga> ysionneau: thanks
<zyga> looking
<zyga> ysionneau: yay, so just no lists
<zyga> ysionneau: it seems the old doc was just wrong
<crestcore> How do we connect to serial port in snappy? Is there option an like terminal?
<dholbach> davidcalle, I just encountered a bug in the link replacement - I'll work on fixing it
<jdstrand> kyrofa: https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1467595/comments/28 :\
<ubottu> Launchpad bug 1467595 in xorg (Ubuntu) "cursor sometimes disappears on XPS 13 9343 and external monitor" [High,Confirmed]
<ysionneau> is there a documentation of the different "caps" available?
<crestcore> How do we connect to serial port in snappy? Is there option an like terminal?
<davidcalle> dholbach: what was it?
<dholbach> davidcalle, I had a   <a href="bla.md">   in there
<dholbach> still debugging it
<davidcalle> dholbach: I'm re-adding the image to build-apps/
<dholbach> davidcalle, ok... let's do that for now -it will get overwritten on import again though
<davidcalle> dholbach: indeed, but we'll need to have a way to special case the page though, it's seven-col instead of eight-col + the image. We'll find a way to fix it in md maybe.
 * dholbach twitches :)
<davidcalle> :)
<dholbach> maybe it'd be easier to use the image from https://github.com/ubuntu-core/snapcraft in intro.md directly?
<davidcalle> dholbach: but of course, all the special cases we need we'll be clearly defined in a branch somewhere and merged at import step. :p
<dholbach> I'm close to calling you the biggest troll in the channel, but deep down in my heart I know that that's a solution we're going to seriously consider
<davidcalle> dholbach: :) +1 on using the other graph /me changes
<davidcalle> dholbach: WFM ->  https://developer.ubuntu.com/en/snappy/build-apps
<dholbach> <3
<zyga> crestcore: do you want to write an app that talks to a serial port that runs on snappy?
<timeax> Hi peoples :)
<timeax> Is there somebody expert in portings of ubuntu touch?
<crestcore> Zyga, yes we do
<dholbach> davidcalle, I fixed a number of small things, but still can't reproduce the breakage I see in the live system after an import in the test
<zyga> crestcore: you can do that with my skill system
<dholbach> timeax, if you are after porting Ubuntu touch to another phone, I'd suggest asking in #ubuntu-touch
<zyga> crestcore: (which just got renamed to the "interface" system)
<zyga> crestcore: I actually started working on a small demo snap that just looks at the serial port and logs what it gets
<crestcore> okay
<zyga> crestcore: so if you have heard about skills, nothing has changed since, there are some new names for existing concepts
<zyga> crestcore: I myself may confuse them at times
<zyga> crestcore: the way this works is that you will write a snap that will have a "slot" where the snappy system will connect a "plug"
<crestcore> where do we refer skills?
<zyga> crestcore: and that plug will be of inteface, say "serial-port"
<zyga> crestcore: your app will just look at what it got, the user may plug any of the available serial ports there
<zyga> crestcore: you declare this in your snap.yam
<zyga> crestcore: or in your snapcraft.yaml to be precise
<zyga> crestcore: right now that is _not_ available in the master builds so you'll have to work with some more bleeding edge code
<popey> timeax: ubuntu touch is discussed in #ubuntu-touch
<zyga> crestcore: I have a branch that you can push onto your development device (just replacing snap, snapd and snappy)
<popey> timeax: oh, my bad, you found someone :)
<zyga> crestcore: that has all the extra logic
<zyga> crestcore: I can help you out but actually now is not the best moment for this, I'd prefer to finish something I'm in the middle of
<zyga> crestcore: write the demo serial-port snap
<zyga> crestcore: and share that
<timeax> Dholbach tnx i already done,them told me that i could find some experts in this channel
<crestcore> ok
<zyga> crestcore: this way many people can refer to it
<zyga> crestcore: what you can do now is this:
<zyga> crestcore: write your app to be able to do two things:
<dholbach> timeax, all the phone people are hanging out there
<zyga> crestcore: assume you get told where the serial port is
<zyga> crestcore: so don't hardcode /dev/tty-something
<zyga> crestcore: make that something you can set
<timeax> Tnx a lot anyway guys :)
<dholbach> popey, http://paste.ubuntu.com/15188088/
<zyga> crestcore: and assume you have a hook in your snap, that when the serial port is determined, that hook gets ran
<zyga> crestcore: now you can do anything you want in your hook, just write to a config file you read, or something similar
<popey> thanks dholbach
<zyga> crestcore: at that time, your app will have permissions to actually open and work with the serial port
<zyga> crestcore: so for now, you can just hack on your app, write 99% of the code needed
<zyga> crestcore: and we can help you interface with snappy wrt to the hook and particular snapcraft.yam syntax needed
<zyga> crestcore: and while you wait, you can use hw-assign to grant the permission to your snap
<zyga> crestcore: or you can just run it from the shell, without confinement applied
<zyga> crestcore: and very little will change later when all the bits are in place
<zyga> crestcore: does that sound sensible?
<crestcore> Yes it does, we will try this and update you
<zyga> crestcore: cool, stay in touch
<crestcore> can i have your email address pl
<zyga> crestcore: my name is zygmunt krynicki, you can check me out on github.com/zyga or launchpad.net/~zyga
<zyga> crestcore: but I'd rather just talk here
<zyga> crestcore: unless your topics are private
<ysionneau> I've created a service, but it fails to start, even though I can run the wrapper manually: http://pastebin.com/NvXdzVt2
<crestcore> okay
<ysionneau> any idea?
<zyga> ysionneau: 2016-02-24T15:47:09.100526Z ubuntu-core-launcher /apps/ulogcatd.sideload/INPIOCNWfAUN/ulogcatd.ulogcat.wrapper: 5: exec: ulogcatd.ulogcat: not found
<ysionneau> yes I saw that
<zyga> ysionneau: ulogcatd.ulogcat is not in your snap perhaps
<ysionneau> but running the wrapper works
<zyga> ysionneau: investigate that
<zyga> oh?
<ysionneau> and running ulogcatd.ulogcat by hand works also
<zyga> ysionneau: if that's on 15.04 I cannot help you, I just don't know 15.04 that well
<ysionneau> yes still on 15.04
<zyga> ysionneau: (do move to 16.04 so that your snap can work on 16.04 if you can, it's far easier to focus on 16.04 for us now)
<zyga> ysionneau: or perhaps ask someone else for help
<ysionneau> I'll try to see if what I did so far also works on 16.04
<zyga> ysionneau: it should with minimal snapcraft.yaml changes
<zyga> ysionneau: and I can actually help you out with that
<ysionneau> :)
<ysionneau> let's see how it goes, I'm using your ubuntu-image tool
<zyga> cool :)
<ysionneau> I had to re-run it cause I got a "unexpected EOF" for the first run
<zyga> oh?
<ysionneau> during the 2nd download
<zyga> maybe just network fluke
<zyga> but if you can, pastebin the log
<zyga> maybe a bug that's hiding there
<ysionneau> not much in the logs :/
<ysionneau> well, by log you mean standard output ?
<zyga> can you paste the single error line?
<zyga> yes
<ysionneau> http://pastebin.com/eZM14ziN
<zyga> Thanks
<zyga> seem like a network fluke in ubuntu-device-flash inside
<ysionneau> probably yes
<sergiusens> elopio, hello, I am back! but hungry
 * zyga pushed new version of github.com/zyga/devtools with official support for the dragon board
<ysionneau> zyga: http://pastebin.com/GW7CmyT5 I got this, was I supposed to generate an ssh key for the root user?
<zyga> ysionneau: no, for your normal user
<zyga> ysionneau: don't run anything as sudo, the tool uses sudo where it has to
<zyga> ysionneau: if you have an ssh key on this machine it should work
<ysionneau> I didn't run as sudo
<zyga> ysionneau: the fact that it looked at /root is odd
<ysionneau> I have one
<zyga> ysionneau: so how did you run it?
<zyga> ysionneau: maybe your environment is different than mine in some important way
<ysionneau> I did ./ubuntu-image as my normal user
<ysionneau> but your script runs udf as sudo
<zyga> right
<zyga> but sudo keeps HOME intact
<zyga> what is the host OS you use?
<ysionneau> Debian Testing
<zyga> ah
<zyga> hmm, perhaps there are some differences in sudo
<zyga> at least in sudo configuation
<zyga> can you run sudo env | grep HOME
<ysionneau> yes it prints /root
<ysionneau> weird
<ysionneau> I'll add Defaults env_keep += HOME to my sudoer file
<zyga> ysionneau: I think that's a well-known delta
<ysionneau> ok now sudo env | grep HOME returns my user's home
<zyga> ysionneau: I can probably patch that with my sudo call
<zyga> hmm, there's no way to do that sadly
<zyga> ysionneau: well, anyway, not it should work
<ysionneau> yes it should work now, I re-run :)
<ysionneau> thanks
<ysionneau> ubuntu-core failed to install: received an unexpected http response code (500) when trying to download https://public.apps.ubuntu.com/anon/download/canonical/ubuntu-core.canonical/ubuntu-core.canonical_16.04.0-10.armhf_armhf.snap
<ysionneau> :/
<zyga> ysionneau: I hear that some server issues are happening now
<zyga> ysionneau: just keep trying a few times
<mvo> ysionneau: it looks like there is a hickup currently, I forwarded this problem report
<ysionneau> ok thanks =)
<ysionneau> New image complete \o/
<sergiusens> ogra_,  about generic initrd; how did your landing go? mvo and me are just discussing that in the "other" room
<zyga> ysionneau: cool
<jdstrand> zyga: hey, looking at the new interfaces doc-- on Migration from 15.04 it specifies:
<jdstrand> slots:
<jdstrand>   old-security:
<jdstrand>     caps:
<jdstrand>      ...
<jdstrand> zyga: 'old-security' there is still the slot reference, yes? or did migration-skill move to old-security and old-security is the new type?
<jdstrand> niemeyer: ^
 * jdstrand is updating the review tools to move from skills to interfaces
<jdstrand> basically, what I really want to know: is migration-skill now simply known as old-security (for the type)
<zyga> jdstrand: hey
<zyga> jdstrand: yes, old-security is the new name of the type (interface)
 * jdstrand thinks that is the case comparing the Complete syntax from skills and interfaces
<jdstrand> ok, good
<zyga> jdstrand: so apart from the rename, nothing much changes
<jdstrand> for a moment I panicked a little but it seems like just renames of the various keys
<zyga> yep
<zyga> there's a tiny change to the REST apis but I'll deal with that
<jdstrand> niemeyer: nm
<niemeyer> jdstrand: Right, it's just a rename of syntax
<niemeyer> jdstrand: Same thing behind it
<ysionneau> zyga: maybe it's new in 16.04 but is it normal the image generated by your script only contains 2 partitions? a fat32 and an ext3 ?
<ysionneau> instead of 2 ext3 systems + 1 ext3 /writable
<ysionneau> (+ 1 boot)
<ysionneau> for rpi2
<pindonga> jdstrand, fyi: crt 592 on prod
<jdstrand> pindonga: woo!
<jdstrand> pindonga: thanks :)
<pindonga> jdstrand, we'll push tip as soon as we can next
<jdstrand> sergiusens, zyga: what is the timeline for snapcraft and snappy's migration to skills?
<pindonga> so it's ready for the updated squashfs tools
<jdstrand> pindonga: sounds great
<jdstrand> sergiusens, zyga: (I'm preparing a branch for the review tools)
<sergiusens> jdstrand, skills are already part of snapcraft ;-)
<jdstrand> pindonga: fyi, there will be one more pull for the skills to interfaces change, but I won't request it until after the above
<jdstrand> sergiusens, zyga: err, migration to interfaces
<zyga> ysionneau: yes, that's normal
<zyga> ysionneau: that's the simplified partition layout
 * zyga breaks for the evening, see you tomorrow
<sergiusens> jdstrand, I don't have a timeline, kenel snap is on my prio list
<jdstrand> beuno: hey, who is implementing 'snappy try'?
<beuno> jdstrand, we'll find out soon!
<jdstrand> heh, ok
<beuno> mvo is usually the primary candidate, but he has too much on his plate I think
 * jdstrand nods
<jdstrand> there are some bits I need to be involved with-- this is in the card already, but I want to make sure we work together
<sergiusens> elopio, can you easily find the qemu-arm-static bug that affects this https://bugs.launchpad.net/snapcraft/+bug/1544763 ?
<ubottu> Launchpad bug 1544763 in Snapcraft "fatal error creating a snap" [Undecided,New]
<sergiusens> elopio, found it
#snappy 2016-02-25
<dyfi> Hello; is there anybody here who is familiar with loading a Snappy image on to the Beaglebone Black?
<aatchison> Hey guys. Energies severely depleted over here. I just had a crazy idea. Tensor flow on snappy?
<aatchison> Also, random question. Does Snappy deploy well with JuJu?
<dholbach> good morning
<ysionneau> morning
<zyga> good morning
<noizer> good morning
<zyga> hey ysionneau, noizer :)
<zyga> have you read about the skills rename?
<ysionneau> skills rename ?
<noizer> no
<noizer> was it send in the mailing?
<zyga> https://lists.ubuntu.com/archives/snappy-devel/2016-February/001501.html
<zyga> yep
<zyga> it's just a new name, nothing has changed
<ysionneau> ah yes I had this email
<ysionneau> zyga: would you know what is supposed to be the init= cmdline for the rpi2 snappy 16.04 ?
<ysionneau> (image generated with your tool)
<ysionneau> ah found it, it's in snappy-system.txt
<zyga> ysionneau: no but I guess you just found out :)
<ysionneau> yep!
<ysionneau> I'm trying to boot your rpi2 image using qemu
<ysionneau> so far I'm KO
<ysionneau> it boots the kernel, initrd "works", and then "No init found. Try passing init= bootarg."
<ysionneau> (I do pass the init=)
<zyga> ysionneau: I don't think qemu will boot it
<zyga> ysionneau: initrd is the OS snap btw
<noizer> zyga are the interface then for sharing libs
<noizer> ?
<zyga> noizer: nope
<noizer> ok
 * zyga needs to update https://wiki.ubuntu.com/SnappyHackerUsefulLinkCollection
<zyga> help wanted ^^
<noizer> zyga is snappy an 64bit system?
<zyga> noizer: snappy works on 32 and 64 bit systems
<zyga> noizer: we have official images for x86, amd64, arm v7 hard float and aarch64 (or arm64)
<noizer> do you have images for soft float?
<noizer> the image on the rpi is that an 64 bit systme?
<noizer> zyga
<zyga> noizer: raspberry pi 2 is 32 bit, hard float
<noizer> zyga ok thx
<zyga> noizer: we don't support ARMv6 (soft float)
<noizer> zyga ok
<ysionneau> zyga: I was able to boot the rpi2  15.04 image on qemu
<ysionneau> but not as a rpi2 board but as a generic arm64 board with my own arm64 kernel
<ysionneau> but except the kernel+modules it was the vanilla 15.04 rpi2 image running in my qemu
<ysionneau> that's where I do all my tests so far
<ysionneau> I'm trying to replicate this setup with your 16.04 image
<ysionneau> it seems that the initramfs does not mount the squashfs (the snaps) since the systemd init is not found...
<ysionneau> oh, seems I need to put snappy_os= and snappy_kernel= on the cmdline
<zyga> ysionneau: I'd suggest, if you want to continue down this path, is to build a new kernel snap
<zyga> ysionneau: that's specifically intended to work with qemu
<zyga> ysionneau: you can reuse the os snap as-is
<zyga> ysionneau: you can fine-tune the kernel snap
<zyga> ysionneau: and you will absolutely need a gadget snap that's not pi2
<zyga> ysionneau: I think that would be a fanstastic thing to have
<zyga> ysionneau: just one question, why aarch64 kerenl rather than armhf?
<ysionneau> 10:54 < zyga> ysionneau: I'd suggest, if you want to continue down this path, is to build a new kernel snap < yes I have my own arm64 kernel (which worked fine with 15.04)
<ysionneau> not sure if I need a snap since there is no bootloader involved, qemu boots the kernel directly as I pass it to -kernel cmdline arg
<ysionneau> (a snap for the kernel I mean)
<zyga> ysionneau: 10:43 < ysionneau> but not as a rpi2 board but as a generic arm64 board with my own arm64 kernel
<zyga> ysionneau: you used a different kernel
<zyga> ysionneau: you really need a different kernel snap
<ysionneau> allright, maybe I should start by asking: what's a kernel snap?
<zyga> ysionneau: a snap that has the kenrel, modules and bootloader
<zyga> ysionneau: that snappy mounts from the bootloader
<ysionneau> here I don't use any bootloader
<zyga> ysionneau: and loads the kernel from the mounted snap
<ysionneau> since I boot the kernel directly from qemu
<zyga> ysionneau: right but that will break varius snappy interaction
<zyga> ysionneau: it'd better to boot a disk image
<zyga> ysionneau: with a bootloader
<zyga> ysionneau: it's extra work but what you did won't survive a snappy update and reboot
<ysionneau> not sure if I can boot a disk image with no -kernel
<zyga> ysionneau: depending on what you want, it may not be good or it may be exactly what you need
<zyga> ysionneau: no, but you can boot a whole disk image
<zyga> ysionneau: er. sorry, yes you can
<ysionneau> but yes I agree that booting directly on a kernel will break some snappy stuff
<ysionneau> like the system updates and such
<zyga> ysionneau: I've done things like that in linaro a while ago
<zyga> ysionneau: emulating various beagle board-like hardware
<zyga> ysionneau: though I don't know how much work that would be today
<ysionneau> for now I only need a qemu environment with basic snappy fonctionality, not 100%, to do some tests of .snap packaging of apps
<ysionneau> to package a service, an app etc
<ysionneau> and to test my ability to generate cross-compiled apps correctly
<zyga> ysionneau: I see, good luck
<ysionneau> thanks :)
<ysionneau> 10:55 < zyga> ysionneau: just one question, why aarch64 kerenl rather than armhf? < when I'm done playing with qemu, I will prototype on a real board, which is a Tegra X1 board
<zyga> ysionneau: I see, cool
<zyga> ysionneau: did you use aarch userspace?
<zyga> ubuntu-core (os snap) has an aarch64 build as well
<ysionneau> for user space on my last prototype (15.04 :p) I used the rpi2 image (armhf)
<ysionneau> ok, I have the 16.04 user space booting :)
<ysionneau> bottom line is I had to add this to kernel cmdline : snappy_os=ubuntu-core.canonical_16.04.0-10.armhf.snap snappy_kernel=canonical-pi2-linux.canonical_4.3.0-1006-3.snap
<ysionneau> ok I'm logged in
<zyga> woot, great
<ysionneau> now let's try with an arm64 kernel and a qemu-aarch64
<zyga> maybe just aarch64 with the same bits as before
<zyga> then with different kerenl
<zyga> kernel*
<ysionneau> not sure I understand ?
<zyga> ysionneau: try 64 bit qemu
<zyga> ysionneau: with the same set of blobs
<zyga> ysionneau: so same old kernel and everything else
<zyga> ysionneau: (just suggesting to switch one thing at a time)
<ysionneau> yes that's what I'll do
<ysionneau> just switch the kernel and qemu and keep all the remaining
<ysionneau> that should work
<ysionneau> right, I need to reconstruct the kernel snap squashfs to include the arm64 modules
<ysionneau> jeez
<ysionneau> zyga: ok it boots with arm64 kernel (I had to add the squashfs support in the kernel :p)
<ysionneau> I also have network o/
<ysionneau> *afk eating*
<zyga> ysionneau: \o/
<zyga> ysionneau: great
<uralbash> Hello all
<uralbash> Explain to me please, I want to create a kiosk on ubuntu + mir + qt4 app. Is this ok? Which version of ubuntu (core, snappy-15.04, ..) to use? Where to get mir server (form source or ppa or snap demo)?
<ysionneau> snappy search does not exist any moer ?
<ysionneau> anymore*
<uralbash> on xenial (from there https://people.canonical.com/~mvo/all-snaps/) "snappy search mir"  command out "Unknown command `search'. Please specify one command of: activate, booted, ..."
<ysionneau> same here, snappy search does not seem to exist anymore on 16.04
<svij> it's "snappy find" afaik
<ysionneau> nop, does not work
<uralbash> `find` not work too http://paste.ubuntu.com/15196599/
<ysionneau> zyga: so now, I have my 16.04 environment ready, I want to make some 16.04 packages, where can I find the documentation on how to do that?
<ysionneau> is it still snapcraft? or snappy build? snap.yaml? syntax?
<mvo> uralbash: ysionneau: please try "snap find" (not that the command is "snap" not snappy for this). its a bit confusing, sorry for that. this is transitioning currently ,there will be a new snap command for everything
<mvo> but its not fully done so you are in this in-between state, again, this is just for a couple of days until the conversion is fully done
 * mvo wonder if we should simply make snappy search an alias until the rest has landed and until the docs are updated
<ysionneau> oh ... snappy ... now snap
<ysionneau> now I understand why I wanted to stay on 15.04 :'
<ysionneau> things are documented, now everything changes
<uralbash> it's work :)
<uralbash> thanks
<ysionneau> works great mvo thanks for the intel :)
<svij> ah, so I wasn't completely wrong with "snappy find"
<ysionneau> :)
<ysionneau> where's the source code of "snap" mvo ?
<mvo> ysionneau: https://github.com/ubuntu-core/snappy/tree/master/cmd/snap
<ysionneau> thx
<ysionneau> ah it's just another frontend
<uralbash> `sudo snap add mir.mvp-demo` is an error http://paste.ubuntu.com/15196831/
<Guest81475> Hi, I want to try snappy but there is only an img file available. When I rename it into an iso file and burn it, then I can still not obtain a bootable system. I would like to have snappy as easy  as the regular ubuntu release.
<ysionneau> uralbash: !<arch> means it's an AR archive
<ysionneau> but AFAIK the new snap format is squashfs
<ysionneau> so you are trying to install old snaps on a new system
<ysionneau> and btw, I have the same issue as you =)
<ysionneau> error: nethack-armhf.ogra failed to install: can not open /tmp/nethack-armhf061356496: cannot open snap: unknown header: "!<arch>\ndebian-binar"
<uralbash> ysionneau:  Ah, got it, I need to try build it with snapcraft
<zyga> ysionneau: hey
<zyga> ysionneau: sorry for the lag, busy time :)
<zyga> ysionneau: so apart from small syntax changes, it's the same, you can also use snapcraft
<zyga> ysionneau: you just have to use a xenial host with snapcraft 2.x series
<zyga> ysionneau: the syntax is again, in examples, in snapcraft
<zyga> ysionneau: changes are minor, it's just easier to express stuff IMHO
<zyga> ysionneau: snapcraft CLI is tweaked too but it's again simple to adapt, snapcraft snap makes a snap and there's --help and all that typical stuff
<zyga> ysionneau: you can look at an example snap I'm working on https://github.com/zyga/snappy-pi2-piglow/blob/master/snapcraft.yaml
<zyga> ysionneau: give it a try
<zyga> ysionneau: at runtime there are now "snap" and "snappy" commands, you want to use the snap one, unless it has missing functionality
<zyga> ysionneau: as mvo said, we're transitioning, snap is using our public APIs while snappy had everything linked in
<zyga> ysionneau: you really want 16.04
<zyga> ysionneau: it's trivial to adapt and things work much better than on 15.04
<zyga> Guest81475: hey, give this script a try: https://github.com/zyga/devtools/blob/master/ubuntu-image
<zyga> Guest81475: the images are not iso images, they are hard drive images (or SD card images), typically a CD image has different structure
<zyga> Guest81475: but they are all bootable
<Guest81475> zyga: Thank you for your replies. Do you know why ubuntu does not offer a bootable iso image for snappy ? That is what all people expect and are used to. I am using Windows 10 and have a working Arch linux installation.
<Guest81475> I do not like APT but I love the idea of packages as in snappy. AFAIK, MacOS has a similar system.
<ysionneau> zyga: ok :)
<zyga> Guest81475: http://developer.ubuntu.com/en/snappy/start/
<zyga> Guest81475: http://www.ubuntu.com/internet-of-things/developers
<zyga> Guest81475: https://developer.ubuntu.com/en/snappy/start/raspberry-pi-2/
<ysionneau> zyga: isn't it weird that the snap tool seems to be downloading old snap packages?
<zyga> Guest81475: https://developer.ubuntu.com/en/snappy/start/intel-nuc/
<zyga> everything is there :)
<Guest81475> zyga: ok. Thanks again.
<ysionneau> it downloads .snap which are AR (old format) instead of squashfs, and then fails to install them
<zyga> ysionneau: it's a one-off issue, when we made the transition the store didn't have enough information to filter this out
<zyga> ysionneau: we're well aware of the problem
<ysionneau> oh right
<zyga> ysionneau: and I suspect there's going to be a fix that mass-removes click-based snaps from the 16.04 distribution channel
<ysionneau> because at the beginning of 16.04 it was still using AR files?
<zyga> ysionneau: yep
<ysionneau> arggg
<zyga> ysionneau: tons of moving pieces to make this work on time :)
<zyga> ysionneau: you just see it live
<ysionneau> the magic of live :)
<zyga> the magic of open
 * ysionneau generates a new docker image -> xenial
<ysionneau> there's no "snappy-tools" package in the PPA for Xenial ?
<ysionneau> that's just a meta package ... but that can be handy
<beuno> ysionneau, I think it's part of the Xenial archive now instead of the PPA
<sergiusens> elopio, joining?
<sergiusens> ysionneau, beuno just apt install snapcraft
<ysionneau> yep that's what I've done
<sergiusens> beuno, are we going to have the store treat each release as different pockets?
<beuno> sergiusens, maybe!  what do you mean by that?
<sergiusens> beuno, that I can upload one snap for 16.04 and another for 18.04 during the overlapping support period
<beuno> sergiusens, yes, it works like that right now
<sergiusens> beuno, o really? so no more checkboxes?
<sergiusens> or is it checkbox driven per revision?
<sergiusens> that explains why I have to check those boxes on every upload
<beuno> sergiusens, yeah, it should really be radio buttons at this point
<beuno> it is per revision
<beuno> so you can upload one for 15.04 and one for 16.04
<beuno> and target them differently
<beuno> so yes, that's why you pick each time
<beuno> we'll get better at that UI
<beuno> sergiusens, you even have history in the store now  :)
<beuno> we've essentially created 3 dimensions: release, architecture and channel
<beuno> you can targe different binaries to each of those
<sergiusens> beuno, nice; we should have snapcraft semantics for upload (among others, the 'release' key in the yaml)
<beuno> sergiusens, indeed
<beuno> I think that's part of our UX story overall
<beuno> which I'll find a volunteer to go and play with you soon
<kyrofa> Good morning!
<kyrofa> jdstrand, nooo https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1467595/comments/28
<ubottu> Launchpad bug 1467595 in xorg (Ubuntu) "cursor sometimes disappears on XPS 13 9343 and external monitor" [High,Confirmed]
<sergiusens> kyrofa, joining?
<kyrofa> Haha, just saw that you guys were meeting
<kyrofa> Grabbing headphones
<elopio> stgraber: ping. Our lxc in travis is timing out waiting for eth0. This used to work great for the past weeks.
<elopio> any change on your side?
<stgraber> elopio: what lxc version, what lxd version, what kernel version and what Ubuntu version in the container?
<sergiusens> stgraber, host is trusty; here's the full of it, it's a small log https://travis-ci.org/ubuntu-core/snapcraft/jobs/111744184
<kyrofa> stgraber, 2.0.0~beta4-0ubuntu4~ubuntu14.04.1~ppa1
<stgraber> sergiusens: oh, the output of lxc info changed slightly, you'll need to change that grep, sorry
<kyrofa> stgraber, whew, easy fix though
<sergiusens> stgraber, we are using a beta, all good :-)
<stgraber> "IPV4" now shows up as "inet" (the actual name of the network family)
<sergiusens> stgraber, thanks for spotting it quickly
<stgraber> yeah, had a similar problem here with one of my scripts
<jdstrand> kyrofa: I know, right? there is still hope for 4.4
<jdstrand> kyrofa: and 4.3 is *way* better
<kyrofa> jdstrand, alright, good deal
<noizer> Hi guys is it even possible to communicate with usb devices on snappyN?
<kyrofa> noizer, yes, but you need to give snaps permission to use them
<noizer> ok what skill is it?
<kyrofa> noizer, in 15.04 you had to hw-assign it. jdstrand has that gone away in 16.04?
<jdstrand> kyrofa: hw-assign currently exists. it won't once zyga and niemeyer have their way :)
<jdstrand> but it is still there
<noizer> ok
<zyga> noizer, kyrofa: interfaces (renamed skills)
<zyga> kyrofa: hw-assign is still in 16.04 daily but I'll remove it when interfaces go live
<zyga> and I should read backlogs backwards ;)
<kyrofa> zyga, yeah that's kinda tough-- you never know how far back they go :P
<zyga> kyrofa: eleven years ;)
<zyga> not in this channel though
<kyrofa> zyga, haha, yeah exactly
<zyga> I'm tired with all the rename I did today
<zyga> I'd love to land this but there are Ks of diffs and everyone is busy
<zyga> if someone can have a look at https://github.com/ubuntu-core/snappy/pull/524/files
<zyga> that would help me out
<zyga> or https://github.com/ubuntu-core/snappy/pull/523/files for a shorter pull request
<plars> ev:  I got this when trying to create a spec, which I think might be interesting to you.... it doesn't let me re-run it because it says the spec already exists: "message": "Oops! Something bad happened server side (id=Vs9PuwoZwIwAAGe9IgMAAAAl)"
<beuno> plars, the cloud is being messed with
<beuno> good to know, though
<beuno> just not surprising  :)
<ev> ð¢ ðº
<plars> ev: a sad trumpet? as a trombone player, I'm deeply offended by that
<ev> hahaha, thereâs no trombone in unicode
<plars> a major flaw imho, let's dump unicode
<ev> we probably should
<plars> back to ebcdic until further notice
<ev> LOL
<ev> nearly lost my tea there
<plars> ev in all seriousness though, I guess I should hold off on messing with this while it's in this state? any idea how long?
<ev> depends on IS
<ev> Iâd give it another go next week
<plars> ack
<plars> hah, ok
<kyrofa> sergiusens, say I have a 15.04 snap that depends on the docker framework. If I upload a version of the snap that doesn't depend upon docker, will the previously-installed docker snap still get automatically updated?
<kyrofa> sergiusens, I'm not quite sure how the frameworks thing plays into that
<sergiusens> kyrofa, yes it will
<kyrofa> sergiusens, alright thanks :)
<kyrofa> sergiusens, you okay waiting a bit on that pkg-config PR? I'm giving it some good testing, but might take a while
<sergiusens> kyrofa, no rush
<kyrofa> sergiusens, good deal
<kyrofa> sergiusens, in 16.04 snappy, the .service files still have restart on failure, but it seems the snap installation itself fails if the service fails to start. Do you know anything about that?
<sergiusens> kyrofa, I have no idea; the right person to ask this is Chipaca
<kyrofa> sergiusens, alright thanks :)
<kyrofa> Chipaca, I suppose you're eating
<sergiusens> kyrofa, I am really outdated these days :-)
<sergiusens> lol
<sergiusens> risotto?
<kyrofa> Hahaha
<pindonga> jdstrand, hey, crt @ 596 on prod now
<sergiusens> elopio, can we apt update the jenkins instances before test run?
<jdstrand> pindonga: thanks!
<jdstrand> mvo: note, with that ^ on prod, we are going to start getting a warning that the store can't verify resquashing until bug #1548988 is srud to trusty
<ubottu> bug 1548988 in squashfs-tools (Ubuntu Trusty) "please add -fstime patch for snap v2 checks in review tools" [Undecided,Fix committed] https://launchpad.net/bugs/1548988
<jdstrand> mvo: however, that bug is in hand so next week that'll just work itself out
<mvo> jdstrand: nice, thanks for the update
#snappy 2016-02-26
<dholbach> good morning
<dholbach> anyone ever saw anything like this: http://paste.ubuntu.com/15204671/?
<ogra_> dholbach, yeah, thats snappys way to tell you "cant install snapcraft 1.x snaps"
<ogra_> (or rather "cant install non-squashfs snaps" )
<dholbach> ho hum
<ogra_> sadly the store isnt clever enough to hide them
<dholbach> now I get http://paste.ubuntu.com/15204710/
<dholbach> JamesTait, ^ do you know about this?
<dholbach> ok... I got to install it now
<dholbach> for some reason I had to click the "sign package" and the "publish package" button
<dholbach> (I uploaded it through 'snapcraft upload')
<ogra_> neat !
<ogra_> is that scriptable ? or do you need to interact manually ?
 * ogra_ hasnt tried the upload feature yet
<dholbach> my one-char summary of it is: ð
<ogra_> oh my
<JamesTait> dholbach, what ogra_ said for your first pastebin.  Looking into your second.  Sounds like the signing task either failed or hadn't completed when you tried to download.
<zyga> good morning (so to speak)
<JamesTait> dholbach, it should be fixed now.  One of the units in the pool didn't restart properly.
<dholbach> thanks
<dholbach> sergiusens, kyrofa: do you think one of you (or somebody else?) can reply to the "Packaging an OSGi Java app in snappy" mail on the mailing list?
<sergiusens> dholbach, from today?
 * sergiusens is just getting up
<dholbach> sergiusens, no... from quite some time ago - I just noticed that nobody replied
<dholbach> dpm, you can set SNAPCRAFT_LOCAL_SOURCES when running and it will use your local sources.list
<dpm> dholbach, I think I'll have to get back onto using snapcraft, not sure exactly where to start yet. I might have some more questions in the next few days
<dholbach> dpm, it should be somewhat similar to http://bazaar.launchpad.net/~dholbach/+junk/moon-buggy/view/head:/snapcraft.yaml
<dholbach> popey also used it for packaging cowsay... iirc his snapcraft.yaml looked quite similar
<dholbach> just be careful with the 'snap' bit at the end - it's an explicit list of which files to include in the .snap
<dholbach> best to drop it in the beginning
 * ogra_ recommends to dholbach  to call the binary "play" instead of moon-buggy ... so you end up with moon-buggy.play instead of moon-buggy.moon-buggy
<ogra_> feels somehos more user friendly :)
<dpm> so the important bit for me to package ubuntu-calculator-app I guess is to set 'stage-packages', right
<ogra_> *somehow
<dpm> and where do I need to set  SNAPCRAFT_LOCAL_SOURCES ?
<dholbach> dpm, as an environment variable
<dpm> ok
<popey> dpm: http://paste.ubuntu.com/15205853/ http://paste.ubuntu.com/15205855/ <- cowsay yaml and shell script
<popey> almost certainly a terrible example of how to make a snap via snapcraft
<popey> it was my first :)
<dpm> so just set it to SNAPCRAFT_LOCAL_SOURCES=1  or just define it?
<dpm> thanks popey, I'm going to have a go at packaging calculator, see where it explodes
<popey> heh
<popey> you gonna be able to do that with mir etc?
 * popey updates his pi to get latest snapcraft
<dholbach> ogra_, done
<ogra_> heh :)
 * dholbach <3 'snapcraft upload' :)
<beuno> pindonga that's for you ^
<dholbach> beuno, why do I need to publish it manually though? :)
<dholbach> https://myapps.developer.ubuntu.com/dev/click-apps/4075/rev/8/
<beuno> dholbach, because we're missing the snapcraft publish command
<beuno> which is on our plate, please hold  :)
<popey> good answer
<dholbach> hum
<dholbach> didn't the store auto-publish stuff I uploaded as a click?
<dholbach> I sort of expected that to happen too
<zyga> jdstrand: I see what you did there "gerund-style" :)
<ogra_> there was a checkbox for clicks to have that happen ... i dont think i have seen that for snaps
<beuno> dholbach, it did, but we now have channels, released and architectures
<dholbach> right
<beuno> dholbach, we we need a bit more information on each upload to know where to put it
<dholbach> I filed a bug so we can have 'snapcraft upload edge' :-)
<beuno> great
<beuno> we have a sprint next week
<beuno> maybe we can knock some of these off
<dholbach> something we should advertise as a very useful command to add to any CI :)
<beuno> it depends on how good you are at international beer shipping
<ogra_> nooo !
<ysionneau> zyga: with old snapcraft I was able to generate a .snap by just doing "snapcraft" without argument. Now it seems it does not work. What do I need to type then?
<ogra_> stop having sprints !!!
<ysionneau> (hello  btw!)
<dholbach> ysionneau, that's fixed in the newest snapcraft
<ogra_> every time a team has a sprint something serious changes !
<ysionneau> ah I'm not up to date indeed
<ysionneau> I've got a few commits late
<dholbach> ysionneau, https://lists.ubuntu.com/archives/snappy-app-devel/2016-February/000622.html
<beuno> ogra_, this particular sprint is heads-down-get-things-landed sprint
<dholbach> I just confirmed the fix in xenial :)
<ysionneau> very cool :)
<ogra_> beuno, phew :)
<ysionneau> let me git pull then, thanks!
<beuno> so I hope the only change is, more stuff works!
<dholbach> go go go! :-)
<zyga> ysionneau: snapcraft snap
<zyga> ysionneau: try snapcraft --help
<dpm> hm, this didn't use my sources.list, resulting in no download: http://paste.ubuntu.com/15205934
<dholbach> dpm, I never used the feature, it's just something sergiusens once told me about... maybe he or kyrofa know
<sergiusens> dholbach, dpm SNAPCRAFT_LOCAL_SOURCES
<sergiusens> don't rely on it though
<dpm> yeah, I added it to .bashrc and started a new terminal, didn't seem to work
<dpm> I set it to 1 now
<dpm> will try that
<ysionneau> zyga: --help was giving me this error : UnicodeEncodeError: 'ascii' codec can't encode character '\u201c' in position 364: ordinal not in range(128) :p
<ogra_> just prefix teh snapcraft call with it
<dpm> good point
<ogra_> SNAPCRAFT_LOCAL_SOURCES=1 snapcraft snap
<ysionneau> hmm still same error
<zyga> ysionneau: oh, that smells like a bug
<zyga> sergiusens: ^^
<zyga> ysionneau: file a bug with the backtrace
<zyga> ysionneau: but for now, perhaps look at the .yaml file and see if you have some non-ascii stuff there
<ysionneau> that's the entire stack trace : http://pastebin.com/0rpnsNGt
<ysionneau> seems like a docstring issue
<sergiusens> ogra_, zyga, dpm ysionneau heh, we implemented this for launchpad only, probably the reason why it fails (and the reason we don't want people to use it)
<dpm> ok, calculator app snap created... what's the best way to examine the contents of the generated .snap file?
<sergiusens> launchpad creates on sources.list
<sergiusens> and that's all we use
<sergiusens> if you put the deb line in sources.list it should work
<sergiusens> that said, don't rely on this please
<zyga> dpm: mount it
<dholbach> sergiusens, I think it's nice to be able to test it locally before you try this on LP, which is where we'll send people for something like this right?
<dpm> sergiusens, yeah, otherwise there is no way I can run snapcraft manually to build something out of a PPA, right?
<dpm> zyga, what's the best way to mount then?
<dpm> ok, just mount $SNAP.snap $LOCATION, then
<dpm> contents seem to look ok
<sergiusens> dpm, unsquashfs -l IIRC
<dpm> the simple mount command seemed to work
<dpm> trying to install the generated snap now
<dpm> installed fine, although I'm not sure how to execute it now to execute it
<popey> dholbach: error: no snaps found for "moon-buggy"
<popey> :(
<dpm> not sure where the binary went
<dholbach> popey, moon-buggy.dholbach
<popey> snap find should find that
<popey> moon-buggy.dholbach failed to install: snappy package not found
<dholbach> I don't know what the plan is there
<dholbach> hohum
<popey> I dont see it
<popey> is it amd64 only?
<dholbach> ah yes
<popey> :(
<popey> You suck :)
<popey> I can't play moon buggy on my pi!  ð
<dpm> dholbach, the last line on http://bazaar.launchpad.net/~dholbach/+junk/moon-buggy/view/head:/snapcraft.yaml - why was it needed? was the binary not installed during the snap installation?
<ogra_> and i cant play it on my dragonboard !
 * popey builds
<dholbach> dpm, snap: [..]  limits the list of installed files to just the ones explicitly listed
<ogra_> sadly you cant build it and give it to dholbach with the new snapcraft
<popey> no, but I can upload it
<ogra_> (since it wil become moon-buggy.popey)
<ogra_> indeed
<dholbach> dpm, so you don't install lots of useless files and have huge packages - for the beginning try without it :)
<ogra_> would be cooler if i could quickly build a binary for dholbach so we dont need different namespaces .... thats quite a drawback of our design
<dpm> dholbach, ah, I see yours was just a binary. Yeah, I hadn't used it. So the generated ubuntu-calculator-app was installed, but I'm not sure where :)
<ogra_> (given he doesnt have arm64 HW)
<dholbach> dpm, if you mounted it, can't you just run a find in that directory?
<dholbach> brb
<dpm> ah, it's in /snaps
<ogra_> schnaps !
<dpm> ah, bummer
<dpm> "qmlscene: could not find a Qt installation of 'qt5'"
<dholbach> add qt-default (or whatever it is) to stage-packages?
<ogra_> stage-packages is your friend
<dholbach> qt5-default
 * dpm tries
<dholbach> you might have to add a few other things to make it happy
<dpm> thanks!
<jdstrand> sergiusens: hi!
<dholbach> brb
<jdstrand> sergiusens: so, trying out the new snapcraft-- lxd seems a rather big dependency-- shouldn't this be a recommends or depends?
<jdstrand> sergiusens: meh, recommends or suggests?
<sergiusens> jdstrand, hm, it ended up as a dependency?
<jdstrand> sergiusens: I've had trouble having lxc and libvirt installed on the same machine for example due to how they've interacted with each other's networking
<sergiusens> jdstrand, darn
<sergiusens> jdstrand, it should not be a dep
<jdstrand> -Depends: python3-apt,
<jdstrand> +Depends: lxd,
<jdstrand> +         python3-apt,
<jdstrand> that is 2.3 ^
<sergiusens> jdstrand, I added code in snapcraft to check if lxd was installed
 * sergiusens prepares 2.3.2
<sergiusens> jdstrand, I'll remove the dep
<jdstrand> adding it as a dep in the autopkgtests is of course fine
<jdstrand> sergiusens: thanks! :)
<dpm> it seems if I add staged packages to snapcraft.yaml and then I try to run snapcraft snap, it skips the staging step?
<popey> oooh. "Can not create a new package with name moon-buggy, multiple origins for moon-buggy are not allowed." when I snapcraft upload :(
<sergiusens> not having lxd and calling cleanbuild will error out nicely with followup instructions
<dpm> is there a way to run with a clean environment, or do I just delete the contents of the directory?
<sergiusens> popey, hah, dholbach won you on that name; the logic in itself I will defer to beuno
<jdstrand> sergiusens: might I suggest using Suggests then since Recommends will be installed automatically?
<sergiusens> dpm, snapcraft clean
<popey> but surely it would let me do moon-buggy.popey ?
<dpm> thanks sergiusens
<sergiusens> jdstrand, oh, I was just going to remove it completely, but suggests works fine
<jdstrand> I guess it could be dropped altogether... I'll let you decide. I'm totally fine with suggests
<jdstrand> or dropping
<beuno> popey, package names work differently in snappy
<sergiusens> popey, that's why I say I defer to beuno
<beuno> we won't support developer namespaces for a little bit
<beuno> we will, but not for 16.04
<beuno> sorry
<popey> ah, so just uploading manually will work?
<popey> (not via snapcraft upload)
<beuno> it won't
<beuno> anymore
<beuno> dholbach owns "moon-buggy" for now
<popey> *blink*
<jdstrand> beuno: by 'not for 16.04', do you mean 'never for 16.04' or 'not by 16.04 release'?
<beuno> jdstrand, the latter
 * jdstrand nods
<beuno> I'll start saying "not by April 21st" I think  :)
<jdstrand> cause I squatted a couple things myself
<jdstrand> and depending on that answer, I would do different things
<beuno> jdstrand, put them up for sale on ebay?
<jdstrand> I should! :)
<popey> yeah, you're buggered if you want to make the next hello-world!
<beuno> I'm not saying that's my retirement plan, but...
<popey> (I hope our tutorials don't tell people to do that) :)
<beuno> yes
<ogra_> wow, thats pretty gross
<beuno> it's not great, yeah
<ogra_> cant we bump such a feature to higher prio ?
<beuno> we can't, no
<ogra_> :(
<dpm> ok, seems adding 'qt5-default' to staged-packages does not pull qt
<beuno> we spent a lot of time trying to, but it's not an isolated feature
<beuno> it's built on other things we're building first
<popey> dpm: that doesn't actually contain it, that just sets the default qt to qt 5
<dpm> argh
<ogra_> yeah, there must be another metapackage you can pull to get all the deps
<dpm> yeah, looking, but not sure which one it is
 * ogra_ is curious how big you will end up with the binary :) 
<popey> dpm: you should probably pull in ubuntu-ui-toolkit or the full sdk
<popey> dpm: because you're gonna need more than just qt5
<dpm> indeed
<popey> ubuntu-sdk-libs possibly?
 * dpm looks for Mirv
<popey> (which pulls the world in)
<ogra_> "the new 1.5GB ubuntu-calculator snap just landed in the store"
<dpm> lol
<sergiusens> jdstrand, https://github.com/ubuntu-core/snapcraft/pull/343
<sergiusens> in case you want to look as well
<jdstrand> sergiusens: awesome, thanks
<dpm> the calculator snap is 150 MB, let's see if it works now
<ogra_> oh, thats smaller than expected
<dpm> hm, somehow I can't see the qt libraries in the .snap
<dpm> and no, the snap does not work either
<dpm> it seems to download the qt libraries, but I can't see them under stage/lib/x86_64-linux-gnu, neither in the final snap
<ogra_> dpm, more likely under stage/usr/lib/x86_64-linux-gnu
<ogra_> i dont think qt installs in /lib usually
<dpm> ah, yeah, it seems to be all in there
<dpm> but qmlscene still can't find qt5
<dpm> I'll give up for today. In any case, if someone else wants to give it a go: http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files
<sergiusens> dpm, you need to copy file a config
<sergiusens> you might be 5 minutes away from a working snap though ;-)
<ogra_> sergiusens, had yoda-coffee for breakfast ?
<dpm> sergiusens, not sure I understand
<dpm> lol
<sergiusens> dpm, create a config file and drop it in etc/xdg/qtchooser like in https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/qml.py#L68
<sergiusens> dpm, also set the envvars as in that env function
<sergiusens> except for the mir setup
<dpm> sergiusens, other than creating the conf file itself, is this something that I can do on snapcraft.yaml file (install file, set envvars)?
<dpm> on *the snapcraft.yaml file
 * dpm looks at docs
<jdstrand> dpm: you might need to set QML2_IMPORT_PATH
<jdstrand> dpm: note that it is searched backwards
<dpm> jdstrand, ok, looking at the env vars now
<dpm> not sure what the 'root' should be in https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/qml.py#L79 though
<jdstrand> dpm: looking at what we are doing for click, it seems like 'QML2_IMPORT_PATH={}/usr/lib/{}/qt5/qml'.format(root, arch) should be 'QML2_IMPORT_PATH={}/usr/lib/{}'.format(root, arch)
<jdstrand> dpm: I am no expert in this area though
<jdstrand> well
<jdstrand> actually
<sergiusens> dpm, root should be $SNAP
<dpm> ah, is root /snaps?
<sergiusens> no $SNAP
<ogra_> schnaps !
<dpm> :-)
 * sergiusens missed a comma
<sergiusens> no, $SNAP
<dpm> so in my case 'ubuntu-calculator.sideload'?
<ogra_> dpm, no, just the var
<dpm> ah, I see
<dpm> thanks
<sergiusens> hah, so create two files, one with the conf and another which would be a shell wrapper
<ogra_> that will expand to the actual path at runtime
<sergiusens> in the wrapper export your needed vars
<dpm> ok
<jdstrand> dpm: ok, so I'm not sure if it is right or wrong. I suspect it is right for stage packages but that an additional path should be appended for non-staged qml modules that you ship
<sergiusens> dpm, in some sense like this https://github.com/ubuntu-core/snapcraft/blob/master/examples/tomcat-maven-webapp/wrapper
 * dpm gives it a go
<sergiusens> I suffered a lot getting gallery to work in the click world, there are so many Qt vars and at that time they changed the var to export too.... ah memories I am glad I forgot about
<jdstrand> heh
<dpm> that's the man who told me "you're 5 minutes away from a working snap"
<dpm> you teaser :P
<beuno> I think that's always true, you are 5 minutes away
<ogra_> 5 "jupiter" minutes :)
<sergiusens> dpm, I had more faith in you ;-)
 * sergiusens does a friday troll :-D
<dpm> sergiusens, you're really into this yoda role this morning, aren't you? :)
<dpm> sergiusens, jdstrand, so something like this for the wrapper? http://paste.ubuntu.com/15206673
<ogra_> dpm, and an exec line at the end (like popey showed you earlier)
<ogra_> i'm also not sure dpkg-architecture is still there ... you might need to use uname
<dpm> ogra_, ok. And which exec line you were saying?
<dpm> I can't recall popey showing me this
<ogra_> there was a pastebin above
<ogra_> ( i miss some backlog here on this machine)
<dpm> https://github.com/ubuntu-core/snapcraft/blob/master/examples/tomcat-maven-webapp/wrapper
<dpm> that's the only thing I remember being pasted ^
<ogra_> here is one of my snaps http://bazaar.launchpad.net/~ogra/+junk/ircproxy/view/head:/run-bip (though thats a service ... )
<jdstrand> dpkg-architecture is definitely not there
<ogra_> yeah, thought so
<ogra_> i think 15.04 still had it
<ogra_> as a leftover
<jdstrand> you do have SNAP_ARCH, but it has 'amd64', not x86_64-linux-gnu
<jdstrand> so there is perhaps a bug in snappy to export SNAP_GNU_TRIPLET (or whatever it should be named)
<jdstrand> dpm: fyi, if you install hello-world, then you can do: $ hello-world.env |grep SNAP
<jdstrand> oh, I just noticed a typo
<jdstrand> SNAPP_APP_TMPDIR
 * jdstrand files a bug
<sergiusens> TMPDIR is not needed anymore iirc
<dpm> yeah, just installed it, only amd64, so hardcoding for now?
<ogra_> why do we expose that anyway ? isnt it the same as $TMPDIR nowadays ?
<sergiusens> jdstrand, that's there for legacy; but given everything is so aggressive I'm not sure why this is still there :-P
<sergiusens> ogra_, so things didn't break on day one; but things have been breaking since, so it makes little sense to have this at all ;-)
<jdstrand> I think TMPDIR should be explicitly set to /tmp
<ogra_> sergiusens, yeah
<jdstrand> this actually seems to be a bug in the hello-world snap
<sergiusens> jdstrand, I thought hello-world just ran 'env'
<jdstrand> well, no
 * jdstrand keeps looking
<sergiusens> it's the snappy install logic most likely
<jdstrand> ok, ubuntu-core-launcher is setting it itself
<jdstrand> sergiusens: that's what I thought, but nothing in /snaps/bin had SNAPP_...
<sergiusens> oh, tmpdir is special since it is in a new namespace as well
<jdstrand> but line 254 of main.c of ubuntu-core-launcher definitely is doing it
<dpm> ogra_, sergiusens, jdstrand, better? http://paste.ubuntu.com/15206764
<dpm> Also, another question, so my snap already installs a "command-ubuntu-calculator-app.wrapper" by default. How do I make it ship this new wrapper instead?
<sergiusens> dpm, if it is the wrapper you don't control, you can't
<sergiusens> snappy install will wrap it up once more
<dpm> ok, so what do I do with "my" wrapper, simply point to it in the yaml file?
<sergiusens> dpm, with the copy plugin
<jdstrand> dpm: I bet you want:
<jdstrand> export QML2_IMPORT_PATH=$SNAP/usr/lib/$ARCH/qt5/qml
<jdstrand> export QML2_IMPORT_PATH=$SNAP/usr/lib/$ARCH:$QML2_IMPORT_PATH
<dpm> jdstrand, ah, I changed it from your previous comment, I hadn't understood correctly
<jdstrand> dpm: well, I refined my comment
<jdstrand> dpm: actually, change that to be:
<jdstrand> export QML2_IMPORT_PATH=$SNAP/usr/lib/$ARCH/qt5/qml
<sergiusens> dpm, like done for mqtt-client here https://github.com/ubuntu-core/snapcraft/blob/master/examples/mosquitto/snapcraft.yaml
<sergiusens> but with your shell wrapper
<jdstrand> export QML2_IMPORT_PATH=$QML2_IMPORT_PATH:$SNAP/usr/lib/$ARCH
<jdstrand> dpm: ie, set QMP2_IMPORT_PATH to what is already there, then append your app-specific modules. this should make it so your app-specific modules are used first (since it is searched backwards)
<sergiusens> jdstrand, https://launchpad.net/ubuntu/+source/snapcraft/2.3.2 now we wait again ;-)
<sergiusens> QML!
<jdstrand> yes, not QMPP2 :)
<jdstrand> QMP2*
<jdstrand> meh
<sergiusens> searching backwards when everything else searches forwards is super ackward
<jdstrand> is it friday yet?
<jdstrand> oh, so it is :)
<sergiusens> friday is almost over in some places ;-)
<jdstrand> sergiusens: re backwards> I know, right?
<ysionneau> work day almost over here : 17:20 :'
<jdstrand> nice! :)
<sergiusens> ysionneau, nice that your work day can end at a specific point in time too ;-)
<dpm> sergiusens, jdstrand, looks good? http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files
 * jdstrand installs snapcraft 2.3.2 via debs
<ysionneau> sergiusens: your work day never ends ? :p
<sergiusens> dpm, don't use .wrapper after the : in the copy plugin
<jdstrand> dpm: sorry, to mimic click, change this:
<jdstrand> export QML2_IMPORT_PATH=$QML2_IMPORT_PATH:$SNAP/usr/lib/$ARCH
<jdstrand> to
<jdstrand> export QML2_IMPORT_PATH=$QML2_IMPORT_PATH:$SNAP/lib/$ARCH
<sergiusens> dpm, so; line 15 -> ubuntu-calculator-app.wrapper: bin/ubuntu-calculator-app
<sergiusens> and line 10 -> command: ubuntu-calculator-app
<sergiusens> or line 10 -> command: bin/ubuntu-calculator-app
<sergiusens> if you don't trust PATH resolution
<dpm> ok, just noticed I was missing a 'files:' too, bad syntax
<dpm> sergiusens, jdstrand, ok, updated http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files with your comments, thanks!
<ysionneau> sergiusens: were are the examples installed when installing snapcraft-examples ?
<ysionneau> omg, it's in your email
<ysionneau> sorry
<dpm> building the snap now
<sergiusens> ysionneau, no worries
<dpm> sergiusens, jdstrand, argh, no luck yet:
<dpm> dpm@el-far:/snaps/bin$ ./ubuntu-calculator-app.ubuntu-calculator-app
<dpm> qmlscene: could not find a Qt installation of 'qt5'
 * jdstrand wonders if ubuntu-sdk-libs is enough or if qmlscene needs more...
<ogra_> dpm, you cant just run the wrapper
<jdstrand> oh right, you have to setup the environment
<ogra_> run it without ./
<ogra_> then the system wrapper will exxec it
<dpm> not sure I quite follow, but:
<dpm> dpm@el-far:/snaps/bin$ ubuntu-calculator-app.ubuntu-calculator-app
<dpm> qmlscene: could not find a Qt installation of 'qt5'
<ogra_> like ubuntu-app-launcher on the phone
<sergiusens> dpm, jdstrand you probably need the full list
<sergiusens> dpm, except mir, most of what is here: https://github.com/ubuntu-core/snapcraft/blob/master/snapcraft/plugins/qml.py#L30
<sergiusens> qtubuntu-desktop
<dpm> sergiusens, but I think from Mirv tells me, ubuntu-sdk-libs should pull Qt + the SDK. Ah, so I'm missing that one?
<sergiusens> dpm, I think; I'm not sure; show that to Mirv
<sergiusens> the error message
<dpm> these are all the staged packages, it seems qtubuntu-desktop is not in there
<dpm> http://paste.ubuntu.com/15207150/
<sergiusens> the click code has a bunch of libs added to its chroot creation logic too; so I don't think it is that straight forward
<sergiusens> dpm, that provides the QPA plugin so most likely needed
<dpm> sergiusens, except from qtubutnu-desktop, all the packages from the qml plugin and more are pulled, so I think I should be ok if I just add it for now. Question, though, how do the wrappers work? I'm a bit lost in the wrapper chain, and if I'm doing the right thing when trying to execute the snap from /snaps/bin directly
<sergiusens> dpm, no, don't do it directly; it is package-name.app-name
<sergiusens> or else nothing will work
<dpm> yeah, that's how I've been executing it after ogra told me to drop the ./ but I've no idea what's happening behing the scenes and if the wrapper with the env variables is being called at all
<ogra_> dpm, running package-name.app-name -> exec ubuntu-core-launcher -> execs the snapcraft wrapper -> execs your wrapper script
<ogra_> each of the wrappers adds bits to the env
<dpm> ah, cool, that makes it clearer, thanks
<ogra_> (ubuntu-core-launcher actually sets the SNAP_DIR and stuff)
<ogra_> snpppy should have been called wrappy actually ;)
<ogra_> *snappy
<ysionneau> can someone explain what is the "uses" keyword in snap.yaml?
<dpm> hm, any ideas how this could have happened?
<dpm> $ sudo snappy remove ubuntu-calculator-app
<dpm> Removing ubuntu-calculator-app
<dpm> remove /snaps/ubuntu-calculator-app.sideload/INUMLeWbJcQO/bin/ip: read-only file system
<dpm> I've removed the app a few times already between tries, but this time around it can't be removed
<kyrofa> dpm I'm hitting that as well. You must be on rolling
<dpm> kyrofa, weird thing is, it just affects that particular installation of the app. I can install new versions and remove them
<dpm> have you found any workarounds?
<dpm> actually, I can't
<dpm> garbage collection impossible: prerequisites untrue: remove /snaps/ubuntu-calculator-app.sideload/INUMLeWbJcQO/bin/ip: read-only file system
<kyrofa> dpm no, though it only seems to happen to me when the installation fails
<dpm> yeah, not sure what to do, I can neither remove nor install the app now
<qengho> Is there a good command to use to build a snap package within a snappy environment, to make sure I have dependencies right?
 * zyga ends the day
<zyga> next week: focus on getting working interfaces in master
<zyga> have nice weekend everyone
<dpm> sergiusens, jdstrand, I think I'm nearly there with the calculator snap. I think I've figured out why qmlscene wasn't finding Qt, but in this I've uncovered a new issue. So:
<dpm> ubuntu-calculator-app.ubuntu-calculator-app -> exec ubuntu-core-launcher -> execs the snapcraft wrapper -> execs my wrapper
<dpm> The problem is, the snapcraft wrapper calls 'ubuntu-calculator-app', which also turns out to be the name of the launcher script for the app.
<dpm> If I understand it correctly, as the launcher script is in $SNAP/usr/bin, it takes precedence over my wrapper with the same name in $SNAP/bin
<dpm> So my wrapper is never called and no env variables are set
<jdstrand> dpm: I think you need to have a different name for your wrapper and for the calculator. then your wrapper calls the calculator and you tell snapcraft to install your wrapper as the command
<jdstrand> that way you'll get snapcraft wrapping your wrapper, which wraps your command
<jdstrand> that will work. sergiusens might have another suggestion
<dpm> jdstrand, yeah, but I'm not sure how to best change the name and what controls what the snappy wrapper calls
<dpm> is it the 'command' field under "apps:"?
<jdstrand> dpm: can you provie the link to the snapcraft.yaml?
<dpm> jdstrand, http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files
<jdstrand> dpm: ok, so down in 'files', you have:
<jdstrand> ubuntu-calculator-app.wrapper: bin/ubuntu-calculator-app
<jdstrand> change that to: ubuntu-calculator-app.wrapper: bin/ubuntu-calculator-app.wrapper
<jdstrand> dpm: then up above, do:
<jdstrand> apps:
<jdstrand>   ubuntu-calculator-app:
<jdstrand>     command: ubuntu-calculator-app.wrapper
<jdstrand> I think that will do what you want
<dpm> ah, yeah, that was the bit I wasn't sure about
<dpm> thanks I'll try that
<jdstrand> np
<jdstrand> be sure that ubuntu-calculator-app.wrapper can find your real command of course)
<dpm> hm, that didn't seem to work
<dpm> Stripping ubuntu-calculator-app
<dpm> Command '['/bin/sh', '/tmp/tmp2iyqiobh', '/bin/sh',
<dpm> '/tmp/tmpjc9j0l7z']' returned non-zero exit status 1
<dpm> after running snapcraft snap
<dpm> any ideas how to debug that?
<popey> dpm: i have seen that
<popey> can i see the yaml?
<dpm> popey, http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/files
<dpm> this seemed to cause it: http://bazaar.launchpad.net/~dpm/+junk/calculator-snap/revision/7
<popey> bizarre
<dpm> indeed. If I rename it back to ubuntu-calculator-app, it works :/
<dpm> but neither ubuntu-calculator-app.wrapper nor ubuntu-calculator-app-wrapper does, I get that weird error
<dpm> oh, is the name too long, perhaps?
<dpm> we had that issue with the phone launcher, didn't we?
<kyrofa> sergiusens, elopio alright I'm here for a decent stretch, I think
<dpm> no, it turns out that 'command' can only be 'ubuntu-calculator-app' :/
<kyrofa> dpm that's probably due to the command not being found in the snap
<beuno> right, your binary namespace is your snap namespace in the system
<kyrofa> dpm, that error message could be a bit more helpful, perhaps :)
<beuno> you can't have a snap called "calculator" that installs "apache"  :)
 * beuno hopes dpm is taking notes about the frustrations and sends a summary to the list
<zyga> jdstrand: where should I report DENIED errors on ubuntu 16.04 desktop
<dpm> kyrofa, that's a nice way to put that the error message should be meaningful to humans :)
<kyrofa> dpm, I'm not even sure I'd say that one is meaningful to computers ;)
<dpm> indeed :)
<jdstrand> zyga: what is the denial?
<zyga> Feb 26 20:32:44 x200t kernel: [31556.508068] audit: type=1400 audit(1456515164.332:46): apparmor="DENIED" operation="open" profile="/usr/lib/*/mediascanner-2.0/mediascanner-extractor" name="/sys/devices/system/node/node0/meminfo" pid=17842 comm="qtdemux0:sink" requested_mask="r" denied_mask="r" fsuid=1000 ouid=0
<dpm> beuno, taking notes, but not frustrated yet, I'll succeed! :)
<zyga> jdstrand: though I saw other failures eariler (related to dhcp client)
<jdstrand> zyga: mediascanner2
<zyga> kern.log:Feb 24 19:07:03 x200t kernel: [   15.239795] audit: type=1400 audit(1456337223.467:29): apparmor="DENIED" operation="open" profile="/sbin/dhclient" name="/etc/ssl/openssl.cnf" pid=1112 comm="dhclient" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<jdstrand> zyga: it depends on if the package ships the profile or not. if in doubt, can always file against apparmor and we'll reassign
<kyrofa> dpm, does that bzr repo contain the entire snap? Happy to take a look
<jdstrand> zyga: the dhclient one is already fixed
<zyga> jdstrand: oh, nice, thanks. I'll file the one on mediascanner then
<dpm> kyrofa, it does, do read the readme file, though
<jdstrand> it looks like 4.3.3-5ubuntu8 didn't make it out of proposed yet
<dpm> kyrofa, you'll need to add the PPA to your sources from where the staging packages are being taken
 * jdstrand investigates
<jdstrand> (that was for isc-dhcp)
<zyga> jdstrand: btw, I'd like to look into adding old-security skills next week
<dpm> kyrofa, I think the last issue to overcome is the upstream launcher script overriding the wrapper script in the snap
<zyga> jdstrand: I'll poke you with some ideas
<kyrofa> dpm, alright, grabbing it now
<dpm> kyrofa, oh, and importantly, that snap is for unity 7 on the desktop, not for mir. I.e. it runs on X, and it won't pull any mir dependencies or set any mir env variables
<kyrofa> dpm, sweet
<dpm> bbiab
<kyrofa> dpm, pretty sure it's because the wrapper isn't executable
<kyrofa> dpm, yep, that was it
<kyrofa> Oh my goodness, travis, work with me here. At least wake up, pretend you're alive
<kyrofa> dpm https://bugs.launchpad.net/snapcraft/+bug/1550496
<ubottu> Launchpad bug 1550496 in Snapcraft trunk "Error message when command can't be found/isn't executable is terrible" [High,Triaged]
<dpm> oh wow, nice catch kyrofa!
<dpm> hm, still getting the error
<kyrofa> dpm, did you clean first?
<dpm> kyrofa, no, I didn't, that's what I was going to do next. But is there a way to clean without deleting the staged packages?
<sergiusens> dpm, yeah, that's why I told you not to name your wrapper <app-name>.wrapper as we do that internally as well and there is a clash
<kyrofa> dpm, for this specific situation, yes, but you have to fool snapcraft. Snapcraft isn't very smart about this type of thing yet (I'm working on that right now, actually)
<kyrofa> sergiusens, at least we use command-<app>.wrapper
<dpm> sergiusens, no, the clash is somewhere else. Actually renaming it to .wrapper fixes it
<dpm> (or anything else)
<kyrofa> dpm actually you can replace the old non-executable wrapper with the new one yourself in the parts/ubuntu-calculator-app/install/ directory
<kyrofa> dpm, then run snapcraft snap again
<kyrofa> dpm, that should work
<sergiusens> dpm, right, I gave the exact lines and told you to make sure your script wrapper was +x along the conversation this morning :-P
<dpm> giving it a go
<dpm> sergiusens, these were two separate issues. With the exact lines, there was a clash with the upstream launcher script, that's why I need to rename it now
<sergiusens> dpm, oh, right; your wrapper might have just been called 'wrapper' or whatever; the front facing command is what is in apps: anyways
<dpm> argh, now the wrapper is called, but qmlscene cannot find the main qml file, even though the path is correct
<dpm> $ ubuntu-calculator-app.ubuntu-calculator-app
<dpm>  
<dpm> $ ubuntu-calculator-app.ubuntu-calculator-app
<dpm>  /snaps/ubuntu-calculator-app.sideload/INUXMfbfaWSb/bin/ubuntu-calculator-app.wrapper: 40: exec: /snaps/ubuntu-calculator-app.sideload/INUXMfbfaWSb/usr/bin/qmlscene /snaps/ubuntu-calculator-app.sideload/INUXMfbfaWSb/usr/share/ubuntu-calculator-app/ubuntu-calculator-app.qml: not found
<dpm> I give up for today
#snappy 2016-02-27
<kyrofa> sergiusens, I see you doing stuff. You around this morning?
<longsleep> Hey folks, is the console-setup.service supposed to work on aarch64? I get something very similar to bug #1516591
<ubottu> bug 1516591 in console-setup (Ubuntu) "console-setup.service fails on ppc64el" [Undecided,New] https://launchpad.net/bugs/1516591
#snappy 2017-02-20
<thos37> Iâm just discovering that Intel Joule I2C and UART ports that work in Core beta 4 donât work in Desktop (which makes sense).  Is the source for the kernel and kernel modules in Snappy available somewhere publically?  Weâd like to be able to use the latest Intel Joule support in Desktop.  Is it possible to run a Snap-based kernel in Desktop?
<santoshmahto> alecu: hi
<hangun> zyga:  hi , does your 3.10 patch be merged  into  release-2.22.3?
<mup> PR snapd#2889 opened: errtracker: add support for error reporting via daisy.ubuntu.com <Created by mvo5> <https://github.com/snapcore/snapd/pull/2889>
<zyga> hangun: hey
<zyga> hangun: yes it has
<hangun> zyga: that'w awewome
<zyga> hangun: did it fix your issue?
<hangun> zyga: I have upgrade the snap/snapd to 2.22.3 in my ubuntu 16.04, try it soon
<mup> PR snapd#2890 opened: apparmor: added spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2890>
<Mirv> heads up that QA is about to approve promoting UAP #34 (amd64) to stable channel. for this particular version it has already been in beta/candidate too so this is about the beta -> stable in practice.
<mup> PR snapd#2786 closed: interfaces: initial unity8 interface <Created by mikix> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2786>
<mup> PR snapd#2790 closed: Add a check for an empty argv in snap-confine.c <Created by eriksjolund> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2790>
<mup> PR snapd#2891 opened: interfaces/udev: added spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2891>
<mup> PR snapd#2807 closed: snap: add new `snap switch` command <Created by mvo5> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/2807>
<hangun> zyga: hi
<Son_Goku> mvo: hey
<Son_Goku> mvo: is there anything you'd like me to do to my PR to merge the selinux policy module in? https://github.com/snapcore/snapd/pull/2878
<mup> PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
<hangun> zyga:  the namespace issue is still in my board after upgrading snap to 2.22.3 veriosn
<hangun> zyga: snap --version :   snap    2.22.3  / snapd   2.22.3 series  16 / ubuntu  16.04
<hangun> zyga:  on my board:  I ran "snap version" command, it outputs " snap 2.22.3"
<hangun> zyga:  on my board:  I ran "snap version" command, it outputs " snap 2.22.2"
<hangun> zyga:  host computer: snap version is 2.22.3 .   target board: snap version is 2.22.2
<mvo> Son_Goku: nothing to do for you on your side, just looking into some high profile bugs, then this PR will get attention
<zyga> hangun: hi
<zyga> hangun: in that case can you tell me what error are you seeing now?
<hangun> zyga:  thanks.   I do this commands: $ snap install hello-world. $ hello-world .   Then it output error like this:
<hangun> zyga:  error: can not perform the following tasks:  cannot bind-mount the mount namespace file /proc/4598/ns/mnt - hello-world.mnt : permission denied
<hangun> zyga: host computer: snap version is 2.22.3 .   target board: snap version is 2.22.2
<hangun> zyga:  core_1082.snap
<zyga> hangun: can you please run "dmesg | grep DENIED"
<hangun> zyga:  http://pastebin.com/2xJZv3YF
<om26er> zyga: hey! is there a way to login to snapd without a prompt for password ? aka a way to pass password through stdin or something ?
<ogra_> om26er, use sudo and a sudoers.d file snippet ?
<om26er> ogra_: I meant past sudo i.e. providing the password for snapd user
<ogra_> if you use sudo you dont get asked for a password
<ogra_> at least i dont
<om26er> on desktop:
<om26er> snap login om26er@gmail.com
<om26er> Password of "om26er@gmail.com":
<ogra_> yeah, dont use login at all
<ogra_> then sudo just works
<om26er> ogra_: need to login for very specific testing :)
<ogra_> on my desktop workstation i never logged in with snapd and can use all my scripts with sudo
<ogra_> ah, tricky then
<om26er> ogra_: you can't download a private snap ;)
<ogra_> yeah, nothing i touch :)
<zyga> hangun: looking
<zyga> om26er: not that I know of
<zyga> hangun: thanks
<zyga> hangun: the 3.10 work I did dind't include apparmor so you got one bug less but still one bug to worry about
<zyga> hangun: let me check one thing, I think it is applicable
<zyga> hangun: and you can do a simple experiment locally to confirm
<zyga> om26er: but you can login over the rest API I think
<zyga> om26er: or more precisely -- login locally in any way and save the login data
<hangun> zyga: how I do the experiment?
<zyga> hangun: edit the apparmor profile for snap-confine
<zyga> hangun: can you tell me if you have applied all of the apparmor patches to your kernel?
<zyga> hangun: can you paste `find /sys/kernel/security/apparmor` please
<santoshmahto> alecu : hi
<alecu> santoshmahto: hi!
<hangun> zyga: http://pastebin.com/7RfHaw0v
<zyga> hangun: hmm,
<zyga> hangun: can you come again tomorrow at this time, this is something that jdstrand knows best but he's off today (US holidays)
<hangun> zyga:  OK, thanks!   it's a bit late in my timezone
<zyga> hangun: I remember you reported the bug
<zyga> hangun: oh, perhaps send an email out with all the details (the bug report is fine, let's just add more data to it)
<zyga> hangun: jdstrand is very busy but I'm sure he can get back to you in a few days
<zyga> hangun: I see two ideas to experiment:
<zyga> hangun: check if you can get a more recent kernel
<zyga> hangun: or check if your apparmor support in that kernel is what is in the ubuntu kernel now
<zyga> hangun: I heard that apparmor is pretty self-contained and it is easy to port latest fixes
<zyga> hangun: the issue feels kernel related but without a way to experiment locally it's hard for me to say exactly what is wrong
<zyga> hangun: I bet that across the versions apparmor evolved
<zyga> hangun: and that the profile we have for snap-confine (that's what the error is about) is tuned for the latest version we use
<zyga> hangun: so maybe there's something simple we can do to make it work there
<zyga> hangun: or maybe not and you need to port the more recent apparmor patches
<zyga> hangun: but again, hard to say remotely
<hangun> zyga:  the apparmor patches may be out of date, I ported these patches more than half year ago.
<zyga> hangun: I see
<zyga> hangun: check out master and see what's there, maybe the delta is small
<zyga> hangun: I'm not sure actuall, not a kernel developer
<zyga> hangun: the 2nd idea is to disable apparmor in your build
<zyga> hangun: no security but it'd start to do stuff
<hangun> zyga: thanks
<zyga> hangun: for that the easiest way actually is to change /etc/os-release so that it doesn't say ID=ubuntu
<cappe> I'm having issues with snap and snapd. trying to use it, it states it cannot communicate with server localhost, snapd-snap.socket cannot be found
<zyga> hangun: and re-build snap-conifne (it's not dynamic enough yet)
<zyga> cappe: hey, can you tell us more about the environment you are in? which OS, version, snap --version, etc
<cappe> Linux silver 4.4.0-63-generic #84-Ubuntu SMP Wed Feb 1 17:20:32 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
<cappe> snapversion 2.22.3
<cappe> snapd: unavailable :S
<cachio> niemeyer, if you have any time, here there is a change to review in spread https://github.com/snapcore/spread/pull/25
<mup> PR spread#25: Adding capability to write xunit report with the task suites and results <Created by sergiocazzolato> <https://github.com/snapcore/spread/pull/25>
<hangun> zyga:  target board's  snap veriosn is 2.22.2, it it OK?
<zyga> hangun: yes, though we released .3 lately
<zyga> cappe: can you look at what is the status of the service with "systemctl status snapd.service"
<cappe> I have reinstalled snapd, does it take a reboot?
<zyga> cappe: no, no reboot required
<cappe> Failed to get properties: No such interface ''
<zyga> cappe: oh, interesting
<zyga> mvo: ^
<zyga> cappe: can you do: journalctl -u snapd.service | pastebnit
<zyga> (install pastebin if you need to)
<mvo> zyga: thank you
<cappe> pastebnit? is that right spelled?
<zyga> cappe: pastebinit is the package
<zyga> cappe: sorry, I made a typo above
<zyga> paste-bin-it without the dashes :)
<cappe> http://paste.ubuntu.com/24034163/
<zyga> hmmm
<zyga> empty
<zyga> hmm
<zyga> cappe: how about 'sudo systemctl start snapd.service'
<cappe> same fail
<cappe> Unknown unit: snapd.service
<mup> PR snapcraft#1151 closed: channel maps: remove 'Series' from output <Created by josepht> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1151>
<cappe> mvo: I think you have encoutered this before, the solving of this issue, I'm reading about it at launchpad.net
<cappe> did you guys solve it?
<cappe> snap doesnt work: error: cannot communicate with server
<cappe> that's the same error I have
<cappe> (status: incomplete) guess not
<mvo> cappe: unfortunately not, what is the bugnumber?
<zyga> cappe: hmm, apt-cache policy snapd
<mvo> (or apt list -a snapd)
<cappe> Bug #1631514 reported by eduardo on 2016-10-07
<mup> Bug #1631514: snap doesnt work. error: cannot communicate with server <snapd (Ubuntu):Incomplete> <https://launchpad.net/bugs/1631514>
<mup> PR snapcraft#1147 closed: snapcraft.yaml: 96boards: minimal changes to get a working kernel snap <Created by piso77> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1147>
<cappe> snapd/xenial-updates,now 2.22.3 amd64 [installerat]
<cappe> snapd/xenial 2.0.2 amd64
<cappe> so I need to wait for a fix then?
<zyga> cjwatson: hey, what can I do to sync one github repo to launchpad in a real-time manner
<zyga> cjwatson: can I use some hook magic to trigger that?
<zyga> cjwatson: a webook on the GH side to pull from LP
<cjwatson> zyga: are you just trying to build a snap from a github repo?
<ogra_> cjwatson, https://code.launchpad.net/~snappy-dev/+snap/core moved to GH
<zyga> cjwatson: we have a GH->LP mirror
<zyga> cjwatson: and existing build pipeline in LP
<zyga> cjwatson: I'd like to make the changes move faster for this repo
<ogra_> the prob is that we would now always have to click the import button on the branch to make sure everything is in sync
<cjwatson> LP doesn't accept webhooks yet I'm afraid
<ogra_> cjwatson, any way to special-case this one branch to run on a shorter schedule at least ?
<cjwatson> you can write something that accepts a webhook and calls the necessary API calls
<cjwatson> no sorry
<zyga> cjwatson: could I write a small service that gets poked by GH and then uses LP API to sync?
<cjwatson> yes
<zyga> cjwatson: thanks, I think that will do then
<cjwatson> sounds like you should be able to use build.snapcraft.io once it's ready
<zyga> cjwatson: can you point me to the API method for updating a git import?
<zyga> cjwatson: yes, I think we want to
<cjwatson> https://launchpad.net/+apidoc/devel.html#code_import-requestImport
<zyga> cjwatson: does it just set up the (same) process?
<zyga> cjwatson: or does it do something different at some level
<cjwatson> that is part of it
<zyga> cjwatson: or -- can we use it now? (build.snapcraft.io)
<cjwatson> it doesn't use code imports, it has LP build directly from the GH repo instead
<cjwatson> it's not quite ready
<zyga> hmmmm
<cjwatson> LP building directly from the GH repo *requires* webhooks, since LP has no way to detect pushes otherwise
<ogra_> will it still have a build button ? so you dont have to bump the tree every time you want to trigger a build ?
<zyga> cjwatson: could we change the recipe for the snap so that it only builds from GH and webhooks?
<zyga> cjwatson: or woud something break today/
<cjwatson> ogra_: not in the current design
<ogra_> hrm
<zyga> I think it's fine to keep the rest of the workflow as is
<cjwatson> zyga: you might need to create a new snap, I forget
<zyga> we just need the helper webhook-poke-lp service
<cjwatson> zyga: please see the API docs though, I'm swamped with building BSI this week
<zyga> OK
<zyga> thanks for your help!
<cjwatson> (we have a short deadline)
<ogra_> zyga, well,we still want scheduled builds and the ability to build on demand ... we need to make sure thats still existing if we move over
<zyga> ogra_: it will say as is
<zyga> ogra_: I'll just make the GH->LP push happen faster
<ogra_> zyga, well, regarding the snapcraft.io integration
<zyga> and we can use that for gadgets as they have the same workflow
<cjwatson> webhook -> code_import.requestImport is the smallest change for you, I think
<zyga> ogra_: nah, we won't need that now
<ogra_> ok
<zyga> as cjwatson said :)
<mup> PR snapd#2892 opened: httputils: ensure User-Agent works accross redirects <Created by mvo5> <https://github.com/snapcore/snapd/pull/2892>
<Son_Goku> mvo, I'd appreciate if the selinux PR could be merged as soon as reasonably possible, since I'm working on a dependent PR to add centos/fedora packaging to snapd repo
<mvo> Son_Goku: sure, on it
<zyga> Son_Goku: hey o/
<Son_Goku> thank you
<zyga> Son_Goku: we had a busy week-end
<Son_Goku> did you now?
<zyga> Son_Goku: I'm falling on my face but I'll tell you once the dust settles
<zyga> Son_Goku: we'll do a post mortem
<Son_Goku> something terrible happened?
<Son_Goku> post mortem implies horribleness
<zyga> Son_Goku: hehe, kind of, we did do a silly thing that quickly showed up on our radar
<zyga> Son_Goku: don't do releases on friday they say :)
<zyga> that's wise :D
<Son_Goku> yes, we have a thing at work called "read only Fridays"
<Son_Goku> don't do releases on Fridays, as no one likes the hell that it brings
<Son_Goku> zyga: for now, be my merge monkey! https://github.com/snapcore/snapd/pull/2878
<mup> PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
<zyga> Son_Goku: yeah, I justs asked gustavo to review it
<zyga> Son_Goku: I need to finish a small branch that needs to go into 2.22.4 quickly
<zyga> .4 because 2.22 had less luck
<Son_Goku> mrrrrgh
<niemeyer> Son_Goku: Heya
<niemeyer> Son_Goku: Trying to understand the delta in licensing there
<niemeyer> Son_Goku: What's the rationale for the v2 vs. v3?
<Son_Goku> niemeyer: I want it to remain compatible with fedora-selinux
<Son_Goku> I originally derived the structure from a selinux module from upstream selinux-policy
<Son_Goku> there's literally no reason for me to break license compatibility
<niemeyer> Son_Goku: If you derived code, shouldn't that be explicit in the (c) notice?
<Son_Goku> it also allows for distributions deriving from fedora selinux policies to merge the module into their selinux policy package if they want
<Son_Goku> hmm, probably
<Son_Goku> I can add a line in the notice for Red Hat copyright
<Son_Goku> though I didn't really use much in the way of "code"
<Son_Goku> just the skeleton
<niemeyer> Son_Goku: Yeah, that's the right thing to do.. we still have the option to relicense as v3 per the license terms itself, but then it'd actually be a more clear departure
<niemeyer> Son_Goku: As it is now it's awkward, because it looks like you're creating code yourself and contributing into snapd with your own license
<niemeyer> Which means _that's_ the license "break"
<Son_Goku> makefile is mine though
<Fohlen-> heya there. I am using the python plugin and having some strange issues. The following is happening to me: http://pastebin.com/RZnQP3GY
<niemeyer> Son_Goku: Sure.. for content you are creating for snapd, the normal thing to do is to license per the project license
<Son_Goku> niemeyer: would this work "Skeleton derived from fedora selinux-policy, Copyright (C) 2016 Red Hat, Inc."?
<niemeyer> Son_Goku: Sounds good
<Son_Goku> adding it now
<Son_Goku> one sec
<Son_Goku> niemeyer: done, rewrote the commit for adding the header to include the extra comment
<Son_Goku> https://github.com/snapcore/snapd/pull/2878/commits/f04da024b6221f539e50466ac7c6a0a21dcda837
<mup> PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
<niemeyer> Looking again
<EEight> Hi guys, I have a problem with snap and the interface camera:
<EEight> sudo snap connect myapp:camera ubuntu-core:camera I have this error: snap "ubuntu-core" has no slot named "camera"
<zyga> EEight: try sudo snap connect myapp:camera
<zyga> EEight: that does the right thing and it finds the core snap (no longer called ubuntu-core) and the matching interface
<EEight> will do but still when snapping it's not working automagically
<EEight> https://bugs.launchpad.net/snapcraft/+bug/1609577
<mup> Bug #1609577: Docs: Your First Snap webcam-webui does not work once installed <Snapcraft:New> <https://launchpad.net/bugs/1609577>
<niemeyer> Son_Goku, zyga: Okay, we should eventually ask jdstrand to have a pass over this, but let's get it in now
<Son_Goku> niemeyer: it has no effect for you guys anyway
<Son_Goku> I didn't wire up the debian packaging to build the module
<Son_Goku> mainly because I don't know how
<niemeyer> Son_Goku: Well, of course it does.. that's why we're getting it in! :)
<Son_Goku> well, you guys being ubuntu people :)
<niemeyer> Son_Goku: We care about distros that depend on selinux too..
<Son_Goku> but yes, thanks
<Son_Goku> well, the debian hardened guys will appreciate it once there is a snapd-selinux module for debian, too
<Son_Goku> err, snapd-selinux package
<niemeyer> +1
<Son_Goku> I did make it debian-safe :)
<Son_Goku> I'm not mean, after all :P
<EEight> zyga: yes it's working when sudo snap connect myapp:camera - but of course I cannot ask my user to run this command. Is there a way to make it works out-of-the-box?
<zyga> Son_Goku: woot, thanks for working on this for so long :)
 * Son_Goku sighs
<zyga> EEight: yes, your snap can contain a declaration that will make this happen by default
<Son_Goku> I learned a lot about selinux verbiage
<zyga> EEight: it is something the store can give you, I'm not sure what is the process for this
<zyga> EEight: I think that jdstrand is the best person to ask; he should be around tomorrow
<Son_Goku> niemeyer: I'd be super pleased if snapd's official dsc packaging also shipped the selinux module
<zyga> Son_Goku: I think we can look at that for debian 10
<Son_Goku> zyga: it can also be available as stretch backports
<niemeyer> Son_Goku: I don't know all the details involved, but on principle it certainly sounds fine
<zyga> Son_Goku: yeah, I think we will polish it release by release
<zyga> Son_Goku: it would be good to find someone that cares about debian and selinux there
<Son_Goku> oh come on!
<Son_Goku> I didn't even change anything and travis broke
<Son_Goku> zyga, niemeyer: I hate travis :/
<zyga> Son_Goku: no that's us
<zyga> Son_Goku: we did some shuffling with the core snap
<zyga> Son_Goku: busy weekend
<Son_Goku> ah
<zyga> Son_Goku: we'll try to revert things to as they were over the next 18 hours
<zyga> Son_Goku: that's why 2.22.4 goes out soon
<zyga> Son_Goku: the store was hit with a bug where snapd would download stuff over and over
<Son_Goku> those are the best bugs
<zyga> Son_Goku: and we looked at preventing that, figuring out why it happens and fixing the issue
<niemeyer> zyga: That's a massive failure.. what happened there?
<zyga> niemeyer: in the spread test suite?
<niemeyer> zyga: I mean, why is the test exploding in that way specifically?
<niemeyer> Yeah
<zyga> niemeyer: the core snap that is published now has no configure hook
<zyga> niemeyer: and tests check for that
<zyga> unless something new broke that was what was failing all day today
<zyga> niemeyer: mvo wanted not to change the tests for that (federico suggested this)
<niemeyer> zyga: Ugh :(
<niemeyer> Yeah, well.. it does sounds sane.. we want this working
<niemeyer> Let's get 2.22.4 out then
<zyga> niemeyer: the idea is that now we send and update that gives us visibility into errors and should apply anywhere
<zyga> niemeyer: and next we enable the configure hook
<zyga> niemeyer: and see the actual errors
<niemeyer> +1
<zyga> niemeyer: so after 2.22.4 is out we'll do .5 that just enables the hook
<fgimenez> zyga, niemeyer if you need to do a quick local spread run just commenting out the "snap set core refresh.disabled=true" lines in tests/lib/prepare.sh is enough for getting the current master working
<fgimenez> if the test you run doesn't involve "snap set core", of course
<mup> PR snapd#2893 opened: tests: bail out if core snap is not installed <Created by zyga> <https://github.com/snapcore/snapd/pull/2893>
<mup> PR snapd#2892 closed: httputils: ensure User-Agent works accross redirects <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2892>
<linggao> Hi where  can I find a list of Ubuntu core relases and their dates?  I am trying to trouble shooting something. thanks
<King_InuYasha> zyga_: why did everything fail? https://github.com/snapcore/snapd/pull/2878
<mup> PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
<King_InuYasha> oh
<King_InuYasha> this is related to core snap funkiness
<King_InuYasha> mrrr
<linggao> Hi all, we are using current snap core (revision version 16.04.1  revision 1226), we got kernal panic when intalling our own snap.
<linggao> We'd like to use an old snap core, how do we find out the old core rease dates so that we can pick the core that was working for us?
<linggao> btw, this is for PI2 and PI3.
<kalikiana_> linggao: snap list core will tell you the revision
<kalikiana_> If that's what you're asking
<linggao> kalikiana_,  I know the current version. I would like to get a history of the old revisions.
<kalikiana_> linggao: To check the previous revisions you can ls /snap/core/
<kalikiana_> That's the best way I know of to see recent updates
<kalikiana_> 'snap changes' would be what I'd like to say, but it doesn't tell you that
<linggao> kalikiana_, my node only has 1226.  is there a web site that list all the revisions and their dates?
<zyga_> King_InuYasha: hey
<King_InuYasha> hey
<zyga_> King_InuYasha: yeah, we're in an emergency a little and this is expected; it should be back to normal in a day
<zyga_> linggao: hey, what was the kernel panic?
<zyga_> linggao: you cannot download releases other than the one that is current I'm afraid
<linggao> zyga_,  kernel panic happend when mounting our snap. (on pi2 and pi3).  [336032.404195] Unable to handle kernel NULL pointer dereference at virtual address 00000008
<linggao> [336032.417227] pgd = b66fc000
<linggao> [336032.422448] [00000008] *pgd=21359831, *pte=00000000, *ppte=00000000
<linggao> [336032.432174] Internal error: Oops: 17 [#1] SMP ARM
<zyga_> linggao: can you report this please
<linggao> zyga_, can we do `snap install --revision xxx core`?
<zyga_> linggao: no, you can only do that to the snap you own
<zyga_> linggao: also old core had the same kernel (kernel is a separate snap)
<zyga_> linggao: so I'm not sure that would help you
<linggao> zyga_, we know that upgrading to the latest kernel resoves this problem
<zyga_> linggao: as in latest mainline kernel?
<zyga_> linggao: do you use the official pi2/3 kernel snap or do you roll your own?
<linggao> But we are trying to go back to see where the problem was. It used to work. We are trying to figure out if it was because of our own snap.
<linggao> We build pi2 images based on your offical pi2/pi3 images.
<linggao> IMAGE="ubuntu-16.04-preinstalled-server-armhf+raspi2.img"
<linggao>     URL="http://cdimage.ubuntu.com/ubuntu/releases/16.04/release/$IMAGE.xz"
<linggao> Now we have to run 'apt upgrade' to upgrade to the latest kernl to resolve that problem
<linggao> It uesed to work.
<zyga_> linggao: ah, I thought you were using core images, those are classic images with snapd
<linggao> That's why we susppect that core could be a problem.
<zyga_> linggao: in any case, please report the problem
<zyga_> linggao: attach the kernel log
<zyga_> linggao: attach the snap if you can
<linggao> I have reported a similar problem with snap refresh. https://bugs.launchpad.net/snapd/+bug/1664368
<mup> Bug #1664368: snap refresh hangs on arm architecture <snapd:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1664368>
<zyga_> linggao: that seems to have been fixed
<linggao> zyga_, when I do 'snap list' I see 'core'.  Was core got installed when I install my own snap?
<linggao> zyga_, my boss told me to figure out why the old kernel worked before. :(
<mup> PR snapd#2894 opened: snapstate: allow for 10 retries for the core transition <Created by mvo5> <https://github.com/snapcore/snapd/pull/2894>
<zyga_> linggao: yes
<zyga_> linggao: on a deb based system you can install the old kernel deb but those are not kept aroud either
<zyga_> linggao: if you have it just install it
<zyga_> linggao: or rebuild it from sure
<linggao> zyga_, our theory is that since we still use the old kernel, and things get broken, it must be core whcih might be new that caused the kernel panic.  That's why I was looking for old cores to test our theory.
<zyga_> linggao: well, that's a little odd, the kernel contains nothing that ia a part of the equation
<zyga_> linggao: you can just mount your squashfs without the core at all
<zyga_> linggao: if that oopses, it oopses, the kernel is broken
<zyga_> linggao: there's no core that you need to experiment with this
<linggao> The reason we cannot support the new kernel yet is because it does not work with the onboard widi for pi3.
<linggao> I meant wifi
<zyga_> linggao: did you report a bug about that too?
<linggao> not yet.
<linggao> zyga_, here is the whole story, maybe you can help us figure out why.  We built our pi image on 01/14/2017 beased on http://cdimage.ubuntu.com/ubuntu/releases/16.04/release. It had kernel version 4.4.0-1009-raspi2. We have been testing our snap with this image successfuly until Feb 12th when we start seeing kernel panic during snap mounting. On our side, we have new rleases of for our snaps. We are trying to figure out what ar
<linggao> e the variables that cause the kernel panic.
<linggao> So base image is the same, the variables could be the new version of core or our snap.
<zyga_> linggao: do you update your images?
<zyga_> linggao: do you rebuild your snap or was it fixed and never ever ever touched since?
<zyga_> linggao: building squashfs is not very deterministic last time I looked
<linggao> We did not upgrade the bease image (the upgrade was done when we build the pi image on 01-14-2017)
<zyga_> linggao: if you build a squashfs from same stuff you will not get the same output
<linggao> We keep releasing new revisions for our snap.
<zyga_> linggao: maybe you found an interesting bug in the squashfs support
<zyga_> linggao: quick idea, copy your snap to a amd64 kernel
<zyga_> linggao: and see if that can be mounted
<linggao> zyga_, no problem on amd64.
<zyga_> linggao: if that oopes on other architectures then preserve that snap
<zyga_> linggao: and please report the full backtrace
<zyga_> linggao: I don't know what realyl oopeses
<zyga_> linggao: do you have the stack trace?
<zyga_> linggao: does it reliably oopse on a pi3?
<linggao> bte, after reboot the pi, the snap got intalled and can work.
<linggao> yes, it always gets kernel panic on pi3 now.
<zyga_> linggao: perfect, keep that pi for analysis, report the issue, have some kernel people looking at it
<zyga_> linggao: make sure you can oops the kernel just by using mount
<zyga_> linggao: it's a pure kernel issue
<zyga_> linggao: and don't change the snap file, it really needs to be that one that oopes
<zyga_> linggao: if you show me the bug report with the kernel trace I can offer ideas but I'm not a kernel engineer
<zyga_> linggao: and if you can ooops just with mounting then the core snap is irrelevant
<linggao> zyga_, the kernel trace is in that bug I have reported. https://bugs.launchpad.net/snapd/+bug/1664368.  They told me to upgrade to the new kernel to see.
<mup> Bug #1664368: snap refresh hangs on arm architecture <snapd:Fix Released> <linux-raspi2 (Ubuntu):Fix Released by p-pisati> <https://launchpad.net/bugs/1664368>
<linggao> It is exactly the same.
<zyga_> linggao: looks like a bug in the mount system, there were plenty of those fixed
<linggao> The new kernel works. But my boss asked me to find out why old one stopped working.
<zyga_> linggao: old one was buggy, that snap caused the bug to surface
<zyga_> linggao: not sure what you want to find out, check which changes landed to namespaces and mount propagatinon
<zyga_> linggao: but note that you must be able to cause this with mount alone
<linggao> zyga_, because the new kernel does not work with the onboard wifi for pi3. :-)
<zyga_> linggao: if you do other things then maybe just new core version mounts more things than before
<zyga_> linggao: well, have some kernel peopel look at that
<zyga_> linggao: I don't know about this, we have people use wifi on the current kernel on pi3 all the time
<zyga_> linggao: even today I think ogra_ was doing this
<linggao> zyga_, that's good to know.
<zyga_> linggao: if you want to see what may have changed in the core look at the changes to snap-confine
<zyga_> linggao: it's in github.com/snapcore/snapd
<zyga_> linggao: look at cmd/snap-confine there
<zyga_> linggao: pick your time window, the history contains all the code since day one
<zyga_> linggao: I don't remember when you said the first image was from
<zyga_> linggao: I wonder what version of snap-confine was used ont it
<zyga_> linggao: can you run /usr/lib/snapd/snap-confine --version?
<linggao> snap-confine 2.20.1ubuntu1
<linggao> this is on pi2 which also had kernal panic.
<zyga_> linggao: and when it worked?
<linggao> before Feb 8.
<linggao> Jan 14 to Feb 8, it worked.
<zyga_> you'd have to map those to versions of snap-confine on the system
<linggao> I think it broke sometime between Feb 8 to Feb 12.
<zyga_> linggao: note that core is irrelevant again
<zyga_> linggao: because snap-confine is a separate package
<zyga_> linggao: and snapd doesn't use the version from the core
<zyga_> linggao: let me know what you find otu
<linggao> Is it part of the core (snap) ?
<zyga_> linggao: what?
<zyga_> linggao: snap-confine, yes, but it is not used
<zyga_> linggao: it is only used there if you are running an all-snap system
<zyga_> linggao: (aka a non-classic distro)
<linggao> sorry, I just want to figure out when snap-confine got installed.
<zyga_> linggao: snap-confine is a dependency of snapd
<zyga_> linggao: and nowadays it is a single package
<linggao> Was it built in my bease image or is it downloaded when my snap was installed.
<zyga_> linggao: so core (snap) is not interesting but snapd (debian package) is
<zyga_> linggao: it's a part of snapd
<linggao> The date of /usr/lib/snapd/snapd is Jan 3.
<linggao> That means it has not been changed.
<zyga_> linggao: can you mount your snap on the old kernel, without using snapd, to cause the oops?
<zyga_> linggao: just mount -o ro /path/to/some/snap /mnt
<mup> PR snapcraft#1154 opened: Expose parallel_build_count to scriptlets (LP: #1666271) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/1154>
<zyga_> Conan_Kudo: what's with the new identity?
<linggao> zyga_, yes, I can.
<zyga_> linggao: then this is not core related IMHO, do you agree?
<linggao> zyga_, I do not know enough to make a decision. :-)
<zyga_> linggao: remove all of snapd
<zyga_> linggao: and mount the snap
<zyga_> linggao: do you see that it is not core related now?
<linggao> how to remove all of snapd?
<zyga_> linggao: just purge the package
<zyga_> linggao: apt remove --purge snapd
<zyga_> warning: this will remove all snaps
<zyga_> and all of their state
<linggao> zyga_, I removed the snapd and did mount again, it worked.
<zyga_> linggao: ah, that's interesting then
<zyga_> linggao: so it is not this that is causing the issue
<mup> PR snapd#2894 closed: snapstate: allow for 6 retries for the core transition <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2894>
<mup> PR snapd#2895 opened: first pass at client messaging around modes <Created by chipaca> <https://github.com/snapcore/snapd/pull/2895>
<mup> PR snapd#2896 opened: Headers over redirects <Created by chipaca> <https://github.com/snapcore/snapd/pull/2896>
#snappy 2017-02-21
<linggao> zyga_, sorry, I just want to mention that we are using Ubuntu 16.04 on rpi2/rpi3.
<linggao> then we installed snapd.
<linggao> Hi ogra_, zyga_ told me that you are using on-board wifi on rpi3. Can you let me know what is your os  and kernel version?  I am using Ubuntu 16.04.
<mup> PR snapcraft#1155 opened: beta <Created by snappy-m-o> <https://github.com/snapcore/snapcraft/pull/1155>
<Son_Goku> why the hell is a bot opening up PRs?!
<f_fox> Anyone know why snapctl would hang during a hook/when run inside a snap? Nothing shows up on dmesg and it doesn't seem to matter what the context is.
<f_fox> It happens during the configure hook of the core snap, for instance, but if I skip that task by editing state.json manually everything else seems to work fine.
<f_fox> actually scratch that, I just tried it on a fresh image and it seems to work now
<wxl> anyone have a clue where to file a bug against a particular snap?
<wxl> in this case, speaking specifically of vlc
<mup> Bug #1666386 opened: Snap apps do not work on Lubtuntu <Snappy:New> <https://launchpad.net/bugs/1666386>
<wxl> yeah i'm fixing that
<jjohansen> zyga: the kernels with the fixes are publishing, I'm not sure when these kernels will get rolled into all snaps
<zyga> jjohansen: hey, thank you for noticing the question earlier, is that -62 or -63 that should have the fix?
<zyga> f_fox: hey, known issues
<zyga> f_fox: we disabled the configure hook while we untangle everything
<f_fox> zyga: that explains it, thanks
<zyga> f_fox: we experienced a sequence of bugs when we introduced the configure hook on the core
<zyga> f_fox: a portion of devices did not update successfuly
<zyga> f_fox: we're investigating and trying to understand and fix the issue but for now we disabled the configure hook to let devices update
<jjohansen> zyga: good question so far only zesty has published, and the bug update is reporting as fixed in 4.10.0-8.10 but my tree is saying its in 4.10.0-9.11
<jjohansen> I am going to have to pull down the kernel and test
<zyga> jjohansen: what is 8.10 and 9.11?
<jjohansen> zyga: zesty kernels, the only ones that have published yet, the new kernels are publishing but it will take a while for all the releases
<jjohansen> I expect they will finish some time tonight, zesty obviously goes first as it doesn't have the regression and USN work that xenial and yakkety kernels have
<zyga> jjohansen: I see, thanks
<zyga> jjohansen: I'll run a check to see that the bug is fixed on zesty images
<mup> PR snapd#2889 closed: errtracker: add support for error reporting via daisy.ubuntu.com <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2889>
<zyga> ogra_: hey
<zyga> ogra_: I was wondering about the joule board
<zyga> ogra_: do you know who supports that at canonical?
<zyga> ogra_: I would like to publish the gadget snap to github
<zyga> ogra_: and to see if we can build
<mup> PR snapd#2897 opened: errtracker: mock machine-id path to fix FTBFS in sbuild <Created by mvo5> <https://github.com/snapcore/snapd/pull/2897>
<mup> PR snapd#2897 closed: errtracker: mock machine-id path to fix FTBFS in sbuild <Created by mvo5> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2897>
<mup> PR snapd#2898 opened: many: merge 2.22.5 back to master <Created by zyga> <https://github.com/snapcore/snapd/pull/2898>
<ogra_> zyga, JohnAgosta can get you in contact with the right people
<zyga> ogra_: thanks!
<zyga> ogra_: how are you?
<ogra_> okayish ...
<ogra_> :)
<ogra_> trying to keep up with 600 telegram messages atm :P
<_prasen_> hi
<_prasen_> why does snap install try to download the core snap
<_prasen_> nub
<_prasen_> pls hlp
<ogra_> _prasen_, all snaps are executed in context of the core snap, that is how snaps get distro and release independent
<_prasen_> using 16.04
<_prasen_> doesnt it already have a snappy core?
<ogra_> no
<_prasen_> if i want to develop for ubuntu core without any h/w
<_prasen_> i need to install core using kvm
<_prasen_> ?
<_prasen_> the core snap which gets installed isnt the Ubunbtu Core right?
<_prasen_> I need to install Ubuntu Core on a pi.
<_prasen_> so was trying to run ubuntu core inside kvm
<_prasen_> but on the ubuntu host of 16.04
<_prasen_> I am stuck at snap install trying to "get" due to corporate proxy
<_prasen_> running on kvm till i get hands on the pi
<ogra_> _prasen_, well, if you only want to develop snap packages you can do that directly on your desktop without kvm
<_prasen_> yes
<_prasen_> @oga
<nothal> _prasen_: No such command!
<_prasen_> oga : did not knew about the core snap usage
<_prasen_> was thinking of ssh into the kvm running core and installing snaps developed at the host
<_prasen_> nothal : which cmd
<_prasen_> even my host is a vm :(((
<mup> PR snapd#2899 opened: Kmod use spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2899>
<zyga> _prasen_: hey
<zyga> _prasen_: with the way snappy works you don't need any separate VM
<zyga> _prasen_: just develop snaps locally
<zyga> _prasen_: using snapcraft
<zyga> _prasen_: and install them on your own system
<ogra_> zyga, but what if the company proxy doesntz let you though :)
<zyga> ogra_: I snapd can respect proxy settings for a while now
<zyga> _prasen_: if that's the problem for you I can show you how to proxy your stuff
<ogra_> zyga, depedns wehat the proxy blcks ;)
<zyga> ogra_: true
<_prasen_> my proxy is blocking
<zyga> _prasen_: I think you need to work with your IT to open up the *.ubuntu.com part and the CDN that snappy uses to distribute snaps
<ogra_> _prasen_, did you configure your machine properly for the proxy ?
<_prasen_> search.apps.ubuntu
<_prasen_> yes
<_prasen_> i am on iy
<_prasen_> it*
<zyga> _prasen_: there are plenty of domains under *.ubuntu
<zyga> _prasen_: or just cheat and tether your phone ;-)
<zyga> (you can get fired for that though)
<_prasen_> yes I did that once
<_prasen_> ;D
<_prasen_> tethered and ran
<_prasen_> yes
<_prasen_> would need to get permissions for tat
<_prasen_> can i download the core snap from any diiferent location other than *.ubuntu
<ogra_> well, ifg you have to ask for that you can as well just ask for proxy opening for your machine to the respective urls
<_prasen_> launchpad doesnt have it
<zyga> _prasen_: no, and you also need assertions
<zyga> _prasen_: techically snapd talks to the store at *.ubuntu.com and then gets redirected to a CDN
<zyga> _prasen_: so the core snap is really elsewhere
<_prasen_> okay
<_prasen_> the link really specifies a whole lot
<zyga> _prasen_: but hey, they opened IRC for you
<zyga> _prasen_: please do let us know, it is an intereting problem to solve
<zyga> _prasen_: which URLs are needed to use snapd behind a corporate proxy
<_prasen_> html which I dont understand
<zyga> _prasen_: ?
<_prasen_> okay
<_prasen_> wait
<_prasen_> I'll try to share the link here
<_prasen_> yes it is interesting to solve
<_prasen_> but the main work that  i have to do
<_prasen_> i am stuck there
<_prasen_> xP
<_prasen_> Get https://search.apps.ubuntu.com/api/v1/snaps/details/core?channel=stable&fields=anon_download_url%2Carchitecture%2Cchannel%2Cdownload_sha3_384%2Csummary%2Cdescription%2Cdeltas%2Cbinary_filesize%2Cdownload_url%2Cepoch%2Cicon_url%2Clast_updated%2Cpackage_name%2Cprices%2Cpublisher%2Cratings_average%2Crevision%2Cscreenshot_urls%2Csnap_id%2Csupport_url%2Ctitle%2Ccontent%2Cversion%2Corigin%2Cdeveloper_id%2Cprivate%2Cconfinement: x509:
<_prasen_> this is the error i get
<_prasen_> mozzilla prompts me to add exception
<_prasen_> to this
<_prasen_> if i do
<_prasen_> it shows 405 Method not allowed
<mup> PR snapd#2862 closed: cmd/snap, store: change error messages to reflect latest UX doc <Created by pete-woods> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2862>
<_prasen_> ogra : should I able to see interfaces before the core snap is present on 16.04
<_prasen_> ?
<ogra_> i dont think so, no
<_prasen_> knowing that helps a lot
<_prasen_> ty
<_prasen_> nowhere in the official doc
<_prasen_> it is said that the first time eecution of snap install will get the core snap first
<_prasen_> or the docker snap
<_prasen_> tis weird
<_prasen_> or any other online resource fails to mention that
<ogra_> it shouldnt get rthe docker snap for sure, only the core snap
<_prasen_> okay..
<ogra_> (unless you did snap install docker indeed)
<ogra_> (then it would try to get both)
<_prasen_> oh some guy in the office said it would do both
<_prasen_> he seems pretty unreliable though
<_prasen_> ;p
<didrocks> stgraber: hey! I don't find the images:ubuntu-core/16 image and getting an error: not found, was the image removed?
<didrocks> stgraber: so, after listing images, I noted that I have 2 available (x86 and i386). I did lxc launch images:ubuntu-core/16/amd64, but getting a download error "Retrieving image: 100% (961.30MB/s)error: multipart: NextPart: EOF" (getting that constantly)
<mup> PR snapcraft#1156 opened: python plugin: use stage headers if applicable <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1156>
<ogra_> jdstrand, do you see jenny murphys question about the ppp interface ? looking at interfaces/builtin/ppp.go it looks like she should just be able to run pppd and write configs to /etc/ppp directly
<ogra_> or am i wrong here
<sergiusens> morphis: hey, mind doing a bit of verification for LP: #1665759 ?
<mup> Bug #1665759: [SRU] New stable micro release 2.27.1 <verification-needed> <snapcraft (Ubuntu):Fix Released> <snapcraft (Ubuntu Xenial):Fix Committed> <snapcraft (Ubuntu Yakkety):Fix Committed> <snapcraft (Ubuntu Zesty):Fix Released> <https://launchpad.net/bugs/1665759>
<morphis> sergiusens: sure, is that already available on the launchpad builders?
<morphis> or still in proposed?
<sergiusens> morphis: in proposed
<morphis> ok
<sergiusens> morphis: you could try and enable proposed on launchpad builders and build if you wanted to
<sergiusens> but you get all of it
<morphis> yes
<hangun> jdstrand: hi,  I have a namespaces issue which is similar to this one ( https://bugs.launchpad.net/snappy/+bug/1665590). With zyga suggestion, I upgraded snap to the latest version(2.22.3), but the issue still be there.
<mup> Bug #1665590: When snapd is refreshed, it does not regenerate apparmor profiles when interfaces have changed <Snappy:In Progress by zyga> <https://launchpad.net/bugs/1665590>
<hangun> jdstrand:   run "dmesg | grep DENIED"  http://pastebin.com/2xJZv3YF
<mup> PR snapcraft#1153 closed: contribution guide: add commit message template <Created by kyrofa> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1153>
<hangun> jdstrand:  I try to disable apparmor option in linux kernel config and re-build it.  but still have the namespace issue. (http://pastebin.com/PvixSWNr)
<jdstrand> hangun: you need to load the profile that is in /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine. This is part of 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>
<jdstrand> hangun: do: sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine.
<jdstrand> err
<jdstrand> sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine
<jdstrand> hangun: if that works for you, feel free to 'sudo cp /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/
<jdstrand> ogra_: hi! would you mind running your machinery for linux-generic-bbb?
<ogra_> jdstrand, on it
<jdstrand> ogra_: thanks! :)
<ogra_> jdstrand, btw, did you see my ping about the ppp interface above ?
<ogra_> <ogra_> jdstrand, do you see jenny murphys question about the ppp interface ? looking at interfaces/builtin/ppp.go it looks like she should just be able to run pppd and write configs to /etc/ppp directly
<ogra_> <ogra_> or am i wrong here
<jdstrand> ogra_: I hadn't yet. you are correct-- that is the intent of the rules
<ogra_> k
<jdstrand> (and that's what they say)
<jdstrand> I think morphis wrote/uses this somewhere. if it isn't working right, should file a bug
<liuxg> sergiusens, ping
<zyga> jdstrand: hey, how are you
<zyga> jdstrand: we have some fire-fighting to do this week but I'd like to re-focus on update-ns when that is done
<ogra_> jdstrand, well, looking at https://github.com/snapcore/snapd/blob/master/interfaces/builtin/ppp.go#L34 we might perhaps wnat to also allow ttyS[0-9], after all it is likely that pppd uses serial modems
<morphis> ogra_, jdstrand: yeah it is a bit mixed in our case between the network-manager, modem-manager and ppp interface
<morphis> needs some cleanup at a future point
<morphis> ogra_: what about her using modem-manager instead of ppp directly?
<ogra_> morphis, yeah, looks like jenny murphy uses pppd directly from her management snap
<ogra_> ask in the mail thread :)
<ogra_> (or on rocket, where she is too)
<ogra_> (in the snapcraft channel)
<morphis> rocket .. too many communication channels .-)
<ogra_> yes
<ogra_> i'm slowly running out of workspaces :) everything plastered with chat tools
<ogra_> telegram, rocket, irc email ...
<jdstrand> mvo: hey, where is SNAP_REEXEC set? I see with 2.22.3 "cmd.go:59: DEBUG: re-exec disabled by user" but I don't see it in /etc/environment. I don't remember setting this. this is on xenial
<mvo> jdstrand: what version do you get with "snap version"
<morphis> ogra_: :-)
<mvo> jdstrand: might be a red-herring
<jdstrand> $ snap version
<jdstrand> snap    2.22.5
<jdstrand> snapd   2.22.5
<jdstrand> series  16
<jdstrand> ubuntu  16.04
<mvo> jdstrand: that looks good, so the message is wrong. iirc we fixed this in master
<sergiusens> morphis: well read /topic ;-)
<jdstrand> mvo: ok, thanks
<ogra_> sergiusens' favorite sentence in here recently :)
<morphis> sergiusens: yeah :-)
<zyga> jdstrand: actually, one tiny review: https://github.com/snapcore/snapd/pull/2881
<mup> PR snapd#2881: 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>
<jdstrand> zyga: ack
<bulldog> hi guys what package should i ship in my snap to allow my Qt app open external links in system's applications
<bulldog> mhall119, hi
<bulldog> ogra_, its been long , holla :)
<bulldog> xdg-open ??
<hangun> jdstrand:  there is only  a "bin" folder in /snap directory, no "core" folder.
<bulldog> lol barry
<hangun> jdstrand: how I load the profile that is in /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine?
<bulldog> help
<jdstrand> hangun: it seems you don't have a core snap installed. can you do 'sudo snap install core' ?
<jdstrand> hangun: this is on classic, right? (not all snaps?)
<sergiusens> ogra_: I;ve never been so eager to tell people to read topic ;-)
<ogra_> haha
<hangun> jdstrand: what does the "classic" mean?
<zyga> bulldog: hey,
<zyga> bulldog: you should not need to do anything anymore
<zyga> bulldog: but on the host you need to apt-get install snapd-xdg-open
<zyga> bulldog: don't put xdg-open into your snap, it will be just useless there
<jdstrand> hangun: you are running snappy on a traditional distribution, like Ubuntu, Debian, Arch, etc
<zyga> jdstrand: I believe so
<zyga> jdstrand: I was working with hangun earlier
<zyga> jdstrand: this is xenial userspace + custom kernel + snapd
<jdstrand> hangun: as opposed to 'Ubuntu Core', which is a minimal image that can work with only snaps
<zyga> jdstrand: the kernel is based off 3.10 with apparmor enablement from some time ago
<zyga> jdstrand: I had a look at the error hangun reported where snap confine cannot perform the bind mount capture from the child process
<jdstrand> zyga: hangun gave me a paste: http://pastebin.com/2xJZv3YF
<zyga> jdstrand: I'm not sure if apparmor changed in the last year that would only make the snap-confine profile work with the more current version of kernel code
<zyga> jdstrand: right, that's what I saw
<hangun> jdstrand:  I just upgraded snap version to 2.22.5.  I see there are some folders " bin , core, bubblegum96-gadget ,bubblegum96-kernel"
<mardy_> jdstrand: hi! I just wanted to make sure you are aware of bug 1664155, to know if it makes sense to you :-)
<mup> Bug #1664155: Interface hooks slots should know the name of the client snap <snapd:New> <https://launchpad.net/bugs/1664155>
<jdstrand> zyga: I don't have any idea what's going wrong, but it seemed like perhaps the snap-confine profile on disk was wrong, which I thought was because https://github.com/snapcore/snapd/pull/2810 wasn't merged
<mup> PR snapd#2810: snap: use snap-confine from the core snap <Created by mvo5> <https://github.com/snapcore/snapd/pull/2810>
<jdstrand> zyga: but based on all this new info, it seems different
<zyga> jdstrand: I think that snap-confine is used from the package (still)
<zyga> jdstrand: also hangun rebuilt snapd (by hand) so I'm not sure what is on the system now
<jdstrand> zyga: there is no rule in the profile for this: apparmor="DENIED" operation="mount" info="failed srcname match" error=-13 profile="/usr/lib/snapd/snap-confine//mount-namespace-capture-helper" name="/run/snapd/ns/core.mnt" pid=3902 comm="snap-confine" srcname="/proc" flags="rw, bind"
<jdstrand> we have mount options=(rw rbind) /proc/ -> /tmp/snap.rootfs_*/proc/,
<jdstrand> but that is rbind, not bind
<jdstrand> hangun: to unblock yourself, add 'mount,' to the 'mount-namespace-capture-helper' section of /etc/apparmor.d/usr.lib.snapd.snap-confine, then do 'sudo apparmor_parser -r /etc/apparmor.d/usr.lib.snapd.snap-confine'
<jdstrand> hangun: once you get farther along, feel free to file a bug that /etc/apparmor.d/usr.lib.snapd.snap-confine doesn't have everything you need, with all the info to reproduce
<hangun> jdstrand:  and zyga:  just following jdstrand's instruction:  1)sudo apparmor_parser -r /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine 2) sudo cp /snap/core/current/etc/apparmor.d/usr.lib.snapd.snap-confine /etc/apparmor.d/   ( it doesn't work  read-only file system)
<hangun> 3) snap install hello-world
<jdstrand> hangun: well, forget the cp. you seem to be porting to a new device/kernel. this isn't my area of expertise, but if you edit /etc/apparmor.d/usr.lib.snapd.snap-confine directly in the way I suggested, you might get farther along
<zyga> (dinner)
<jdstrand> mardy_: I think oa needs to be a consideration in the design for trust in snappy, which is something that tvoss is spear-heading. that said, afaik, a) interface hooks don't yet exist and b) you are trying to add ACLs into OA outside of snapd
<jdstrand> mardy_: it seems that in unity8 panel when you enable shotwell for the facebook account, that might perform a 'snap connect'
<mardy_> jdstrand: interface hooks have landed :-)
<mardy_> jdstrand: didn't we say that such interfaces should auto-connect, and the trusted prompt will take care of actually granting the permissions?
<jdstrand> mardy_: I'm also not sure if that ACL should live in OA-- trust-store is moving it to snapd. if you moved it to snapd, then you could rearrange things
<jdstrand> mardy_: well, if the trusted helper is doing the mediating, yes that's true
<jdstrand> mardy_: that then gets to my bit about storing your acls in snapd. again, this is something that should be considered with the trust discussions
<mardy_> jdstrand: I think that OA is quite a special case, it's not granting access to a system resource, but to some data which the user has entered into OA itself
<EEight> jdstrand: hi, someone told me you are the right person for this question: my snap doesn't connect automagically to the camera interface. I need to run sudo snap connect myapp:camera for it to works.
<jdstrand> mardy_: it may be different, but I'm not sure it needs to be treated specially
<EEight> jdstrand: I cannot ask my users to run this command after installing the application, is there a way to make it works out-of-the-box?
<jdstrand> EEight: what is your application?
<EEight> jdstrand: bayam
<EEight> jdstrand: an electron application using electron-builder to build the snap
<zyga> jdstrand: while that is the case how does it work in ubuntu all the time?
<mup> Bug #1666553 opened: snap try works, but executing the application doesn't work in some directories like /tmp <Snappy:New> <https://launchpad.net/bugs/1666553>
<EEight> jdstrand: reported here: https://bugs.launchpad.net/snapcraft/+bug/1609577
<mup> Bug #1609577: Docs: Your First Snap webcam-webui does not work once installed <Snapcraft:New> <https://launchpad.net/bugs/1609577>
<didrocks> zyga: you are quick :)
<zyga> didrocks: haha, I just got lucky
<jdstrand> EEight: the camera interface is considered privileged in that a malicious or misbehaving app could spy on the user when the interface is connected. this is why the user is given a say as to whether the interface should be connected
<zyga> didrocks: I know about this bug, I was wondering what to do in that case
<hangun> jdstrand: trouble you again.   How I add 'mount,' to the 'mount-namespace-capture-helper' section of /etc/apparmor.d/usr.lib.snapd.snap-confine ?
<jdstrand> EEight: it is technically possible to have the interface autoconnected on install using a snap declaration, but then the user doesn't necessarily know what is happening
<didrocks> zyga: yeah, I wonder how hackish a temporary mount point accessible on both side would work
<didrocks> zyga: that or at least failing in snap try with some reasoning
<didrocks> as we have the list of directories that are shadowed inside the snap
<jdstrand> EEight: aiui, there is work to make this more discoverable for users. what some people do is create a small wrapper such that tries to use the resource, notices it cannot, and then tells the user what to do: eg, "Camera not available. Please run: sudo snap connect myapp:camera'
<jdstrand> EEight: I suggest bringing this up on the snapcraft@ mailing list and asking about the progress to make interface connections easier for end users
<mardy_> jdstrand: regardless of where the ACL lives, do you agree that the snap providing the slot needs to be able to get the name of the client (plug) snap, in order to get its name and icon?
<hangun> jdstrand: the /etc folder is read only fs
<EEight> jdstrand: does it means that even the final "solution" for this will be to ask the users to run a command line?
<jdstrand> EEight: I might also mention that gadget snaps are able to influence auto-connect. so if this snap is part of a device you are creating, you can control the auto-connect yourself
<jdstrand> EEight: not necessarily. aiui, snap install will help guide the user
<jdstrand> EEight: but I'm not designing that and not up to date on it. I suggest asking on the list
<_prasen__> its says ubuntu 16.04 comes with a snappy core but during the first execution of snap install it firsts installs the snap core after downloading it
<jdstrand> hangun: I'm a bit confused by your system setup. it sounds like a traditional distro, but /etc is read-only. did it not boot correctly and the boot put / as readonly?
<_prasen__> core snap*
<EEight> jdstrand: well the instruction on how to install my application on ubuntu is to use software center. don't know how it will help my users.
<_prasen__> so that snaps get a reference to be built
<jdstrand> hangun: you can cp /etc/apparmor.d/usr.lib.snapd.snap-confine somewhere else, then modify that file, then run apparmor_parser -r on it. that will not survive a reboot
<_prasen__> or installed
<_prasen__> so that they could be shipped across various distros and versions
<_prasen__> *confused*
<jdstrand> EEight: re software-center, aiui, that is supposed to tie into snap install
<zyga> didrocks: I'll think of something
<jdstrand> EEight: again, I'm not designing that so not up to date
<_prasen__> *confused*
<_prasen__> why isnt 16.04 shipped with the core snap
<jdstrand> mardy_: I'm not sure I agree with that. if the design is what you laid out in the bug, probably, but if the design is you calling snap rest api to do things/whatever, maybe not
<ogra_> _prasen__, because that would most likely be outdated
<EEight> jdstrand: ok i understand (not up to date) but question so that i can ask a good one: if my users install via the command line or via the software center - either way they will need to run eventually sudo snap myapp:camera?
<_prasen__> hi ogra
<jdstrand> EEight: yes
<EEight> damn
<jdstrand> EEight: *today*
<_prasen__> this is _prasen_ only
<_prasen__> left myself logged in
<jdstrand> EEight: but there is planned work to make that better. I just don't know the priority or the designs
<ogra_> _prasen__, like you should not keep the original kernel on a fresh install but apply all security updates on a classic 16.04 installation when using it in production the same applies to the snappy system
<hangun> jdstrand: I copy it into home directory which can be modified.  How I modified this file? I can't understand how to add "mount" to mount-namespace-capture-helper section
<ogra_> so when invoking snap for the first time the core snap is pulled freshly from the store
<ogra_> sincer that has all the latest fixes and security updates
<_prasen__> okay
<_prasen__> that clears it
<_prasen__> ty
<_prasen__> but what about users
<ogra_> (and as i said, all yourr snaps are executed in context of the core snap, so you really dont want to have any security holes in that one as it could break the snap confinement of the apps)
<_prasen__> who would want to develop locally?
<_prasen__> without having any internet access
<jdstrand> hangun: open the file in a text editor. put 'mount,' (don't forget the comma) anywhere within the '^mount-namespace-capture-helper (attach_disconnected) { ... }' stanza
<ogra_> you would still have to pull the core snap once
<_prasen__> though that would never practically happen
<jdstrand> hangun: then use 'sudo apparmor_parser -r /path/to/file'
<_prasen__> ogra : the classic confinement is related to this ?
<ogra_> the classic confinement just means its a deb in a snap dress :)
<_prasen__> that breaks the snap confinement tho, doesnt it
<_prasen__> ?
<ogra_> it behaves like a deb and has the same access to the system a deb has but you can use the advantage of snap packaging for it
<ogra_> well, you declare it as "confinement: classic" in the snap metadata
<_prasen__> yes
<ogra_> so you told it to not use any of the actual confinement
<_prasen__> yes
<ogra_> it doesnt *break* it ... but you chose to not use it :)
<_prasen__> even then it requires the context of snap core ?
<_prasen__> ^ignore this then
<ogra_> yes, it does
<_prasen__> your last statement cleared that up
<_prasen__> total nub at this.
<ogra_> we all were once, no worries ;)
<_prasen__> that gives me a boost
<_prasen__> :D
<ogra_> :)
<ogra_> mvo, do we actually allow sideloading of the core snap for people without any internet access that just want to develop and test their own snaps locally ?
<_prasen__> hey
<_prasen__> how do we do that?
 * ogra_ has never tried to sideload it before snapd initially installed it
<ogra_> _prasen__, well, i dont know if your system would be set up properly afterwards, there is likely more store communication involved than just installing the core snap to have a proper setup ... which is why i pinged mvo
<_prasen__> yes
<ogra_> lets just wait til he finds time to answer and sees the ping :)
<hangun> jdstrand:  following your guide, I added "mount" to snap-confine and then reload it.  snap install hello-world, then run hello-world, an error outputs: seccomp_load failed with -22 , abouting: invaild argument
<_prasen__> it tries to "get" some more too
<hangun> jdstrand: have to go to bed. it's midnight here
<jdstrand> hangun: sounds like you maybe don't have seccomp enabled in your kernel or you have a too old libseccomp? again, this isn't really my area of expertise. You might want to send these questions to the devices@ mailing list (or use the porting guide (I don't have the url, perhaps someone here does?))
<jdstrand> hangun: mailing list: https://lists.snapcraft.io/mailman/listinfo/devices
<jdstrand> hangun: goodnight and good luck! :)
<ogra_> hangun, jdstrand https://docs.ubuntu.com/core/en/guides/build-device/image-building
<_prasen__> in the snapd.service file we have to set the path to the environment file
<_prasen__> where we will set the env variables we want to export
<jdstrand> ogra_: noted, thanks
<_prasen__> ogra : any doc/resource where I can know more about it?
<ogra_> _prasen__, you mean the environment (for a proxy) ? http://askubuntu.com/questions/764610/how-to-install-snap-packages-behind-web-proxy-on-ubuntu-16-04
<_prasen__> talking precisely about tis link ;D
<ogra_> _prasen__, note that this already points to "EnvironmentFile=/etc/environment"
<ogra_> _prasen__, so whatever you add to /etc/environment will be used by snapd
<_prasen__> where do I get to learn more about this?
<_prasen__> currently i do this to set my https_proxy and http_proxy variables
<ogra_> i guess the bug linked in the question above is the best you can get
<_prasen__> okay
<_prasen__> ty
<_prasen__> ogra : savior man _/\_
<ogra_> heh
<mvo> ogra_: installing a core snap without internet should work if you ack the assertion for the core snap first and then install it
<ogra_> how would he do that ack'ing ?
<ogra_> is there anything interactive ?
 * ogra_ would just have said --dangerous --devmode 
<ogra_> though i guess that would still try to access the store and install core frome there first ...
<ogra_> *from
<_prasen__> i guess --dangerous option is invalid with --devmode
<ogra_> well, i think you dont need --devmode if using --dangerous, iirc --dangerous automatically sets --devmode nowadays
<ogra_> (i'm a bit behind using snaps locally, i tebnd to use everything from the store nowadays)
<_prasen__> I think --devmode pnly has to used if confinement is devmode
<_prasen__> only*
<stgraber> didrocks: hmm, could be a problem with the mirrors or maybe some kind of proxy between you and the server
<stgraber> didrocks: is it still failing now?
<_prasen__> if confinement is changed to strict
<stgraber> (I'm trying on my laptop and it seems happy with images:ubuntu-core/16, currently downloading the image)
<_prasen__> then we need to use the dangerous flag if our locally created snap isnt verified by the store
<didrocks> stgraber: let me try
<didrocks> stgraber: yes: images:ubuntu-core/16 still fails with the fingerprint thingy and images:ubuntu-core/16/amd64 gives Retrieving image: 100% (614.64MB/s)error: multipart: NextPart: EOF
<stgraber> didrocks: oh, I didn't read your error too closely, it could actually be a problem with the legacy protocol for the image server. We actually have a change coming in the next LXD release to force change that protocol for everyone.
<stgraber> didrocks: lxc remote remove images ; lxc remote add images http://images.linuxcontainers.org --protocol simplestreams
<didrocks> stgraber: error: flag needs an argument: --protocol
<stgraber> oh, oops
<didrocks> ah error: Only https URLs are supported for simplestreams
<didrocks> hum
<stgraber> didrocks: oh, oops, that was meant to be https://
<stgraber> didrocks: lxc remote remove images ; lxc remote add images https://images.linuxcontainers.org --protocol simplestreams
<mup> PR snapd#2822 closed: interfaces: add a linux framebuffer interface <Created by femdom> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2822>
<didrocks> stgraber: perfect! images:ubuntu-core/16 is now downloadable, thanks! :)
<didrocks> stgraber: do you need a bug report for handling the transition if not already?
<stgraber> didrocks: nah, the commit was already merged yesterday
<stgraber> didrocks: I'll look into why the old protocol doesn't work though, you indeed would have needed to use images:ubuntu-core/16/amd64 for that, but it should still have worked...
<didrocks> stgraber: ah ok, that's weird. Good hunt! Thanks for the help on unblocking me
<zyga> re
<mup> PR snapd#2871 closed: overlord/hookstate/ctlcmd: helper function for creating a deep copy of interface attributes <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2871>
<jdstrand> roadmr: hi! can you sync r840 whenever it is convenient?
<roadmr> jdstrand: sure! hello :)
<zyga> roadmr: hey, long time no see
<roadmr> hello zyga  :) how's it going?
<roadmr> you've been super busy :)
<zyga> roadmr: me? no I just work on night shifts ;-)
<roadmr> you vampire :)
<zyga> roadmr: it's been good, preparig to move back to Polad this summer, otherwise all good
<roadmr> zyga: temporary move or for good?
<zyga> roadmr: I may be in Canada this spring
<zyga> roadmr: the only permanent move is when I go to the cementary ;)
<zyga> roadmr: not sure, for now we need to move
<roadmr> zyga: hehe :) ok, hope the move goes well, and the trip to Canada too! spring is nice if you manage to arrive after all the ice melts heh
<genii> Not much ice this year so far
<zyga> roadmr: I'm not sure if I'll go, or where the sprint is going to be even
<roadmr> zyga: well, it'll all become clearer in the coming weeks :)
<roadmr> genii: true, I've seen worse. I expect a quick thaw this year
<genii> roadmr: In fact, it's like 9C out right now here in Toronto, Wed-Thur up to 15C
<roadmr> genii: really? wow, thanks to climate change Toronto is now a tropical city
<genii> Heh, almost
<roadmr> genii: we're *just* below zero in Montreal.
<jdstrand> roadmr: thanks!
<noise][> FYI, we are experiencing an outage of the snap download service, see http://status.snapcraft.io/ for status updates
<EEight> jdstrand: I didn't want to involve the application name of the company in the mailing-list discussion...
<jdstrand> davidcalle: ping re https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/> html is rc5 but pdf is rc6
<EEight> I guess it is not possible to modify your post?
<jdstrand> EEight: I'm sorry :( the name is an important part of the conversation so I referenced it
<jdstrand> niemeyer: ^
<jdstrand> niemeyer: is there anything we can do to the mailing list archive (I'm not an admin of the list)
<niemeyer> Let me see
<EEight> niemeyer: the actual post is: https://lists.ubuntu.com/archives/snapcraft/2017-February/003363.html
<niemeyer> There's apparently no way.. I'll have to reach out to our internal support so they can edit the offending post manually
<EEight> Is there a form to do that, because there is a risk that Google will show this post when people look for Bayam and security + children = bad
<jdstrand> EEight: no form. niemeyer is reaching out now
<EEight> niemeyer: thank you very much for this
<EEight> jdstrand: I now understand why it's not connected (camera) out-of-the-box
<jdstrand> I apologize again. I didn't think it was a problem since it was discussed here
<niemeyer> EEight: Done, should be done in the next 24h
<EEight> you guys rocks!
<niemeyer> EEight: Sorry for the trouble
<jdstrand> niemeyer: thanks for taking care of that
<niemeyer> EEight: As a side note, you just associated the company name with security in the public logs of this channel
<EEight> And lost my job
<EEight> I have a plan B, making breads
<EEight> No worries for me
<niemeyer> :)
<niemeyer> It's not a bad plan :)
<EEight> Well I should begin to work on it...
<EEight> And for the record (and public log) I was talking about the leaf: http://chiap-hup.com/bayam-bulat-0501/ ;)
<zyga> Pharaoh_Atem: hey
<zyga> Pharaoh_Atem: any chance you use a 16.10 machine to develop base snaps?
<joedborg> hey all
<joedborg> I'm getting `unusual mode 'rwxr-xr-x' for symlink` errors from ubuntu store when i push a snap build
<joedborg> not sure what's unusual about that?
<jdstrand> nessita: hey, several hours ago I rejected https://myapps.developer.ubuntu.com/dev/click-apps/6203/rev/6/, but r7 never underwent auto-review and is in 'Task state unknown'
<nessita> jdstrand, checking
<nessita> still checking
<qengho> joedborg: sounds fishy. symlinks don't have their own modes, iirc.  $ find snap prime stage -type l -ls
<joedborg> qengho: yeah, i've looked at them in the prime dir, because the full output lists each one
<nessita> jdstrand, I rerun the review task, is Manual review pending
<joedborg> qengho: and they all look legit, as expected all of the permissions are inherited
<jdstrand> nessita: thanks!
<nessita> jdstrand, thanks for reporting!
<jdstrand> np :)
<qengho> joedborg: If you have a URL someone can look at, at https://myapps.developer.ubuntu.com/ , then that might help someone who knows.
<joedborg> qengho: https://myapps.developer.ubuntu.com/dev/click-apps/6896/rev/2/
<joedborg> qengho: I've submitted for manual review - but I don't understand why symlinks are a build failure - perhaps it's a bug
<Pharaoh_Atem> zyga: I don't have a 16.10 machine on hand, but I can set up one, why?
<zyga> Pharaoh_Atem: no, just curious
<zyga> (no need to set one up)
<mup> PR snapcraft#1157 opened: repo: support versioned stage-packages <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1157>
<jdstrand> ogra_: hey, just noticed that pc-kernel is way out of date too in all channels
<jdstrand> ogra_: and thank you for the bbb update!
<cory_fu> elopio: Can you take a look at https://github.com/travis-ci/travis-ci/issues/7318#issuecomment-279860608 and tell me if that's feasible?  Could we fix the snap issue in travis using root inside whatever container they're using?
<cory_fu> It seems to me like it would depend on the kernel of the host system?
<devil> anyone has a hint for some documentaion on snap security measures?
<jdstrand> devil: https://developer.ubuntu.com/en/snappy/guides/security-whitepaper/
<jdstrand> devil: but read the PDF instead of the html. the html is out of date for some reason
<jdstrand> davidcalle: ping ^
<devil> jdstrand: thanks. writing an article on security of flatpak and snap
<davidcalle> jdstrand: looking
<jdstrand> davidcalle: html says rc5 but pdf is rc6
<jdstrand> davidcalle: google doc is also rc6
<mup> Bug #1666690 opened: Dependency issues when sharing a library through content interface <Snappy:New> <https://launchpad.net/bugs/1666690>
<davidcalle> jdstrand: sorry I missed your pings earlier, I think we need to get rid of the HTML version and stick to the PDF, the CMS is not maintained anymore (we are moving out of it page by page) and I'm having issues with publications
<davidcalle> jdstrand: how would you feel about only publishing the PDF?
<jdstrand> davidcalle: that is fine with me since it means it is easier to be up to date, but, like before, I'm not the main consumer of this
<jdstrand> davidcalle: iirc, people wanted the pdf, then they didn't, then now they do
<davidcalle> jdstrand: PDF it is then, I'll fight some more with the page to replace the content by an introduction to the whitepaper, then the link. Tomorrow, though.
<jdstrand> devil: in addition to that whitepaper (which has a slant towards Ubuntu Core as opposed to classic distributions), you might also want to look at https://github.com/snapcore/snapd/wiki/Interfaces, https://github.com/snapcore/snapd/wiki/Security and https://github.com/snapcore/snapd/wiki/snap-confine-Overview
<jdstrand> devil: there is a lot of stuff in https://github.com/snapcore/snapd/wiki
<devil> jdstrand: thanks again
<jdstrand> np
<jdstrand> davidcalle: thanks
<devil> what I am particularly interested in is the sandboxing mechanisms
<jdstrand> devil: the whitepaper gets into that and so do the specific wiki pages
<devil> jdstrand: ok, that'll keep me busy for a while
<jdstrand> but there is other info that is related or may give context in the other parts of the wiki
<AlbertA> Hi snappy team :) so we've been playing around with content interface as a way to share libraries among snaps, however there are issues concerning dependencies.
<AlbertA> we've outlined the problems in the bug: https://bugs.launchpad.net/snappy/+bug/1666690
<mup> Bug #1666690: Dependency issues when sharing a library through content interface <Snappy:New> <https://launchpad.net/bugs/1666690>
<AlbertA> has there been any talk about potential solutions to those problems?
<bdmurray> Is bug 1665756 fixed in snappy core?
<mup> Bug #1665756: environment variable setting issue <Snappy:Fix Committed> <https://launchpad.net/bugs/1665756>
<bdmurray> Or would it be fixed in snapcraft?
<ogra_> bdmurray, likely snapcraft
<ogra_> bdmurray, did you see my ping in #ubuntu-bugs from today btw ?
<bdmurray> ogra_: How can I run the latest snapcraft? I did see your ping.
<ogra_> not sure if the latest did already make it to proposed
<ogra_> in any case you can clone the branch from github and just run ./snapcraft in there i think
<ogra_> jdstrand, pc-kernel is kind of kernel team's thing to release, i pinged bjf before about them only releasing to beta, not sure how we can fix that (note that we cant release pi kernels at all to stable since we cant update /boot from the gadget snaps yet)
<jdstrand> ogra_: ok, thanks
<ogra_> jdstrand, (teh pi kernels depend on having the devicetrees in the gadget ... and also usually require new bootloader blobs for major version bumps of the kernel)
<ogra_> i'm bumping the bbb kernel now though, thanks for the ping :)
 * zyga EODs
<zyga> good night everyone
<mhall119> devil: ping
<devil> mhall119: pong
<mhall119> devil: hey, I just wanted to offer to answer any questions you had, or help with your article when it comes to the snaps part (I'm not as familiar with the flatpak side)
<mhall119> I'm a community manager here at Canonical
<devil> mhall119: thanks for the offer, I will come back to it if I have questions
<mhall119> no problem, I look forward to reading it :)
<devil> it's gonna be in German and international linux print mags in ~2-3 months. I can point you to it when it hits market
<mhall119> ah, thanks. In that case I can answer any questions, but I won't be any help reviewing the german text :)
<mhall119> we do have people who can, if you'd like a review before it goes to print
<mhall119> but sadly, I myself am mono-lingual
<devil> mhall119: I am pretty well informed, because I wrote on the topic before, as these projects are in rapid developement, I just want to get an as recent as possible look on the security models
#snappy 2017-02-22
<mup> PR snapd#2884 closed: snapstate: limit the ubuntu-core transition attempts to 5 in total every 12h <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2884>
<_prasen_> hi ogra
<mup> Bug #1631165 changed: no ability to move snap directory out of $HOME <Snappy:New> <https://launchpad.net/bugs/1631165>
<mup> PR snapd#2900 opened: errtracker: include snapd version in err reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/2900>
<mup> PR snapd#2901 opened: tests: update listing test for latest core snap version update <Created by mvo5> <https://github.com/snapcore/snapd/pull/2901>
<mup> PR snapd#2902 opened: tests: update listing test for latest core snap version update <Created by mvo5> <https://github.com/snapcore/snapd/pull/2902>
<mup> PR snapd#2903 opened: many: rebased uname branch for 2.22 <Created by zyga> <https://github.com/snapcore/snapd/pull/2903>
<mup> PR snapd#2904 opened: overlord/snapstate: tweak messages in {un,}link-snap <Created by zyga> <https://github.com/snapcore/snapd/pull/2904>
<mup> PR snapd#2905 opened: errtracker: include kernel version in error reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/2905>
<mup> PR snapcraft#1154 closed: Expose parallel_build_count to scriptlets (LP: #1666271) <Created by oSoMoN> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1154>
<laralauer> Good evening
<laralauer> SInce I just got mircade running on QEMU/Ubuntu Core 16, is there already a working Unity8 snap for Mir?
<mup> PR snapcraft#1126 closed: docs: build and push the API docs to github pages <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1126>
<laralauer> sorry, disconnected
<ogra_> laralauer, snap install unity8-session --devmode --edge
<ogra_> then
<ogra_> sudo unity8-session
<ogra_> (you might need to connect some interfaces first though)
<ogra_> hey _prasen_
<laralauer> ogra_: thanks!
<mup> PR snapd#2906 opened: overlord/ifacestate: don't unconditionally retry stuff <Created by zyga> <https://github.com/snapcore/snapd/pull/2906>
<_prasen_> if i get a random .yaml to build a snap
<_prasen_> made up of different parts and different apps
<_prasen_> how do i map the binaries of the apps to the parts?
<_prasen_> I want to prime different parts one by one
<laralauer> What are some of the most useful snaps?
<_prasen_> what does dump plugin exactly do
<mup> PR snapd#2902 closed: tests: update listing test for latest core snap version update <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2902>
<mup> PR snapd#2907 opened: overlord/ifacestate: improve error messages <Created by zyga> <https://github.com/snapcore/snapd/pull/2907>
<mup> PR snapd#2881 closed: cmd/snap-confine: don't crash if nvidia module is loaded but drivers are not available <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2881>
<mup> PR snapd#2876 closed: snap: error when `snap list foo` is run and no snap is installed <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2876>
<mup> PR snapd#2908 opened: snapstate: fix incorrect cut of the timestamps for the error reports <Created by mvo5> <https://github.com/snapcore/snapd/pull/2908>
<zyga> _prasen_: dump just copies stuff as-is
<mup> PR snapd#2901 closed: tests: update listing test for latest core snap version update <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2901>
<ogra_> fgimenez, you should really put a warning in https://github.com/snapcore/snapd/blob/master/packaging/ubuntu-16.04/tests/README.md that adt-buildvm-ubuntu-cloud can take a century :P
<Jablonski> Hi
<mup> PR snapd#2909 opened: overlord/snapstate: improve error reporting around core migration <Created by zyga> <https://github.com/snapcore/snapd/pull/2909>
<Jablonski> Hello?
<Jablonski> Hi
<fgimenez> ogra_, :D PRs welcome!
<ogra_> sigh, and running it nearly killed my machine !
 * ogra_ hasn't seen a stuttering cursor on that HW ever ... 
<mup> Bug #1666873 opened: Snap icon is not visible when called from terminal but it does when called from dash <Snappy:New> <https://launchpad.net/bugs/1666873>
<_prasen_> zyga : i want to understand how organise and filesets options for the dump plugin
<_prasen_> work*
<zyga> _prasen_: I think this is a question for kyrofa and sergiusens - it may be documented already but maybe that is not sufficient
 * zyga would recommend to sergiusens to open a wiki for snapcraft like what was done for snapd
<sabret00the> Is there any plans to fix snappy so that the notification icons actually show up and don't cause headaches like when you're trying to update Telegram and can't because the notifcation icon won't let the app shut down?
<mup> PR snapcraft#1156 closed: python plugin: use stage headers if applicable <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1156>
<zyga> sabret00the: yes but the issue is not simple (legacy protocols are hard to confine or fix)
<zyga> sabret00the: can you tell me more about the shutdown issue?
<zyga> sabret00the: there are reported issues for other problems but this feels like something new
<_prasen_> zyga : ty
<sabret00the> zyga: Sure. If you have an update to telegram and press restart, then telegram hangs. However if you disable the notification icon it updates fine.
<_prasen_> ogra: hi?
<_prasen_> resolved the proxy issue
<zyga> sabret00the: can you pastebin: dmesg | grep "DENIED"
<_prasen_> : D
<zyga> sabret00the: and report this as a separate issue, I'm sure sergiusens will want to know about it
<ogra_> _prasen_, congrats !
<_prasen_> zyga : tis documented but as you said nor nuff for a  nub
<_prasen_> ogra : can you tell me summin about the organise and filesets options for the dump plugin
<zyga> _prasen_: you just said this is documented, did you read that documentation?
<_prasen_> https://snapcraft.io/docs/reference/plugins/dump
<_prasen_> https://github.com/snapcore/snapcraft/blob/master/docs/your-first-snap.md
<_prasen_> the git link is snap for a go webcam server
<_prasen_> it uses the dump plugin
<zyga> _prasen_: look at the common keywords: https://snapcraft.io/docs/reference/plugins/common
<zyga> _prasen_: organize is documented there
<zyga> _prasen_: as are filesets
<_prasen_> and some comments are there
<_prasen_> okay..ty!
<_prasen_> will see this
 * zyga needs to reboot, brb
<_prasen_> and I guess trying out will get me ahead
<_prasen_> if i write a single .c file with just a printf and create a makefile for it
<_prasen_> I made a .yaml for it
<laralauer> ogra_: I read that you made a Kodi snap for armhf, is there one for x86_64?
<_prasen_> so what plugin do i need to use for this
<_prasen_> because "." works fine for the source option
<_prasen_> if i use the autotools plugin it requires an autoconf file
<laralauer> ogra_: Sorry, found it, https://code.launchpad.net/~ogra/+snap/kodi-mir-snapshot/+build/17382
<ogra_> laralauer, thats far from being usable
<_prasen_> ogra : hlp hlp hlp
<_prasen_> !
<sabret00the> zyga: I've done so https://github.com/sergiusens/telegram-snap/issues/6
<laralauer> ogra_: It block for a while, shows the loading screen very briefly and then crashes because of "double free or corruption". It's a start
<ogra_> laralauer, nope ... its broken and i dont intend to fix it atm ... it is a test package , if it would be intended for use i would have uploaded it to the store
<ogra_> it is really not intended for anyone to be used
<ogra_> (you wont make it run)
<laralauer> ogra_: Okay, thanks
<jdstrand> ogra_: sorry for the poort timing, looks like another usn is out for linux-generic
<jdstrand> poor*
<ogra_> jdstrand, lol
<ogra_> jdstrand, i dont see anything newer than -64
<ogra_> (and i have that one for the bbb already)
<jdstrand> huh. I thought I remembered this was 63 yesterday
<ogra_> and you pinged me last night about -64
<ogra_> :)
<jdstrand> ogra_: oh, last night was actually meant to be about -63 for pc-kernel
<jdstrand> hehe
<ogra_> hah
<jdstrand> communication for the win!
<ogra_> yeah. pc-kernel is a bjf or apw think
<ogra_> *thing
<ogra_> they need to release them to stable
 * jdstrand nods
<ogra_> (same for dragonboard ... just not for pi since that would break the installs out there)
<jdstrand> ogra_: looks like you interprested my question as another ping for bbb and conincidentally (and unknown to me at the time), 64 had snuck in
<jdstrand> man, I can't type
<jdstrand> interpreted*
<ogra_> weklcome to my worlsd :)
<jdstrand> funny :)
<jdstrand> hehe
<jdstrand> ogra_: our team is going to chase down pc-kernel with the kernel team I think so I'll try not to ping you on that. thanks for the bbb updates! :)
<ogra_> np
<mup> PR snapd#2908 closed: snapstate: fix incorrect cut of the timestamps for the error reports <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2908>
<zyga> jdstrand: hey, we have some zesty failures on jailmode + classic confinement
<zyga> jdstrand: cannot map segment of libc.6
<zyga> jdstrand: maybe the kernel has changed so apparmor semantics has changed again
<zyga> jdstrand: I'll tell you more in a sec
<zyga> jdstrand: [ 2929.841318] audit: type=1400 audit(1487770576.927:40): apparmor="DENIED" operation="file_mmap" profile="snap.python0.python0" name="/snap/core/1264/lib/x86_64-linux-gnu/libm-2.23.so" pid=5235 comm="python0" requested_mask="m" denied_mask="m" fsuid=1000 ouid=0
<zyga> jdstrand: looks like exactly what we saw before
<zyga> jdstrand: I'll report this
<zyga> jdstrand: https://bugs.launchpad.net/snapd/+bug/1666897
<mup> Bug #1666897: snaps with classic + jailmode confinement started to fail on zesty <snapd:Confirmed> <https://launchpad.net/bugs/1666897>
<nelsk> Looks like the copr snapcraft repo hasn't been updated to support Fedora 25, is there a technical barrier?
<zyga> nelsk: hey
<zyga> nelsk: not sure, kyrofa might know
<nelsk> zyga: Ah, I recognize your handle :)
<zyga> nelsk: if you ask about snapd then we have a 2.23 release pending (since Friday) but we're in emergency mode and we won't release it untill this is fixed
<zyga> nelsk: and 2.23 will (finally) go into F25 and 26
<nelsk> is there some kind of bug blocking release or you guys are just in a code freeze?
<nelsk> Just curious so I can follow along
<zyga> nelsk: for snapd or snapcraft (I don't know about snapcraft)
<zyga> nelsk: snapd is in emergency mode, we realized that 2.22.x that went out had a very nasty bug
<zyga> nelsk: and we're iterating, since Friday, with point releases that unbreak people in the field
<zyga> nelsk: 2.23 is frozen as the whole team is just busy on the fire
<nelsk> I'm sorry, I meant your snapcore* repo in copr. Looking for snapd, so that makes sense
<nelsk> Good to know, thank you.
<zyga> nelsk: 2.23 and 2.24 will just go out delayed
<zyga> nelsk: probably 2.24 will have all the fedora packaging and policy merged
<zyga> nelsk: but the code is fine as of last week, we just were waiting for the tag to flow
<zyga> just bad luck
<zyga> when we release the "candidate" release goes to "stable"
<zyga> and master "edge" goes to "candidate"
<zyga> and we pushed the candidate to stable and started to see things explode
<zyga> so we stopped
<zyga> the candidate release also goes for distribution packaging
<zyga> like $ubutnu_codename-proposed and what not
<zyga> (sid, etc)
<zyga> just really bad luck this week
<nelsk> sounds good, will look forward to the release
<nelsk> Just popped in to see if there was anything holding up the Fedora 25 repo and if I could help with that
<zyga> nelsk: if you want to see what's coming have a look at the snapd repo on fedora git, I think neal has commited everything there already
<zyga> nelsk: you can help for sure
<zyga> nelsk: we'll need to improve the selinux policy
<zyga> nelsk: and just polish bits as I'm sure we'll find out things are not working in some odd edge cases
<nelsk> ah yes, good old selinux
<zyga> nelsk: the test suite doesn't run on fedora yet, but that's easy to fix
<zyga> nelsk: fedora builds use /var/lib/snapd/snap as a location for all the mounted packages
<zyga> nelsk: and the test suite has hard-coded /snap directory
<nelsk> are there GH issues floating around against these?
<zyga> nelsk: there will be some boring branches to fix that
<zyga> nelsk: we switched to laucnhpad for that launchpad.net/snapd
<zyga> nelsk: there's no issue filed for the unit tests I think
<nelsk> cool, will subscribe over there
<zyga> nelsk: if you want to help now: fork and clone master of github.com/snapcore/snapd
<zyga> nelsk: and I can work with you on enabling the test suite
<zyga> nelsk: (the C test suite passes, the Go one will fail on /snap)
<zyga> nelsk: I had a look at this a few months ago but I got a gigantic branch that was very ugly
<zyga> nelsk: so after talking to some people on the snapd team we decdied to use a different approach
<nelsk> will fork and ping you later on, thanks for your quick help
<zyga> nelsk: and just mock /snap for testing
<zyga> nelsk: thanks! great to have you here, stay in touch please
<nelsk> will do!
<zyga> nelsk: for the mocking we'd need to add a function to dirs/dirs.go
<zyga> nelsk: and just use it when we test for this in the unit tests
<zyga> nelsk: should be not that big of a patch
<nelsk> I'd be happy to take that one
<zyga> nelsk: and cna be done on a per-package basis so some stuff turns green while other is not changed yet
<zyga> nelsk: and after the 2.23 release I'd like to enable snapd CI to work with fedora
<zyga> I can explan how that works when you want to know
<nelsk> that would be great. have to run off to some meetings but I will ping you later on
<zyga> great, see you :-)
<mup> PR snapcraft#1158 opened: packaging: snapcraft as a snap <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1158>
<mup> PR snapd#2906 closed: overlord/ifacestate: don't unconditionally retry stuff <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2906>
<mup> PR snapd#2909 closed: overlord/snapstate: improve error reporting around core migration <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2909>
<mup> PR snapd#2825 closed: osutil: add package for reading Build-ID <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2825>
<mup> PR snapd#2910 opened: osutil: add package for reading Build-ID <Created by mvo5> <https://github.com/snapcore/snapd/pull/2910>
<mup> PR snapd#2900 closed: errtracker: include snapd version in err reports <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2900>
<mup> PR snapd#2903 closed: many: rebased uname branch for 2.22 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2903>
<mup> PR snapd#2888 closed: many: display kernel version in 'snap version' <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2888>
<mup> PR snapd#2898 closed: many: merge 2.22.5 back to master <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2898>
<jdstrand> davidcalle: hi! fyi, I got some feedback on the whitepaper and it is now at rc7. You should have an email in your inbox
<davidcalle> Great, thanks jdstrand
<mup> PR snapcraft#1159 opened: docs: use correct target to generate docs <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1159>
<baggachipz> I'm sure this gets asked all the time, but I'm having trouble finding info. What's the best way to get snapd on Debian Jessie? If I simply install snap (and not snapd), installing snaps throws errors.
<mup> PR snapd#2911 opened: release: return "unknown" if uname fails <Created by zyga> <https://github.com/snapcore/snapd/pull/2911>
<jdstrand> zyga: I'm not sure 'High' is the right priority for that (I mean, --classic with --jailmode is a bit of a corner case, no?), but I'll respond in the bug
<mup> PR snapd#2905 closed: errtracker: include kernel version in error reports <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2905>
<mup> PR snapd#2911 closed: release: return "unknown" if uname fails <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2911>
<jdstrand> zyga: fyi, https://bugs.launchpad.net/snapd/+bug/1666897/comments/1
<mup> Bug #1666897: snaps with classic + jailmode confinement started to fail on zesty <snapd:Confirmed> <https://launchpad.net/bugs/1666897>
<jdstrand> zyga: that tells how to fix it
<jdstrand> jjohansen: can you look at https://bugs.launchpad.net/snapd/+bug/1666897/comments/1 ? there is a difference of behavior concerning 'm' mediation on 4.10 and 4.4
<mup> Bug #1666897: snaps with classic + jailmode confinement started to fail on zesty <snapd:Confirmed> <https://launchpad.net/bugs/1666897>
<jdstrand> jjohansen: I think that 4.10 may be working correctly...
<mup> PR snapd#2912 opened: errtracker: include the build-id of /usr/bin/sanp <Created by mvo5> <https://github.com/snapcore/snapd/pull/2912>
<lazyPower> Hey snappy crew, simple question. Are you using Travis-CI in any of your build toolchain? We're looking into using snaps in travis-ci and have been blocked on some apparmor config we haven't been able to work-around. Curious if anyone else has run into this, and if we haven't, is there a list of apparmor ignore/allow that we can send over to the travis folks and get this unblocked? https://github.com/travis-ci/travis-ci/issues/7318
<lazyPower> cc cory_fu ^
<cory_fu> lazyPower: https://github.com/travis-ci/travis-ci/issues/5821 is also somewhat relevant
<cory_fu> lazyPower: elopio had mentioned previously the possibility of using lxd to get a xenial env, but I'm not sure if that would work under Docker that Travis uses?
<mup> Bug #1666978 opened: Security setup may fail with ErrNoState if repository and snapstate get out of sync <Snappy:New> <https://launchpad.net/bugs/1666978>
<mup> PR snapd#2913 opened: overlord/ifacestate: loudly ignore ErrNoState where we cannot handle it <Created by zyga> <https://github.com/snapcore/snapd/pull/2913>
<mup> PR snapd#2914 opened: snapstate: retry ubuntu-core -> core transition every 6h <Created by mvo5> <https://github.com/snapcore/snapd/pull/2914>
<kyrofa> nelsk, zyga_ I don't know about snapcraft on fedora either. It might be community-driven
<Pharaoh_Atem> O.o
<Pharaoh_Atem> wait, what?
<Pharaoh_Atem> snapcraft on Fedora is blocked by two things:
<Pharaoh_Atem> 1. https://bugs.launchpad.net/snapcraft/+bug/1602258
<mup> Bug #1602258: Support other distributions as sources (Fedora, Mageia, openSUSE, Debian) instead of Ubuntu <centos> <debian> <fedora> <mageia> <opensuse> <rfe> <rpm> <Snapcraft:Confirmed> <https://launchpad.net/bugs/1602258>
<Pharaoh_Atem> 2. snapd needs a concept of base snaps
<Pharaoh_Atem> for different bases
<Pharaoh_Atem> nelsk, zyga_, kyrofa: ^
<kyrofa> Pharaoh_Atem, indeed. nelsk asked about a snapcraft copr though, and why it wasn't updated
<Pharaoh_Atem> we don't have one
<Pharaoh_Atem> snapcraft *does not run* on anything but Ubuntu
<Pharaoh_Atem> it can't
<nelsk> Pharaoh_Atem, kyrofa: I mispoke and actually mean zyga/snapcore
<nelsk> meant*
<Pharaoh_Atem> ah
<Pharaoh_Atem> so you'd like snapd
<kyrofa> Pharaoh_Atem, I'm well aware :)
<nelsk> Pharaoh_Atem: yep, that's what I was looking for
<kyrofa> nelsk, ah ha! That makes more sense
<Pharaoh_Atem> indeed
<Pharaoh_Atem> it's been a while since someone asked about snapcraft on Fedora, so I was confused :P
<kyrofa> Pharaoh_Atem, me too!
<kyrofa> Pharaoh_Atem, I actually assumed it was you messing with stuff
<nelsk> hah, sorry for the confusion. Relatively new to the project so the significance of that blunder was over my head :P
<Pharaoh_Atem> no one else knows what the project is called, so that's fine :)
<nelsk> hahaha
<kyrofa> nelsk, yeah, you're not alone ;)
<Pharaoh_Atem> I call the whole thing snappy, because there's not something much better
<Pharaoh_Atem> snapcraft makes snaps, that are consumed by snapd
<kyrofa> nelsk, but, just to clarify: snapd is the daemon behind actually using/running snaps
<kyrofa> nelsk, snapcraft is the tool that actually creates snaps
<nelsk> does "snapcore" encompass anything more than snapd?
<Pharaoh_Atem> it's the name of the GitHub organization
<kyrofa> nelsk, on github? Snapcraft as well
<kyrofa> As well as our official gadget snaps, I think
<nelsk> aha! okay that makes sense
<Pharaoh_Atem> snapcore was created after it was agreed to move everything out of the Ubuntu organization
<Pharaoh_Atem> so snapd is actually nearly ready to run OOTB
<Pharaoh_Atem> two things (again!):
<kyrofa> Two is a terrible number
<Pharaoh_Atem> 1. snapd selinux policy needs to be merged: https://github.com/snapcore/snapd/pull/2878
<mup> PR snapd#2878: Merge SELinux policy module <Created by Conan-Kudo> <https://github.com/snapcore/snapd/pull/2878>
<Pharaoh_Atem> 2. snapd packaging needs to be merged (no PR yet, since it's blocked on that being merged)
<Pharaoh_Atem> then snapd can be released and zyga and I can push everything into CentOS and Fedora
<Pharaoh_Atem> Fedora first, and then we'll work out CentOS
<kyrofa> Pharaoh_Atem, is SELinux integration looking good?
<Pharaoh_Atem> kyrofa: it's actually not in great shape
<Pharaoh_Atem> but the module basically throws snapd into permissive domain
<Pharaoh_Atem> which keeps everything from breaking
<kyrofa> Oh, not ideal
<mup> PR snapd#2915 opened: errtracker: include the number of ubuntu-core -> core retries <Created by mvo5> <https://github.com/snapcore/snapd/pull/2915>
<Pharaoh_Atem> it also allows us to iterate on actually making snapd confined properly
<kyrofa> Rather than one enormous PR, good call
<Pharaoh_Atem> and by merging the policy into the snapd repo, I'm hoping other people will help me keep up with the churn in snapd
<Pharaoh_Atem> I'm constantly playing catch-up, which is really, really, really draining
<zyga_> o/
<kyrofa> Pharaoh_Atem, I hear you
<Pharaoh_Atem> it also puts more impetus on hopefully a SELinux developer getting hired to do formal SELinux integration into snapd
<Pharaoh_Atem> because frankly, my skills are being pushed to their limits with this
<Pharaoh_Atem> I'm doing the best I can, but keeping up with all of the new things snapd does in every release AND adjusting the policy so that snapd itself is properly confined AND making it so snap-confine would work is impossible fo rme
<Pharaoh_Atem> *me
<zyga_> Pharaoh_Atem: once we have CI we can make this better
<zyga_> Pharaoh_Atem: but we need to release first for CI
<Pharaoh_Atem> that's what everyone says...
<Pharaoh_Atem> CI isn't magic
<zyga> well, that's because it is true :)
<zyga> Pharaoh_Atem: CI means we don't regress
<Pharaoh_Atem> well, not necessarily, as you could just ignore them :)
<zyga> Pharaoh_Atem: and when we CI on Fedora we know we regress when we break something w
<zyga> we don't ignore CI :)
 * kyrofa has to drive back home. Be back in about 5 hours
<zyga> that's like CI
<Pharaoh_Atem> I hope not
<zyga> Continuous Ignorance
<zyga> :D
<Pharaoh_Atem> :D
<Pharaoh_Atem> I see Continuous Ignorance everywhere :)
<Pharaoh_Atem> it's so easy, after all :P
<zyga> bliss ;-)
<zyga> Pharaoh_Atem: can you try to package master
<zyga> Pharaoh_Atem: that will become 2.23 soon (or .24)
<mup> PR snapd#2916 opened: osutil: trivial tweaks to build ID support <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2916>
<Pharaoh_Atem> zyga: I can try
<zyga> Pharaoh_Atem: I want to have a good nights sleep and wake up with the fire put out so that we can return to normal work
<Pharaoh_Atem> zyga: snap-confine fails to build
<Pharaoh_Atem> zyga: https://paste.fedoraproject.org/paste/EzIdE98z5AUQyKFnbrBH4F5M1UNdIGYhyRLivL9gydE=
<zyga> Pharaoh_Atem: that file must be built with -static
<zyga> Pharaoh_Atem: and cannot take relocation AFAIK
<zyga> Pharaoh_Atem: we had the same issue in ubutu
<zyga> Pharaoh_Atem: look at the hack in configure.ac
<zyga> Pharaoh_Atem: er in Makefile.am
<zyga> Pharaoh_Atem: it's also uselss so if you cannot fix it just rip it out
<zyga> Pharaoh_Atem: or do a trivial patch that disables the shutdown helper
<Pharaoh_Atem> also, the merged-usr switch doesn't work?
<zyga> oh? what do you mean?
<Pharaoh_Atem> look at the log
<Pharaoh_Atem> it's unrecognized
<zyga> Pharaoh_Atem: hmm
<zyga> enable-merged-usr?
<zyga> maybe simple bug that I didn't see because it doesn't stop
<Pharaoh_Atem> autotools doesn't die on unrecognized switches
<Pharaoh_Atem> it's --enable-merged-usr now?
<zyga> checking
<zyga> Pharaoh_Atem: it was all along
<zyga> Pharaoh_Atem: sorry, slipped under my radar
<mup> PR snapd#2916 closed: osutil: trivial tweaks to build ID support <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2916>
<Pharaoh_Atem> alright, now the C bits are built
<mup> PR snapd#2808 closed: interfaces: use mount.Entry instead of string snippets <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2808>
<Pharaoh_Atem> zyga: you've got godeps to package :)
<Pharaoh_Atem> zyga: https://paste.fedoraproject.org/paste/cnAi~vkNe-YMvtLyCYRdql5M1UNdIGYhyRLivL9gydE=
<zyga> Pharaoh_Atem: gah what an annoying URL with trailing =
<zyga> Pharaoh_Atem: can we vendor everything in snapd if we annnotate?
<Pharaoh_Atem> yes, but it's arguably harder to annotate
<Pharaoh_Atem> as it has to be versioned Provides
<zyga> Pharaoh_Atem: mm?
<zyga> Pharaoh_Atem: provides how?
<zyga> Pharaoh_Atem: I mean I know provides but I don't know what you mean
<Pharaoh_Atem> well, it'd have to be something like this...
<Pharaoh_Atem> Provides: golang(github.com/foo/bar) = <ver> (versioned, with githash)
<zyga> hmm
<zyga> Pharaoh_Atem: that's much better than maintaining ~30 packages
<Pharaoh_Atem> and every time the dependency is updated, added, removed, these have to be updated
<zyga> Pharaoh_Atem: especially we could easily derive this data from vendor.json
<zyga> Pharaoh_Atem: it contains exactly that I think
<Pharaoh_Atem> plus licensing data must be packaged with it too
<zyga> Pharaoh_Atem: this is more important
<zyga> Pharaoh_Atem: what do we need to package ? each license file?
<zyga> Pharaoh_Atem: do we need it with snapd or the source package?
<Pharaoh_Atem> from each source package
<Pharaoh_Atem> bundled stuff needs their licensing preserved too
<zyga> Pharaoh_Atem: where do we need to put the source files?
<zyga> Pharaoh_Atem: that's a curious thing
<zyga> Pharaoh_Atem: if we didn't bundle
<zyga> Pharaoh_Atem: we'd ship the same binary with one copyright file
<zyga> Pharaoh_Atem: if we bundle we ship the same binary with... lots of files
<Pharaoh_Atem> the reason is because we have the sources somewhere else
<zyga> Pharaoh_Atem: it's not like .c wherere the .so files pull in the license
<zyga> Pharaoh_Atem: wait, we still do
<zyga> Pharaoh_Atem: we can generate a tarball that has the sources
<zyga> Pharaoh_Atem: (in fact we do already)
<Pharaoh_Atem> do you guys have the copyright file with all the dependencies licensing data?
<zyga> Pharaoh_Atem: we have a repo that automatically commits the whole dependency into vendor
<zyga> Pharaoh_Atem: so all the copyrights and everything
<Pharaoh_Atem> zyga: I do not see it
<Pharaoh_Atem> https://github.com/snapcore/snapd-plus-vendor/blob/master/packaging/ubuntu-16.04/copyright
<Pharaoh_Atem> if you're really shipping vendored tarballs, you're doing it wrong
<Pharaoh_Atem> zyga: the thing is, an acceptable substitute would have been a debian/copyright file that has all the declarations
<Pharaoh_Atem> but they don't
<zyga> Pharaoh_Atem: no, not that
<zyga> Pharaoh_Atem: we don't keep it in one place automatically
<zyga> Pharaoh_Atem: I see what you are saying now, that will have to be done
<zyga> Pharaoh_Atem: I'll get my hands on this, we should have done this during the vendoring
<Pharaoh_Atem> yeah
<Pharaoh_Atem> since it doesn't exist, we cannot vendor yet
<zyga> I think I will do both
<Pharaoh_Atem> zyga: incidentally, a version of the copyright file that doesn't assume that /usr/share/common-licenses/* exists would be extremely helpful
<zyga> Pharaoh_Atem: I'll fix debian copyright because that's an omission
<Pharaoh_Atem> because as you're aware, that's Debian only thing
<zyga> Pharaoh_Atem: and I'll package deps separately in case this is a policy issue of any kind
<Pharaoh_Atem> yeah
<Pharaoh_Atem> well, fortunately, as a maint/comaint for those deps, it's not problematic to update as needed
<Pharaoh_Atem> keep in mind it's not like the Debian world where updating deps is difficult politically due to bureaucratic processes just making it difficult
<zyga> Pharaoh_Atem: I'll try to get the build deps packaged tonight, maybe at lest two
<zyga> Pharaoh_Atem: yes :-)
<zyga> Pharaoh_Atem: will you be around in +3 hours if I poke you for a quick review
<Pharaoh_Atem> yes
<zyga> Pharaoh_Atem: looking at the list.. just top-to-bottom I guess
<zyga> Pharaoh_Atem: with some luck maybe suse can reuse them
<zyga> Pharaoh_Atem: but I don't have high hopes
 * Pharaoh_Atem sighs
<zyga> Pharaoh_Atem: btw, I ran into rpkg, is that lie fedpkg for rhel?
<Pharaoh_Atem> pyrpkg is the base module
<Pharaoh_Atem> fedpkg, centpkg, and rhpkg are frontends for rpkg
<zyga> ah, I see
<zyga> cool :)
<zyga> Pharaoh_Atem: thanks for letting me know, please commit your changes back
<zyga> Pharaoh_Atem: I'm going to be off next week
<zyga> Pharaoh_Atem: maybe I can use that time for something fun :)
 * zyga needs some sleep 
<zyga> at least an hour
<Pharaoh_Atem> hmm
<Pharaoh_Atem> I wonder if it might be easier to regenerate the spec using gofed
<mup> PR snapd#2904 closed: overlord/snapstate: tweak messages in {un,}link-snap <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2904>
<mup> PR snapd#2910 closed: osutil: add package for reading Build-ID <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2910>
<mup> PR snapd#2907 closed: overlord/ifacestate: improve error messages <Created by zyga> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2907>
<mup> PR snapd#2914 closed: snapstate: retry ubuntu-core -> core transition every 6h <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2914>
<mup> PR snapd#2915 closed: errtracker: include the number of ubuntu-core -> core retries <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2915>
<bdmurray> Is there any documentation on this Restart option?
<bdmurray> Feb 22 19:11:25 localhost systemd[1]: snap.apport.enable.service: Service has Restart= setting other than no, which isn't allowed for Type=oneshot services. Refusin
<mup> PR snapd#2912 closed: errtracker: include the build-id of /usr/bin/snap <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2912>
<jjohansen> jdstrand: okay bug updated
<jdstrand> jjohansen: thanks
<mup> PR snapd#2917 opened: osutil: remove duplicate build_id from other branch <Created by zyga> <https://github.com/snapcore/snapd/pull/2917>
<mup> PR snapd#2918 opened: revert: osutil: add package for reading Build-ID <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2918>
<mup> PR snapd#2918 closed: revert: osutil: add package for reading Build-ID <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2918>
<mup> PR snapd#2913 closed: overlord/ifacestate: loudly ignore ErrNoState where we cannot handle it <Created by zyga> <Closed by zyga> <https://github.com/snapcore/snapd/pull/2913>
<mup> PR snapd#2919 opened: overlord/ifacestate: don't fail if affected snap is gone <Created by zyga> <https://github.com/snapcore/snapd/pull/2919>
<mup> PR snapcraft#1159 closed: docs: use correct target to generate docs <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1159>
<zclark> test
<mup> PR snapd#2920 opened: wrappers/services: RemainAfterExit=yes for oneshot daemons w/ stop cmds <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2920>
<jdstrand> cprov: hey. I'm trying to see the plugs and slots for all the snaps in the store. I'm using curl -s https://search.apps.ubuntu.com/api/v1/snaps/search?fields=name,plugs,slots | jq -M '.', but the output is incomplete (eg, ufw and snappy-debug aren't in there). what am I doing wrong?
<lazyPower> has snapcraft grown support for detecting snapped lxd?
<lazyPower> sorry i asked before i looked and found https://bugs.launchpad.net/snapcraft/+bug/1666735
<mup> Bug #1666735: snapcraft cleanbuild does not work with lxd installed via snap <Snapcraft:New> <https://launchpad.net/bugs/1666735>
<jdstrand> nessita: hey, perhaps you can hel with my question? ^
<bdmurray> Ah, I found bug 1613971 and commented on it.
<mup> Bug #1613971: using oneshot results in failed service <Snapcraft:Invalid> <Snappy:New> <https://launchpad.net/bugs/1613971>
<pedronis> jdstrand: the output is paginated, you need a script (but maybe I'm misunderstanding the question)
<cprov> jdstrand: yup, there are 6 pages of 100 results each. Let me find a script you can use
<jdstrand> pedronis, cprov: ah, thanks
<jdstrand> I didn't know if there as an extra something to add to the url to give me unpaginated
<jdstrand> nessita: nm, cprov is helping me
<ssweeny> bdmurray: as luck would have it https://github.com/snapcore/snapd/pull/2920 should take care of that :)
<mup> PR snapd#2920: wrappers/services: RemainAfterExit=yes for oneshot daemons w/ stop cmds <Created by ssweeny> <https://github.com/snapcore/snapd/pull/2920>
<cprov> jdstrand: something like this -> https://pastebin.canonical.com/180409/
<jdstrand> ssweeny: oh, nice! :)
<jdstrand> cprov: let me try
<jdstrand> cprov: yes, that is perfect. thanks!
<cprov> jdstrand: anytime
<jdstrand> cprov: and aiui, this is only for stable and there isn't a way to search via search.apps.ubuntu.com for other channels, right?
<jdstrand> ssweeny: hey, do you know of a snap that slots 'upower-observe'?
<cprov> jdstrand: yup, stable (strict+classic)
 * jdstrand nods
<jdstrand> thanks again
<cprov> np
<ssweeny> jdstrand: can't think of one
<jdstrand> ssweeny: ok, thanks. the slot side was implemented but I can't find a snap that uses it
<jdstrand> slot side of the interface
<jdstrand> I'll ask mor phis tomorrow
<ssweeny> right. I've seen one or two plug side uses of it
<mup> PR snapd#2919 closed: overlord/ifacestate: don't fail if affected snap is gone <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2919>
<mup> PR snapcraft#1160 opened: history: rename to 'revisions' with alias 'list-revisions' <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1160>
<mup> PR snapd#2921 opened: releasing package snapd version 2.22.6 <Created by zyga> <https://github.com/snapcore/snapd/pull/2921>
#snappy 2017-02-23
<mup> PR snapd#2921 closed: releasing package snapd version 2.22.6 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2921>
<mup> PR snapd#2922 opened: many: merge 2.22.6 back into master <Created by mvo5> <https://github.com/snapcore/snapd/pull/2922>
<_prasen_> https://github.com/mectors/sensortag
<_prasen_> hi
<_prasen_> while building this snapcraft filw
<_prasen_> i get a error of property does not match the schema
<_prasen_> Issues while validating snapcraft.yaml: The 'parts/move/filesets/sensortag-in' property does not match the required schema: 'bin/sensortag-in' is not of type 'array'
<mup> PR snapd#2893 closed: tests: bail out if core snap is not installed <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2893>
<mup> PR snapd#2917 closed: osutil: remove duplicate build_id from other branch <Created by zyga> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2917>
<zyga> hi
<zyga> _prasen_: probably outdated repo, snapcraft is changing over time
<_prasen_> how do i fix this?
<_prasen_> should it be of type string?
<_prasen_> is this a problem of vim?
<zyga> _prasen_: no, this is not related to vim
<zyga> _prasen_: I don't know, sorry, just waking up after long evening work
<zyga> _prasen_: I'd suggest yu ask mectors to correct this repository
<_prasen_> hahahhahaha
<_prasen_> i am like starting my day
<_prasen_> though its well past noon
<_prasen_> working with yaml for first time
<_prasen_> so saw that there could be errors due to ansi indent
<_prasen_> zyaga: will do that
<_prasen_> zyga*
<_prasen_> zyga: ty _/\_
<zyga> _prasen_: good luck :)
<zyga> mvo: do you think you could do a 2nd review of https://github.com/snapcore/snapd/pull/2848
<mup> PR snapd#2848: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2848>
<zyga> mvo: it's been out for 9 days and I'd like to push forward
<mup> PR snapd#2477 closed: interfaces/builtin: first cut at repowerd interface <Created by afrantzis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2477>
<mup> PR snapd#2818 closed: Allow specifying another store via commandline option for the download command <Created by morphis> <Closed by niemeyer> <https://github.com/snapcore/snapd/pull/2818>
<mup> PR snapd#2847 closed: tests: enable docker test <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2847>
<ppisati> uhm
<ppisati> what am i doing wrong?
<ppisati> https://travis-ci.org/snapcore/snapcraft/jobs/204522771
<ppisati> ogra_: i know you are not the right person but, do you know who's the snapcraft/store guy here for this ^?
<ppisati> mvo: you too ^
<ogra_> ppisati, fgimenez
<ppisati> fgimenez: ^
<ogra_> he's the master of tests :)
<mvo> ppisati: sergiusens is usually the goto person for snapraft* but let me have a look
<ppisati> yeah, it's more like 'it explodes while trying to download a snap'
<mvo> ppisati: this looks like the store was giving a connection reset during the tests
<mvo> ppisati: so a simple retry, sometimes we have these problems (store or cdn, one of those)
<mvo> ppisati: I can restart the job for you if you want
<mup> PR snapd#2848 closed: cmd/snap-update-ns: add compare function for mount entries <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2848>
<ppisati> mvo: can i do it myself? so i won't bother anyone next time
<mvo> ppisati: I'm not sure, it may well be that you can't and only people with certain privs in the snapcore group can. I restarted it now
<ppisati> mvo: ta
<niemeyer> jdstrand: Easy one, maybe: snapd#2855
<mup> PR snapd#2855: interfaces/builtin: add intel realsense udev rules into camera interface <Created by swem> <https://github.com/snapcore/snapd/pull/2855>
<mup> PR snapd#2836 closed: release: assume higher version of supported distros will still work <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2836>
<mup> PR snapd#2857 closed: interfaces/builtin: add /boot/uboot/config.txt access to core-support <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2857>
<mup> PR snapd#2817 closed: many: switch channels on refresh if needed <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2817>
<_prasen_> working behind corporate proxy, while running snapcraft a part needs npm to install a sdk. to pass the proxy variables to npm we need to set proxy and https-proxy var's in .npmrc file
<_prasen_> and for npm install we have to pass the flags : --without-ssl , --insecure
<_prasen_> how do i tell snapcraft to take these flags
<mup> PR snapd#2839 closed: debian/tests: map snapd deb pockets to core snap channels for autopkgtest <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2839>
<fgimenez> ogra_, ppisati hey :) for snapcraft-related issues about tests and CI elopio is the right person to ask
<ogra_> thanks
<mup> PR snapd#2923 opened: cmd/snap-update-ns: add function for sorting mount entries <Created by zyga> <https://github.com/snapcore/snapd/pull/2923>
<mup> PR snapd#2870 closed: tests: failover test for rc.local crash <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2870>
<jdstrand> niemeyer: ack
<jdstrand> morphis: hey, is there a slot implementation of upower-observe?
<zyga> jdstrand: o/
<jdstrand> hey zyga :)
<mvo> ppisati: looks like your test is green now
<morphis> jdstrand: yes, we added that recently
<jdstrand> morphis: right. I mean, do you have a snap that slots upower-observe
<morphis> yes we do
<morphis> jdstrand: but not yet in stable
<morphis> snap install --candidate upower
<jdstrand> morphis: great, thanks!
<morphis> jdstrand: any specific reason you're asking for or just for reference?
<jdstrand> morphis: I am preparing a PR to mediate socket(PF_NETLINK, ...) and saw that upower uses udev, and I need to add 'socket PF_NETLINK - NETLINK_KOBJECT_UEVENT' to its PermanentSlot policy and want to test that it is enough
<morphis> ah ok
<jdstrand> morphis: there are a few slots that you guys wrote that I've made adjustments to and will ping you in the PR
<morphis> jdstrand: thanks
<zyga> jdstrand: did you see that error I reported for zesty yesterday?
<mup> PR snapd#2922 closed: many: merge 2.22.6 back into master <Created by mvo5> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2922>
<jdstrand> zyga: I did. I commented in the bug
<zyga> jdstrand: it's not an urgent thing but I'd like to fix it as zesty freezes and it breaks all the tests
<zyga> jdstrand: thank you!
<zyga> jdstrand: I'll try the kernel that jj recommended
<mup> PR snapd#2833 closed: many: allow core refresh.schedule setting <Blocked> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2833>
<mup> PR snapd#2810 closed: snap: use snap-confine from the core snap <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/2810>
<mup> PR snapd#2874 closed: kmod: added Specification for kmod security backend <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2874>
<mup> PR snapd#2878 closed: data/selinux: merge SELinux policy module <Created by Conan-Kudo> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2878>
<Son_Goku> ð
<Son_Goku> zyga: this means that now proper snapd selinux integration can begin
<Son_Goku> since we have "official" labels for things :)
<zyga> Son_Goku: :-)
<zyga> Son_Goku: I'm happy to see this
<zyga> Son_Goku: I'm sleepy after 2AM release last night
<zyga> Son_Goku: but with the main fire out I think next week will see some releases
<Son_Goku> I'm thinking that we should regenerate the packaging from gofed
<zyga> Son_Goku: though I'm on holidays since Tue
<zyga> Son_Goku: all of it?
<zyga> Son_Goku: for snapd or for deps?
<Son_Goku> snapd
<Son_Goku> there's been a lot of churn and I don't know what things are anymore :(
<zyga> Son_Goku: we can, I think that's ok
<Son_Goku> now that the SELinux policy is merged into the repo, I can start rebasing my packaging on that
<Son_Goku> :D
<Son_Goku> zyga: do we have a file that declares what our deps are in snapd?
<Son_Goku> I'm not completely familiar with how this works in golang
<zyga> Son_Goku: yes, it's called...
<zyga> Son_Goku: vendor/vendor.json
<Son_Goku> ah, so it's in the vendor directory
<mhall119> jdstrand: I tried to push a php-based snap to the store and got this:
<mhall119> found errors in file output: unusual mode 'rwx-wx-wt' for entry './var/lib/php/sessions'
<mhall119> I didn't do anything special, and php is installed via stage-packages
<jdstrand> mhall119: what is the name of the snap?
<mhall119> laravel-mhall119
<jdstrand> mhall119: can you request manual review in the store?
<mhall119> I can, but I also want to make sure this doesn't happen for every php-based snap if we can avoid it
<jdstrand> mhall119: I understand. I will fix the review tools for that
<jdstrand> rwx-wx-wt is unusual, but it doesn't hurt anything
<mhall119> jdstrand: requested
<ppisati> fgimenez: can you help me with some snapcraft tests?
<fgimenez> ppisati, i can try but probably better to ask elopio, i'm not actively working on them
<ppisati> fgimenez: k
<ppisati> elopio: ^
<mup> PR snapd#2924 opened: interfaces: specs for apparmor, seccomp, udev <Created by stolowski> <https://github.com/snapcore/snapd/pull/2924>
<mup> PR snapd#2891 closed: interfaces/udev: added spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2891>
<mup> PR snapd#2890 closed: interfaces/apparmor: add spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2890>
<mup> PR snapd#2883 closed: seccomp: added Specification for seccomp backend <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2883>
<fgimenez> hey kyrofa :) i'm trying to do some tests on the nextcloud image, have a minute for some questions?
<mhall119> jdstrand: do you need a bug report for that unusual file permission?
<zyga> jdstrand: can I add the snippet that will make the zesty regression no break all the PRs for snapd?
<zyga> jdstrand: (along with a note and a bug reference)
<zyga> jdstrand: note that this is just for jailmode on classic snaps so pretty isolated
<Son_Goku> sergiusens: hey
<Son_Goku> have you made any progress on the repo refactor thing?
<kyrofa> fgimenez, ah, sorry, responded to your internal ping first, heh
<fgimenez> kyrofa, np! thanks :)
<lool> ppisati: hey!
<lool> ppisati: so https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1652504?comments=all is apparently hitting one of the demos for MWC
<mup> Bug #1652504: Recent updates broke Ubuntu on Raspberry Pi 3 <armel> <kernel-da-key> <regression-update> <xenial> <yakkety> <flash-kernel (Ubuntu):Confirmed for fo0bar> <linux (Ubuntu):Confirmed for fo0bar> <https://launchpad.net/bugs/1652504>
<lool> ppisati: I'm not sure they need video output (checking with them), but they've just passed this bug to me
<lool> ppisati: ok, it's not critical, they're just giving us a heads up
<mup> PR snapd#2925 opened: [WIP] interfaces: migrate existing intarfaces to use new kmod and seccomp spec <Created by stolowski> <https://github.com/snapcore/snapd/pull/2925>
<ppisati> lool: i thought ryan fixed that already
<lool> ppisati: do yo know where the fix is?
<ppisati> lool: actually, it doesn't break video, your board won't boot at all
<ppisati> lool: wait wait
<ppisati> lool: that bug, was because ryan's image didn't have the correct address for the dtb
<lool> ok
<ppisati> lool: if you are hitting that bug, your board won't boot at all
<ppisati> lool: but you mention a problem with video output
<lool> ppisati: that's what they said
<lool> I'm proxying here
<ppisati> lool: ok, if you want to loop me in any conversation
<lool> ppisati: so the workaround/fix is to correct DTB addr and we'll land that soon and can be applied manually in the mean time?
<ppisati> lool: i can test if that bug was fixed in the meantme
<lool> ppisati: we're on their slack
<lool> I've invited folks here
<ppisati> lool: let me reinstall the image, so i can check what's the status
<lool> ppisati: thanks man
<mup> PR snapcraft#1158 closed: packaging: snapcraft as a snap <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1158>
<mdye> @ppisati hi there, @lool passed on the word that we had trouble with video after updating our ryan's pi3 image to kernel 4.4.0-1042-raspi2
<nothal> mdye: No such command!
<mdye> bad slack habits :)
<lool> mdye: Hey!
<mdye> lool: ahoy!
<ppisati> mdye: fb or mir?
<lool> ppisati: ^ mdye is setting up a jetson tx1 + pi3 boards demo for MWC; he's also a really awesome guy  :-)
<mdye> ha, thx
<mdye> ppisati: so the jist is we build a pi3 image from ryan's base in a chroot; I use FLASH_KERNEL_SKIP=1 to get kernel updates installed successfully in the chroot
<ppisati> mdye: ok
<mdye> the config.txt on the updated pi3 has device_tree_address=0x100 and device_tree_end=0x8000 (which I think are the original addresses from earlier images)
<mdye> the result is a system that will boot the kernel, but the kernel command line "console=tty1" isn't applied such that the console never outputs messages after uboot hands control over to the kernel
<ppisati> mdye: uhm, that is weird
<ppisati> mdye: is you did a dist-upgrade, you should get a new firmware too
<ppisati> *if
<ppisati> mdye: that would move the dtb address around, and your board wouldn't boot then
<ppisati> mdye: i'm reinstalling an image to check, hold on
<mdye> ok, thx
<mup> PR snapd#2861 closed: [WIP] interface hooks: expose attrs to the interface API, snapctl enhancements (step #4) <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2861>
<mup> PR snapd#2896 closed: httputil: copy some headers over redirects <Created by chipaca> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2896>
<mup> PR snapd#2925 closed: [WIP] interfaces: migrate existing interfaces to use new kmod and seccomp spec <Created by stolowski> <Closed by stolowski> <https://github.com/snapcore/snapd/pull/2925>
<mup> Bug #1667359 opened: After a reboot store was not accessible <Snappy:New> <https://launchpad.net/bugs/1667359>
<mup> PR snapd#2923 closed: cmd/snap-update-ns: add function for sorting mount entries <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2923>
<zyga> jdstrand: hey
<mup> Bug #1667385 opened: devmode flag disappears after disabling+re-enabling a snap <Snappy:New> <https://launchpad.net/bugs/1667385>
<zyga> jdstrand: can you please have a look at https://github.com/snapcore/snapd/pull/2827
<mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
<zyga> jdstrand: I think it is good to land now
<zyga> jdstrand: and I waaaaant it to land :)
<zyga> jdstrand: the new patches are: https://github.com/snapcore/snapd/pull/2827/commits/6573f698a22db592006cf6af7d5284cf66a891e4 and https://github.com/snapcore/snapd/pull/2827/commits/9e24bee9f0cb94aef73c23667fd80364db66d3bb
<mup> PR snapd#2827: cmd: add helpers for mounting / unmounting <Created by zyga> <https://github.com/snapcore/snapd/pull/2827>
<mup> PR snapd#2872 closed: tests: do not use core for "All snaps up to date" check <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2872>
<slunatecqo> Hi - question about ubuntu Core. I have a working machine in KVM, and when I want to ssh into it, it asks key passphrase. When I enter it correctly, it asks users password, which I don't know... any ideas?
<kyrofa> slunatecqo, you uploaded your SSH public key to your SSO account, etc.?
<slunatecqo> kyrofa: yes - the key is set up - after I enter its passphrase it asks for user password
<nacc> slunatecqo: is the 'it' ssh? ssh -vvv may help see if it rejected your key, if so
<kyrofa> slunatecqo, which implies to me the key you're using doesn't match up to a key authorized on the device
<kyrofa> slunatecqo, indeed, try nacc's advice
<jdstrand> zyga: I'll add it to the list. not sure it will be today, but will be able to first thing next week (off tomorrow)
<slunatecqo> nacc: yeah... thats it.. the passphrase should be blank, but for some reason ssh says "debug2: no passphrase given, try next key"
<zyga> jdstrand: I'm off next week
<zyga> jdstrand: if you can I'd appreciate it, the diff is tiny
 * zyga back to other things
<zyga> slunatecqo: it means that it tried your ssh key (which was encrypted) but they it tried password auth
<zyga> slunatecqo: the key associated with your account is not the key you've used
<slunatecqo> zyga: yeah. I understand.... thanks
<mup> PR snapd#2873 closed: tests: several improvements to the nested suite <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2873>
<mup> PR snapd#2926 opened: cmd/snap-update-ns: move test data and helpers to new module <Created by zyga> <https://github.com/snapcore/snapd/pull/2926>
<slunatecqo> Ok - one more. I just installed docker in fresh UbuntuCore. running any container gives me "container command XXXX could not be invoked"
<zyga> slunatecqo: not sure about that, what is your environment?
<slunatecqo> environment?
<slunatecqo> I am running ubuntu-core-16-amd64.img using qemu-KVM
<zyga> mmm
<zyga> slunatecqo: can you please report that
<zyga> slunatecqo: I'm sure people will want to look at it and fix it
<slunatecqo> where? launchpad bugs?
<zyga> slunatecqo: yes please, on launchpad.net/snappy
<mup> Bug #1667408 opened: docker container command XXXX could not be invoked <docker> <Snappy:New> <https://launchpad.net/bugs/1667408>
<kyrofa> slunatecqo, lool might have some thoughts if he's around
<slunatecqo> kyrofa: is it ok to ask directly him? on some IRCs it is not...
<lool> slunatecqo: which docker is this?
<lool> slunatecqo: 1.13?
<kyrofa> slunatecqo, I sorta did ;)
<lool> slunatecqo: 1.13 is known broken unfortunately
<slunatecqo> lool: Docker version 1.11.2, build v1.11.2-snap-38fd0d3
<kyrofa> slunatecqo, not the best to directly ping people for generic questions, but in this case I know lool is The Docker Guy
<slunatecqo> kyrofa: thank you :-)
<lool> slunatecqo: are you on classic or on core?
<slunatecqo> KVM image from here https://developer.ubuntu.com/core/get-started
<slunatecqo> lool: so I guess core :D
<lool> Yes
<lool> slunatecqo: how are you installing and running?
<lool> slunatecqo: my whole knowledge is recap-ed in https://docs.google.com/document/d/1JHa6tkuR9PtpnAVVmAJIAKuyKBy8E9ZkvG5Wbc6HZSY/edit#heading=h.j2sflymhgsj8
<lool> which might be slightly out of date
<lool> it's also possible that some regressions occurred
<slunatecqo> https://bugs.launchpad.net/snappy/+bug/1667408 here is the bug reported
<mup> Bug #1667408: docker container command XXXX could not be invoked <docker> <Snappy:New> <https://launchpad.net/bugs/1667408>
<slunatecqo> basically just snap install docker
<slunatecqo> ah - that will be it... the image is armhf?
<slunatecqo> no... doesnt solve the problem..
<slunatecqo> lool: have to leave now for few minutes. Could you write ideas to the bug on launchpad?
<lool> slunatecqo: I suggest you open a bug against github.com/docker/docker and link it back on Launchpad
<lool> slunatecqo: docker is directly publishing the snap
<lool> slunatecqo: I wont have time to debug this this week and am travelling the next 2.5 weeks
<pmcgowan> is there any way to determine when the next refresh check is scheduled?
<lool> slunatecqo: I dont have a clean Core environment handy, but I did give this a try on classic and it worked there: http://paste.ubuntu.com/24054379/
<lool> slunatecqo: so it's probably specific to core
<mup> PR snapd#2927 opened: cmd: add .indent.pro file to the tree <Created by zyga> <https://github.com/snapcore/snapd/pull/2927>
<zyga> pmcgowan: hey, there are some controls for that coming
<zyga> pmcgowan: it's mostly implemented
<zyga> pmcgowan: but not released yet
<mup> Bug #1606674 changed: Unable to drive Adruino over USB from Arduino IDE snap <isv> <snapd-interface> <snapd:Triaged by zyga> <https://launchpad.net/bugs/1606674>
<zyga> pmcgowan: you can set schedule in a very detailed way
<pmcgowan> zyga,ok, it seems one of my systems runnign xenial isnt doing refreshes
<pmcgowan> zyga, wondering how to debug
<zyga> pmcgowan: what's the version of snapd?
<pmcgowan> its got core 16.04.1
<pmcgowan> 2.22.3 snapd
<kyrofa> jdstrand, raw-usb doesn't seem to cover /dev/ttyUSB*, right?
<zyga> pmcgowan: what does "snap info core" say?
<pmcgowan> zyga, http://pastebin.ubuntu.com/24054592/
<pmcgowan> refresh --list shows 8 snaps
<zyga> wow
<zyga> don't refresh yet please
<zyga> one sec
<zyga> pmcgowan: can you pastebin snap changes
<pmcgowan> zyga, http://pastebin.ubuntu.com/24054598/
<pmcgowan> not very interesting
<jdstrand> kyrofa: correct. it allows access to /dev/bus/usb/*, not /dev/.... /dev/ttyUSB* is covered by the serial-port interface
<zyga> pmcgowan: can you run journalctl -ux snapd
<zyga> anything broken?
<kyrofa> jdstrand, which again is gadget only
<jdstrand> today, yes
<kyrofa> jdstrand, talking about bug #1606674 here
<mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <isv> <snapd-interface> <snapd:Triaged by zyga> <https://launchpad.net/bugs/1606674>
<zyga> kyrofa: we need hotplug
<kyrofa> zyga, yes. But I don't see that on the horizon
<pmcgowan> zyga, http://paste.ubuntu.com/24054608/
<kyrofa> And this has been an issue from the beginning
<pmcgowan> zyga, assume you meant -u
<kyrofa> zyga, we need something to unblock
<jdstrand> kyrofa: I think it is on the horizon. it was discussed as important in The Hague. best to ask JamieBennett on the priority
<zyga> pmcgowan: -ux is for failures but this is good
<pmcgowan> zyga, ah, yes no matches
<jdstrand> kyrofa: niemeyer said in The Hague that he would design hotplug and then present it for review. I don't know where that fell in the prioritization discussions after
<zyga> pmcgowan: systemctl status snapd.refresh.timer
<zyga> kyrofa: I think we need to work on hotplug and not to stopgaps
<jdstrand> kyrofa: also, this should work in devmode. https://bugs.launchpad.net/snapd/+bug/1606674/comments/2
<mup> Bug #1606674: Unable to drive Adruino over USB from Arduino IDE snap <isv> <snapd-interface> <snapd:Triaged by zyga> <https://launchpad.net/bugs/1606674>
<pmcgowan> zyga, I did have it off at some point but its been on a wile now http://pastebin.ubuntu.com/24054611/
<zyga> pmcgowan: how about snap list
<jdstrand> fwiw, I agree with zyga on focusing on hotplug instead of stop gaps cause that will unblock a lot
<kyrofa> jdstrand, devmode is not the answer when you're done developing and want to ship something
<pmcgowan> zyga, http://paste.ubuntu.com/24054612/
<jdstrand> kyrofa: of course, but the bug talks about it not working in devmode
<zyga> pmcgowan: ok, can you, just for debugging, save /var/lib/snapd/state.json somewhere
<zyga> pmcgowan: and then sudo snap refresh
<pmcgowan> sure
<zyga> and hold your fingers croessed
<zyga> thanks!
<zyga> maybe you will uncover why this happens
<pmcgowan> zyga, I think that works, but then it doesnt update again for days
<kyrofa> jdstrand, indeed, though it was clarified in the comments that was a normal permission issue
<jdstrand> kyrofa: I suggest escalating this via the snappy team's stakeholder process
<zyga> kyrofa: yes, +1 on that process
<jdstrand> kyrofa: yes, that is the comment I gave the url to :)
<zyga> kyrofa: it's rally the best thing we can do
<jdstrand> kyrofa: JamieBennett holds a weekly stakeholder meeting iirc. he can help you participate in the process
<pmcgowan> zyga, yeah its getting everything
<zyga> pmcgowan: including core?
<pmcgowan> yes
<zyga> (let's see what we get)
<pmcgowan> btw why did the versioning go from 16.04.1 to 16-2
<zyga> pmcgowan: $reasons, we want something we cannot yet get so this is a stub
<zyga> pmcgowan: we'll get 16-$snapd_version
<zyga> pmcgowan: when snapcraft can
<pmcgowan> ah
<niemeyer> pmcgowan: Heya
<pmcgowan> niemeyer, hey
<niemeyer> pmcgowan: So what happens when you type "snap refresh core"?
<niemeyer> Sorry if I missed that in the backlog
<zyga> niemeyer: we have a copy of the old state
<zyga> niemeyer: for forensics
<pmcgowan> niemeyer, snap refresh got everything (except devmodes)
<zyga> pmcgowan: I'd appreciate if you send that to us in private
<pmcgowan> niemeyer, it always manually works
<pmcgowan> zyga, can email to you
<niemeyer> pmcgowan: What happens when you run, more specifically?
<niemeyer> pmcgowan: "snap refresh core"
<pmcgowan> niemeyer, it already refreshed but quite sure it would work
<zyga> pmcgowan: please
<zyga> do you think it is worth aborting and checking just core
<niemeyer> pmcgowan: So manually it works, but it wasn't running automatically?
<pmcgowan> correct
<zyga> niemeyer: the timer was set and enabled
<zyga> niemeyer: but last ran ... 21 days ago
<pmcgowan> at some  point I had disabled the timer
<pmcgowan> but it was on since a week I think
<zyga> pmcgowan: but it was meant to run in two hours based on your pastebin above
<zyga> is it possible that the timer no longer works for whatever reason
<zyga> (e.g. runs as real root)
<niemeyer> The systemd timer is no longer respected..
<zyga> ?!
<niemeyer> It's internal now..
<zyga> in 2.21.3?
<zyga> hmmm
<niemeyer> Or am I mixing that with code that is yet to come?
 * niemeyer looks
<zyga> niemeyer: I think we live on the ege, let's see what was on 2.21.3
<pmcgowan> zyga, I had 2.22.3 fwiw
<zyga> right, sorry
<mup> PR snapd#2920 closed: wrappers/services: RemainAfterExit=yes for oneshot daemons w/ stop cmds <Created by ssweeny> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/2920>
<zyga> 22 is the only version with further point releases
<niemeyer> zyga: Nevermind.. the logic I'm talking about hasn't landed yet
<niemeyer> pmcgowan: What do you have on "snap changes" by now?
<zyga> niemeyer: omg
<zyga> niemeyer: it's not doing refreshes in that version
<zyga> just the timer can do that
<niemeyer> pmcgowan: Also, please: "systemctl cat snapd.refresh.service" and "systemctl cat snapd.refresh.timer"
<niemeyer> zyga: Not sure I understand what you mean
<niemeyer> zyga: Yes, just the timer can do that, and it's the timer that does that.. ?
<pmcgowan> niemeyer, http://paste.ubuntu.com/24054719/
<zyga> niemeyer: sorry, I misread your earlier statement, I thought we managed to release a version that doesn't refresh internally and ignores the timer
<zyga> pmcgowan: snap version
<zyga> pmcgowan: is it 2.22.6?
<niemeyer> Nope
<niemeyer> We actually never released a version that ignores the timer
<pmcgowan> zyga, yes
<niemeyer> This is up for review and pending high-level conversations
<pmcgowan> niemeyer, zyga lets see if it works now, I don't want to waste your time
<pmcgowan> zyga, niemeyer earlier today I saw that the system time was storing local to the rtc, and I suspected that messed up the timer
<pmcgowan> since the local time was set after snapd ran
<pmcgowan> but I fixed that, so maybe I then just didnt wait long enough
<zyga> pmcgowan: what's the delta between local and utc?
<pmcgowan> 5 hours
<zyga> ha
<niemeyer> pmcgowan: journalctl -u snapd.refresh.service
<zyga> so you only had 1/6 of chance to update
<pmcgowan> niemeyer, no entries
<zyga> or am I reading it wrong?
<niemeyer> pmcgowan: That means the timer has never ever run
<pmcgowan> hmm
<niemeyer> Well, sorry, that's actually not true.. your system might not be persisting the logs
<pmcgowan> niemeyer, maybe I somehow have the service disabled
<niemeyer> pmcgowan: systemctl status snapd.refresh.timer?
<zyga> niemeyer: default journal is not going across boots I think
<niemeyer> Yeah, it requires a mkdir
<zyga> right
<pmcgowan> http://pastebin.ubuntu.com/24054758/
<pmcgowan> is the service just not started?
<zyga> pmcgowan: the service is just a oneshot AFAIR
<zyga> pmcgowan: runs snap refresh
<pmcgowan> well maybe it was the time thing, in which case it should start working
<zyga> niemeyer: set your system to local time (like windows)
<zyga> niemeyer: and see what you get
<zyga> niemeyer: just let it sit for 24 hours
<zyga> niemeyer: I think you're almost as far from UTC, right?
<Pharaoh_Atem> niemeyer is on my timezone, I think
<Pharaoh_Atem> UTC-5?
<niemeyer> pmcgowan: That log says the timer was started 3h ago
<zyga> timedatectl set-local-time true (AFAIR)
<pmcgowan> niemeyer, yes
<zyga> hmmm
<pmcgowan> although  it spits out two lines of adding hh:mm:ss
<niemeyer> pmcgowan: And there are logs
<niemeyer> pmcgowan: Can you please try this again:
<niemeyer> pmcgowan: journalctl -u snapd.refresh.timer
<zyga> niemeyer: recall that in http://pastebin.ubuntu.com/24054592/ we saw the core snap was last refreshed on 2017-02-02 13:25:08 -0500 EST
<pmcgowan> http://pastebin.ubuntu.com/24054781/
<niemeyer> zyga: That's irrelevant.. we don't fiddle with the systemctl timer I don't think
<zyga> niemeyer: we don't fiddle with it no, but if it ran 3 hours ago then... what happened/
<pmcgowan> why does it say adding 5h then adding 4h
<niemeyer> pmcgowan: So how come it had no entries and now it does?
<zyga> pmcgowan: that's a systemd randomization thing
<niemeyer> pmcgowan: Did you run "systemctl restart snapd.refresh.timer" by any chance?
<zyga> pmcgowan: did you reboot in the last three hours?
<pmcgowan> niemeyer, the service had no entries
<niemeyer> @pmcgowan Ah, sorry, gotcha
<nothal> niemeyer: No such command!
<niemeyer> pmcgowan: Did you reboot your system ~3h ago?
<pmcgowan> zyga, up 3:13
<pmcgowan> yes
<zyga> so it could have ran earlier
<zyga> but we don't have logs
<zyga> but I think syslog is preserved
<zyga> maybe there is a trace in syslog beore the boot
<zyga> can you check at around that time?
<niemeyer> pmcgowan: Okay.. my theory so far is that the timre was indeed not enabled, but it's hard to validate it
<niemeyer> pmcgowan: Can you please enable the logs persistently by doing "mkdir /var/log/journal"
<pmcgowan> niemeyer, sure
<pmcgowan> zyga, what should I look for?
<niemeyer> pmcgowan: and systemctl restart systemd-journald
<zyga> pmcgowan: for the service name maybe
<zyga> pmcgowan: not sure how it is logged
<zyga> pmcgowan: ideally for a trace that it ran and maybe for the output
<niemeyer> Uh oh, wait
<niemeyer> pmcgowan: grep 'snap.*refresh' /var/log/syslog | pastebinit
<pmcgowan> zyga, there is a failure in there http://pastebin.ubuntu.com/24054813/
<pmcgowan> niemeyer, http://paste.ubuntu.com/24054819/
<zyga> hmmm
<zyga> niemeyer: theory: related to exit code of refresh
<zyga> niemeyer: maybe we refresh once, nothing to do, we return an error and systemd skips running this?
<zyga> DNS error
<zyga> hmmm
<niemeyer> zyga: I was wrong.. the snapd I have from edge is ignoring refreshes from the timer.. I'm about to figure when that started
<niemeyer> Commit was on Feb 1st
<zyga> niemeyer: 2.22.3 was on Date:   Fri Feb 17 21:04:27 2017 +0100
<zyga> (tagged)
<EEight_> hey, i am trying to upload a snap to myapps.dev via jenkins, is there a way to use snapcraft login --username xxx --password xxx?
<niemeyer> zyga: Nope, wasn't disable on 2.22.3
<zyga> EEight_: no but you can copy the auth data
<niemeyer> wasn't disabled
<zyga> niemeyer: look up in history
<EEight_> zyga: can you give me more information (auth data)?
<zyga> niemeyer: mvo probably commited it on Feb 1st but it landed later
<zyga> EEight_: look at .snap/auth.json
<niemeyer> zyga: Was never released
<niemeyer> zyga: It's in master only
<niemeyer> Thus edge
<niemeyer> pmcgowan: Were you on edge by any chance?
<zyga> I see
<zyga> niemeyer: it was tracking stable
<zyga> niemeyer: there's a pastebin at the start of the converstation, let me pull it up
<zyga> http://pastebin.ubuntu.com/24054592/
<EEight_> zyga, where to find this file (no .snap in my home)
<zyga> EEight_: snap login
<zyga> EEight_: the it will be there
<zyga> (sudo snap login)
<EEight_> zyga, excellent got it, then how to pass that to snapcraft login for uploading my snap on myapp.devs...
<zyga> kyrofa: ^^^
<niemeyer> pmcgowan: That syslog is a bit suspect
<niemeyer> pmcgowan: How come the time goes back and forth and back and forth
<zyga> niemeyer: wow
<zyga> niemeyer: maybe ntp is not aware of local time
<niemeyer> A crazy clock would be a great reason for timers not to work :)
<zyga> niemeyer: and kicls in
<zyga> niemeyer: and then ... some other component does the same
<pmcgowan> niemeyer, thats the local time screwup
<zyga> pmcgowan: is this a VM?
<pmcgowan> no
<niemeyer> pmcgowan: Ok, but it's not just a screw up
<zyga> hmmm
<niemeyer> pmcgowan: It's going back and forth multiple times
<pmcgowan> I think once each reboot
<pmcgowan> or do you see otherwise
<zyga> niemeyer: now that you menitoned it that clock is everything but monotonic
<niemeyer> pmcgowan: I don't have reboot information there.. I just see that on Feb 23 alone it went 10, 15, 10, 16, 11, ...
<pmcgowan> what I thought it was doing was booting to utc, then reseting to local time one the network was checked
<pmcgowan> niemeyer, thats each boot, and the last boot I had local turned off
<pmcgowan> thinking that was screwing with the refresh timer
<niemeyer> pmcgowan: OKay, that may well be the case.. can you dig into an older syslog file with that same grep line
<zyga> pmcgowan local time is stored in the hardware clock
<zyga> pmcgowan: tha's what the systemd knob controls AFAIR (for compat with windows)
<niemeyer> pmcgowan: syslog.1 or 2.gz
<zyga> pmcgowan: do you dual boot?
<pmcgowan> niemeyer, sure which grep again?
<niemeyer> pmcgowan: Well, not really.. the hardware clock stores *a* time.. it's the O.S. that gives it meaning, and that's configurable
<niemeyer> Sorry, that was for zyga
<niemeyer> pmcgowan: Let me copy, just a sec
<niemeyer> pmcgowan: grep 'snap.*refresh' /var/log/syslog.1 | pastebinit
<zyga> niemeyer: yes, that's correct
<zyga> niemeyer: I meant that the knob on systemd instructs it to store the local time into the clock
<zyga> niemeyer: vs UTC as is done by default
<kyrofa> EEight_, I'm afraid zyga is incorrect
<kyrofa> EEight_, snapcraft login isn't the same as snap login
<kyrofa> EEight_, but it's similar. Running `snapcraft login` saves a macaroon in .config/snapcraft/snapcraft.cfg
<zyga> kyrofa: ah, too bad
<pmcgowan> niemeyer, no hits
<pmcgowan> on .1 or .2
<kyrofa> EEight_, you can encrypt that file and use it in CI, though I recommend you create a store account for your bot
<kyrofa> (rather than giving it your macaroon)
<niemeyer> pmcgowan: Any hits on any of the other files?
<kyrofa> EEight_, note that snapcraft has an `enable-ci` command
<EEight_> kyrofa, snapcraft login, not possible to pass the username and password directly on the command line?
<kyrofa> Which does this for you
<kyrofa> But it only supports travis at the moment
<kyrofa> You might investigate adding support for jenkins
<pmcgowan> niemeyer, http://paste.ubuntu.com/24054941/
<kyrofa> EEight_, I'm afraid not
<EEight_> kyrofa, ok, so the solution is to encrypt the macaroon and pass that to snapcraft?
<kyrofa> EEight_, in CI, you'll need to un-encrypt that file and place it in ~/.config/snapcraft/snapcraft.cfg
<kyrofa> EEight_, at that point, snapcraft will be "logged in" if you will
<kyrofa> EEight_, note that encryption is not required here, but I assume you'll be storing it in a source tree somewhere, in which case note that macaroon is essentially a password
<kyrofa> EEight_, i.e. don't share it in the clear
<ahasenack> hi guys, do you know if /usr/bin/lsb_release was removed from the core snap?
<zyga> ahasenack: not sure but I'd recommend to use /etc/os-release instead
<ahasenack> zyga: the tool is a convenient way to avoid having to parse the file (but parse the tool's output)
<alex-abreu> kyrofa, ping
<zyga> ahasenack: the file is easier to parse and you don't have to run a separate process
<alex-abreu> kyrofa, quick question, where do you see the configure hooks logs?
<ahasenack> zyga: still, if it was removed in an update, sounds like an important change
<pmcgowan> zyga, niemeyer it just did a refresh check
<kyrofa> alex-abreu, you mean stdout/stderr? They belong to the task as I recall, which means you don't see them unless the hook fails
<kyrofa> alex-abreu, note that you can run the hook directly with `snap run --hook`
<alex-abreu> kyrofa, yes
<kyrofa> If you're just talking about developing
<alex-abreu> kyrofa, the hook then runs in the same context as the one defined when running as part of snap-confine?
<niemeyer> pmcgowan: Nice. I really don't know what to make from it.. the complete silence on the logs for several days hints at a manually disabled timer, which I think you said had happened, right?
<kyrofa> alex-abreu, indeed
<niemeyer> pmcgowan: That plus the crazy clock makes me feel like the environment is a bit unhealthy
<niemeyer> pmcgowan: In either case, we're changing that timer mechanism and making it internal
<niemeyer> pmcgowan: So one way or another, the problem will be fixed
<pmcgowan> niemeyer, I can except it was my system setup
<pmcgowan> I do suspect the rtc clock setting, I could try later to put it back and see what happens
<niemeyer> pmcgowan: I'll remember to review the timer logic and consider what would happen in such skews
<niemeyer> pmcgowan: The new logic, that is
<pmcgowan> great thanks for the help
<alex-abreu> kyrofa, mmmh ... a hook has access to SNAP_COMMON right?
<kyrofa> alex-abreu, it should, yes
<kyrofa> alex-abreu, though note that things in there are typically owned by root if you're running into permissions issues and aren't running `snap run` via sudo
<zyga> ahasenack: we don't guarantee it will be present there
<ahasenack> zyga: ok, so after some debugging... We have a snap that calls /usr/bin/lsb_release
<ahasenack> zyga: on existing systems that upgraded to the latest core snap, our snap keeps working somehow
<ahasenack> zyga: but if these are rebooted, then our snap doesn't find /usr/bin/lsb_release anymore
<zyga> ahasenack: let me look
<ahasenack> zyga: https://bugs.launchpad.net/snappy/+bug/1619420 is about the lsb_release removal
<mup> Bug #1619420: snappy removal of dpkg-query breaks lsb_release --all <cloud-init:New> <Snappy:Fix Committed by ogra> <livecd-rootfs (Ubuntu):Fix Committed by ogra> <https://launchpad.net/bugs/1619420>
<zyga> ahasenack: on core systems?
<ahasenack> it was indeed removed
<ahasenack> zyga: no, ubuntu
<zyga> ahasenack: maybe it was removed on ubuntu
<ahasenack> zyga: /usr/bin/lsb_release was removed from the core snap
<zyga> ahasenack: yeah, I just checked
<ahasenack> see comment #11 and #14 in that bug
<ahasenack> zyga: ok, that broke our snap, we will fix it, but the question I have now
<ahasenack> zyga: is why upgraded systems kept working
<ahasenack> are they seeing the old core snap?
<zyga> ahasenack: no idea
<zyga> ahasenack: maybe
<zyga> ahasenack: snap info core
<zyga> ahasenack: if you have such a system around that would be good
<ahasenack> we just rebooted it
<ahasenack> I think I have a snap list --all
<mup> PR snapd#2924 closed: interfaces: specs for apparmor, seccomp, udev <Created by stolowski> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2924>
<zyga> ahasenack: I'll gladly help you figure out what's going on with the core snap but I think the fate of lsb_releaes is sealed
<zyga> it's a dead thing
<ahasenack> it's ok
<ahasenack> what I wanted to understand now is the dynamics of core updates, what happens to existing snaps when the core one is updated
<ahasenack> what do they see
<zyga> ahasenack: nothing
<ahasenack> it *looks* like they saw the old core filesystem, or perhaps a mix
<zyga> ahasenack: they see the old core till the machine reboots
<ahasenack> or maybe it was just a case of a dangling fd
<ahasenack> ah
<zyga> ahasenack: unless the app is not running
<zyga> ahasenack: we persist the mount namespace across app runs
<ahasenack> zyga: if the app snap is restarted, it still sees the old core?
<zyga> ahasenack: as long as it was not removed
<zyga> ahasenack: yes
<zyga> ahasenack: we keep three revisions of core around
<ahasenack> zyga: ok, and if the app snap is updated?
<ahasenack> it also keeps seeing the old core?
<zyga> ahasenack: yes
<zyga> ahasenack: that's a bug I'm fixing for the past month
<zyga> ahasenack: or more now
<zyga> ahasenack: that won't change soon actually but we plan to change the mount namespace the app exists in
<ahasenack> zyga: ok, is there a case where the app snap would see the new core, outside of a reboot?
<ahasenack> it would have to be removed and reinstalled?
<zyga> ahasenack: technically when the app changes it will see its new self on top of the core it ran with when you stated it for the first time since last boot
<zyga> ahasenack: not at present
<ahasenack> zyga: what if core got updated, say, 5x?
<ahasenack> I have core v1, app snap v1
<ahasenack> then core v2 removed lsb_release, app still sees it because core v1 is still there
<ahasenack> and so on, but you said we only keep 3 revisions around
<zyga> ahasenack: yes
<zyga> ahasenack: once the rootfs is removed strange things will happen
<ahasenack> zyga: at some point I will have core v3, v4, v5 (v5 being current)
<ahasenack> none with lsb_release (continuing on this example)
<ahasenack> then my app snap would fail outside of the reboot scenario?
<zyga> ahasenack: I'm working on snap-update-ns that goes into the snap's mount namespace and does updates
<zyga> ahasenack: I'm not entirely sure but I suspect so
<ahasenack> ok
<ahasenack> that's fine, I'm just trying to gather the failure scenarios for our bug
<ahasenack> where we are working on parsing /etc/os-release instead of relying on the presence of /usr/bin/lsb_release
<zyga> ahasenack: which language are you using?
<zyga> ahasenack: there are libraries for this for anything out there
<ahasenack> go
<ahasenack> we want to be sure we are on xenial
<ahasenack> never thought lsb_release would be gone, because, well, lsb stands for linux standards base :)
<zyga> ahasenack: lsb is as dead now as it was before
<ahasenack> hehe :)
<zyga> ahasenack: thank you
<zyga> ahasenack: you made me realize we have a nasty bug
<zyga> ahasenack: anyway
<ahasenack> "good" :)
<zyga> ahasenack: the core is okay, unless I can do what I think I did before when removal of the squashfs file made crazy things happen
<zyga> maybe it was a kernel bug though
<zyga> but what is buggy at present is that if your app was running
<zyga> and you update
<zyga> and even restart the app
<zyga> it will see the old core snap
<zyga> I'll fix that ASAP
<zyga> https://bugs.launchpad.net/snapd/+bug/1667479
<mup> Bug #1667479: mount namespace is not discarded when core snap changes revision <snapd:New for zyga> <https://launchpad.net/bugs/1667479>
<zyga> jdstrand: FIY, small omission /o\
<alex-abreu> kyrofa, we dont seem to run in a proper snap context when running snap run --hook ... my snapctl call fail
<zyga> alex-abreu: yes, known issue
<alex-abreu> zyga, ah do you have a bug # ?
<zyga> alex-abreu: the context you get when your hook runs for real is special (kind of a transaction)
<zyga> alex-abreu: no, pawel was handling that, I don't recall
<zyga> alex-abreu: there's an unfinished branch that adds a generic context for all the run cases so that you can always use snapctl
<zyga> alex-abreu: but still the run in a real (internal) run is special as we abort the transaction if the hook fails
<zyga> alex-abreu: let me look if there's a bug for this
<zyga> alex-abreu: I don't see one
<alex-abreu> thank you
<zyga> alex-abreu: please report it, I'll make sure pawel knows
<zyga> alex-abreu: sorry for the inconvenience
<alex-abreu> zyga, np, thank you for the heads up on that, ...
<kyrofa> alex-abreu, ah, right, snapctl can't be called without snapd generating the hook context variable
<kyrofa> alex-abreu, as zyga mentioned, pawel is working on making snapctl usable from apps as well, which will allow it to be used from snap run as well
<alex-abreu> kyrofa, yes, ... is there still a plan to expand snapctl to have systemctl like caps for like the current snap owned daemons etc.?
<kyrofa> alex-abreu, snapd generates a cryptographic token for each hook run that ties it to a specific snap (i.e. so you can run `snapctl get` without also supplying the snap name)
<kyrofa> alex-abreu, that's also probably pawel's domain these days
<alex-abreu> kyrofa, yes I saw that and tried to follow what snapd was doing around that
<alex-abreu> ah so pawel is the person to bother then
<zyga> kyrofa: pawel is a bit pulled around but I think he wants to go back there
<stokachu> do i need to ask to have a track created?
<stokachu> also how do i set my 2.1/stable as the default track users get when running snap install conjure-up --classic
<kyrofa> stokachu, yes, I believe you need to ask
<kyrofa> stokachu, who? I'm not quite sure
<stokachu> kyrofa, cool thanks
<mup> PR snapd#2927 closed: cmd: add .indent.pro file to the tree <Created by zyga> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2927>
<mup> PR snapcraft#1161 opened: channels: Add track support to commands <Created by josepht> <https://github.com/snapcore/snapcraft/pull/1161>
<ToyKeeper> Gah, I can't seem to get spread to respect my kill timeout.  It's defaulting to 15 minutes, which isn't long enough for this test to run, and ignoring my configured value.
<ToyKeeper> I've got "kill-timeout: 60m" in tests/main/gccgo/task.yaml (in snapd), but it's having no effect.
<kyrofa> zyga, any ideas on that? ^^
<ToyKeeper> I probably just need to set it at a project level instead of task level, if I can find the right place for it.
<mup> PR snapd#2880 closed: tests: empty init (systemd) failover test <Created by fgimenez> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2880>
<mup> PR snapd#2928 opened: tests: 2 workers on 14.04 and core 64, drop fixme system <Created by niemeyer> <https://github.com/snapcore/snapd/pull/2928>
<mcphail> 'error: snap "whatever" requires classic or confinement override' is a rather ugly and uninformative error message
#snappy 2017-02-24
<mup> PR snapd#2928 closed: tests: 2 workers on 14.04 and core 64, drop fixme system <Created by niemeyer> <Merged by niemeyer> <https://github.com/snapcore/snapd/pull/2928>
<mup> Bug #1667493 opened: Please update Ubuntu Core "snappy" 16.04 LTS   with libusb-1.0 <bot-comment> <Snappy:New> <https://launchpad.net/bugs/1667493>
<ToyKeeper> kyrofa, zyga: I got it to work, I think...  at least it hasn't timed out yet.  So that's promising.  Will submit a patch after it's confirmed.
<ToyKeeper> This device is quite a bit slower than the project was designed for, it seems.
<CreggerC> cool
<mup> PR snapd#2929 opened: Added storage-framework interface <Created by michihenning> <https://github.com/snapcore/snapd/pull/2929>
<mup> Bug #1667493 changed: Please update Ubuntu Core "snappy" 16.04 LTS   with libusb-1.0 <bot-comment> <Snappy:Invalid> <https://launchpad.net/bugs/1667493>
<jlorenzo> hi there! do you guys know where I can find the revision history of 'desktop-gtk3'?
<seb128> jlorenzo, hey, https://github.com/ubuntu/snapcraft-desktop-helpers/commits/master
<jlorenzo> seb128: thank you :)
<seb128> yw!
<seb128> do you have a problem with some recent change/update?
<jlorenzo> seb128: yes, but I'm not sure where's the issue. I'm building Firefox 52.0b9 with the same snap yaml file as 4 days ago.  And now I get this error:
<jlorenzo> Issue while loading plugin: properties failed to load for desktop-gtk3: Additional properties are not allowed ('prime' was unexpected)
<seb128> did you snap version change?
<jlorenzo> could it be that change? https://github.com/ubuntu/snapcraft-desktop-helpers/pull/54/files#diff-184032a532406b07009403e26f4fc62fR86
<mup> PR ubuntu/snapcraft-desktop-helpers#54: Support mir-libs content snap <Created by mikix> <Merged by didrocks> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/54>
<jlorenzo> I don't believe so, let me check
<seb128> could be I guess
<seb128> didrocks is out today though
<jlorenzo> seb128: I'm not too familiar with snap. Is there a way to pinpoint a revision in "after" (like here https://dxr.mozilla.org/mozilla-beta/source/release/docker/firefox-snap/snapcraft.yaml.in#37 ) ?
<seb128> jlorenzo, no there isn't afaik
<seb128> the situation is a bit unfortunate :-/
<seb128> Trevinho, flexiondotorg, you use the desktop helper for your snaps, did you hit that error recently^?
 * flexiondotorg reads backlog...
<flexiondotorg> Hello jlorenzo :-)
<jlorenzo> flexiondotorg: hi!
<flexiondotorg> To answer seb128's question, I do use the desktop helpers.
<flexiondotorg> I've not encountered the issue: Issue while loading plugin: properties failed to load for desktop-gtk3: Additional properties are not allowed ('prime' was unexpected)
<mup> PR snapd#2930 opened: tests: add systemd dependency loop failover test scenario <Created by fgimenez> <https://github.com/snapcore/snapd/pull/2930>
<flexiondotorg> jlorenzo You're working at Mozilla?
<jlorenzo> flexiondotorg: good to know :)
<jlorenzo> flexiondotorg: that's right
<flexiondotorg> OK, I was chatting to Rail Aliiev and Mike Kaply about snap Firefox yesterday :-)
<jlorenzo> great :D I'm on duty while Rail is still sleeping ;)
<flexiondotorg> Is the CI system building the snap on Ubuntu 16.04?
<jlorenzo> I believe so. Let me double check
<seb128> flexiondotorg, that change was made on wednesday it looks like, did you rebuild some snaps since?
<seb128> well I guess I can try a desktop-gtk3 example here
<flexiondotorg> jlorenzo Can you also make sure you have snapd 2.22.3 and snapcraft 2.27.1 installed on the build server.
 * seb128 does that
 * jlorenzo does it as well
<seb128> flexiondotorg, you think old versions would not handle some new syntax?
<jlorenzo> it that helps, we have a docker image that helps repro
<flexiondotorg> jlorenzo I understanding there are some patches for AppMenu integration that are being merged to Firefox, is the snap building a branch that has those patches?
<seb128> yeah, I can confirm the issue here
<jlorenzo> flexiondotorg: no, that's the regular firefox beta. For the record, 4 days ago, the previous beta (52.0b8) was correctly built. I rebuilt the same changeset, in the same condition, and it failed with the "prime" error
<seb128> on my simple ghex example
<flexiondotorg> jlorenzo Thanks.
<seb128> works after updating snapcraft to current
<jlorenzo> okay, I'll try updating
<seb128> jlorenzo, flexiondotorg, ^ I could reproduce on an non uptodate system, fixed for me after updating snapcraft to the xenial-updates version
<flexiondotorg> seb128 Yeah. I've not seen this issue myself but saw mention of something similar and that an update resolved it.
<jlorenzo> the last time our docker image got update was 5 months ago. It looks like the non-update is the cause
<jlorenzo> got updated*
<flexiondotorg> jlorenzo Once you have a snap building again you might want to do this following:
<flexiondotorg> after:
<flexiondotorg>       - desktop-gtk3
<flexiondotorg>       - indicator-gtk3
<flexiondotorg> Change the after stanza as above.
<flexiondotorg> The indicator-gtk3 helper will pull in all the libraries to support AppMenu.
<flexiondotorg> So when those patches land, you'll have the required support in the snap.
<Trevinho> with indicator-gtk3 you get the support before the patches have landed (to ubuntu, upstream is already fine) :-)
<jlorenzo> awesome! thank you guys for the leads
<jlorenzo> I'll tell you if the thing worked
<Trevinho> flexiondotorg: do you have any experience with classic confinement (defined in 'snapcraft.yaml' itself?)
<flexiondotorg> Trevinho I do.
<Trevinho> flexiondotorg: as... it seems that with latest snapcraft, PATH and LD_LIBRARY_PATH's aren't set by snepcraft itself, isn't it?
<zyga> o/
<flexiondotorg> Trevinho I hadn't noticed. I'll have to check that.
<Trevinho> flexiondotorg: as that causes th desktop-launch not to work anymore...
<flexiondotorg> OK, I'll test.
<Trevinho> flexiondotorg: although things such as themes and stuff, shouldn't be embedded when classic is set...
<flexiondotorg> I'm making a new classic snap PoC later.
<Trevinho> seb128: ^ ....
<Trevinho> ok
<flexiondotorg> So I'll be sure to test that. Thanks for the heads up.
<seb128> Trevinho, is that a reported bug/regression?
<seb128> if so it should be flagged as important
<Trevinho> I didn't look for that, as I though it was somewhat a wanted thing?
<flexiondotorg> jlorenzo Other than upstreaming the AppMenu patches, are there any blockers for Firefox?
<Trevinho> maybe is the core handling that now? I don't know if the environment: stanza  would do that
<Trevinho> seb128: i was also wondering if we should remove some things in the desktop-* parts when classic is used... as they access to global themes and such, so maybe... we don't have to embed those?
<Trevinho> a question for didier too
<jlorenzo> flexiondotorg: not that I know of, but I'm not too aware of the snap integration. I'll ask Rail later today about it.
<flexiondotorg> jlorenzo Thanks.
<flexiondotorg> jlorenzo I'm out of the office next week, but I'd like to catch up with you and Rail the following week.
<mup> PR snapd#2931 opened: vet: fix vet error on mount test <Created by stolowski> <https://github.com/snapcore/snapd/pull/2931>
<jlorenzo> flexiondotorg: sounds good to me
<flexiondotorg> Great.
<seb128> Trevinho, yeah, I guess we could
<mup> PR snapd#2932 opened: snap yaml: validate slot/plug names <Created by stolowski> <https://github.com/snapcore/snapd/pull/2932>
<flexiondotorg> jlorenzo Ping us here when you have good news from CI ;-)
<jlorenzo> flexiondotorg: sure! It may take several hours. We're still figuring if we need to respin a new build of not.
<jlorenzo> (we freeze every hash at the first step of the build, including the docker images)
<mup> PR snapd#2931 closed: vet: fix vet error on mount test <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/2931>
<mup> PR snapd#2926 closed: cmd/snap-update-ns: move test data and helpers to new module <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/2926>
<mup> PR snapd#2933 opened: overlord/hookstate: don't report a run hook output error without any context <Created by pedronis> <https://github.com/snapcore/snapd/pull/2933>
<_prasen_> I have 2 apps inside the yaml
<_prasen_> where one is a regular app and the other is a daemon
<_prasen_> both of them are shell scripts
<_prasen_> a variable created by the app script is used by the daemon script to launch a go server
<_prasen_> so I want to understand the context in which all of this happens
<glimcoil> John Lenton around? I have the install stuck at 'Run configure hook of "core" snap if present'
<_prasen_> the go server thingy is another part
<glimcoil> (Martin here)
<_prasen_> how do daemons inside the snap run
<_prasen_> ?
<_prasen_> is there a way to see the currently running daemons
<Chipaca> glimcoilâ o/
<Chipaca> glimcoilâ hello!
<glimcoil> Hello.
<Chipaca> glimcoilâ I've got to go on a school run in ~10 minutes but will be back after that
<glimcoil> Send me an email with a SSH public key and I can get you access to play around on one of them
<Chipaca> glimcoilâ ooh! that's more access than I expected to get, but I'll take it
<glimcoil> They are all VMs and I can rebuild them trivially
<Chipaca> glimcoilâ https://launchpad.net/~chipaca/+sshkeys
<glimcoil> So you can experiment on them - and I can get them again into the bad shape :-)
<_prasen_> sum1 tell me how do i see the running daemons
<glimcoil> Ok, I'll send you email. I hope you can access over IPv6. no IPv4 inbound access....
<Chipaca> glimcoilâ i'm john.lenton@canonical.com
<glimcoil> Noticed.
<Chipaca> I hope so too :-)
<Chipaca> ah, d'oh, you had my email from the list
<glimcoil> Just wanted to make clear that you don't need to worry about breaking things...
<_prasen_> glimcoil : how do i see running daemons?
<Chipaca> glimcoilâ i'm on a&a here and they do give me ipv6 but i've never needed it i think
<Chipaca> _prasen_â in what?
<_prasen_> i am using the awsiot snap
<Chipaca> _prasen_â systemctl | grep awsiot
<_prasen_> i did not find it there
<_prasen_> wait
<Chipaca> _prasen_â then systemctl status snap.awsiot-yadda
<_prasen_> gimme 2
<_prasen_> you familiar with the awsiot snap?
<Chipaca> looks like the service is snap.awsiot.run
<Chipaca> _prasen_â i am not
<Chipaca> also it did not work here
<_prasen_> it = ?
<Chipaca> _prasen_â reach out to the author?
<Chipaca> the service in the snap failed to start
<_prasen_> i will
<_prasen_> but i am very much not clear on how different parts are aligned to work together
<_prasen_> the daemon's command is a shell script
<_prasen_> that launches a go server
<Chipaca> I've got to go
<_prasen_> okaaay
<Chipaca> glimcoilâ looking forward to that email
<Chipaca> _prasen_â reach out to mectors; he should be around
<_prasen_> thanks for the help
<Chipaca> ttfn
<_prasen_> marteen ectors ?
<glimcoil> _prasen_: If you look for example (for a server written in C), see https://github.com/freerangerouting/frr.git  (Look for the snapcraft subdirectory). This is a Fork of Quagga with multiple routing daemons
<_prasen_> glimcoil : hahahahhahahahaha
<_prasen_> this is a pretty heavy example
<_prasen_> ty
<_prasen_> will try to get my head around it
<_prasen_> though the task i am at
<_prasen_> it just has a single daemon
<_prasen_> launching a pretty basic go server
<_prasen_> ty!
<_prasen_> well its fri night here..getting off for now
<_prasen_> gg
<desrt> hey.  does anyone know how snappy gets the profiles into aa?
<desrt> for some reason my aa-status has nothing, and my snaps are running unconfined
<ppisati> elopio: are you the test guy for snapcraft?
<ogra_> ppisati, i think he is on vacation this week
<ppisati> ogra_: :(
<mup> PR snapd#2933 closed: overlord/hookstate: don't report a run hook output error without any context <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/2933>
<jlorenzo> flexiondotorg: seb128: hey guys! so, the version upgrade fixed our pipeline! Thank you very much for your help and the context :D
<flexiondotorg> jlorenzo Great! :-)
<seb128> jlorenzo, hey, glad you got it resolved and yw! :-)
<Chipaca> *interesting*
<Chipaca> zyga, pedronis: I'm seeing the configure script stuck starting from *no snaps*
<Chipaca> zyga, pedronis, this is 2.22.3
<pedronis> Chipaca: I cannot even parse that?
<pedronis> what does from no snaps mean?
<Chipaca> pedronisâ snap list core -> "try hello world"
<Chipaca> i mean snap list
<pedronis> Chipaca: on, what?
<Chipaca> # snap list
<Chipaca> No snaps are installed yet. Try "snap install hello-world".
<pedronis> starting from what version of snapd?
<Chipaca> root@ci-comp11-dut:~# snap install core
<Chipaca> [|] Run configure hook of "core" snap if present
<Chipaca> ouch, shouldn't've pasted that, sorry
<Chipaca> pedronisâ 2.22.3
<Chipaca> pedronisâ nothing in debug logs either
<sborovkov> Hi. how can I run bash from inside the snap environment? There was command, something like snap try but I don't remember exact syntax
<Chipaca> sborovkovâ snap run --shell snap.app
<Chipaca> pedronisâ anything you want me to try, or should i wait for zyga? :-)
<pedronis> Chipaca: so it's very easy to reproduce?
<Chipaca> pedronisâ apparently!
<pedronis> good and bad
<Chipaca> pedronisâ but I'm not sure
<Chipaca> pedronisâ i mean, every test suite we run starts from no state
<Chipaca> right?
<sborovkov> Chipaca: thanks
<Chipaca> sborovkovâ np; good luck
<Tryum> Hi there !
<Chipaca> pedronisâ so, yes: reset-state, snap install core -> hanging conf hook
<pedronis> do we know where it hangs?
<Chipaca> pedronisâ how can i know?
<pedronis> strace?
<Chipaca> pedronisâ i've got root on the machine (because glimcoil is awesome like that)
<pedronis> Chipaca: anyway the issue might well be that we restart core but don't stop
<Chipaca> ah, strace. Give me a bit.
<pedronis> early
<pedronis> enough
<pedronis> so no snapd to talk to ?
<pedronis> or something like that
<Chipaca> pedronisâ https://private-fileshare.canonical.com/~john/trace
<Chipaca> pedronisâ that's post-restart
<zyga> Chipaca: re
<zyga> jjohansen: hey
<zyga> jjohansen: I'm about to add a new apparmor rule to 2.22.7 release
<zyga> jjohansen: can I use the one you gave in the bug report verbatim or do you have any last wishes?
<Chipaca> zygaâ o/
<Chipaca> zygaâ in your sea of VMs :-) do you have one that's pristine-ish (or pristinable), running stock snapd from the archive?
<zyga> Chipaca: I have a xenial VM that is snapshotted at 2.0.14 or something like that
<Tryum> Discovering ubuntu core ... tried it in a VM, and now on a pi 3... I wanted to launch a simple gui app (ubuntu-calculator-app) ... it asks me to install "ubuntu-app-platform" which seems not to be available ... :/
<Chipaca> zygaâ can you take it to 2.22.3 or thereabouts without installing snaps?
<Chipaca> zygaâ and then try to install core?
<Tryum> Is there some dirty-work-manual-package-installation to enable gui on rpi3 ?
<zyga> Chipaca: I did that all monday I think trying to reproduce the issue lool reported (ErrNoState), it was OK then
<zyga> Chipaca: but I tried with different core revision
<zyga> Chipaca: I'll try in a sec, let me push one thing first
<Tryum> (Not affraid to do so, I'm just evaluating if ubuntu-core could fit our needs for an iot-project :) )
<zyga> Tryum: the answer is yes!
<zyga> Tryum: and we can help you out
<kyrofa> ogra_, today, on stable core, is there no way to disable auto-updates, then?
<nacc> Tryum: it's a snap?
<nacc> Tryum: at least snap find, here, shows it exists
<Chipaca> Tryumâ did you check 'snap info ubuntu-app-platform'? maybe it's not a stable snap yet
<Chipaca> naccâ that's on amd64; armhf might be different
<Chipaca> (i'm assuming)
<zyga> jjohansen, jdstrand: should we add the extra rule for libc to all snaps or just those that use classic confinement in jailmode?
<nacc> Chipaca: good point
 * nacc is not certain how to see other archs from `snap`
<zyga> nacc: you need to run native AFAIR
<nacc> zyga: ah ok
<Chipaca> yeah. Not added a --arch option.
<kyrofa> Chipaca, that would be handy!
<Chipaca> hush you
<Chipaca> :-p
<kyrofa> Chop chop
<Chipaca> aww! but i wanted a weekend!
<nacc> heh
<Tryum> Ok snap info returns me something !
<kyrofa> Haha, yeah you're about there eh?
<Chipaca> Tryumâ also depending on your iot needs there are people poking at the framebuffer directly from qt i think?
<Chipaca> kyrofaâ <this> close
<Tryum> Chipaca: yes that's something I'm doing on raspbian
<Chipaca> I only know because we recently landed that interface (so the snap could be confined)
<Tryum> so the snap is available as candidate/beta/edge !
<Chipaca> (on master; not released yet afaik)
<Tryum> I guess that's why it does not install directly ;)
<Chipaca> Tryumâ as i understand it if you use e.g. --candidate for the app snap, the other one will come automatically
<Chipaca> but i could be wrong; i haven't worked on that
<mup> PR snapd#2934 opened: errtacker,overlord/snapstate: more info in errtracker reports <Created by pedronis> <https://github.com/snapcore/snapd/pull/2934>
<ogra_> kyrofa, yeah, i dont think you can disable updates currently
<kyrofa> ogra_, yeah I saw that PR you referred to was closed
<Tryum> Chipaca: --candidate did the trick ! thanks ;)
<ogra_> Tryum, i dont think ubuntu-app-platform will help much
<mup> PR snapd#2935 opened: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <https://github.com/snapcore/snapd/pull/2935>
<mup> PR snapd#2936 opened: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <https://github.com/snapcore/snapd/pull/2936>
<Tryum> ogra_: it's not providing the required interface ?
<Tryum> is there a way to list packages providing interfaces ?
<ogra_> Tryum, you can install mir-kiosk and mir-libs to get a display server up, but the app wont integrate with it (it would have to be specifically developed to run in kiosk mode) ... alternatively you can install unity8-session but that is also not helping with any additional apps since it wont allow execution in the UI
<ogra_> Tryum, we are simply not there yet
<Tryum> oki doki ;)
<ogra_> bits and pieces exist and run ... i.e. the mir kiosk demos do ... as well as the unity8-session snap
<ogra_> but integration is still lacking
<ogra_> (teh session can only run apps shipped inside the session snap ... (which is ... well... system-settings ...)
<ogra_> )
<Tryum> well my current app is a qt/eglfs app ... I should try to package it and try it on ubunt-core instead of poking around :D
<ogra_> well, your app might be able to run in kiosk mode then
<ogra_> you would have to a) make it use mir ... and b) make it use the mir interface on a snap level
<Tryum> I think maybe without mir-kiosk even ... as I did not compiled with wayland support
<Chipaca> ogra_â there's things talking to the framebuffer directly
<Chipaca> ogra_â not sure of the details though :-)
<ogra_> we dont have an interface for that (yet)
<ogra_> the mir-kiosk snap definitely works for Qt apps though
<ogra_> (i also have an experimental (VERY experimental) kodi snap that uses mir-kiosk just fine)
<mup> PR snapd#2937 opened: errtracker,overlord/snapstate: more info in errtracker reports <Created by pedronis> <https://github.com/snapcore/snapd/pull/2937>
<Chipaca> zygaâ did you get that vm up? or are you otherwise busy?
<WebWiz> hi there -- is there a snap for Google Chrome
<Tryum> ogra_: oh if you want testers for the kodi snap, I'm here ! I need a kodi running for a future product ;)
<ogra_> Tryum, once it is usable i'll remember you :)
<ogra_> (the mir patches are in kodi 18 only ... i had a backport into the just released kodi17 tree that worked but then i moved forward and everything is broken atm)
<ogra_> so it is kind of a matter of waiting for the kodi development release to be fixed
<ogra_> and there is no sound support at all yet
<ogra_> in any case, if you want graphical output on one of the arm boards, Qt and mir-kiosk are your best bets currently
<ogra_> https://developer.ubuntu.com/en/snappy/guides/mir-snaps/ has some info
<ogra_> (slightly outdated i think though ... )
<kyrofa> Hey davidcalle, the dragonboard image link on developer.ubuntu.com is hard-coded to 20161102 instead of using the current symlink
<davidcalle> kyrofa: hey, can fix tonight, not sure about deploying before monday, though, will check with webteam/is
<kyrofa> davidcalle, yeah no rush, just wanted to see if that was intentional or should be fixed
<Tryum> ogra_: thanks for the link
<davidcalle> Must have been, at some point
<davidcalle> Clearly not ideal now
<davidcalle> Thanks Kyrofa !
<kyrofa> davidcalle, sure thing!
<Tryum> well I guess it will be hard to quickly port our app to ubuntu-core then : currently we use omxplayer for the video playback, as we did not manage to get hardware video decoding throug QtMultimedia.
<Chipaca> glimcoilâ you around
<Chipaca> ?
<mup> PR snapd#2935 closed: interfaces/apparmor: compensate for kernel behavior change <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2935>
<mup> PR snapd#2937 closed: errtracker,overlord/snapstate: more info in errtracker reports <Created by pedronis> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/2937>
<kyrofa> ogra_, which channel do I need to use if I want the core snap including xenial's /etc/os-release for classic?
<ogra_> kyrofa, what arch ?
<ogra_> an x86 one ?
<ogra_> i just released something to candidate for amd64 and i386 ... all others ... edge
<kyrofa> ogra_, arm64
<kyrofa> ogra_, ah, okay thanks :)
<ogra_> arm64 classic ?
<ogra_> where did you get the classic install from ?
<kyrofa> ogra_, to clarify, I meant the classic snap
<kyrofa> ogra_, and edge
<ogra_> oh
<ogra_> yeah, classic -> edge
<alex-abreu> kyrofa, hey, sorry another quick question about configuration values & hooks
<alex-abreu> kyrofa, what characters are allowed for config keys?
<alex-abreu> snapctl is not very explicit about it, and when you have an error it is a bit hard to debug
<kyrofa> alex-abreu, good question
<kyrofa> alex-abreu, let me look
<alex-abreu> I get "invalid option name", the errors are a bit cryptic
<kyrofa> alex-abreu, yeah: ^(?:[a-z0-9]+-?)*[a-z](?:-?[a-z0-9])*$
<kyrofa> alex-abreu, regex errors are tough to make friendly
<alex-abreu> kyrofa, yeah in the meantime I found this bug by Pawel https://bugs.launchpad.net/snapd/+bug/1658140
<mup> Bug #1658140: More strict key check in snap/snapctl get/set broke existing snap <snapd:New> <https://launchpad.net/bugs/1658140>
<alex-abreu> kyrofa, well yeah ...
<alex-abreu> kyrofa, thank you for looking that up
<kyrofa> alex-abreu, no problem
<kyrofa> ogra_, on arm64, I refreshed core to edge, uninstalled classic, reinstalled, and I still have "Ubuntu Core" in my /etc/os-release
<kyrofa> (in the classic shell)
<kyrofa> This is new, too. Now we have the HOME_URL and BUG_REPORT_URL
<jjohansen> zyga: just use the suggested rule and go with classic confinement at least for now
<ogra_> kyrofa, hmm, when freshly creating the core chroot ?
<ogra_> err
<ogra_> the classic chroot
<kyrofa> ogra_, yep
<kyrofa> ogra_, I refreshed core to edge, the removed classic and re-installed it. That should do it, right?
<ogra_> you should actually see it creating os-release and lsb-release at the end of the creation when "sudo classic" creates the new chroot
<kyrofa> I don't, actually
<ogra_> i definitely saw it during my presentation yesterday
<kyrofa> I did too!
<ogra_> and there i also had snap removed classic first ...
<kyrofa> ogra_, this is what I see: http://pastebin.ubuntu.com/24060776/
<ogra_> and your core is also on edge ?
<kyrofa> Yeah, rev 1316
<ogra_> very weird
<kyrofa> ogra_, happy to try anything to debug it further, if you like
<ogra_> well, let me try again
<ogra_> i'm just in some other emergency thing atm so i cant constantly focus on that
<kyrofa> ogra_, understood, no problem
<ogra_> kyrofa, crap, yeah, there is something broken
<ogra_> kyrofa, switch your core to stable ... that should still have the bits
<kyrofa> ogra_, that what I used initially-- it didn't have the bits, which is when I asked you what I should be using instead
<kyrofa> ogra_, I'm not blocked, that file is writable. But yeah, something broke
<ogra_>  snap refresh core --stable ....reboot ...  then: snap remove classic ... snap install classic --devmode --edge
<ogra_> that should give you exactly what i used in the presentation
<kyrofa> ogra_, ah, I was using the initial image. I was probably not up-to-date core-wise
<ogra_> ah, yeah
<ogra_> you really want to be on the latest stable core
 * kyrofa goes back to stable
<ogra_> but that edge doesnt work is worrying
<ogra_> kyrofa, urgh
<ogra_> so when moving the build scripts a lot of stuff was missed by me ... https://github.com/snapcore/core/pull/10/files ...
<mup> PR core#10: sync up-to-date hooks (how did that happen?) <Created by ogra1> <https://github.com/snapcore/core/pull/10>
<ogra_> kyrofa, thanks for pointing it out, we were about to release a new core
<kyrofa> ogra_, sure thing, glad I didn't think to update my stable core :P
<ogra_> well, we didnt release yet
<kyrofa> ogra_, nah, I mean, I would have been perfectly happy
<kyrofa> And not talked to you at all
<kyrofa> ogra_, which by the way I can confirm works
<ogra_> yeah
<kyrofa> Oh my gosh.... someone remind me why I decided to build this on-device instead of using LP
<davmor2> kyrofa: you don't like flagellation but need punishment?
<kyrofa> Yeah that sounds about right
<kyrofa> davmor2, I finally slapped myself the fourth or fifth time I pressed the arrow keys to make sure it didn't freeze
<kyrofa> Alright, it's at the `staging` step. I'm going to spin up an LP build and I bet it'll finish first
<mup> Bug #1667829 opened: console-conf v0.0.5 crashes if no config needed <Snappy:New> <https://launchpad.net/bugs/1667829>
<Blu2> So, will snaps that have the home interface ever be able to access symlink folders?
<Blu2> or is that by design excluded?
<kyrofa> Blu2, what do you mean?
<kyrofa> symlink folders?
<kyrofa> Blu2, you mean symlinks that point outside of the home directory?
<Blu2> yes
<Blu2> on another HDD
<kyrofa> Blu2, I believe that's by design. There's the removable-media interface that covers that use-cas
<kyrofa> e
<Blu2> ok
<Blu2> thanks for the answer
<Blu2> I wish I could give programs specific folders that they can access
<mup> PR snapcraft#1084 closed: make: add support for cwd path to make() function <Created by 3v1n0> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1084>
<mup> PR snapcraft#1116 closed: Changed "snappy try" to "snap try" <Created by liu-xiao-guo> <Closed by kyrofa> <https://github.com/snapcore/snapcraft/pull/1116>
<mup> Bug #1667841 opened: core snap should clean up /run after build <Snappy:Triaged by ogra> <https://launchpad.net/bugs/1667841>
<mup> Bug #1667844 opened: r1325 core snap candidate rebooting every 7 min without iTCO_wdt module loaded <Snappy:New> <https://launchpad.net/bugs/1667844>
<ogra_> plars, sorry, 1337 fixes the blacklist stuff again
<plars> ogra_: awesome! good to hear :)
 * ogra_ just noticed the bug ... two image builds badly regressed not processing some build hooks
#snappy 2017-02-25
<mup> PR snapd#2938 opened: cmd/snap-update-ns: compute next action to transiton mount profile <Created by zyga> <https://github.com/snapcore/snapd/pull/2938>
<mup> Bug #1667865 opened: Unable to sideload large snap on DragonBoard <Snappy:New> <https://launchpad.net/bugs/1667865>
<mup> PR snapd#2939 opened: cmd/libsnap: add sc_string_append_char <Created by zyga> <https://github.com/snapcore/snapd/pull/2939>
<sborovkov> Hi, is there any documentation about how to turn on hwrng on rpi3 ubuntu core?
<azubieta> hello! I'm traing to get the list of available snaps by departments from https://search.apps.ubuntu.com/api/v1/departments/ but i get snaps that are not available from "snap install". How I could get the right snaps list for my device ?
<bjf> what is the snapcraft.yaml syntax for adding an alias to an app?
#snappy 2017-02-26
<azubieta> Hello, I'm trying to get the available snaps for my pc from https://search.apps.ubuntu.com/api/v1/departments/books-comics but I'm getting a lot of non-compatible items. Can someone help me to improve my query ?
#snappy 2018-02-19
<mborzecki> morning
<mup> PR snapd#4699 closed: cmd/snap: tweaks to 'snap info' output <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4699>
<mborzecki> mvo: morning
<mup> PR snapd#4689 closed: tests: new spread test for kvm interface <Created by sergiocazzolato> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4689>
<mvo> hey mborzecki ! good morning
<mup> PR snapd#4686 closed: daemon: make the ast-inspecting test smarter; drop 'exceptions' <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4686>
<mup> PR snapd#4617 closed: many: implement "refresh-mode: {restart,endure,...}" for services <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4617>
<mborzecki> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1746710 is this something calling xdg-user-dirs-update with incorrect locale?
<mup> Bug #1746710: Snap creates redundant duplicate directories in home folder <amd64> <apport-bug> <artful> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1746710>
<zyga> good morning
<mborzecki> zyga: morning
 * zyga feels sick today, I'll be off for at least half the day
<zyga> sorry guys
<mborzecki> zyga: get some rest
<zyga> I'll try to work in a few hours after some meds take effect
<mvo> hey zyga
<mvo> zyga: uh, yeah, get well!
<mborzecki> mvo: any idea why this test would randomly fail? https://paste.ubuntu.com/p/zSH48GPxp6/
<mborzecki> mvo: last i've seen it fail on #4702, restarted the build and it's green now
<mup> PR #4702: cmd/snap: also include tracking channel in list output <Created by chipaca> <https://github.com/snapcore/snapd/pull/4702>
<mborzecki> mvo: this one in particular failed on debian-9
<mvo> mborzecki: I assume this is randomly failing? or conistently?
<mborzecki> mvo: randomly
<mvo> mborzecki: it
<mvo> mborzecki: ups
<mvo> mborzecki: did that start recently? there was a branch to move to EnsureDirState() for this file recently by zyga
<mvo> I wonder if it that is related
<mborzecki> i don't recall exactly when it started to fail
<mborzecki> seen it a couple of times and it enede in my to-investigate list
<mvo> mborzecki: whats your feeling time wise? a couple of days or more than that? iirc the ensuredirstate thing landed only mid last week
<mborzecki> mvo: days, might as well be that change
<kalikiana> sliff
<Chipaca> moin moin
<mborzecki> Chipaca: kalikiana: morning guys
<Chipaca> just popping in for a minute before doing the morning school run
<Chipaca> what was up with the failing apparmor test on debian?
<mborzecki> Chipaca: https://paste.ubuntu.com/p/zSH48GPxp6/ it's gone after i restarted the job
<Chipaca> huh
<mborzecki> pstolowski: morning
<pstolowski> morning!
<Chipaca> pstolowski: o/ :-)
<Chipaca> mborzecki: good call on those changes, i'll do them when i get back
<mup> Issue snapcraft#1939 closed: rust plugin: i386 multiarch linker error  <Created by General-Beck> <Closed by kalikiana> <https://github.com/snapcore/snapcraft/issue/1939>
<mborzecki> mvo: i can reproduce the failure locally
<mvo> mborzecki: oh, nice!
<mvo> Chipaca: https://pad.ubuntu.com/dcABWlRGY9 are some notes about the c-n-f work, let me know what you think and where it is too terse
<zyga> re
<zyga> how are things
<Chipaca> mvo: on it
<Chipaca> mborzecki: when you say you'd rather the if directly next to the for, you just mean remove the interleaving comment and move the comments into the if/for?
<mborzecki> Chipaca: haha, don't know what i was thinking about when writihg this comment, what i meant is that you could swap the order of if/for blocks, so that the for comes first
<Chipaca> mborzecki: reason for having it earlier is that it's a quicker check
<Chipaca> feels silly to put quick checks after the slow one
<mborzecki> Chipaca: hm so maybe you meant to return in the `if idx2 := strings.IndexByte(rest, '/'); idx2 >= 0` block?
<Chipaca> gah
<Chipaca> mborzecki: ignore me, i shouldn't be allowed to look at code this early
<Chipaca> of course there's no return so the order is unimportant
<mborzecki> mvo: haha, yeah, that bug is random surely, we're replacing core snap revision in a string like this tmp.check-1114575628337396084.0.var.lib.snapd.snap.core.111.usr.lib.snapd.snap-confine with simple .Replace(..., "111", 1), this ends up replacing the first '111' that appears, producing glob: tmp.check-*4575628337396084.0.var.lib.snapd.snap.core.111.usr.lib.snapd.snap-confine
<zyga_> mborzecki oooh
<mborzecki> good thing is it will go away once we wait long enough
<zyga_> sorry, my bad!
<mborzecki> will open a PR shorty :)
<zyga_> thank you for tracing this and working on a fix
<mvo> mborzecki: haha, nice bug
<pedronis> mvo: hi, IÂ think once pstolowski auto-connect branch goes in, #4103 will need changes, but the hard problem should not be there anymore either
<mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<pedronis> mvo: we can talk about it when you want
<mvo> pedronis: oh, that sounds great. I was just picking up this PR again
<mvo> pedronis: when is a good time for you? in ~30min maybe?
<pedronis> yea
<mup> PR snapd#4703 opened: interfaces/apparmor: use snap revision with surrounding '.' when replacing in glob <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4703>
<mborzecki> zyga_: ^^
<pstolowski> pedronis, thanks for the review btw, i've just finished addressing your last comment and added some more tests; do you want
<zyga_> ack
<pstolowski> pedronis, do you want to take another look or can I merge when green?
<pedronis> pstolowski: mmh, IÂ just noticed something,  it's not a bug in the new code, the old code would behave the same I think, maybe you want to pop in that chat with mvo in a bit?
<pstolowski> pedronis, sure
<pedronis> pstolowski: it's related to the managers_test fwiw
 * kalikiana moving to coffee shop
<mborzecki> anyone wants to take a look at #4676?
<mup> PR #4676: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4676>
<mup> PR snapd#4049 closed: debian,vendor: import github.com/snapcore/squashfs and use <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4049>
<pstolowski> mborzecki, yes, looking at it atm
<mborzecki> pstolowski: thanks
<mvo> pedronis, pstolowski I am in the hangout channel now, ready when you are (not exactly 30min yet so no worries)
<pstolowski> k
<mup> PR snapd#4703 closed: interfaces/apparmor: use snap revision with surrounding '.' when replacing in glob <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4703>
<Chipaca> mborzecki: i think fmtChannel is a lot nicer thanks to your feedback, now
<pedronis> pstolowski: the ErrNoState change seems wrongly placed
<pstolowski> hmm
<pedronis> we still want to return err if it's not ErrNoState
<pedronis> pstolowski: IÂ left a comment
<pedronis> sorry
<pstolowski> ah
<pedronis> pstolowski: thank you for working through this, once it is green it can land
<pstolowski> pedronis, cool. thanks again for great reviews and spotting all these issues!
<Chipaca> niemeyer: are you here?
<niemeyer> Chipaca: Heya
<Chipaca> niemeyer: oh!
<Chipaca> mvo: he's here now, we could continue this right now
 * Chipaca can go to physio after the standup
<mvo> Chipaca: sure, I can if you want
<mvo> Chipaca: whatever is more convenient for you
<Chipaca> niemeyer: can you hangout?
 * Chipaca pops back onto the standup
<zyga_> what are you chatting about?
<mvo> zyga: c-n-f
<zyga> ah, interesting
<zyga> well, I'm in mount-land and I feel like <unicode poo> so I'll skip
<zyga> sorry guys, barely holding up here
 * Chipaca hugs zyga 
<mvo> zyga: thats fine
<zyga> good luck guys
<Chipaca> zyga: take a break, take a walk
<zyga> Chipaca I just got out of bed, I want to do stuff as otherwise I'll just sleep
<niemeyer> Chipaca, mvo: Yeah, omw
<Chipaca> zyga: taking a walk fixes that as well
<zyga> I think it's too cold now, it's been a windy and outdoory weekend for me and I guess this is why I feel like this now
<pstolowski> mborzecki, reviewed 4676
<thresh> hello
<thresh> I'm struggling with theming issues on VLC snap;  It only seems to work under Unity, and GNOME shell, KDE, and MATE seem to show non-themed windows95-like UI.  We're using Qt5 from xenial-updates.
<mborzecki> pstolowski: thanks a lot :)
<thresh> I've tried editing desktop-launch, to remove QT_QPA_PLATFORMTHEME=appmenu-qt5 and QT_QPA_PLATFORM=xcb from it, and now on KDE the Qt theme is picked up, but no icons show up at all.  It also does not fix the issue on gnome shell.
<thresh> Is there anything I forgot to include to the snap?  Maybe some deps which provide theming are not staged?   Here's the snapcraft.yaml: git.videolan.org/?p=vlc.git;a=blob;f=extras/package/snap/snapcraft.yaml
<popey> thresh: heya. I think this is a known issue which will be resolved as part of the work on 'layouts'. I believe zyga owns this?
<zyga> hey
<zyga> theme support?
<popey> Making it so desktop applications don't look out of place on other desktops.
<zyga> I think this is not strictly related to layouts but close; I believe the desktop theme is working on that
<zyga> I'm not actively involved anymore as the part I was working on (mechanics to make that possible) is ready now
<thresh> hey popey
<popey> I believe jamesh has a branch which is needed in the desktop helpers, but that's blocked on layouts AIUI
<popey> zyga: when will it land?
<zyga> popey my part has landed in 2.31
<zyga> I don't know what's the progress of the desktop team to use this
<zyga> seb128 ^ do you know anything about theme support work?
<zyga> https://forum.snapcraft.io/t/desktop-improvements-report-and-plans/3510 has some info
<zyga> popey I believe themes are now possible
<zyga> and I'm working on user mounts
<pstolowski> mvo, hey, a weird failure in just one test/machine - https://api.travis-ci.org/v3/job/343305881/log.txt - snap-userd-reexec test, have you seen that before?
<popey> I will drop jamesh a mail to see where we are (for when he wakes) (thresh, james is in nz), and get back to thresh once I know more.
<thresh> sweet popey
<pstolowski> mvo, looks like unexpected diff when checking /usr/share/dbus-1/services/io.snapcraft.Launcher.service
<thresh> thanks!
<pedronis> zyga: what's the status of #4644
<mup> PR #4644: tests: add a spread test for layouts <Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/4644>
<zyga> pedronis on my backlog,
<zyga> pedronis I think I know what to do now but I need to discuss this with mvo
<pedronis> ok
<mup> PR snapcraft#1938 closed: tests: improvements to demos <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1938>
<seb128> zyga, not more than what is in the forum
<mup> PR snapcraft#1940 opened: tests: remove the webcam-webui demo <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1940>
 * cachio afk
<mvo> pstolowski: in a meeting right now
<mvo> pstolowski: the error seems to be "Job for snapd.socket canceled." ?
 * zyga shivers
<pstolowski> mvo, gosh, the log got overwritten as I restarted the job. it was different issue before
<mup> PR snapd#4702 closed: cmd/snap: also include tracking channel in list output <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/4702>
<mvo> pstolowski: aha, ok.
<mup> PR snapcraft#1941 opened: project_loader: handle invalid unicode chars <Created by kalikiana> <https://github.com/snapcore/snapcraft/pull/1941>
 * kalikiana lunch
<zyga> mvo are bionic adt tests running against proposed?
<mvo> zyga: yes
<mvo> zyga: I run them locally now again to see if that helps
<zyga> because bionic still has an artful kernel
<zyga> I'm looking at that now
<mvo> zyga: I like your idea about the secocmp things
<zyga> (kernel)
<mvo> zyga: maybe I was unfairly blaiming adt!
<zyga> mvo I suck at finding the source package for 4.15 in bionic
<zyga> and at getting a useful changelog
<zyga> or configuration
<pedronis> mvo: fighting a bit to have clean tests but should have my UserAgent for snap repair PR soonish
<mvo> pedronis: great, thank you. no worries, I'm wrestling with autopkgtest right now anyway so I'm not blocked
 * zyga gets more meds, brb
<mup> PR snapd#4401 closed: snapstate/ifacestate: auto-connect tasks <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4401>
<pstolowski> mvo, pedronis ^ autoconnect changes landed
<mborzecki> yay !!
<pstolowski> yay indeed, i hope to see the same re interface-hooks soon :}
<mvo> pstolowski: nice!
<pedronis> pstolowski: \o/
<mup> PR snapd#4704 opened: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <https://github.com/snapcore/snapd/pull/4704>
<pedronis> mvo: a strange formatting in vendor.json has landed on master:  https://github.com/snapcore/snapd/blob/master/vendor/vendor.json#L77
<Chipaca> mborzecki: https://www.youtube.com/watch?v=rzKaOp383vA
 * Chipaca forgot to press enter half an hour ago
<mborzecki> haha
<mborzecki> right, looks relaxed :)
<mborzecki> Chipaca: https://www.youtube.com/watch?v=3QiGuXETYnQ
<thresh> popey, huh;  I've used KDE Neon repos with their version of Qt5 -- and VLC looknfeel on Kubuntu 17.10 is great now;  I'm going to do more testing now.
<popey> Yeah, it looks great on KDE Neon 16.04 here too.
<popey> (the version in stable)
<thresh> I mean I used kde neon repos to stage & build packages :)  Testing on the same kubuntu 17.10 to run it..
<popey> ahh
<thresh> it's weird that you have it working nicely on Neon @ 16.04
<thresh> it's not supposed to :]
<popey> Pretty sure the screenshot i put in the @ubuntu social post came from my kde laptop
<mvo> pedronis: autsch, probably my fault while resolving a conflict
<mup> PR snapd#4705 opened: set snap-repair User-Agent on requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4705>
<thresh> that probably means my snap is not exactly contained?
<mup> PR snapcraft#1940 closed: tests: remove the webcam-webui demo <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1940>
<pedronis> mvo: proposed 4705
<pedronis> mvo: do want me to do a PR for vendor.json ?
<mvo> pedronis: yeah, please do
<Chipaca> thresh: what's your snap?
<popey> Chipaca: vlc
<mup> PR snapd#4706 opened: vendor: resync formatting of vendor.json <Created by pedronis> <https://github.com/snapcore/snapd/pull/4706>
<Chipaca> looks confined here
<pedronis> mvo: ^ done
<pedronis> mvo: do you needa  cherry pick for 2.31 of 4705 ?
<thresh> http://thre.sh/stuff/vlc-snap-kubuntu-neon.png  - the one on the right is the snapped one, the left one is 2.2.6 from the repos
<thresh> looks like I'm missing some fonts still
<kalikiana> re
 * pedronis break
<thresh> yeah, solves the looknfeel on Gnome shell as well
<thresh> let's try mate
<ogra_> what is really awesome about the vlc snap is that it comes with full vaapi support ... i can actually run fully accelerated video playback on 16.04 with it where vaapi in the repo isnt properly working...
<ogra_> popey, ^^^ we should probably do some promotion around that fact ;)
<popey> It was quite a challenge to get that working!
<niemeyer> Stepping out for an early lunch so I can be in a call at the top of the hour.. biab
<popey> (on nvidia, amd and intel)
<ogra_> and it is soooo awesome !
<thresh> yeah, and that's all not my fault :)
<cachio> mvo, snap core 2.31 in stable
<ogra_> i really love that my laptop fan stays silent if i stream TV
<cachio> mvo, smoke test passed
<thresh> yep, but that isnt reproduced on Debian stable with nvidia, on gnome shell, it's the same
<thresh> oops EWRONGCHAN
<thresh> I wonder if I'm supposed to ship all the fonts the users might use?
<thresh> it would be pretty tough to handle all weird languages
<popey> No, as I understand it layouts can fix fonts too
<ahasenack> hi, this doesn't seem right, I have just two revisions of the core snap installed, but many more mountpoints for it: https://pastebin.ubuntu.com/p/7nj4VNrsw5/
<ahasenack> this is on xenial, and the machine was rebooted a few minutes ago
<mup> PR snapd#4707 opened: Tests interface broadcom asic control <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4707>
<kalikiana> Chipaca: your comment on #1941 is confusing me... either I utterly failed at explaining or you're talking about something else than I am. You seem to be suggesting that I am somehow changing validation. I'm not. All this is is an explicit error message. No change in the underlying logic whatsoever.
<mup> PR #1941: interfaces/builtin: allow mmaping pulseaudio buffers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/1941>
<Chipaca> kalikiana: before your change, if you had a ð©  in your description, you'd get a nasty traceback
<kalikiana> Yes
<Chipaca> kalikiana: with your change you now get an error that says "character foo not allowed in description"
<kalikiana> Chipaca: You got that same error together with the traceback before
<Chipaca> kalikiana: I'm saying: it's not true that it's not allowed
<Chipaca> the yaml parser can't handle it, but it's totally allowed
<Chipaca> tell the user that, not that it's not allowed
<kalikiana> Hmmm
<Chipaca> their ð© apps can be as ð©-y as they want
<kalikiana> Chipaca: They could be, if pyyaml would release a fix...
<Chipaca> all the user needs to do, today, without you doing anything, is use a \u escape
<Chipaca> or a \U escape if it's not BMP
<Chipaca> just saying "not supported (try escaping)" would be more truthful and helpful
<Chipaca> that's my point
<Chipaca> nothing more
<Chipaca> (the 'escape it before loading it' is a lot of work and needs a lot of testing, but you might want to consider it if you have nothing else to do :-D )
 * Chipaca -> school run
<mvo> cachio: thank you!
<mvo> pedronis: no need to cherry pick the vendor.json I think thats only a issue in master
<ogra_> mvo, did you see https://forum.snapcraft.io/t/accessing-ttys0-on-raspberry-pi-3-running-ubuntu-core/4096
<mvo> ogra_: I have not, let me look (but in a meeting)
<pedronis> mvo: IÂ meant the snap-repair fix
<ogra_> mvo, no hurry ... minor addition to the config.txt code (one more option)
<mvo> pedronis: yes, I will cherry-pick that one
<mvo> ogra_: yeah, looks almost trivial
<pedronis> mvo: ah, ok
<pedronis> mvo: not green yet though
<mvo> pedronis: yeah, store was a bit unhappy
<pedronis> Chipaca: could you do a 2nd review of #4705, it's small and should be an area you know
<mup> PR #4705: cmd/snap-repair,httputil: set snap-repair User-Agent on requests <Created by pedronis> <https://github.com/snapcore/snapd/pull/4705>
<zyga> is it an US holiday today?
<mcphail> yes. presidents day
<zyga> ah, thanks
 * zyga refrains from joking about it
<mcphail> indeed. too painful, i suspect
<ogra_> not for non-americans :)
<Chipaca> pedronis: +1
<cwayne> It's ok, were just celebrating 44/45 Presidents today
<mup> PR snapd#4706 closed: vendor: resync formatting of vendor.json <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4706>
<zyga> cwayne my thoughts exactly
<Chipaca> kalikiana: question, trying to understand this a bit more: why am I able to load the yaml from the bug in python without issues?
<kalikiana> Chipaca: I was just asking myself that, but with regard to Travis CI. It seems the Debian package is patched so it behaves different than what's in pip...
<Chipaca> ahh
<kalikiana> Chipaca: I added a work-around now so the result is what you expect with either version. And no more need for second-guessing error messages now I think
<Chipaca> kalikiana: ð
 * cachio lunch
 * Chipaca physio
<kalikiana> Chipaca: Thanks for your review. I definitely don't consider it noise! :-)
<niemeyer> Call is over, and I need to take kid to school.. o/
<mvo> zyga: good news (or bad news) - I can reproduce the failure of autopkgtest on i386 - its systemd-udev invoked oom killer (on a 1.5gb machine)
<zyga> oh
<zyga> could it be caused by our "trigger" usage?
<zyga> or a regression in systemd somewhere
<zyga> in any case that's not a fun thing to learn
<ogra_> trigger shouldnt be able to cause OOM ... after all it just replays uevents in the kernel
<mvo> zyga: http://paste.ubuntu.com/p/zJTYQ4SjqX/
<mvo> zyga: I have no idea should
<zyga> I don't understand those logs out of the blue, not sure what's using memory
<zyga> how did you reproduce it?
<mvo> zyga: http://paste.ubuntu.com/p/9w5YwCJXP9/ is also interessting
<mvo> zyga: yeah, I need to dig into this now and figure out what it means
<mvo> zyga: but it really looks like snapd and snap are the outliners in the second paste
<zyga> mvo so both snapd and snap use about 200MB/s?
<zyga> or is toal_vm just address space and rss is the right thing
<mvo> zyga: aiui rss is the working set so closer to the truth
<mvo> zyga: but still high on both snapd and snap
<mvo> zyga: woah, its really interessting (and hard to debug as it keeps killing the bash I use to ssh into my vm). its related to snap connect, that triggers the oom
<zyga> do you have the state? maybe there are some interesting tasks?
<zyga> pstolowski did you land the connect hooks?
<pstolowski> zyga, no. just autoconnect changes
<pstolowski> zyga, made autoconnect handled by tasks
<mvo> zyga: I looked at the state size, its just 136k
<mvo> zyga: butthe state is now lost, my ssh got killed
<zyga> how are you setting that up for tetsing?
<zyga> (it's certainly annoying to do)
<mvo> zyga: at first I was running autopkgtest, then just pure spread on a ubuntu-18.04-32 image
<pstolowski> zyga, is your question related to the issue you're discussing with mvo?
<zyga> pstolowski yes
<mvo> zyga: and now I try to do it on my regular system (which is -64)
<pstolowski> zyga, my changes landed shortly after the standup
<mvo> zyga: the usage pattern was ~800mb free mem (according to htop), then "snap connect ..." and my task got killed
<mvo> pstolowski: its probably not that (yet)
<mvo> pstolowski: because the adt failure is older and shows the same pattern
<zyga> mvo not sure if you can, try to set oom score for your shell
<mvo> (older as in a couple of days older)
<mvo> zyga: yeah, I'm running the spread again
<mvo> zyga: its a bit of hit and miss if I get a shell at all :)
<mup> PR snapd#4705 closed: cmd/snap-repair,httputil: set snap-repair User-Agent on requests <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4705>
<mvo> thanks pedronis - and its cherry-picked now
<pedronis> thank you
<andyrock> hey all, regarding logging in snapd during in ubiquity (the installer) the chroot solution will not work. I tried to feed the auth data (something like this https://paste.ubuntu.com/p/sSbKstQ2Sy/) and it seems to work fine
<mvo> cachio: where is test-snapd-hello-classic? we will need a build for ppc64el for this one (and probably s390x)
<cachio> mvo, let me check
<andyrock> any thoughts?
<cachio> mvo, I don't have it
<cachio> mvo, I don't see it neither in the store nor launchpad
 * kalikiana wrapping up for today
<cachio> mvo, you don't see it in the store?
<mvo> cachio: slightly mysterious it is only there for i386/amd64 - test-snapd-hello-classic
<mvo> cachio: I need to have dinner now, not sure where it comes from but we need to make it available for all arches
<cachio> mvo, np, could you please share it with me?
<cachio> mvo, I'll do the rest
<cachio> mvo, I'll push it to launchpad
<mvo> mborzecki: do you have a snapcraft.yaml for test-snapd-hello-classic for cachio ?
<mborzecki> it should be in the repo
<mborzecki> mvo: cachio: https://github.com/snapcore/snapd/tree/master/tests/lib/snaps/test-snapd-hello-classic
<cachio> mvo, mborzecki I uploaded the snap to launchpad to generate all the snaps for all the arch https://code.launchpad.net/~snappy-dev/snappy-hub/test-snapd-hello-classic
<cachio> mvo, mborzecki could you please share the snap with me in the snap store?
<cachio> so I can trigger the build for all the archs
<mborzecki> cachio: it was reassigned to the 'canonical' account
<cachio> mborzecki, great tx
<cachio> it was already shared to me
<cachio> mborzecki, mvo builds triggered for arm64 armhf and ppc64el
<cachio> snaps will be available in 1 hour aprox
<cachio> mvo are you going to send 2.31.1 to beta today?
<mvo> cachio: probably not, I need to fix the autopkgtest failures first, without that there is little use in having 2.31.1
<mvo> cachio: I'm kill struggling, with that, looks like we need some extra snaps for s390x and ppc64el (that should be fine) and we might need to figure out the interface-many test. it causes a out-of-memory condition
<mvo> cachio: I'm checking now if increasing the memory helps, its a bit thorny
<mvo> cachio: interfaces-many will fail on bionic on i386 (if you want to reproduce it)
<cachio> mvo, ok, just tell me on what I can help you
<cachio> mvo, sure
<mvo> cachio: you will need https://github.com/snapcore/snapd/pull/4704
<mup> PR #4704: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <https://github.com/snapcore/snapd/pull/4704>
<cachio> mvo, ok
<mvo> cachio: and then just run spread against the one interfaces-many test, this should result in an error and dmesg/journal should show you that it ran out of memory
<cachio> ok
<mvo> cachio: we probably want to improve spread to set /proc/$$/oom_score_adj to -960 or something to ensure the ssh shell is not killed but that is a PR for later :)
<mvo> cachio: if you can find out anything, please do let me know. I'm currently running it with -m 3500 to see if that helps
<cachio> mvo, which image are you using?
<cachio> the last one?
<cachio> 18-Feb?
<mvo> cachio: I created a bionic image via autopkgtest-buildvm -r bionic -a i386 and renamed it to ubuntu-16.04-32
<cachio> mvo, ok, I'll try that
<cachio> }tx
<mvo> cachio: thanks, I tried with -m 3500 - kill OOM :/
<pedronis> mvo: is snapd using so much memory?
<mvo> pedronis: its not quite clear what is triggering this, it might also be something else, kernel or udev, the debug log I have so far is hard to read :/
<mvo> pedronis: but at least it is reproducible
<pedronis> I would hope is not snapd, unless it's a change in go that triggers the issue
<pedronis> IÂ mean no deep reason for memory usage of snapd to change
<pedronis> mvo: as usual is also hard IÂ suppose to correlate to what has changed recently in bionic :/
<mvo> pedronis: yeah, bionic is very much in flux and we did not run an i386 based test there in a while
<mvo> pedronis: maybe cachio can run this test with a 4.13 (artful) kernel to isolate if its that. then the same with systemd (downgrrade that as well). that might give us clues
<mvo> pedronis: its definitely not fun
<mvo> pedronis: the memory pattern I saw does not look terrible (saw in the journal output). snapd uses quite a bit of memory but nothing like the 1.5gb my VM has. not talking about the 4.5gb I gave it for testing and it would still die. also this works on amd64
<mvo> pedronis: and maybe cachio can test using a go1.9 build (and/or all of this I can also try in my morning)
<cachio> mvo, pedronis I can try all this this afternoon
<mvo> cachio: thank you, keep me updated please :)
<cachio> mvo, sure
<mvo> cachio: fwiw, here are the current autopkgtest results http://people.canonical.com/~ubuntu-archive/proposed-migration/update_excuses.html#snapd - the worrying one is i386 with the interfaces-many failure. ppc64el looks like some snaps are missing, I think I uplaoded them all, s390x is new and also misses some snaps but I think they are also available now
<mvo> cachio: the next adt run (in a couple  of hours) hopefully gives us some more hints
<cachio> mvo, thaks!!
<cachio> I'll keep an eye on that run
<cachio> mvo, I am running here on i386 to see the output of interfaces-many
<cachio> mbut preparing yet
<mvo> cachio: thank you. one more possible test is to use gccgo instead of go for the i386 build but that would really be the last possible thing to try
<mvo> cachio: cool, that is interessting
<mvo> cachio: it took a while for me but the oom is triggered every time
<mup> PR snapcraft#1935 closed: elf: contemplate more patching scenarios <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1935>
<hurricanehrndz> Please look over at your pleasure: https://github.com/lupoDharkael/flameshot/pull/120
<mup> PR lupoDharkael/flameshot#120: snapcraft files added <Created by hurricanehrndz> <https://github.com/lupoDharkael/flameshot/pull/120>
<sergiusens> zyga:  when will snaps work in lxd again?
<mvo> sergiusens: what is broken right now?
<sergiusens> mvo: same thing from Kyle's forum post on refreshes
<mvo> sergiusens: hm, iirc things have landed in edge - is it broken with edge still?
<sergiusens> mvo: last time you told me to go to edge I couldn't move back, not going to lightly move as my entire workflow depends on snaps working :-)
<sergiusens> I will check later
<mvo> sergiusens: *cough*
<mvo> sergiusens: are you running stable right now? if so you should have 2.31 since today
<mvo> sergiusens: which might contain the fix already, I can double check if you want
<mup> PR snapd#4678 closed: snap: fix `snap moo` output <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4678>
<sergiusens> no worries, I'll keep an eye open and complain accordingly :-P
<zyga> sergiusens it already should work
<zyga> but you need a new deb
<mvo> aha, new deb - I'm working on that
<Chipaca> why am i getting excited about new terminal escape sequences in bionic
<Chipaca> sergiusens: are you on bionic?
 * Chipaca goes back to reading vte sourcecode
 * zyga gets back to bed 
<zyga> 37.5C again :/
#snappy 2018-02-20
<mup> PR snapcraft#1929 closed: sources: proper errors for invalid handlers <bug> <Created by kalikiana> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1929>
<mup> PR snapcraft#1942 opened: Release changelog for 2.39.2 <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1942>
<elopio> snappy-m-o autopkgtest 1926 xenial:armhf xenial:amd64 xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
<elopio> snappy-m-o autopkgtest 1942 xenial:armhf xenial:amd64 xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
<hego555> yo guys, my snaps seem to not have any internet connection... Spotify says no internet connection and so does Writefull
<hego555> i made sure the network plug was enabled
<sergiusens> snappy-m-o autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
<mup> PR snapcraft#1943 opened: Release/2.39.2+18.04 (DO NOT MERGE) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1943>
<mborzecki> morning
<mborzecki> mvo: morning
<mvo> hey mborzecki ! good morning
<mborzecki> mvo: i noticed this in one of the travis jobs: https://paste.ubuntu.com/p/qYKjfqYdxF/ is this the restart on refresh mode thing?
<mvo> mborzecki: yes - looks like a race, do you have the full log? there should be logging to syslog around this to help tracking this down
<mborzecki> mvo: https://api.travis-ci.org/v3/job/343470218/log.txt
<mvo> mborzecki: hm, hm, the log looks ok, the right restart reason and all that. puzzling
<mborzecki> mvo: maybe the log comes from before the actual test action happened?
<mvo> mborzecki: yeah, I wonder why
<mborzecki> mvo: backend calls systemd.Restart(), that's implemented as stop & start
<mvo> mborzecki: oh, thats an interessting clue, a restart with no restart reason. when is backend calling this?
<mborzecki> mvo: i believe the path is ifacestate.setupSnapSecurity() -> backend.Setup() -> systemd.Restart()
<mvo> ta
<mborzecki> mvo: do you need any help with that issue?
<mvo> mborzecki: help would be great, I'm still fighting with the 2.31.1 stable release and the oom error and the autopkgtests
<mborzecki> mvo: oom error? you got me interested now
<mvo> mborzecki: on bionic/i386 the interfaces-many tests triggers an oom error
<mvo> mborzecki: its not a new bug, I can reproduce it with 2.29.x too
<mvo> mborzecki: but its very unclear right now what is causing it
<mvo> mborzecki: its reliable to reproduce on i386
<mborzecki> mvo: is snapd getting killed?
<mvo> mborzecki: everything is getting killed :) its also strange as htop does not show any user space grwoing like mad. also the swtich from ok(ish) to oom comes very fast
<mvo> mborzecki: http://paste.ubuntu.com/p/gVgDtTqPBg/ this is the script
<mvo> mborzecki: I can prepare a tar that includes the two snaps to run this
<mborzecki> mvo: no need, if they are in tests/lib/snaps i can build them myself
<mvo> mborzecki: I will do it anyway I think because I want to run it on an amd64 and compare the logs. it seems like th eoom condition is not triggered there
<mvo> mborzecki: might be kernel, might be udev
<mvo> mborzecki: each connect seems to take in the range of 12mb
<mvo> mborzecki: it could be apparmor too, we load profiles on each connect
<mborzecki> mvo: wow, that's a lot
<mvo> mborzecki: well, thats what "free" tells me, its not clear (to me yet) where this memory actually goes
<mborzecki> mvo: i'll try to play with pprof, see if anything comes up
<mborzecki> mvo: there's a bunch of maps flying around in the code, also we may be collecing some output from processses that we run
<mvo> mborzecki: my gut feeling is that its external to snapd, we need more data, but afaict this is fine on xenial/i386
<mborzecki> mvo: interesting, is ti possible to say, disable apparmor and not call apparmor_parser?
<mvo> mborzecki: yeah, that might be worth a shot
<mvo> mborzecki: its puzzling, free telle me I have "479404" used and "784648" free - thats confusing (but memory reporting apparently is)
<mvo> mborzecki: I also see a lot of kmalloc-8192 in slab-info
<mvo> mborzecki: the objects there grow from 500 to 5000
<mvo> (which is still not that much in total memory size about 40mb)
<pstolowski> mornings
<mvo> mborzecki: my current theory is that for some reason "normal" memory runs out on i386. there is plenty of "highmem" free but the normal memory falls below the threshold of 20mb
<mborzecki> pstolowski: morning
<mvo> hey pstolowski ! good morning
<pstolowski> mvo, heya, is this re to the 'killed...' issue on connect from yesterday?
<mvo> pstolowski: yes
<pstolowski> interesting
<mup> PR snapd#4676 closed: timeutil: introduce helpers for checking it time falls inside the schedule <Created by bboozzoo> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/4676>
<mborzecki> mvo: hm the test only connects the interfaces, so maybe temporarily linking apparmor_parser to /bin/true would allow to skip this path if that's what you suspect
<mborzecki> pstolowski: if you're up for reviews https://github.com/snapcore/snapd/pull/4695 needs looking at :)
<mup> PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
<mborzecki> mvo: xenial i386 vm is updating, meanwhile i'll look at refresh mode thing
<pstolowski> mborzecki, sure!
<mborzecki> pstolowski: great, thanks :)
<mvo> mborzecki: I will write a forum post in a wee bit that summarizes my current findinds
<sergiusens> snappy-m-o autopkgtest 1942 xenial:armhf xenial:amd64 xenial:arm64
<snappy-m-o> sergiusens: I've just triggered your test.
<Chipaca> sergiusens: morning! (?)
<sergiusens> Chipaca: intermittent, just woke up to trigger these darn tests :-)
<sergiusens> snappy-m-o autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
<mup> PR snapd#4708 opened: overlord/snapstate: use spread in the default refresh schedule <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4708>
<mborzecki> mvo: so no apparmor no leak?
<mvo> mborzecki: thats what it looks like to me at least
<mborzecki> that's interesting observation
<mborzecki> , udev/seccomp/cgroups is all there right?
<mvo> mborzecki: yes, I just disabled this one
<mup> PR snapd#4709 opened: tests: fixes for autopkgtest in bionic <Created by mvo5> <https://github.com/snapcore/snapd/pull/4709>
<mborzecki> mvo: can you try with something more recent, like 4.15.4?
<mborzecki> mvo: i mean the kernel ofc
<mvo> mborzecki: yeah, I am preparing a more automatic thing now
<mvo> mborzecki: I mean a tarfile so that one can just run ./test.sh
<mvo> mborzecki: and then I can test on more systems (artful etc) to see when it started
<mborzecki> mvo: i did not observe any issues on xenial, but that's a really old kernel
<mvo> mborzecki: interessting
<mborzecki> mvo: https://paste.ubuntu.com/p/bWVBw4Yp6v/
<mborzecki> LowTotal:         858144 kB
<mborzecki> LowFree:          723696 kB
<mvo> mborzecki: this is xenial?
<mborzecki> mvo: yes
<mvo> mborzecki: it seems to have a different lowmem split
<mvo> mborzecki: i.e. more available (my system only had ~400mb)
<mvo> mborzecki: is it also shrinking fast?
<mvo> mborzecki: same here, no craziness on 16.04-32
<seb128> mvo, hey
<seb128> mvo, can you help us? andyrock needs some input on changes he would like to suggest for snapd that he needs for his livepatch work
<mborzecki> mvo: https://imgur.com/a/xDeVR
<mvo> seb128: sure, what kind of changes does he have in mind?
<mborzecki> mvo: the test script stars around 20s mark
<andyrock> mvo: so we need to login  in snapd from the installer. The problem is that we can't talk with the to-be-installed snapd in ubiquity
<andyrock> mvo: the chroot hack does not work (in a nutshell the chroot is not ready when we need it)
<mvo> mborzecki: what is the y axis?
<mborzecki> mvo: kB, LowFree
<mvo> mborzecki: ta
<andyrock> mvo: would be possible to have a way to seed the auth state? something like this: https://paste.ubuntu.com/p/sSbKstQ2Sy/
<mvo> andyrock: interesting! pedronis, what do you think about the ability to put auth.json into the seed directory and import it on firstboot? this is for the desktop installer use-case
<pedronis> mvo: I'm a bit missign the context
<andyrock> pedronis: I've been asked to add snapd login in the installer
<mvo> pedronis: they allow people to login into the store/snapd in the livecd session. but the snapd that is running in there is not the snapd that is copied to the hardisk. the harddisk snapd will have an empty state.json
<mvo> pedronis: so the user would have to login again after the system was installed
<pedronis> what is that auth.json?  the  one from the homedir?
<pedronis> or something else
<andyrock> something else
<pedronis> the one in the homedir doesn't have all the data
<andyrock> something we need to take from the livecd state.json
<andyrock> we can take all under auth: {...}
<pedronis> no you don't want everything
<pedronis> because there's device info there
<andyrock> kk
<pedronis> and IÂ think we are trying not to make livece session count the same wa
<pedronis> as full installs
<andyrock> pedronis: so last-id, users, and macaroon-key?
<andyrock> or last-id and users are enough?
<pedronis> andyrock: you need the macaroon-key as well, if you plan to port ~/.snap/auth.json over or the gnome-software equivalent
<andyrock> kk
<andyrock> pedronis: so are you willing to accept something like that?
<pedronis> maybe, is not just my decision
<pedronis> it needs also to be a bit more paranoid about checking the perms of that file
<andyrock> kk who else should we ask?
<pedronis> you need niemeyer +1 as well
<pedronis> I'm mildly worried that it allows to clone the same creds on a lot of images, it's not your use case but it can be used that way
<andyrock> pedronis: should we move the discussion the forum?
<andyrock> *in the
<pedronis> yes
<pedronis> you should make a proposal there IÂ suppose
<mvo> pedronis, andyrock another option might be to join the standup as a guest
<zyga_> o/
<zyga_> I'm sick and I won't be around today
<zyga_> I just got off the bed to let you guys know
<zyga_> sorry about that :/
<mvo> zyga_: get well
 * mvo hugs zyga_ 
<zyga_> thank you, I be back as soon as I can
<mup> PR snapd#4704 closed: tests: store journal in autopkgtest artiffacts and add 18.04-32 to qemu <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/4704>
<mvo> mborzecki: fwiw, artful seems to show the same behavior
<magicaltrout> random question, is there a pattern for dealing with migrating configs and stuff on a snap package upgrade?
<magicaltrout> or do you just bake something into the start script?
<popey> mvo: I'm told there's a PR in flight somewhere which will enable a snap (like gnome-calculator) to auto-download & install a platform snap (like the gnome one). Do you know what stage that's at?
<mvo> popey: that is #4103
<mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<mvo> popey: we want to get it in for 2.32, its a bit hard because there is some work to do still but its super important to us
<popey> mvo: excellent, thanks.
<popey> Yes, that would be awesome.
 * pstolowski lunch
<mborzecki> mvo: that problem with test-snapd-service endure, the only idea i have atm is that we do journalctl --rotate, but no journalctl --sync, if a test using test-snapd-service was run before that one, we could end up with a log from the previous run
<mvo> mborzecki: interessting, that sounds like a good theory
<mborzecki> funnily enough, looking at the source code of journalctl, you cannot use `journalctl --sync --rotate` in a single command, both flags are set to the same variable
<mup> PR snapd#4710 opened: tests/lib/prepare-restore: sync journal before rotating and vacuuming <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4710>
<mborzecki> mvo: ^^ a simple fix for now, let's see if this is enough
<mup> PR snapd#4709 closed: tests: fixes for autopkgtest in bionic <Created by mvo5> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4709>
<mvo> mborzecki: \o/
<Chipaca> mborzecki: mvo: #4708 gtg
<mup> PR #4708: overlord/snapstate: use spread in the default refresh schedule <Critical> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4708>
<mup> PR snapd#4708 closed: overlord/snapstate: use spread in the default refresh schedule <Critical> <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4708>
<mvo> Chipaca, mborzecki thanks, cherry-picked into 2.31.1
<cachio> mvo, hey
<mvo> hey cachio
<cachio> test-snapd-hello-classic in the store for s390x, stil waiting a review
<cachio> mvo, updating the kernel in the qemu machine
<mvo> cachio: aha, cool, I can do that after lunch
<cachio> mvo, same issue with an old kernel
<mborzecki> cachio: oom?
<cachio> mborzecki, yes
<mborzecki> cachio: how much ram are those vms getting?
<cachio> mborzecki, well, I could not connect anymore
<cachio> mborzecki, 3500 MB
<mborzecki> cachio: tried this today on 16.04 32bit, with -mem 4096 and haven't observed any issues, lowmem did drop a bit though, see ~20s mark https://imgur.com/a/xDeVR
<cachio> mborzecki, I ran some scripts yesterday and it is like in 18.04 i386 the garbage collections is not done
<cachio> so you connect disconnect and do stuff and the memory is not release
<cachio> d
<mborzecki> cachio: can you try to collect this `while true; do echo "$(date +%s) $(awk '/LowFree/ {print $2}' < /proc/meminfo)"; sleep 1; done` while the test is run and paste is somewhere?
<cachio> mborzecki, sure
<cachio> mborzecki, https://paste.ubuntu.com/p/JTBkvh5PqN/
<mborzecki> hmm it's really low to begin with
<Chipaca> jdstrand: ping
<jdstrand> hey Chipaca
<Chipaca> jdstrand: pm
<mvo> jdstrand: hey, https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101 might be interessting for you guys, I suspect it is apparmor related (but maybe not)
<sergiusens> stgraber: hi there, was wondering if there is a probe command in lxd to figure out that we have been `init'ed`
<mborzecki> i'm experimenting with `snap set core refrsh.timer=<...>` and it's a bit weird, you see the current setting appear right away in `snap refresh --time` but it becomes effective only after restart or when the current next expires
<pedronis> mborzecki: shouldn't be like that looking at the code, but it might take 5 minutes to take effect if we are not careful
<mborzecki> pedronis: how often is autorefresh.Ensure() called?
<cachio> mvo, mborzecki I ran with this kernel and I for the oom issue too https://paste.ubuntu.com/p/4X9s7jtybd/
<pedronis> mborzecki: if nothing is going on, each 5 minutes
<pedronis> that's where my 5 minutes comes from
<mup> PR snapd#4710 closed: tests/lib/prepare-restore: sync journal before rotating and vacuuming <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4710>
<mvo> cachio: oh, interessting.
<pedronis> mborzecki: it's   ensureInterval  in overlord/overlord.go, probably worth getting familiar with that bit
<mborzecki> pedronis: yup, looking at it now
<pedronis> mborzecki: we have state.EnsureBefore  to trigger it earlier, various places use it
<pedronis> some in taskrunner.go
<mborzecki> right, i've seen this one before :)
<cachio> mvo, is it any way to disable apparmor and make the tests work?
<cachio> mvo, to discard that?
<cachio> mvo, I'll try just removing it
<mvo> cachio: I did: "mv /sbin/apparmor_parser /sbin/apparmor_parser.saved"
<mborzecki> pedronis: there's a funny effect, that once a refresh runs as is successful, next becomes time.Time{}, so when you do `snap refresh --time`, next will be 'n/a'
<mvo> cachio: cp /bin/true /sbin/apparmor_parser
<jdstrand> mvo: interesting. As you said, this sounds like a kernel issue since you couldn't reproduce on 4.10 or lower
<cachio> mvo, you already tried that and it didn't work?
<jdstrand> mvo: you said 4.10 was not affected. 4.13 (artful) is? why are we only seeing this now? is it just now is when you decided to get to the bottom of artful and bionic issues?
<mvo> jdstrand: take it with a grain of salt, cachio said he sees it with 4.10 too, I will double check
<mvo> cachio: that worked for me
<mvo> cachio: when I moved the apparmor_parser away I did not see the mem leak anymore
<jdstrand> mvo: how much memory is in the vm?
<mvo> jdstrand: I think its some factors: the interfaces-many test got added relatively recently, we don't run much on i386 and autopkgtest for 2.30 did not run because we had problems getting this snap accepted into the archive at all
<mvo> jdstrand: the vm has 1500mb
<mvo> jdstrand: but it seems like the LowMem is what triggers the oom on i386 which is just 400mb
<jdstrand> mvo: this is i386 only/
<jdstrand> ?
<mvo> jdstrand: I suspect its amd64 too, it just takes a lot longer as it has the full 1500mb of memory
<mvo> jdstrand: for some reason its the lowmem on i386 that runs out
<mvo> jdstrand: the oom-test.tar.gz should have all that is needed to reproduce
<mvo> jdstrand: let me run it (in a loop) on amd64 to see if it eventually also dies
<jdstrand> mvo: yes. I'd like to remove snapd from the equation though so I commented in the topic
<mvo> jdstrand: I see ~15mb per "snap connect" decrease in free memory with 4.13. maybe with 4.10 (and below) the leak is just smaller that is why cachio sees it (because he was looking harder) and I don't (because I was just looking for the oom to trigger)
<Chipaca> mvo: the interfaces-many test is a bit of a hog, it has so many changes that towards the end it takes seconds to do each one
<mvo> Chipaca: indeed
<mvo> jdstrand: I run it now on amd64 in a loop just to see what will happen (bionic with 4.13)
<mborzecki> mvo: what if you try to reload apparmor profiles in a loop?
<jdstrand> mvo: note that an apparmor profile does take kernel memory. it should not take that much and it shouldn't lose 15mb with a replace operation
<mvo> jdstrand: *nod*
<mborzecki> off to pick up the kids
<mvo> jdstrand: fwiw, it looks like amd64 is also affect, just takes longer because of the different memory available (1480 vs 390)
<cachio> mvo, https://paste.ubuntu.com/p/YsCpXvfgNg/
<cachio> 56MB free
<cachio> preparing the suite
<kalikiana> re
<sergiusens> snappy-m-o autopkgtest 1942 xenial:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
<mvo> cachio: yeah, same here, eventually amd64 also runs out of memory
<cachio> mvo, I am gonna try with an older bionic image
<mvo> cachio: thank you
<jdstrand> mvo: https://forum.snapcraft.io/t/oom-for-interfaces-many-on-bionic-i386/4101/5
<jdstrand> oh heh, you already liked it
<mvo> jdstrand: very much indeed! thanks for the reproducer
<mvo> cachio: -^
<mvo> cachio: looks like jdstrand has an even better reproducer that does not involve snapd, probably easy(ish) to bisect using this
<brunosfer> Hi guys! I installed bluez in Ubuntu Core Snappy and I'm having this problem:
<brunosfer> bluez.sdptool browse local
<brunosfer> Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory
<jdstrand> mvo: I think for now the test should be disabled on i386
<brunosfer> Does anyone knows how can I solve this issue?
<jdstrand> mvo: the test really only needs to be run on one arch imho
<mvo> yes+
<jdstrand> well
<jdstrand> the snapd part of the test is only useful on one arch
 * mvo nods
<jdstrand> the fact that it showed an issue on i386 is certainly helpful :)
<marcoceppi> o/ can anyone help me with this: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/11
<brunosfer> Hi guys! I installed bluez in Ubuntu Core Snappy and I'm having this problem: $bluez.sdptool browse local Failed to connect to SDP server on FF:FF:FF:00:00:00: No such file or directory
<brunosfer> Does anyone knows how can I solve this issue?
<ogra_> brunosfer, it is probably best to ask this on the forum ... koza can probably help but i think he is not around currently (so he can more easily pick up the question on the forum later)
<ogra_> also make sure to describe what HW you run and if all your interfaces are connected properly etc
<brunosfer> how much later? because I posted that issue since December 17th and so far I'm stuck and nobody replied...
<ogra_> brunosfer, where did you post it ?
<marcoceppi> Chipaca: o/
<brunosfer> Everytime I make this question here people redirect me to the forum and it's a dead end...
<ogra_> (got a link to the forum post ?)
<brunosfer> https://forum.snapcraft.io/t/failed-to-connect-to-sdp-server-permission-problem/3085
<mvo> hm, hm, today https://forum.snapcraft.io/t/all-revisions-of-snaps-are-mounted-when-they-dont-need-to-be/2294 came up, I wonder if anyone ever looked what is taking >500ms
<jdstrand> mvo: fyi, jjohansen is aware of a profile replace memory leak and will continue to look into it
<Chipaca> marcoceppi: o/!
<Chipaca> marcoceppi: how's things?
<Chipaca> marcoceppi: so, tell me more about this messed-up snapd you have
<marcoceppi> great except for my broken snaps :(
<marcoceppi> I mean, it's my laptop
<Chipaca> marcoceppi: ok. Can you enabled debug, if you haven't already?
<Chipaca> enable*
<marcoceppi> 16.04 full patched, few days ago a new kubectl snap was published and since then it's not been well
<Chipaca> marcoceppi: that's add SNAPD_DEBUG=1 to /etc/environment and 'systemctl restart snapd'
<marcoceppi> yeah, restarting snapd hangs
<Chipaca> niiice
<Chipaca> marcoceppi: hangs how?
<mvo> marcoceppi: what exactly is broken? does snapd itself misbehave? or one (or muliple) snaps?
<marcoceppi> mvo: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/11
<Chipaca> mvo: https://forum.snapcraft.io/t/refreshing-disabled-snap-kubectl-not-supported/4060/7
<marcoceppi> Chipaca: restart command blocks indefinitely
<Chipaca> haha
<Chipaca> youch
<Chipaca> marcoceppi: what does 'journalctl -u snapd' show?
<marcoceppi> I can straight up kill it
<marcoceppi> Chipaca: https://paste.ubuntu.com/p/fDhqFCPGkC/
<Chipaca> marcoceppi: is that the _end_ of the journal?
<marcoceppi> yeah, I mean, I just did an -f and it's printing a few more things
<marcoceppi> like sysctl just SIGKILL'd the proc
<Chipaca> with the SNAPD_DEBUG, and it hanging, i'd expect lots of stuff
<Chipaca> nnngh
<marcoceppi> oh, no, still waiting for it to restart
<marcoceppi> so it can get SNAPD_DEBUG
<Chipaca> ok, so just kill it
<Chipaca> something is bad
 * marcoceppi nods
<Chipaca> and the oom will kill one thread and leave go wondering
<Chipaca> so when that happens you need to manually kill the whole thing
<pedronis> kubectl is classic fwiw
<Chipaca> ack
<marcoceppi> yes, but lxd isnt pedronis and it has the same problem
<Chipaca> pedronis: i mean, if it were just the snap misbehaving i'd kick it over to sergio :-)
<Chipaca> pedronis: but this is snapd doing something weeeird
<pedronis> but you said it started when you got the new kubectl
<marcoceppi> that's when I noticed it exhibiting issues, yes
<Chipaca> marcoceppi: how's the kill-everything-and-start-over going?
<marcoceppi> it's started
<marcoceppi> Chipaca: https://paste.ubuntu.com/p/vR9Nky4bhx/
<Chipaca> marcoceppi: can you 'curl -s -N -0 --unix-socket /run/snapd.socket http://localhost/v2/changes?select=all | python -m json.tool | pastebinit'?
<Chipaca> marcoceppi: assuming you have pastebinit, otherwise you know what i mean
<marcoceppi> that's a mouthful
<marcoceppi> http://paste.ubuntu.com/p/nRTM6jyyvT/
<Chipaca> marcoceppi: can you do a 'sudo du -sh /root/snap/* /home/user/snap/* /var/snap/*' ?
<Chipaca> (depending on your permissions you might need to tweak that for the glob to expand everywhere)
<marcoceppi> Chipaca: https://paste.ubuntu.com/p/HNq9hGGm66/
<Chipaca> marcoceppi: if you say 'snap watch 481' does it still say it's copying stuff?
<marcoceppi> yes
<Chipaca> marcoceppi: that's kubefed, yes?
<marcoceppi> correct
<Chipaca> marcoceppi: so my question for you is, how does it take this long to copy 28k of data
<marcoceppi> well, that's my question for you - isn't it :D
<marcoceppi> SSD with over 60GB of free space on EXT4
<Chipaca> marcoceppi: can you try copying that directory somewhere, by hand? ie 'cp -a /var/snap/kubefed /var/tmp' ?
<marcoceppi> Chipaca:
<marcoceppi> time cp -a /var/snap/kubefed /var/tmp/
<marcoceppi> real	0m0.003s
<marcoceppi> user	0m0.000s
<marcoceppi> sys	0m0.000s
<marcoceppi> worked without issue
<cachio> mvo, using an 2 months old bionic image I see the same oom error
<mvo> cachio: ta
<Chipaca> marcoceppi: the other one you had in doing was copying the lxd data
<Chipaca> marcoceppi: that one could take a bit longer, it being 5 gigs
<mvo> cachio: jdstrand told me the memory leak is something that jjohansen is investigating. maybe he knows (roughly) when this started ? if not we might be able to help bisecting
<marcoceppi> yeah, but it's been over 24 hours
<marcoceppi> and LXD was a problem after 24 hours of the kubectl issue
<marcoceppi> I feel like snapd is unable to perform this action
<Chipaca> marcoceppi: is there anything new in the logs?
<marcoceppi> Feb 20 11:03:59 T430 snapd[28114]: 2018/02/20 11:03:59.146915 daemon.go:233: DEBUG: pid=28499;uid=1000;@ GET /v2/changes?select=all 1.369681ms 200
<marcoceppi> that is the only new line
<Chipaca> that's you
<marcoceppi> yes, I realize that, but wanted to be complete in my reporting
<Chipaca> yes yes, i was just confirming
<Chipaca> I don't understand what it thinks it's doing
<marcoceppi> can I - like delete this change attempt and just start over?
<marcoceppi> I really /really/ DO not want to lose my lxd containers
<marcoceppi> but kubectl has no userdata
<Chipaca> marcoceppi: i mean, you could, but it'd be hairy
<Chipaca> marcoceppi: can you stop snapd, and start it straced?
<marcoceppi> you got what I should invoke for snapd to be strace'd?
<Chipaca> marcoceppi: so, first, systemctl stop snapd.\*
<cachio> mvo, so, are you preparing 2.31.1 today, or we need to wait until this is fixed?
<Chipaca> marcoceppi: and then: sudo strace -E SNAPD_DEBUG=1 -f -s 9999 -o /tmp/snapd.trace /usr/lib/snapd/snapd
<cachio> mvo, or any other fix?
<pedronis> Chipaca: 5G in versioned data, that's a problem in itself, we though common is for that
<Chipaca> pedronis: is it versioned?
<pedronis> well if it's being copied
<pedronis> we don't copy common data, no?
<Chipaca> we don't
<Chipaca> but I don't know if that's what it's doing
<Chipaca> it says it's copying a 28k directory, also
<pedronis> ok, ignore me
<Chipaca> for hours
<Chipaca> pedronis: no, no, i need ideas :-)
<Chipaca> pedronis: especially if nothing turns up in the trace
<pedronis> anyway both these snaps are classic IÂ suppose
<marcoceppi> Chipaca: so, I can't start snapd manually , says socket is in use but no other proc is really running
<pedronis> so they could do strange stuff on their own
<pedronis> fwiw
<pedronis> though hooks have timeouts
<pedronis> in theory
<marcoceppi> Chipaca: nvm, fixed it
<Chipaca> marcoceppi: what was it?
<marcoceppi> I have like 100% lack of chill right now, heh
<marcoceppi> how long do you want me to collect strace data?
<mvo> cachio: today
<mvo> cachio: it looks like we need test-snapd-password-manager-consumer for s390x
<mvo> cachio: I'm just inspecting the s390x autopkgtest failure
<Chipaca> marcoceppi: a couple of minutes after it says 'Running task 5559 on Doing: Copy snap "kubefed" data'
<mvo> cachio: but no blocker, I will go ahead with 2.31.1 onw
<marcoceppi> Chipaca: cool, it's been doing that, I'll let it run a wee bit
<Chipaca> marcoceppi: you can tail /tmp/snapd.trace if you're anxious (i know i'd be)
<cachio> mvo, ok, I can't update the snap recipe
<mvo> cachio: oh, ok. let me check
<cachio> to generate the snap fo s390x
<mup> PR snapd#4711 opened: tests: make restore of interfaces-password-manager-service more robust <Created by mvo5> <https://github.com/snapcore/snapd/pull/4711>
<cachio> mvo, it is yours
<marcoceppi> Chipaca: Okay 5 mins of strace data since copy message
<mvo> cachio: *cough* indeed - fixed
<marcoceppi> Chipaca: https://paste.ubuntu.com/p/4CphPf7stb/
<Chipaca> marcoceppi: and /tmp/snapd.trace ?
<marcoceppi> Chipaca: yeah, let me paste it
<Chipaca> ah :-)
<Chipaca> i was worried and perplexed, there
<marcoceppi> although - heh - I can't get the proc to interrupt
<marcoceppi> Chipaca: http://paste.ubuntu.com/p/7bCBVTMMTV/
<marcoceppi> I hope I didn't crash pastebin
<Chipaca> marcoceppi: you're probably going to have to sudo killall strace
<marcoceppi> sure, I'll also gz upload that file
<Chipaca> can confirm that pastebin is not a happy bunny
<marcoceppi> Chipaca: http://marcoceppi.com/snapd.trace.gz
<mup> PR snapcraft#1944 opened: tests: split the plugins tests in the same directory <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1944>
<cachio> mvo, I see several errors on the arm64 execution for autopkgtest
<cachio> mvo, should I fix them?
<marcoceppi> Chipaca: interestingly, I have a bunch of orphaned sync commands like in the paste above
<mvo> cachio: yeah, but not high priority, it was not green before so it will not be a blocker
<cachio> mvo, yes, smae for ppc64el and s390x
<mvo> cachio: the issues on ppc64el and s390x are considered regressions by adt so that is higher priority
<mvo> cachio: afaict ppc64el is mostly good
<mvo> cachio: and s390x has some snaps missing, then we need to retrigger and see
<cachio> ppc64el just 4 errors
<mvo> cachio: its "funny", s390x was considered working before because we skipped it because it was only a lxd container
<mvo> cachio: the timezone ones, right?
<marcoceppi> brb, going to restart
<mvo> cachio: those are fixed with the systemd in -propsoed
<cachio> mvo, yes and confinement-classic because the snap was not relased
<cachio> released
<mvo> cachio: indeed
<mvo> cachio: apparently it is possible to retrigger the adt with &trigger=systemd/proposed&trigger=snapd/proposed at the end of the retrigger url - this will cause snapd to be tested with the right systemd version
<cachio> mvo, perfect
<pedronis> Chipaca: the copies are cp -av afaict
<Chipaca> yep, "cp", "-av", "/home/marco/snap/kubectl/303", "/home/marco/snap/kubectl/328"
<pedronis> so ps should tell use which one is taking forever?
<mvo> cachio: I uploaded snapd 2.31.1 to the ppa, if all goes well you should have a beta core in ~45min or so
<cachio> mvo, great, thanks
<pedronis> mvo: I just noticed that this bit of test  mock := testutil.MockCommand(c, "kdialog", "sleep 9999999") seems to leave around the sleep
<Chipaca> pedronis: it looks like the cp's finished
<cachio> mvo, we need test-snapd-wayland for arm64 in edge
<cachio> mvo, could you please share it to me?
<cachio> tx
<Chipaca> pedronis: lxd and kubectl at least, looking at the other two
<marcoceppi> Chipaca: I restarted my machine and everything's fixed
<Chipaca> marcoceppi: oh no
<pedronis> for a bit, usually snapd will restart doing what it was doing before
<marcoceppi> I mean, the changes are all flushed, and the snaps are enabled and the currect current versions
<marcoceppi> ID   Status  Spawn                 Ready                 Summary
<marcoceppi> 481  Done    2018-02-17T01:48:48Z  2018-02-20T16:39:28Z
<marcoceppi> 482  Done    2018-02-19T05:32:01Z  2018-02-20T16:39:45Z  Refresh snaps "lxd", "go"
<marcoceppi> 483  Done    2018-02-20T16:39:41Z  2018-02-20T16:40:23Z  Auto-refresh snap "core"
<marcoceppi> Only problem is debug is stillenabled despite removing the environment line and restart snapd
<Chipaca> marcoceppi: what's "snap tasks 481"?
<marcoceppi> that was the first one that got stuck, the kubectl and kubefed one
<pedronis> Chipaca: we had a bug when you refreshed some exact number of snaps the summary would come out empty
<Chipaca> ah ok
<Chipaca> marcoceppi: this wasn't the first time you restarted since this started, right?
<pedronis> it's fixed, IÂ don't remember what the magic number was
<marcoceppi> no, this was the first time
<pedronis> it was a confusion bug around go switch stmt != C switch stmt
<marcoceppi> I don't like restarting, messes up my state
<Chipaca> pedronis: heh
<Chipaca> marcoceppi: fair enough
<pedronis> Chipaca: a missing fallthough
<pedronis> or something like that
<Chipaca> marcoceppi: I hate losing state, and i hate problems that disappear without me learning from them
<marcoceppi> I suppose I should have done so earlier; either way it seems something about sync getting stuck causing a backup
<Chipaca> marcoceppi: but, you're fixed, so yay :-)
<marcoceppi> hah, yes, back to work now
<Chipaca> marcoceppi: does running 'sync' hang, for you?
<marcoceppi> not anymore
<marcoceppi> but I should have tested earlier
<Chipaca> marcoceppi: was it doing so before the reboot/
<Chipaca> ?
<marcoceppi> did not test that
<Chipaca> ah
<Chipaca> if it was, I'd start shopping for SSDs
<marcoceppi> considering there were sync processes from days ago, I'm inclined to believe that may be the problem
<Chipaca> but Â¯\_(ã)_/Â¯
<marcoceppi> hum, I don't have any smart errors
<marcoceppi> but I'll start a disk copy anyways
<Chipaca> marcoceppi: it might be something weirder, some corner case in the mount handling code that we're tripping up
<Chipaca> marcoceppi: (we've fixed so many of those already...)
<Chipaca> marcoceppi: if it ever happens again, jump on here
<Chipaca> marcoceppi: glad you're unstuck, and good luck
<marcoceppi> Chipaca: I'll keep an eye out - thanks!
<marcoceppi> Chipaca: any way to get rid of the debug output?
<Chipaca> marcoceppi: if should be enough to remove it from /etc/environment and restart
<marcoceppi> yeah, did that :|
<Chipaca> marcoceppi: but, note you'll still have it in your shell and stuff
<marcoceppi> oh, yeah, it's in my shell
<marcoceppi> DUH
<Chipaca> marcoceppi: but systemctl shouldn't pass them to the units
<Chipaca> marcoceppi: but if you're running it by hand because that's cool, then there's why
<marcoceppi> I mean, it's showing in all my snap commands
<marcoceppi> but because snap_debug was in my shell
<marcoceppi> so unset and ready to go!
<Chipaca> ah, i thought you were seeing it in the journal
<Chipaca> :-) ok
<mvo> jdstrand: I noticed something curious - it looks like c1093d46437a33d60d7378b1c6676818655bc359 is not in master currently, I noticed when merging back the changes from 2.31.1
<mup> PR snapd#4712 opened: release: version 2.31.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4712>
<cachio> mvo, in fact I can't see where the test-snapd-wayland code is? do you know?
<cachio> mvo, I found it
<cachio> jdstrand, hey, we need the test-snapd-wayland for arm64
<cachio> to make autopkgtests pass
<cachio> jdstrand, could you please create the snap?
 * kalikiana wrapping up for the day
<mvo> cachio: i386/amd64 core 2.31.1 ready in beta
<mvo> cachio: arm* should be ready in ~1h or so
<mup> PR snapd#4711 closed: tests: make restore of interfaces-password-manager-service more robust <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4711>
<mvo> cachio: hrm, hrm, armhf/arm64 does not give me a built slot, maybe the 1h was too optimistic - I keep an eye on things
<phoenix_firebrd> what version of intel vaapi driver is present in snappy core package in stable channel
<niemeyer> jdstrand: Looks like the review tools need to learn about the "adapter" field:
<niemeyer>   - unknown fields for app 'jmes': 'adapter'
<jdstrand> niemeyer: ack, noted. I'll get that fixed
<niemeyer> jdstrand: Thanks!
<niemeyer> jdstrand: I just added a note to the original topic, btw: https://forum.snapcraft.io/t/telling-snapcraft-to-skip-generating-wrapper-scripts/1635
<jdstrand> thanks
<niemeyer> jdstrand: Meanwhile, would you mind to unblock the review and let it through.. it's a pretty boring snap otherwise
<niemeyer> strict, no interfaces, etc
<jdstrand> yes, I was heading over there
<niemeyer> Thanks!
<jdstrand> niemeyer: done. you'll need to release it to a channel
<niemeyer> jdstrand: Thanks again!
<jdstrand> np :)
<mvo> cachio: all arches for 2.31.1 in beta now
<cachio> great, 32 and 64 bits already running
<cachio> mvo, no errors so far
<mvo> cachio: \o/
<mvo> cachio: 32bit is 2.31.1? I think I did something wrong with the promotion before but its correct now (sorry for that)
<cachio> yes, 2.31.1
<cmars> I'm trying to use this sockets feature in a snap, doesn't seem to be supported by snapcraft. it is supported yet? https://docs.snapcraft.io/build-snaps/syntax#sockets
<niemeyer> cmars: It is supported, but not with that syntax.. this documentation is out of date as of a couple of years ago :)
<cmars> niemeyer: gotcha.. do you have an example of how it's supposed to look?
<niemeyer> cmars: It took us a while to reimplement support for it, but it's now in.. let me provide you with something you can go forward with.. just a sec
<cmars> niemeyer: awesome to hear, thanks!
<niemeyer> cmars: https://github.com/snapcore/snapd/blob/master/tests/lib/snaps/socket-activation/meta/snap.yaml
<cmars> trying..
<cmars> hmm
<jdstrand> niemeyer: hey, so looking at adapter. this seems to be a snapcraft.yaml thing and not a snap.yaml thing. I don't see anything for processing adapter in snapd. shouldn't snapcraft remove adpater when generating snap.yaml?
<cmars> snapcraft still doesn't accept it, https://paste.ubuntu.com/p/8FKdbnHmTt/
<cmars> i guess i'll open a bug?
<niemeyer> jdstrand: Waaait
<niemeyer> jdstrand: Yes!
<niemeyer> jdstrand: Good catch.. it makes no sense to have this in snap.yaml
<jdstrand> niemeyer: ok, I'll file a snapcraft bug then and follow up in the forum
<niemeyer> jdstrand: Thanks!
<niemeyer> cmars: :/
<niemeyer> cmars: It's been there for a few months.. let me find the topic..
<niemeyer> cmars: https://forum.snapcraft.io/t/socket-activation-support/2050
<niemeyer> cmars: Meanwhile, after you get the snap fully cooked, you can workaround the problem by changing the meta/snap.yaml in prime/ and then packing the snap
<cmars> niemeyer: interesting, ok, thanks
<phoenix_firebrd> how to know what version of intel vaapi driver is used in ubuntu snap core in stable channel?
<popey> phoenix_firebrd: I dont believe we ship vaapi drivers in core
<phoenix_firebrd> popey: so vlc snap uses driver from the host?
<popey> yes
<phoenix_firebrd> popey: in general how can you find the versions of software used in a core snap?
<popey> it uses whatever the right driver is for the gpu
<popey> that's a question for someone who works on the core snap I think
<popey> (not me)
<popey> (I imagine ogra_ knows) :D
<popey> the yaml is probably somewhere abouts
<phoenix_firebrd> popey: I patched my vaapi driver, the normal install of software reflects that, but it has no effect on the snap version of vlc
<ogra_> phoenix_firebrd, http://people.canonical.com/~ogra/core-builds/ has links to manifest files for all auto-built core snaps
<phoenix_firebrd> ogra_: thanks, I will take a look at that
<ogra_> and no, i dont think vaapi from the host is used, the vlc snap definitely uses something it ships itself
<ogra_> (my laptop has no working vaapi setup yet, i can configure vlc from the snap with the vaapi driver and get accelerated playback)
<ogra_> libva info: VA-API version 0.39.0
<ogra_> libva info: va_getDriverName() returns 0
<ogra_> libva info: Trying to open /snap/vlc/158/usr/lib/x86_64-linux-gnu/dri/i965_drv_video.so
<ogra_> libva info: Found init function __vaDriverInit_0_39
<ogra_> libva info: va_openDriver() returns 0
<ogra_> [00007f3ced0781c0] avcodec decoder: Using Intel i965 driver for Intel(R) Ivybridge Mobile - 1.7.0 for hardware decoding
<ogra_> this pretty clearly points to the in-snap driver ...
<phoenix_firebrd> ogra_: vainfo from where?
<ogra_> thats simply from starting vlc in a terminal
<popey> oh, it depends :)
<phoenix_firebrd> ogra_: ok. can you show me a link to the manifist of this package ubuntu-core-libs
<ogra_> yeah, probably different on non-intel
<popey> yeah
<ogra_> phoenix_firebrd, no, i have no idea where a manifest for the vlc snap would live
<ogra_> phoenix_firebrd, the vaapi lib is included in the vlc snap ... not anywhere in core
<popey> for intel, yeah, and it builds using the 16.04 archive, so whatever is in 16.04
<ogra_> cant be
<ogra_> the vaapi in the archive is broken
<phoenix_firebrd> ogra_: thats right
<ogra_> i assume the vlc snap builds some upstream version
<popey> (I made that bit of the vlc snap)
<phoenix_firebrd> ogra_: who maintains the vlc snap, the vlan team or a ubuntu dev?
<popey> vlc
<popey> https://github.com/videolan/vlc/blob/master/extras/package/snap/snapcraft.yaml
<ogra_> $ snap info vlc|grep publisher
<ogra_> publisher: videolan
<phoenix_firebrd> ogra_: it cant be an upsteam version, you version as you saw is pretty old
<popey> note the libva stage packages
<phoenix_firebrd> popey: the latest is version 2.1.0
<popey> the latest version of what?
<phoenix_firebrd> ogra_: may be i show file a bug report to ask them to bump the version
<popey> What's up with the one it ships?
<phoenix_firebrd> popey: libva
 * ogra_ hasnt had any issues with in on ivybridge and kybylake HW
<popey> ok, well currently it's using the one from 16.04
<phoenix_firebrd> popey: it has bug that when playing a vp9 codec video (4k videos from youtube) shows some corrupted video frames
<ogra_> i still dont get why i cant get vaapi to work at all with the archive version while vlc just bundles it and it works ... very weird
<popey> phoenix_firebrd: interesting, I'd file a bug upstream in vlc
<ogra_> yeah
<phoenix_firebrd> popey: niced
<popey> thresh: is the maintainer of the vlc snap, maybe they can comment :)
<phoenix_firebrd> nice
<ogra_> note that bumping such a version is quite some work ... (the snap would have to build a newer upstream version at build time)
<phoenix_firebrd> ogra_: popey let me find the upstream bug report and the official patch , so that we can have some idea
<ogra_> note that snaps are currently bound to 16.04 versions of the dependencies they use ...
<ogra_> regardless where they are executed
<ogra_> (this is about to change in 18.04 at some point but currently it means if you want to patch a dependency it gets kind of awkward)
<phoenix_firebrd> https://github.com/intel/intel-vaapi-driver/issues/297
<phoenix_firebrd> https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
<phoenix_firebrd> thats the bug report and the next is the patch
<ogra_> fun, a one liner
<phoenix_firebrd> ogra_: what about in the edge channel?
<phoenix_firebrd> ya
<ogra_> that has nothing to do with channels
<ogra_> snaps use deb packages ass build dependencies and as runtime deps
<phoenix_firebrd> ogra_: both stable and edge are 16.04?
<ogra_> with the current design thies debs have to be 16.04 ones
<ogra_> yes
<ogra_> all snaps are 16.04 based currenty
<phoenix_firebrd> I understand
<ogra_> you *can* build your deps from source
<phoenix_firebrd> you mean for snaps or normal packages?
<ogra_> or you can maintain a PPA with backports of newer debs for your dependencies and hack usage of that PPA into your snapcraft.yaml
<ogra_> for snaps
<ogra_> they usually ship their dependencies ...
<phoenix_firebrd> ogra_: I did that, but the point is i dont this issue to be present in 18.04
<ogra_> if you read the snapcraft.yaml popey linked above you see "build-packages" and "stage-packages" ... these are typically 16,04 deb packages
<ogra_> yes, i understand
<ogra_> but the version in the snap is 16.04 ... unless someone backports the fix into the ubuntu archive or the vlc maintainer jumps through some hoops (build vaapi from source or backport the 18.04 version in a PPA and maintain it there ... (and hack the snapcraft.yaml of vlc to use that PPA))
<ogra_> there is no easy solution for this atm ...
<phoenix_firebrd> ok
<ogra_> the design is changing  to allow newer dependencies via "base snaps" in the future (then your whole snap can be built against i.e. 18.04 but still run on 14.04 or 16.04)
<ogra_> but thats not done yet
<ogra_> so for now its a big amount of extra work for the snap packager to include such a patch
<phoenix_firebrd> ok
<phoenix_firebrd> what happens in case of a security patch for a dependency?
<popey> the developer rebuilds the snap
<popey> (or it's automatic)
<phoenix_firebrd> if the core snap is rebuilt does the vlc snap for example have to be rebuilt?
<ogra_> no
<phoenix_firebrd> ok
<phoenix_firebrd> vlc snap is like a static executable?
<ogra_> not really :)
<phoenix_firebrd> ok
<ogra_> it is a dynamically linked executable that ships all the libs it is linked against and sets a library path pointing to them
<phoenix_firebrd> ogra_: understood
<phoenix_firebrd> ogra_: do you know/guess what version of libva will be shipped during release of 18.04?
<ogra_> nope
<ogra_> and until there is snap support for 18.04 (beyond the 16.04 base we have today) it will still take some time
<ogra_> so for a while snaps will still be 16.04 based ... even in 18.04 ... until the base snap spec is fully implemented
<ogra_> (which will likely happen within the 18.10 timeframe)
<phoenix_firebrd> ogra_: If a snap is strictly confined, is it denied of gpu access?, I read in a forum. Is that true?
<ogra_> it needs to define an interface for access
<popey> https://docs.snapcraft.io/reference/interfaces
<popey> there's an opengl interface
<ogra_> right
<ogra_> and an x11 one ... and a wayland one
<ogra_> (and various others)
<phoenix_firebrd> popey: Its like policykit
<ogra_> lol
<phoenix_firebrd> :)
<ogra_> thats quite a simplification :)
<phoenix_firebrd> ogra_: Can a theme be installed to be used for snaps?
<ogra_> currently only if you ship it along with your app
<ogra_> there is work going on to solve this though ...
<phoenix_firebrd> ogra_: oh o_O
<phoenix_firebrd> ok
<phoenix_firebrd> popey: ogra_ thanks for the support
<ogra_> np :)
<popey> no problem
<elopio> snappy-m-o autopkgtest 1943 xenial:armhf xenial:amd64 xenial:arm64
<snappy-m-o> elopio: I've just triggered your test.
#snappy 2018-02-21
<mup> PR snapcraft#1942 closed: Release changelog for 2.39.2 <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1942>
<niemeyer> Why is every test failing with uboot-go now? Something changed behavior recently
<elopio> snappy-m-o autopkgtest 1943 bionic:armhf bionic:amd64 bionic:arm64
<snappy-m-o> elopio: I've just triggered your test.
<mborzecki> morning
<mborzecki> arch package updated to 2.31.1
<mvo> mborzecki: yay, thank you
<mborzecki> mvo: morning :)
<mvo> mborzecki: and good morning to you as well :)
<brett__> Need some advice on remote parts I've just built a snap on build.snapcraft.io more specifically its intended to be used as a part. I'm now building the snap that will use the above part. So the question is how does snapcraft find the part when its building my snap.  My understanding is that my part will be on the 'edge' channel until approved. Does that mean I need to swich snapcraft to the edge channel in order to find my part? Al
<brett__> to find a local copy of the part?
<kalikiana> good morning, snappy
<brett__> Need some advice on remote parts I've just built a snap on build.snapcraft.io more specifically its intended to be used as a part. I'm now building the snap that will use the above part. So the question is how does snapcraft find the part when its building my snap.  My understanding is that my part will be on the 'edge' channel until approved. Does that mean I need to swich snapcraft to the edge channel in order to find my part? Al
<brett__> to find a local copy of the part?
<brett__> looks like it must be 9am somewhere in the world
<kalikiana> hey brett__
<kalikiana> Do you know about he parts wiki?
<kalikiana> https://wiki.ubuntu.com/snapcraft/parts
<pstolowski> morning!
<brett__> I know about the parts wiki, but I assumed that its controlled.
<brett__> I also note that there is only a very small no. of parts visible on the wiki, which makes me think that is not actually the primary parts source.
<brett__> my part is still beta so I'm not certain its ready to be visible publicly
<brett__> how can I make it available locally?
<brett__> If I can make it available locally to the snap I'm building then I can confirm that it works correctly as a part.
<kalikiana> brett__: just include the part in your snap's snapcraft.yaml directly for testing
<kalikiana> or you could set SNAPCRAFT_PARTS_URI
<kalikiana> (the default value is https://parts.snapcraft.io/v1/parts.yaml)
<brett__> I don't understand what you mean by 'just include the part in your snap's snapcraft.yaml'
<brett__> do you mean copy each of the  sections of the parts yaml into the snaps yaml.
<brett__> This is likely to be messy as its a moderatley complex part, also what about all of the files scripts?
<brett__> If you change the SNAPCRAFT_PARTS_URI can I point it at a local file system?
<brett__> kalikiana - if I point it to a local file system, exactly what should it point to.
<brett__> I've been googling the URI but can't find any useful doco.
<kalikiana> brett__: see the URL above, that's what contents should look like
<kalikiana> brett__: by include it in the yaml what I mean is, you can add it to parts: like a local part. it works the same way. you can do that with any remote part, the syntax is the same.
<brett__> kalikiana, sorry but I don't understand what you mean
<brett__> a local part defined a plugin to build it
<brett__> what plug do I use when referencing a local part
<brett__> also its not clear what you mean by: see the URL above, that's what contents should look like
<brett__> clearly the uri points to a url with a 'parts.yaml' file.
<kalikiana> brett__: say you have something like this `parts:
<kalikiana>   foo:
<kalikiana>     plugin: python3
<kalikiana>     source: some-github-url`
<brett__> I have no idea what a parts.yaml looks like and if it requires a url then that implies I need set up a private webserver
<brett__> why 'python3'
<kalikiana> brett__: "foo" is the name of the part. you can use it directly in your snapcraft.yaml
<kalikiana> or, you get it from a remote part, where it's instead in the snapcraft.yaml of the remote part
<brett__> my part is built with java, or is python3 the 'its a part' plugin
<kalikiana> in both cases the definitoin looks the same
<brett__> sorry which definition are you referring to.
<kalikiana> brett__: I don't know what your part looks like, this is an example to explain it better :-)
<brett__> I current have:
<brett__> parts:   # build the web app   orion-monitor-webapp:     plugin: maven     source: git@bitbucket.org:sbsutton/orionmonitor.git     maven-options:       [-DskipTests=true]     organize:       war/orionmonitor-1.0-SNAPSHOT.war : webapps/orionmonitor.war     after: [tomcat-with-ssl]
<brett__> ok, that wasn't helpful
<brett__> this is the part
<brett__> https://github.com/bsutton/tomcat-with-ssl-snap
<brett__> currently in the snap I just have after: [tomcat-with-ssl]
<brett__> so I've just tried your suggestion of including the part directly
<brett__> Failed to pull source: unable to determine source type of 'https://github.com/bsutton/tomcat-with-ssl-snap'.
<brett__> tomcat-with-ssl:     plugin: python3     source: https://github.com/bsutton/tomcat-with-ssl-snap
<brett__> how do I tell it what the 'source type' is?
<kalikiana> brett__: source-type: git
<brett__> ok, it appears to be building :))
<brett__> I think we need some more doco on this. I've re-read the user guide multiple times and it really doesn't explain how this works.
<brett__> the python3 plugin was particularly non-obvious
<brett__> I will put some notes on a forum post for others that might be interesed.
<kalikiana> brett__: You can try `snapcraft help plugins` or more specifically `snapcraft help python3` to get docs
<brett__> I have seen one warning that didn't make much sense
<brett__> You must give at least one requirement to install (maybe you meant "pip install /home/bsutton/git/orionmonitor/snap-projects/installer/parts/tomcat-with-ssl/python-packages"?)
<brett__> just looked at the doco for python3 plugin and it certainly wouldn't have led me to use it as you suggested.
<brett__> the doco basically says to use it for python3 projects and my part is java so I would have just sailed past it.
<mvo> hm, I'm getting "snap install hello\nerror: unable to contact snap store" - is that just me/my connection?
<mborzecki> mvo: same here
<pstolowski> mvo, and here
<mvo> just asked in #snapstore and they know and work on it
<mvo> fallout from the DDoS we introduced with the strict timeout handling
<mvo> eh, strict schedule
<mvo> time
<mvo> and back
<mborzecki> sorry :(
 * mvo hugs niemeyer for his review
 * niemeyer hugs mvo back
<pstolowski> mvo, ack, thx
<pedronis> mvo: you haven't yet changed to not wait for in progress default provider in prereq, right? I saw niemeyer, sadly we have a bit of the complication that what we need for bases vs default providers is a bit different, bases need to be ther much earlier, IÂ suppose to run any hook
<pedronis> s/niemeyer/niemeyer's comment/
<mvo> pedronis: I changed it so that new snaps getting installed (base,default-providers) will be waited upon by the original snap only
<pedronis> what is the original snap?
<mvo> pedronis: snap install "foo" might pull in base,prepreq1,prepreq2, then foo will wait for these three but no waiting between the three new ones
<mvo> pedronis: but you are right, I thing we only need the waits for bases, everything else now does not need any waits at all
<pedronis> yes, we should need to avoid adding multiple tentative to install for other stuff
<pedronis> but we need ot wait only for bases
<pedronis> otoh it destroys the simplicity of comment's pov, life is complicated
<mvo> pedronis: yeah, let me fix that, it will only wait for bases, the rest will be done in parallel. if you are looking at this, please let me know what further tests you would like to see
<pedronis> mvo: I think the new code can support things that are default provider of each other, otoh it's a complicated contrived scenario
<niemeyer> mvo, pedronis: In the future, we may be able to drop the requirement to wait on install altogether, and bake that logic in the "ready" feature
<pedronis> s/complicated/competely/
<niemeyer> I hope this is one of the things we'll be able to tackle in that next round of polishings
<mvo> pedronis: yeah, I think so as well, I can build a test case for that if you want, I think the ciruclar case is handled now
<Chipaca> I'm seeing snapd not release the unix socket when built with 1.10
<Chipaca> on success; on error it releases it fine
<mwhudson> Chipaca, mvo: i'm thinking of making go 1.10 the default for bionic btw
<Chipaca> mwhudson: not 1.11? tsk
<Chipaca> :-D
<mwhudson> Chipaca: well i could shove git master in whatever state it's in into the archive the day before release, that's a sound plan, right?
<Chipaca> mwhudson: well, it certainly rings a bell
<mwhudson> i'm just happy we don't have a new architecture having its first release in an LTS this time...
<Chipaca> mwhudson: seriously, 1.10 is fine for 18.04, but by 20.04 it'll be just as old as 1.6 is today
<mwhudson> yeah i know
<mwhudson> something else i also know: it's time for bed
 * mwhudson zzz
<mborzecki> FYI master is currently broken on Arch, can't start snaps, one user brought it up in snapd-git comments, i'm looking into it, otoh 2.31.1 works just fine
<ogra_> cjwatson, is there something like "set -x" i can use in grub.cfg (i got u-boot->grub working but it falls over when loading the initrd (i think at least))
<pstolowski> mborzecki, commented on one of your timer PRs
<mborzecki> pstolowski: thanks
<pstolowski> niemeyer, hey, thanks for the review of limitedbuffer! will you have a moment to take a look at #4551?
<mup> PR #4551: ifacestate: do not auto-connect manually disconnected interfaces <Created by stolowski> <https://github.com/snapcore/snapd/pull/4551>
<niemeyer> pstolowski: Is this a requirement for auto-connect to land?
<niemeyer> pstolowski: Sorry, I meant interface hooks more generally
<cjwatson> ogra_: set debug=<various things>.  set debug=all gives you everything though will be pretty noisy, but if you have a serial console so that you can capture the full dump it's the easiest way to start.  https://www.gnu.org/software/grub/manual/grub/grub.html#debug
<ogra_> cjwatson, perfect, thanks !
<pstolowski> niemeyer, no, it's independent
<niemeyer> pstolowski: So I'd prefer to hold that back if you don't mind
<niemeyer> pstolowski: Marking as blocked until the other features have landed, are working fine, and were released in stable
<mup> PR snapd#4713 opened: cmd/snap: add self-strace to `snap run` <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4713>
<niemeyer> pstolowski: Otherwise this is one more change piled up on that already complex space
<pstolowski> niemeyer, ok
<mborzecki> any idea what's happening here? https://paste.ubuntu.com/p/JCMTRnG3PQ/ snapd from master
<mborzecki> the last thing is: execve("/usr/lib/snapd/snap-device-helper", ["/usr/lib/snapd/snap-device-helpe"..., "add", "snap_ohmygiraffe_ohmygiraffe", "/sys/class/mem/null", "1:3"], 0x7fff4eff7858 /* 0 vars */) = -1 ENOENT (No such file or directory)
<mborzecki> that's tough luck because /usr/lib/snapd/snap-device-helper is there in the filesystem
<pstolowski> mborzecki, hmm this snap works here (core from beta)
<mborzecki> pstolowski: i'm running 2.31.r470.g8fd74f718 (latest master), without reexec, that would make it ahead for --edge and --beta
<cachio_> mvo, hey
<cachio_> mvo, did you see the email that I sent you?
<pstolowski> mborzecki, are you using core from edge? i think this helper needs to exist in core. it doesn't exist in beta core image, only in edge, so if you're running master you may have an incompatibility
<mborzecki> pstolowski: yeah, i think it runs in the mount namespace of the snap, probably edge will work
<mborzecki> pstolowski: .. and it does
<mvo> cachio_: that i386 is unhappy? I saw it, could you point me to a log with the failures please?
<pstolowski> good
<cachio_> mvo, https://paste.ubuntu.com/p/mdJgCbyqnR/
<cachio_> mvo, could be related to the problem that you mentioned yesterday?
<mvo> cachio_: hm, that looks unreleated, strange, can you see with `snap changes` what is actually going on?
<cachio_> mvo, it shows there is an auto-refresh
<cachio_> mvo, I canceled it
<cachio_> mvo, then the tests continues
<cachio_> but , I tried 3 times and alwaut I saw the same problem
<cachio_> mvo, I'll try again
<mvo> cachio_: strange, I will try after lunch
<cachio_> mvo,
<cachio_> np
<Facu> hi! where are snapd logs? I want to see what it's currently doing in my system (thanks!)
<mborzecki> Facu: try `journalctl -u snapd`
<Facu> mborzecki, last thing I see is "Started Snappy daemon.", 1h80m before, and it's been hammering a couple of CPUs since... maybe I should enable debug logs or something?
<Facu> *1h20m
<mborzecki> Facu: you can add SNAPD_DEBUG=1 its environment file, `systemctl cat snapd` to find the right path
<Facu> mborzecki, done, and restarted, let's give it some minutes, thanks!
<mup> PR snapcraft#1944 closed: tests: split the plugins tests in the same directory <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1944>
<sergiusens> o/
<sergiusens> mvo: fyi https://pastebin.ubuntu.com/p/Svkx2KZ8jG/
<mvo> sergiusens: is this inside lxd? is it a new thing?
<sergiusens> mvo:  inside lxd, yes
<sergiusens> mvo: it looks like the same thing (except I used to trigger it on garbage collection)
<mvo> sergiusens: hrm, drat - zyga will want to know about this once he is back
<mup> PR snapd#4707 closed: tests: spread test for broadcom-asic-control interface <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4707>
<sergiusens> snappy-m-o: autopkgtest 1943 bionic:amd64 bionic:arm64 bionic:armhf
<snappy-m-o> sergiusens: I've just triggered your test.
<sergiusens> mvo: we sort of need that working to make this https://forum.snapcraft.io/t/per-project-containers/388/16 a thing
<Chipaca> sergiusens: is this running snapd in a snapped snapcraft inside a snapped lxd ?
<diddledan> snapception
<Chipaca> one day we're going to find we've completely melted the bits of the kernel that handle mount namespaces
<Chipaca> it'll just be a 20MB array of half-bits
<mvo> seb128: please invite pedronis for the install state.json call too
<seb128> mvo, done
<Son_Goku> I guess I'm spending lunch today updating snapd and snapd-glib
<popey> \o/
<Son_Goku> kyrofa, ping
<kalikiana> Son_Goku: you'll have better luck next week, since he's taking care of a kid that just came out of the oven
<Son_Goku> oh jeez, okay
<kalikiana> Son_Goku: anything I could potentially help with?
<sergiusens> Chipaca: all correct except the snapped snap, this is snapcraft in venv but installing what it snapped in the env (the forum post however is the full deal, snapcraft snap, any build-snaps entry installed running inside a container created by lxd as a snap or whatever mechanism)
<Son_Goku> kalikiana, I'm looking to try to make some time to bang out an initial prototype of rpm-based snaps in snapcraft
<Son_Goku> I wanted to know if there were any major changes to how snapcraft's backends work since we last looked at it in October
<pedronis> Chipaca: was your question about errors in the new api?
<Guest28851> hello, is there a way to specify the python interpreter to use on the package ?
<Guest28851> instead of "python3", y want /usr/bin/python3.6
<Guest28851> instead of "python3", I want /usr/bin/python3.6
<kalikiana> Son_Goku: Not really, no.
<kalikiana> Son_Goku: Also, awesome to hear that :-D
<Guest28851> So it will always use the default python3 of the system?
<Son_Goku> Guest28851: yes
<Guest28851> Ok, thanks
<Guest28851> Also, I think it doesn't support py3.6
<mvo> seb128: ta!
<jdstrand> mvo: hi! thinking about the OOM issue
<jdstrand> mvo: with spread tests, how many squashfs are mounted?
<jdstrand> mvo: I ask cause while we can trigger the issue and jjohansen is looking into it, it seems (to me) to trigger too quickly with the amount of ram the system is supposed to have (1.5G)
<jdstrand> mvo: I'm kinda wondering if there are lingering squashfs mounts (but they seem to be cleaned up on snap remove, so not sure why that would be the case)
<mvo> jdstrand: I need to investigate how many but I also see it when this test runs in isolation
<mvo> jdstrand: its also not 1.5G - its 400M on i386 because it eats LowMem
<mvo> jdstrand: so its ~400/15 steps before it dies
<mvo> (that is my rought esitmate)
<jdstrand> jjohansen: fyi ^
<jdstrand> mvo: there is LowTotal and LowFree. in /proc/meminfo. in my i386 VM with artful release kernel (no spectre/meltdown) and -updates kernels, I see that LowTotal is approaching the total ram (768M in the VM I'm using).
<jdstrand> mvo: I realize LowFree is going down because there is a leak, but, for example, I only have 200M in LowFree here, but it takes a few loops to hit the condidition
<jdstrand> mvo: as opposed to load, connect, oom
<jdstrand> mvo: which you observe with twice the ram and twise the LowFree
<jdstrand> twice*
 * kalikiana lunch
<jdstrand> jjohansen: fyi, note my followup ^
 * pstolowski lunch
<mup> PR snapcraft#1945 opened: elf: clear execstack by default <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1945>
<sergiusens> jdstrand: when you have time, mind reviewing https://github.com/snapcore/snapcraft/pull/1945 ?
<mup> PR snapcraft#1945: elf: clear execstack by default <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1945>
<jdstrand> sergiusens: sure
<sergiusens> thanks
<mup> Bug #1750840 opened: [Enhancement] Please show (optionally) size consumed by snap in snap list <enhancement> <Snappy:New> <https://launchpad.net/bugs/1750840>
<mup> PR snapcraft#1877 closed: tests: move test files out of the snapcraft dir <Created by elopio> <Closed by elopio> <https://github.com/snapcore/snapcraft/pull/1877>
<mup> PR snapcraft#1892 closed: meta: parse float version as string <Created by kalikiana> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1892>
<xnox> mvo, 2.31.1+18.04	snapd/2.31.1+18.04 systemd/237-3ubuntu3 still red on s390x, but passes on other arches =(
<xnox> this is latest snapd, triggered together with latest systemd.
<xnox> + [[ ubuntu-18.04-s390x == ubuntu-14.04-* ]]
<xnox> + systemctl stop dbus-provider
<xnox> Failed to stop dbus-provider.service: Unit dbus-provider.service not loaded.
<xnox> hm... something interesting is expected on s390x?
<xnox> what is "location-control"?
<xnox> 2018-02-21 14:31:31 Failed task prepare: 1
<xnox>     - autopkgtest:ubuntu-18.04-s390x:tests/main/interfaces-location-control
<xnox> 2018-02-21 14:31:31 Failed task restore: 1
<xnox>     - autopkgtest:ubuntu-18.04-s390x:tests/main/interfaces-location-control
<xnox> error: unsuccessful run
<pedronis> xnox: an interface to control locationd  IÂ think
<xnox> pedronis, is that available on s390x?
<xnox> $ apt search locationd -> gives me nothing
<xnox> pedronis, what is locationd?
<mvo> xnox: yeah, s390x used to be virtual and now is (more) real so the tests run for the first time
<mvo> xnox: all sorts of test snaps missing, we are making progress there
<mvo> xnox: thanks for including my systemd "fix" (workaround) for the apparmor label issue!
<pedronis> xnox: sorry locationd is the name of a snap, I think the deb is ubuntu-location-service-*
<pedronis> it's for GPS access basically
<xnox> ok, source package is location-service and that does not exist for s390x
<xnox> and has been removed everywhere post-xenial
<xnox> pedronis, mvo, none of the location service tests should be running on bionic+, no? and definately not on s390x
<pedronis> xnox: well the snap still exists
<pedronis> for core
<pedronis> so they need to run somewhere
<pedronis> but for sure not s390x
<xnox> true
<xnox> location-service is in dep-wait state since xenial
<xnox> Missing build dependencies: libubuntu-platform-hardware-api-headers, libubuntu-platform-hardware-api-dev
<xnox> i don't think you will be able to build location-service on s390x ever.
<xnox> mvo, pedronis - so i think we should open a bug; badtest snpad on s390x; and release current systemd & snapd.
<mvo> xnox: yeah, lets put snapd on s390x in the "ignore" list for promotion for now, we work towards fixing it
<mvo> xnox: and we will skip this particular test on s390x as a start (I'm sure there are more)
<mvo> (more that will need fixing)
<xnox> https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1750856
<mup> Bug #1750856: snapd on s390x tried to run locationd tests, which does not exist on s390x <snapd (Ubuntu):New> <snapd (Ubuntu Bionic):New> <https://launchpad.net/bugs/1750856>
<sergiusens> niemeyer: https://forum.snapcraft.io/t/fixing-the-snapcraft-cache-lp-1582469/4127 (for when you have time)
<mup> Bug #1750856 opened: snapd on s390x tried to run locationd tests, which does not exist on s390x <britney:New> <Snappy:New> <snapd (Ubuntu):New> <snapd (Ubuntu Bionic):New> <https://launchpad.net/bugs/1750856>
<xnox> slangasek, https://code.launchpad.net/~xnox/britney/badtest-snapd-s390x-locationd/+merge/338446 please =) based on above conversation and bugs
<slangasek> xnox: done
<mvo> cachio__: what are the chances for 2.31.1 for candidate? is i386 still give you trouble?
<mvo> xnox: thank you!
<cachio__> mvo, I am researching the last failure
<cachio__> mvo, after that we can go to candidate
<mvo> cachio__: thank you!
<niemeyer> sergiusens: Noted and replied (a while ago, just for the record)
<niemeyer> jdstrand: ping
<jdstrand> niemeyer: hey
<niemeyer> jdstrand: Heya, do you
<niemeyer> have a moment for a call?
<jdstrand> niemeyer: yes
<niemeyer> jdstrand: https://hangouts.google.com/hangouts/_/canonical.com/snap-interfaces
<cachio__> mvo, 2.31.1 is in candidate now
<mvo> cachio__: \o/
<mvo> cachio__: thank you
<cachio__> mvo, np
<sergiusens> niemeyer: thanks
<Chipaca> unnnh
<Chipaca> why are weekdays in timeutils called weeks?
<Chipaca> that is very confusing
 * kalikiana wrapping up for the day
<kalikiana> Chipaca: I vote for calling them years, much clearer that way :-P
<kalikiana> Chipaca: Actually sounds like a Japanese thing. Like saying "convenience" when you mean a shop, or saying "work" when you mean a part-time job.
<kalikiana> You add the missing word in your head
<mup> PR snapcraft#1946 opened: errors: add ability to send stack traces to sentry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1946>
<Chipaca> kalikiana: my problem isn't with synecdoche per se
<Chipaca> or would this be metonymy
<Chipaca> darn it
<Chipaca> anyway, my problem isn't with the figure of speech :-)
<mup> PR snapcraft#1946 closed: errors: add ability to send stack traces to sentry <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/pull/1946>
<mup> PR snapcraft#1947 opened: errors: add ability to send stack traces to sentry <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1947>
<cachio__> jdstrand, hey
<cachio__> I am making an update on the interface tests, and removing part of the connection checks
<cachio__> asi we are already checking that in the interfaces-many test
<cachio__> jdstrand, do you have any idea about how to check that the autoconnection is done or not as part of this test?
 * Chipaca -> walk
<mvo> pedronis: we still want  4599 for 2.32, right?
<pedronis> mvo: yes
<pedronis> mvo: I was having dinner
<mvo> pedronis: np, I see what I can do tonight about the review, otherwise tomorrow early
<mvo> pedronis: looks like 2.32 can will be branched tomorrow morning(ish)
<pedronis> mvo: I'm trying to see if I can re-review your branch still tonight
<popey> Is there any way to switch a snap to devmode without removing it (and thus losing all my data)?
<popey> snap refresh doesn't seem to take any notice of the --devmode flag
<pedronis> mvo: left some comments still
<pedronis> mvo: did we lose waiting for the base case?
<mup> PR snapcraft#1948 opened: tests: move test files out of the snapcraft dir <Created by elopio> <https://github.com/snapcore/snapcraft/pull/1948>
<mvo> pedronis: hm, iirc I added code that would make everything in the change wait for the base snap, let me double check
<mvo> pedronis: thanks for your comments, I'm looking now
<mvo> pedronis: aha, I see what you mean now, checking
<pedronis> mvo: it's called setup-profiles  not setup-profile I think
<mvo> pedronis: indeed, thanks. I re-added the wait, the test is still missing, I look into this next
 * pedronis eods
<jdstrand> xnox: hehe "And mainframes don't usually change their
<jdstrand> GPS location ;-)
<jdstrand> "
<pat-s> Hi guys, does anyone know why the LD paths of my binary are altered during the prime stage? Everythings fine during build/install/stage until it gets primed..
<mup> PR snapd#4563 closed: tests: new spread test for gpio-memory-control interface <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4563>
<mup> PR snapd#4714 opened: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
#snappy 2018-02-22
<mup> PR snapcraft#1948 closed: tests: move test files out of the snapcraft dir <Created by elopio> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1948>
<mborzecki> morning
<mborzecki> mvo: morning
<mborzecki> mvo: someone on arch tried to use `snap run --gdb` to debug a segfault with nvidia, they had some problems though so i'm trying to find out more
<mvo> mborzecki: aha, interessting. yeah, this is super new. keen to learn more about the exact issues
<mborzecki> zyga: hey, feeling better?
<zyga> mborzecki hey
<zyga> yeah I feel better
<zyga> I think the worst is over now, I'll try to help as much as I can now
<mborzecki> zyga: take it easy ;) no use if end up getting worse
<zyga> thanks, I'm wrapped in blanket and dressed like an onion
<mvo> zyga: hey, welcome back. yeah, be careful and take it easy. I wonder how long I will last, my kids are sick too
<zyga> is it flu as well?
<zyga> I had fever for a few days but now it's (almost) good, I hope your kids are better quickly
<mvo> zyga: yeah, fever and all that
<kalikiana> good morning
<kalikiana> zyga: are you using tor as well? ;-)
<zyga> kalikiana, no I don't use tor
<kalikiana> Just thinking you are dressed accordingly at least
<zyga> aahh
<zyga> :D
<zyga> sorry, I'm slow on jokes today
<zyga> yeah, I wish there was a flu firewall ;)
<kalikiana> Avoid touching your face with your own hands ever unless you cleaned your hands
<zyga> can I git push? :)
<kalikiana> You can you the keyboard, it's the dirtiest thing around you anyways
<kalikiana> *touch
<zyga> I clean my keyboard regularly but yeah
<mwhudson> snap download going extremely slowly for me for some reason :/
<mwhudson> 35 kB/s
<pstolowski> morning!
<zyga> hey pawel
<zyga> mwhudson are you being redirected to some CDN on the other side of the planet?
<mwhudson> zyga: how would i tell?
<mwhudson> it was fast yesterday i think...
<zyga> mwhudson mmm, good question
<zyga> I don't know
<mborzecki> pstolowski: hey
<mwhudson> but that might have been office vs home
<zyga> mwhudson btw, kudos on the installer work, it's stellar!
<mwhudson> zyga: thanks, it's ok :)
<pstolowski> zyga, hey, can you revoke your approval of #4358 (I don't seem to be able to)? there were many additions that it mandates 2 reviews again I'm afraid
<mup> PR #4358: interfaces: interface hooks implementation <Created by stolowski> <https://github.com/snapcore/snapd/pull/4358>
<zyga> sure
<pstolowski> thankx
<mborzecki> travis jobs timing out again?
<Chipaca> *yawn*
<zyga> hey John
<pedronis> Chipaca: hi
<Chipaca> zyga: pedronis: hiya
<Chipaca> zyga: are you back amongst the living?
<zyga> hey pedronis :-)
<zyga> Chipaca yeah, more or less
 * Son_Goku rises from the dead
<mborzecki> guys, should we have a content snap with debugging symbols for the core?
<mup> PR snapd#4715 opened: store: reorg auth refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4715>
<pedronis> Chipaca:  this ^ might be something for you to review
<zyga> mborzecki very interesting and big problem to solve correctly (ideally with gdb support for snap run --gdb)
<mborzecki> an example, a user found a segfault that happens with nvidia drivers and snaps that require acceleration, he tried to use snap run --gdb, got this https://hastebin.com/sutuguquxu backtrace points to libc (probably something corrupt) but it's hard to discern what has really happened
<mvo> hrm, a pastebin that requires javascript to display text *grumpf*
<pedronis> mvo: I +1ed #4103,  but there were quite a few changes since Gustavo's +1, I think it needs a 2nd review again, not sure if by Gustavo or somebody else, maybe pawel
<mup> PR #4103: snapstate: auto install default-providers for content snaps <Created by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<pedronis> Chipaca: mvo: what do you think of a PR  that does  s/remoteRepoTestSuite/storeTestSuite/ s/UbuntuStoreRepository// in store/store_test.go
<Chipaca> pedronis: +33
<pedronis> Chipaca: ok, once a couple of other PRs touching store have landed I can do that, seems a clean up that is quite overdue
<pstolowski> pedronis, mvo curious about your opinion on https://forum.snapcraft.io/t/snap-set-xxx-requires-configure-hook/4134
<pedronis> pstolowski: my impression is that is something we could revisit when we have configuration schemas
<pstolowski> pedronis, right, good idea. that will ensure people don't add more config garbage
<pedronis> once we have schemas to say what is the config/who can read it, then it might make sense to make configure optional
<pstolowski> +1
<mborzecki> hmm: Failed to fetch http://security.ubuntu.com/ubuntu/dists/trusty-security/main/binary-amd64/Packages  Hash Sum mismatch
<pedronis> mvo: there's a failure of  tests/main/snap-service-refresh-mode on suse here:  https://travis-ci.org/snapcore/snapd/builds/344719396?utm_source=github_status&utm_medium=notification
<pedronis> plus the Hash Sum mismatch stuff
<Son_Goku> zyga, mvo: new errors from gcc
<Son_Goku> libsnap-confine-private/locking-test.c: In function 'sc_test_use_fake_lock_dir':
<Son_Goku> libsnap-confine-private/locking-test.c:53:24: error: cast between incompatible function types from 'int (*)(const char *)' to 'void (*)(void *)' [-Werror=cast-function-type]
<Son_Goku>    g_test_queue_destroy((GDestroyNotify) unsetenv,
<Son_Goku>                         ^
<Son_Goku> cc1: all warnings being treated as errors
<Son_Goku> make[1]: *** [Makefile:1571: libsnap-confine-private/libsnap_confine_private_unit_tests-locking-test.o] Error 1
<zyga> Son_Goku oho, thanks I will fix that shortly
<mup> PR snapd#4716 opened: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <https://github.com/snapcore/snapd/pull/4716>
<mup> PR snapd#4717 opened: cmd/snap-update-ns,testutil: move syscall testing helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4717>
<mup> PR snapd#4718 opened: tests: disable interfaces-location-control on s390x <Created by mvo5> <https://github.com/snapcore/snapd/pull/4718>
<zyga> mvo ^ this is the first chunk of the move, it turned out to be pretty harmless actually, the diff is mostly caused by me writing tests for the testing helperrs
 * zyga -> break for lunch and meds
<mup> PR core#81 opened: 14-set-motd.chroot: updated based on the suggestions from Mark <Created by mvo5> <https://github.com/snapcore/core/pull/81>
 * pstolowski lunch
 * pstolowski lunch
<niemeyer> Heya
<niemeyer> chipaca, mvo: Around?
<Chipaca> niemeyer: o/
<niemeyer> Hey
<zyga> hey niemeyer
<niemeyer> Chipaca: did you catch up with mvo about command not found?
<Chipaca> niemeyer: a little last night; last i heard there was more discussion to be had
<niemeyer> We said we'd have a call yesterday and I missed it.. Want to make sure you are in sync about the discussion in the meeting yesterday before spending time in a diff direction
<Chipaca> niemeyer: i am not spending time on it, pending those discussions
<niemeyer> Mark suggested a simpler approach, which looks fine to me
<niemeyer> Has less data
<niemeyer> We didn't agree on an output for the fuZy case but it should be easy to extrapolate
<niemeyer> He also recommended c-nf to be its own tool for the output to not go out of sync between the different backends
<niemeyer> Which is also fine since he understands we won't be able to change the output so easily
<mup> PR snapd#4719 opened: timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4719>
<niemeyer> I would like to preserve the idea of us using a command on our end, though, instead of having c-n-f coonsulting a file by itself.. The command can put json out
<niemeyer> The rationale for that is being able to evolve the implementation without having to keep historical data around that arbitrary tools depend on
<niemeyer> Chipaca: Those are the main points, I think
<niemeyer> Or at least the main points that seem worth typing on a phone :)
<Chipaca> niemeyer: ack. Not much for me in that; will await further news.
<mup> PR snapd#4720 opened: interfaces: add xdg-desktop-portal support to desktop interface <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/4720>
<Chipaca> mvo: need to go to the school for a meeting, probably won't make it back for the standup
<zyga> mborzecki can you please have a look at https://github.com/snapcore/snapd/pull/4717
<mup> PR #4717: cmd/snap-update-ns,testutil: move syscall testing helpers <Created by zyga> <https://github.com/snapcore/snapd/pull/4717>
<ogra_> mvo, is there anything wrong with the PPA  seems all nightly core snap builds failed with PPA errors ... https://launchpadlibrarian.net/357979314/buildlog_snap_ubuntu_xenial_amd64_core_BUILDING.txt.gz
<zyga> most of the diff is just new unit tests
<mborzecki> zyga: ok
<zyga> but have a look at the API in general, I'd like to turn it from "locally crafted helper" to "semi reusable helper"
<zyga> hey ogra_
 * zyga looks
<ogra_> hmm, ut different PPA issues in the different arches
<zyga> launchpad was offline for some maintenance lately, maybe that is related
<ogra_> thats weird
<ogra_> ah
<ogra_> yeah, that might be it
<zyga> though not really sure
<zyga> does it happen now or is that log from last night
<ogra_> thats from 5:20 this morning
<ogra_> but arm64 has an internal server error for the PPA https://launchpadlibrarian.net/357979358/buildlog_snap_ubuntu_xenial_arm64_core_BUILDING.txt.gz
<ogra_> so i guess it was that maintenance window
<zyga> yeah, could be
<cjwatson> There were some reboots which weren't completely perfectly coordinated.  Just retry those.
<pedronis> mborzecki: wasn't the issue here addressed:  https://travis-ci.org/snapcore/snapd/builds/344749295?utm_source=github_status&utm_medium=notification
<pedronis> IÂ merged master in that branch
<mborzecki> pedronis: looking
<pstolowski> mvo, "mainframe does not change location that often", love that :D
<pedronis> mborzecki: ah, the test seems to need to be fixed too
<mborzecki> pedronis: hah right
<mborzecki> pedronis: are you fixing this or should i?
<pedronis> I can fix it I suppose
<pedronis> mborzecki: I find the original code a bit strange to be honest
<mborzecki> pedronis: you mean globbing & stuff?
<pedronis> I mean all this replacing
<pedronis> but not your fault
<pedronis> seems just odd
<mvo> ogra_: thanks, I have not seen this error yet, hope its transient?
<kalikiana> re
<ogra_> mvo, i fired off a new auto-build, then we will know soon
<ackk> hi, is something special required in the snap to make xdg-open work? I have the snapd-xdg-open package installed (this is artful)
<magicaltrout> has the snap store died a death?
<zyga> ackk it depends on what you want to open
<ackk> zyga, web url
<zyga> ackk then it should just work
<zyga> what happens when you try?
<ackk> zyga, https://pastebin.canonical.com/p/WhvMqTgCDx/
<ackk> zyga, note that is a --devmode snap installed via snap try
<ackk> (if it makes a difference)
<zyga> ah
<zyga> don't ship xdg-open
<ackk> ah you mean it's trying to use the wrong one?
<zyga> kalikiana ^ snapcraft should not bundle xdg-open deb as it will just break things
<zyga> yes, it's using the regular one and that's shadowing the magic one
<zyga> magicaltrout what are you seeing?
<magicaltrout> api.snapcraft.io is 503ing
<magicaltrout> can't install anything
<mborzecki> mvo:  the 2.31-maybe PR  I mentioned: https://github.com/snapcore/snapd/pull/4594
<mup> PR #4594: systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4594>
<ahasenack> magicaltrout: confirmed
<magicaltrout> lovely
<ahasenack> I pinged staff
<magicaltrout> thanks
<zyga> https://status.snapcraft.io is useful
<magicaltrout> ah
<magicaltrout> cool
<magicaltrout> 99.57%
<magicaltrout> how rubbish! ;)
<ackk> zyga, fwiw we don't pull it in explicitly, it's pulled as a dep
<mvo> jdstrand: hey, quick question - do we want settimeofday in time_control.go (in the time-control inteface). I think we do and we did in 2.31 but for some reason its not there in master afaict. I noticed when doing the merge of 2.31 back into master (c.f.  https://github.com/snapcore/snapd/pull/4712/files#diff-398a6a1ea514e53bd322812b60f02924R111 )
<mup> PR #4712: release: version 2.31.1 <Created by mvo5> <https://github.com/snapcore/snapd/pull/4712>
<ackk> zyga, i guess we can strip it manually from the snap
<zyga> ackk yes, please try to remove it, I think you can do that with one of the organize features of snapcraft
<zyga> kalikiana may be able to help, I don't remember the syntax for them
<ackk> zyga, yeah, thanks for the info
<brunosfer> error: unable to contact snap store
<ackk> zyga, does the base snap provide xdg-open?
<zyga>   yes
<ackk> I wonder if base-18 has it
<zyga> ackk it is a part of snapd now
<zyga> but ... hmm
<zyga> mvo ^ perhaps omission
<ackk> zyga, it's not there in base-18 fwiw
<mvo> yeah, base-18 does not have it just yet
<jdstrand> mvo: it was in https://github.com/snapcore/snapd/pull/4687
<mup> PR #4687: 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>
<jdstrand> mvo: which says it was merged...
 * jdstrand scratches head
<mvo> jdstrand: yeah, I'm puzzled
<jdstrand> mvo: but looking at https://github.com/snapcore/snapd/pull/4687/files, it isn't in there
<mup> PR #4687: 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>
<jdstrand> but there it is: https://github.com/snapcore/snapd/pull/4687/commits/c1093d46437a33d60d7378b1c6676818655bc359
<b4nt> Hello, is the snapcraft downtime planned?
<zyga> b4nt no, https://status.snapcraft.io
<pedronis> it should be back
 * jdstrand verifies the others
<b4nt> ok, weird...
<mvo> jdstrand: yeah, its there and the log says it is mereged but https://github.com/snapcore/snapd/blob/master/interfaces/builtin/time_control.go#L109 in master does not have it and I'm puzzled why
<jdstrand> mvo: this reverted it: https://github.com/snapcore/snapd/pull/4687/commits/cc5dcd8cd8879f81d9077b8300b36dd1db2224eb
<mup> PR #4687: 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> b4nt it's down but not on purpose
<mvo> jdstrand: ohhhh
<mvo> jdstrand: accidently?
<mvo> jdstrand: if it got reverted by mistake I will just pull it back in via the 2.31 merge
<jdstrand> mvo: I know there was a conflict in that file. I may have done a rebase somewhere and reorganized and messed it up
<jdstrand> mvo: definitely a mistake
<mvo> jdstrand: no worries!
<mvo> jdstrand: thank you for helping solve this mystery :)
<jdstrand> heh
<mvo> jdstrand: its back now!
<jdstrand> mvo: sorry :) and thank you for pulling that in and noticing it in the first place! :)
<diddledan> is api.snapcraft.io down?
<diddledan> I'm getting 403
<mup> PR snapd#4712 closed: release: version 2.31.1 <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4712>
<mvo> jdstrand: np!
<diddledan> aah, I'm behind - I see yes it is
<mup> PR snapd#4718 closed: tests: disable interfaces-location-control on s390x <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4718>
<diddledan> bonus points for zyga sharing the status.snapcraft.io page which I didn't know existed
<kalikiana> ackk: zyga: what do you need to know for organize? to exclude a binary?
<zyga> kalikiana yes, get rid of xdg-open
<zyga> and it should _probably_ be excluded by default
<kalikiana> what's pulling it in? desktop helpers?
<zyga> kalikiana unclear, ackk can share his snapcraft yaml
<kalikiana> I'd recommend `snapcraft help plugins` to learn about he syntax in general. There's a section about "organize" as well as the other generic keywords
<kalikiana> Okay, looking at the YAML would be best to see what's needed here
<mborzecki> off to pick up the kids
<ackk> kalikiana, amtterm is pulling it in as a dependency
<ackk> kalikiana, zyga: https://git.launchpad.net/maas/tree/snap/snapcraft.yaml
<kalikiana> ackk: Ah. By the looks of it, you can probably just add -usr/bin/xdg-open to the existing "remove" fileset. Note the leading - in addition to the - for each item in the list. That's how you exclude.
<ackk> kalikiana, ah yeah, thanks
<ackk> kalikiana, I'll try that
<mup> PR snapd#4717 closed: cmd/snap-update-ns,testutil: move syscall testing helpers <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4717>
<ogra_> mvo, looks like the builds succeeded, so it was transient indeed
<jdstrand> sergiusens: hi! not sure you saw, but https://github.com/snapcore/snapcraft/pull/1945#pullrequestreview-98350157
<mup> PR snapcraft#1945: elf: clear execstack by default <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1945>
<mvo> ogra_: puh, thanks
<jdstrand> zyga: hi! would you mind briefly looking at https://github.com/snapcore/snapd/pull/4714, and responding to my questions? that way I can finish the PR for a proper review
<mup> PR #4714: interfaces/apparmor,system-key: add upperdir snippets for strict snaps on livecd <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4714>
<zyga> gladly, looking
<jdstrand> zyga: thanks!
<zyga> I'm doing some cleanups in that area actually
<zyga> this should address point 10
<zyga> 1)
<jdstrand> zyga: fs_detect.go could be detect.go?
<jdstrand> zyga: ah, ok
<zyga> jdstrand I'll probably merge overlay, nfs into mount.go later
<sergiusens> thanks jdstrand
<zyga> jdstrand reviewed
<jdstrand> zyga: fyi, willcooke asked about the per-user mounts feature yesterday (I heard you were out. hope you're feeling better). I tried to summarize it as best I could that you are actively looking at it with priority
<mup> PR snapd#4721 opened: tests: update interface tests to remove extra checks and normalize tests <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4721>
<jdstrand> zyga: thanks!
<zyga> jdstrand does this look sane, as a list of mount constraints for user mounts: https://pastebin.ubuntu.com/p/V6zXf9wWkd/
<mvo> Chipaca: the snap pack validation saved my bacon a couple of times today when creating test snaps, nice job
<jdstrand> zyga: looking
<zyga> jdstrand thanks
<jdstrand> zyga: I'd love for point '3' to be enforceable because then this could be bulletproof. unfortunately '3' can't be a constraint for portals to work (see https://github.com/snapcore/snapd/pull/3963#discussion_r164623540)
<mup> PR #3963: cmd/snap-confine: add support for per-user mounts <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/3963>
<zyga> aha, in that case 3 has to fly off the list
<jdstrand> zyga: yeah. otherwise +1
<zyga> jdstrand btw, I was thinking about traversing the filesystem (descending from /) and then doing mount ., this would halve the attack surface
<zyga> for bind mounts that is
<zyga> for normal mounts it would make it race-free
<zyga> (whee)
<zyga> (well, assuming /dev doesn't race0
<jdstrand> zyga: that's an interesting idea
<zyga> we could also do one more crazy thing
<zyga> for bind mounts
<zyga> but that's not for today
<ackk> mvo, is there a place to file bugs about things that are missing in base-18, or is it too early?
<zyga> jdstrand do you think it is worth it?
<jdstrand> zyga: if you do ConservativeMount, then I think that should be sufficient for portals for now since the setuid process (which dropped, but retains enough privilege to mount) will fail if mismounted
<jdstrand> we have to get that detection right though
<jdstrand> (mismount detection)
<zyga> right
<zyga> I think that's quite easy but maybe I miss something
<jdstrand> we can consider hardening after
<zyga> because of rule 4) we can simply look for the mount point in mountinfo _after_
<zyga> so before we mount we ensure that mountinfo doens't contain the mount point
<zyga> and after mount we ensure that it does
<zyga> this means that we managed to mount exactly where we intended
<jdstrand> zyga: james h had trouble with it, but he didn't write all the mount code you did. it seemed like something that would be easy for you :)
<zyga> I wrote some test code for that
<mup> PR snapd#4599 closed: many: send  new Snap-CDN header with none or with cloud instance placement info as needed <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4599>
<jdstrand> zyga: hmm. actually I was thinking of '4' as 'a snapd managed mountpoint', not an 'absolute mountpoint'
<jdstrand> zyga: because XDG_RUNTIME_DIR (/run/user/uid) *is* a mountpoint
<zyga> aha
<zyga> so that's good feedback, I didn't realise that
<jdstrand> zyga: *perhaps* for just portals it is ok because XDG_RUNTIME_DIR will *not* be a mountpoint
<zyga> I will have to adjust the verification logic accordingly
<zyga> mmm, one sec
<jdstrand> zyga: but we will want to mount on XDG_RUNTIME_DIR to cleanup the wayland compat symlinks in XDG_RUNTIME_DIR/snap.foo/wayland -> ../wayland
<jdstrand> (ie, get rid of wrappers)
<zyga> jdstrand so for portals we'll have the equivalent of: mount --bind $XDG_RUNTIME_DIR/doc/by-app/snap.pkg.$SNAP_NAME $XDG_RUNTIME_DIR/doc
<zyga> jdstrand and what's the value of $XDG_RUNTIME_DIR we want?
<zyga> jdstrand /run/user/1234 or something else/
<jdstrand> zyga: re equivalent> that is my understanding
<jdstrand> zyga: with XDG_RUNTIME_DIR, it will be /run/user/<uid>, which is a mountpoint, but /run/user/<uid>/doc will not be
<jdstrand> zyga: so '4'
<mvo> pedronis: thanks again for the review. I added a unit and spread test for circular content providers and I think this is good for a review by e.g. pstolowski
<jdstrand> meh
<jdstrand> zyga: so '4' should be ok for portals
<pstolowski> mvo, sure
<jdstrand> zyga: but it won't be for the XDG_RUNTIME_DIR cleanup (if you recall, XDG_RUNTIME_DIR as /run/user/uid/snap.foo has been problematic for some snaps)
<jdstrand> zyga: and to be even more clear, XDG_RUNTIME_DIR in this context is what the host sees as XDG_RUNTIME_DIR, not what the snap sees. portals won't bind mount into /run/user/uid/snap.foo/doc
<jdstrand> aiui
<jdstrand> we might need jamesh for that bit if we want to keep '4' as a constraint
<jdstrand> I think I can answer definitively though. while we could distro patch portals to do what we want, we can't distro patch all the distros, so it needs to operate the way it does, which is /run/user/uid/doc
<jdstrand> jamesh: can you comment ^
<zyga> jdstrand thanks for explaining this, I'm still a bit slow on the logic (I'm still a little sick)
<jdstrand> zyga: regardless. we do know that we want to eventually have a per snap mount of: mount --bind /run/user/uid/snap.foo -> /run/user/uid, with bind-file mounts for the wayland and pulse sockets
<zyga> the per snap mount is okay as that can be done with non-conservative mount
<jdstrand> zyga: I think the question is, do we plan for this now or do we do the 'whatever makes portals work today'
<zyga> I think we make portals work while considering what will be needed eventually
<jdstrand> where 'this' is the bind mount for /run/user/uid
<mvo> pstolowski: thank you!
<jdstrand> zyga: if that is the constraint, then '4' can remain, but we need to comment that we'll need to lift this restriction at some point
<zyga> ok
<zyga> I'll get to work
<mup> PR snapd#4722 opened: store: cleanup test naming, dropping remoteRepo  and UbuntuStore(Repository)? references <Created by pedronis> <https://github.com/snapcore/snapd/pull/4722>
<pedronis> mvo: Chipaca:  #4722  is the cleanup I was talking about, prereq has not landed though, anyway probably easist to look at each commit by itself
<mup> PR #4722: store: cleanup test naming, dropping remoteRepo  and UbuntuStore(Repository)? references <Created by pedronis> <https://github.com/snapcore/snapd/pull/4722>
<pstolowski> mvo, reviewed, great stuff! some nitpicks/suggestions + one question
<mup> PR snapd#4723 opened: Translate polkit strings <Created by gunnarhj> <https://github.com/snapcore/snapd/pull/4723>
<pstolowski> #4716 needs 2nd review (and is trivial)
<mup> PR #4716: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <https://github.com/snapcore/snapd/pull/4716>
<pedronis> pstolowski: I myself forgot about Attrer, thanks for the review
<pedronis> IÂ mean for mvo's PR
<pstolowski> pedronis, np
<mvo> pstolowski: thanks,  I have a look and will fixup things
<pstolowski> yw
 * kalikiana wrapping up for today
<mup> PR snapd#4724 opened: osutil: aggregate mockable symbols <Created by zyga> <https://github.com/snapcore/snapd/pull/4724>
<Chipaca> huh
<Chipaca> mvo: you around?
<mvo> Chipaca: ish
<mvo> Chipaca: good envening
<Chipaca> mvo: good evening
<Chipaca> mvo: I've got a grep for you
<Chipaca> mvo: grep -r SNAP_REFRESH_FROM
<Chipaca> mvo: I have a relatively strong suspicion that the two lines should match more than they do
<mvo> Chipaca: uh, oh, I see the problem
<Chipaca> :-)
<mvo> Chipaca: thanks for spotting this, lets fix it and get the fix in 2.31 (just in case)
<mvo> Chipaca: will you or shall I?
<Chipaca> funny what you spot when a user asks questions
 * Chipaca hugs Odd_Bloke 
 * mvo hugs Odd_Bloke as well
<Chipaca> mvo: if you can do it, i'll review it
<mvo> Chipaca: thanks! lets catchup on c-n-f tomorrow morning, sorry that I did not managed today, but it looks like the default content provider is sorted, so that is good
<mvo> Chipaca: sure think
<Chipaca> mvo: my git is very messy right now
<Chipaca> and the sort of messy that doesn't stash well
<Chipaca> (added and removed files)
<mvo> Chipaca: eh, actually - I think there is a reason! sorry, we used to have the _FROM_TIMER=1 and then changed it to the emergency timer. so the check in the code is really there to prevent us running in case of an old .service file/timer file being around (hope that makes sense)
<Chipaca> mvo: but there's nothing that triggers from the emergency timer
<Chipaca> i mean, setting that env var does nothing
<Chipaca> or am i missing something?
<Chipaca> (as it is the systemd timer is firing and people are seeing "manual" refreshes triggered by it)
<Chipaca> mvo: https://forum.snapcraft.io/t/refresh-vs-auto-refresh-in-snap-changes-output/4145
<pedronis> Chipaca: afaik  "refreshed"  in snap info  is the time of revision mount directory
<Chipaca> pedronis: it's the mtime of the mount dir
<Chipaca> pedronis: i.e. the mtime of the squash root
<Chipaca> code is in daemon/snap.go:57, func snapDate
<Chipaca> 	st, err := os.Stat(info.MountDir())
<Chipaca> and then ModTime of that
 * Chipaca greps the logs
<Chipaca> mvo: so... it seems we had FROM_TIMER in the systemd files in debian, and FROM_EMERGENCY_TIMER in the ones in data, and at some point we dropped the ones in debian for the ones in data, but there never was code to handle the FROM_EMERGENCY_TIMER
<Chipaca> the FROM_TIMER was there so that a new snapd (with internal timer) would ignore the systemd timer
<Chipaca> whereas the FROM_EMERGENCY_TIMER I think the idea was that snapd would check how long it'd been since it refreshed?
<Chipaca> but we never did that code afaict
<Chipaca> not sure Â¯\_(ã)_/Â¯
<Chipaca> ah, the note on on the emergency one is that it'd just run a manual refresh once a week
<Chipaca> ehhhhhh
<pedronis> Chipaca: IÂ suppose /snap/*/current mtime would be a better estimate of when it was refreshed, right?
<Chipaca> pedronis: I love the current value
<Chipaca> it tells you when the snap was created
<Chipaca> (assuming sane system times where it was created, but hey)
<Chipaca> maybe we should validate it though :-)
 * Chipaca seems to be thinking a lot about validation
<Chipaca> jdstrand: do we check the times in the squash at all?
<pedronis> Chipaca: yes, but IÂ have been asked for other reasons, about the time the snap was refreshed
<pedronis> on the system
<Chipaca> right, for that, get the mtime of /var/lib/snapd/snaps/<yoursnap>
<pedronis> Chipaca: that emergency timer behavior seeems bad
<Chipaca> pedronis: bd946e43a477b054b6ea944497998faa4a709442
<Chipaca> (there's a followup that s/RY/CY/)
<Chipaca> pedronis: that's the explanation for the current behaviour
<pedronis> ?
<Chipaca> the ignoring of FROM_TIMER is because if you have FROM_TIMER you're on an older systemd unit which runs too often
<Chipaca> so that's ignored completely
<pedronis> I thought EMERGENCY was for repairs
<pedronis> not refresh
<Chipaca> this predates repairs by a lot, i think
<Chipaca> pedronis: ah, by  bd946e43a477b054b6ea944497998faa4a709442  i meant 'git show bd946e43a477b054b6ea944497998faa4a709442'
<Chipaca> pedronis: this is literally so if <random event> happens and the refresh timer never fires, _something_ kicks the system to refresh so we can fix it
<pedronis> Chipaca: that behavior is wrong now that we have monthly schedules
<jdstrand> Chipaca: not for reasonableness. we do for complete grossness (ie, if unsquasfs -lls matches "date_pat = re.compile(r'^\d\d\d\d-\d\d-\d\d$')" and "time_pat = re.compile(r'^\d\d:\d\d$')"
<jdstrand> Chipaca: is there something you are thinking about? this is kinda tricky for arbitrary files in the system
<jdstrand> s/system/snap/
<Chipaca> jdstrand: not sure if you saw, but we were talking about how we report the mtime of the root of the squash as the time the snap was â¦ updated? (currently we say refreshed, which is wrong)
<jdstrand> I didn't see that
<pedronis> Chipaca: we shouldn't trigger a random weekly one, if the schedule is monthly
<jdstrand> Chipaca: it might be better to look at the superblock
<Chipaca> jdstrand: how so?
<jdstrand> this is what the review tools do: extract the fstime from the superblock then feed that back in for the resquash
<Chipaca> (and, how? :-) but i can google that)
<Chipaca> pedronis: we should make a note about it at least
<Chipaca> pedronis: 'system administrators that wish to have refreshes >1week should also adjust yadda yadda'
<pedronis> Chipaca: or we convey the env var along the api request
<pedronis> and check something in snapd itself
<jdstrand> Chipaca: the why is cause it seems plausible that someone might have a dir tree up, never remove it and tickle files inside, so squashfs-root doesn't change (does mksquashfs update it? I don't know)
<Chipaca> pedronis: I'd favour that tbh
<pedronis> sounds like we need a note somewhere
<pedronis> Chipaca: can you add something here:  https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239 perhaps ?
<jdstrand> Chipaca: right, sBlk.s.mkfs_time. here is a patch I did for squashfs-tools for extracting that: http://launchpadlibrarian.net/242328684/squashfs-tools_1%3A4.2+20130409-2_1%3A4.2+20130409-2ubuntu0.14.04.1.diff.gz
<jdstrand> perhaps mksquashfs updates squashfs-root times whenever it is created
<jdstrand> that's easy enough to check
<Chipaca> jdstrand: i can confirm the root timestamp doesn't change unless something in it contains directly changes
<jdstrand> ok
<Chipaca> IOW mksquashfs preserves the filesystem timestamp
<Chipaca> wait, let me double-check the flags we use
<jdstrand> Chipaca: so, mksquashfs is is going to update the mkfs_time on each run
<jdstrand> Chipaca: so you don't have to worry about squashfs-root
<Chipaca> a'ight
<Chipaca> I'll fix this at some point
<jdstrand> I mean, someone could game that, but what does it gain them? buggy freshness?
<jdstrand> so I think mkfs_time is going to be most robust
<jdstrand> (even if it can be gamed)
<Chipaca> pedronis: https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/18
<Chipaca> jdstrand: okie doke
<Chipaca> not for the first time I find myself thinking of writing a squashfs parser in go
<jdstrand> heh
<Chipaca> jdstrand: that patch isn't upstream, is it?
<jdstrand> it shouldn't be *terrible* to extract the super block...
<pedronis> Chipaca: thank you
<jdstrand> Chipaca: in squashfs-tools? no
<Chipaca> ah well
<Chipaca> i should have a way to ask the kernel for this
<Chipaca> huh, "file" knows how to find it
<jdstrand> Chipaca: $ unsquashfs -s /path/to/snap
<jdstrand> Creation or last append time Fri Feb  2 19:23:56 2018
<Chipaca> aww, that's a lot easier than figuring out what '>>>40   bequad x'  means
 * Chipaca hugs jdstrand 
 * jdstrand hugs Chipaca :)
<pedronis> Chipaca: "file" knows a lot of things
<jdstrand> it does
<jdstrand> it also occasionally has bugs
<Chipaca> every time I'm tempted to look at its sourcecode I'm amazed it works so consistently well
<jdstrand> I can't remember otoh, but I feel like it had to do with the review-tools and file behaving differently on 14.04 and 16.04+
<jdstrand> I could be making that up. I know I was annoyed with file once though
<jdstrand> oh yeah, it's great
<Chipaca> mvo: you'll be pleased to hear that "unsquashfs -s" does report errors with an exit code different from zero
<jdstrand> I was just thinking through if you used file, you'd probably want to use the one from the core snap rather than the system
<Chipaca> I don't think there's a file in the core snap
<jdstrand> all the more reason to use unsquashfs :)
<Chipaca> ooh, yes there is a file in the core snap
<Chipaca> oh wait this one is classic
 * Chipaca backpedals
<pedronis> I'm not finding it
<jdstrand> and yes, isn't unsquashfs annoying in that it returns 0 when it seems pretty clear it shouldn't?
<Chipaca> there's no file in the core snap :-)
<jdstrand> glad -s is reasonable
<Chipaca> jdstrand: we have a bug about that, and a patch upstream, thanks to mvo
<pedronis> no "file"Â in core
<jdstrand> Chipaca: I actually wonder how the world will break if that patch is applied
<pedronis> there is "fold"Â though
<jdstrand> Tyler came across it (might be what prompted mvo to submit the patch) and we were uneasy about it
<Chipaca> jdstrand: the workaround we're using is grepping the output of unsquashfs for the error strings (fortunately they're consistent) (unfortunately, nobody can ever have a file named like one of their error messages)
<pedronis> and "factor"
 * pedronis stops
<jdstrand> Chipaca: hehe, yes
<jdstrand> pedronis: I don't know what we would do if 'factor' was removed from core! oh noes! :)
<pedronis> I mostly wonder what depends on it to be there
<jdstrand> it comes from coreutils
<pedronis> I suspect so
<pedronis> still wonder why it's a "core"util :)
<jdstrand> heh, well, the googles may have your answer ;)
<Chipaca> jdstrand: https://github.com/plougher/squashfs-tools/pull/46 fwiw
<mup> PR plougher/squashfs-tools#46: unsquashfs: return exit 1 if writing fails for some reason <Created by mvo5> <https://github.com/plougher/squashfs-tools/pull/46>
<jdstrand> roadmr: can you pull r1004 of the review tools? just some new/updated checks
<jdstrand> Chipaca: thanks. fyi, ^ that has the pkgversion update
<Chipaca> jdstrand: cheers
<Chipaca> jdstrand: next up, I'll be rejecting snap descriptions that aren't valid markdown
 * Chipaca runs
<jdstrand> heh
<Chipaca> (i don't think there's "invalid markdown")
<pedronis> "doesn't look right"Â markdown
<pedronis> so we can add ML to our stack :)
<Chipaca> snap rejection reason: poor phrasing in snap description
<Chipaca> of _course_ unsquashfs doesn't know about locales
<roadmr> jdstrand: sure thing, I'll get an MP for that rolling
<jdstrand> roadmr: thanks!
<tyhicks> huh, I didn't realize that there was a squashfs-tools github project
<Chipaca> so, what's a better label for 'refreshed' in 'snap info'?
 * Chipaca should probably ask in the forum
<pedronis> it's reall "built" no?
<pedronis> but that will be confusing in context
<pedronis> Chipaca: or we could keep refreshed but give the  /var/lib/snapd/snaps/snap.snap time
<pedronis> Chipaca: notice that internally is called InstalledDate so that is worse
<Chipaca> pedronis: https://forum.snapcraft.io/t/better-field-name-for-refreshed-in-snap-info-output/4150
<Chipaca> I think at some point it started looking at the wrong thing, and the tests didn't catch it
<Chipaca> (as i say in that post)
<Chipaca> because, ye, between it being InstallDate in the api, and refreshed in info, ye
<pedronis> IÂ think the api value is wrong
<Chipaca> anyhow. i should stop, go grab me some curry, and then â¦ dunno, more hacking probably
<pedronis> given the api field name
<Chipaca> pedronis: exactly
<Chipaca> pedronis: but i also like that value
<pedronis> we can have a different field with the value you like :)
<Chipaca> exactly!
<Chipaca> that's what the forum post is about, i think
<Chipaca> title might be wrong tho
 * Chipaca might get used to calling it organolepcy
 * Chipaca -> really curry
<jdstrand> tyhicks, mvo: can you update me on the status of the seccomp EPERM status?
<jdstrand> tyhicks, mvo: still see new setpriority and chown questions in the forum
<tyhicks> jdstrand: AFAIK, this cross-distro issue is still the blocker: https://github.com/snapcore/snapd/pull/3998/#issuecomment-358028579
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<tyhicks> jdstrand, mvo: I think we could split that PR up and land the SECCOMP_RET_KILL -> SECCOMP_RET_ERRNO(EPERM) strict mode change separately from the SECCOMP_RET_LOG dev mode change if that helps
<mup> PR snapcraft#1949 opened: repo: silence deb caching when fetching packages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1949>
<zyga_> tyhicks I think this would be welcome by developers
<jdstrand> well
<jdstrand> not if they have a denial, cause it would eperm with no logging
<zyga> I think those that learned would like that denial to go away now :)
<jdstrand> I mean, if its discussed and that is deemed less worse than the current situation, it is an option
<zyga> err, the kill to go away
<jdstrand> I mean, it is a problem, that is why the PR is there
<tyhicks> jdstrand: I think you're getting the two things slightly mixed up
<jdstrand> by requiring to strace an unlogged eperm is pretty bad imho
<tyhicks> SECCOMP_RET_LOG isn't needed for the SECCOMP_RET_KILL -> SECCOMP_RET_ERRNO(EPERM) strict mode change
<jdstrand> tyhicks: I know it isn't required from a technical perspective
<jdstrand> tyhicks: but if we only do eperm, we lose logging, no?
<jdstrand> I mean, that is why the pr is the way it is :)
<tyhicks> if we switch to EPERM, the kernel needs to support the SECCOMP_FILTER_FLAG_LOG filter attribute or EPERM will not be logged
<mup> PR snapd#4725 opened: tests: avoid removing preinstalled snaps on core <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/4725>
<jdstrand> I'm saying *if* we do that, it is a differently bad experience
<jdstrand> tyhicks: right... and you need the golang changes for SECCOMP_FILTER_FLAG_LOG
<zyga> and there is no upstream release still AFAIR
<jdstrand> zyga: there isn't, I just checked. it hasn't moved since Jan 16
<tyhicks> jdstrand: no, we don't need golang changes for SECCOMP_FILTER_FLAG_LOG because snap-confine sets that flag in the seccomp() syscall when it loads the filter
<jdstrand> tyhicks: or am I not remembering right?
<zyga> tyhicks where is SECCOMP_FILTER_FLAG_LOAD passed to? prctl?
<tyhicks> zyga: seccomp(2), when that syscall is available
<tyhicks> it falls back to prctl(), without SECCOMP_FILTER_FLAG_LOAD, when seccomp() isn't available
<zyga> I see
<tyhicks> prctl() doesn't let us specify filter flags
<jdstrand> tyhicks: ok, so SECCOMP_FILTER_FLAG_LOG is only used by golang to query if it is available?
<jdstrand> in the kernel?
<tyhicks> jdstrand: right now, we're not querying the kernel to see if SECCOMP_FILTER_FLAG_LOG is supported by the kernel when snapd is constructing the filters
<tyhicks> jdstrand: I thought we determined that wasn't needed
<jdstrand> tyhicks: ok, I've lost too much context apparently. what is the golang change needed for?
<tyhicks> jdstrand: snapd could call a small piece of C code that determines if SECCOMP_FILTER_FLAG_LOG is supported by the kernel and either use SECCOMP_RET_KILL or SECCOMP_RET_ERRNO(EPERM)
<mup> PR snapcraft#1950 opened: elf: better debug messages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1950>
<tyhicks> jdstrand: the golang change is needed for snapd to be able to construct a filter with SECCOMP_RET_LOG for dev mode snaps
<jdstrand> right
<jdstrand> so, today, we could drop that and devmode snaps operate the same
<tyhicks> yes
<jdstrand> I would be in favor of splitting it then
<jdstrand> unless someone can do the runtime detection
<jdstrand> tyhicks: can you suggest in the PR that it could be split?
<jdstrand> tyhicks: thanks for bringing me up to speed (again) :)
<tyhicks> jdstrand: yes
<tyhicks> jdstrand: do you want to revisit our previous decision to not fall back to SECCOMP_RET_KILL even if SECCOMP_FILTER_FLAG_LOG is not supported?
<jdstrand> it hard to keep all the context in your head when you visit something only monthly :p
<tyhicks> jdstrand: it sounded like you weren't liking the idea of returning quietly returning ERRNO when the kernel doesn't support SECCOMP_FILTER_FLAG_LOG
<tyhicks> s/returning quietly returning/quietly returning/
<jdstrand> tyhicks: no, we don't need to revisit imo. most distros that have strict mode should pick up the kernel change. we can even communicate that outward in the release notes of the snapd version that changes this that distros can pull the patches to get the logging back
<jdstrand> tyhicks: I didn't for everyone
<jdstrand> tyhicks: if we can get the top strict distros to patch, then I think its ok
<tyhicks> ok
<jdstrand> tyhicks: you did say the Ubuntu kernels have this support, right?
<jdstrand> or am I misremembering that too? :)
<tyhicks> jdstrand: yes, for months and months now
<jdstrand> right
<jdstrand> ok
<jdstrand> yes, then I think not falling back to KILL is less of a big deal. we release note it. Ubuntu and (most of) its derivatives just work. solus would probably just snag the patch
<jdstrand> if it proves to be an issue, we can patch snap-confine
<tyhicks> I don't really understand why we define our own golang seccomp actions here: https://github.com/snapcore/snapd/pull/3998/files#diff-52db82d188e96fd9798675f0e17850faL382
<mup> PR #3998: snap-confine, snap-seccomp: utilize new seccomp logging features <Decaying> <Created by tyhicks> <https://github.com/snapcore/snapd/pull/3998>
<tyhicks> and then use libseccomp-golang's here: https://github.com/snapcore/snapd/pull/3998/files#diff-52db82d188e96fd9798675f0e17850faR634
<tyhicks> I followed the lead of the existing code that I was changing in that regard but we could probably be smarter about that and not hit the cross-distro problem
<tyhicks> (and not have to split up the PR)
<tyhicks> I'll leave the requested comments and then think about that some more
<jdstrand> tyhicks: interesting. it might be for the testsuite. mvo would have more context
<Aelius> hello! I just found snap
<Aelius> if it requires sudo to install a package, then I assume the self updating feature won't work? (that is, unless I sign up for an ubuntu one account)
<Aelius> also,is there a way to browse the online repository without searching?
<nacc> Aelius: your first question doesn't make sense
<nacc> Aelius: afaik, all snaps require sudo to install
<nacc> Aelius: and all snaps autoupdate by default
<Aelius> nacc: the docs tell me that sudo is not required if I log in with an ubuntu one account. you log in with sudo, and I guess it caches your credentials
<nacc> Aelius: which docs?
<Aelius> https://docs.snapcraft.io/core/usage
<Aelius> > When you are not logged in, most snap commands will require you to run them as root.
<diddledan> Aelius: snapd runs as root, so refreshing installed snaps is already privileged. snap login lets you assign your user account which allows you to snap install without sudo
<pedronis> for public snaps  there's no need for store credentials to update them, auto update works also for the one installed with sudo
<Aelius> ok, good
<Chipaca> Aelius: also, you shouldn't need sudo anyway
<Chipaca> you'll just get a polkit dialog
<diddledan> that too
<Aelius> I am on archlinux- this dialog doesn't seem to be implemented here
<Chipaca> Aelius: it being arch, i guess it's up to you to have polkit installed and configured and everything?
<Aelius> probably. I believe I installed it for the sole purpose of being able to use `reboot` without sudo
<Aelius> but havent touchhed it otherwise
<Chipaca> Aelius: if so maybe you need to copy the policy files
<Chipaca> anyway, i personally prefer sudo :-)
<Aelius> yeah sudo is fine
<Chipaca> Aelius: OTOH if you're creating snaps, you'll want to log in anyway
<Chipaca> (as snapd can then let you get arbitrary revisions of your snaps, and/or private snaps)
<cachio_> zyga, which driver is ok for the nvidia
<cachio_> machine
<cachio_> the nouveau is ok?
<zyga> no
<cachio_> or has to be the once from nvidea
<zyga> cachio_ the test must use proprietary driver
<zyga> ideally the non-legacy
<zyga> (depending on hardware version)
<cachio_> zyga, ok, I'll try now with nvidia-390
<cachio_> for xenial
<cachio_> and see
<zyga> perfect
<zyga> try all of spread suite
<cachio_> zyga, yes
<Saviq> niemeyer: do you know if 17.10 images went away for good from linode ?? https://www.linode.com/distributions
<Saviq> our CI is failing, missing ubuntu-17.10 images
#snappy 2018-02-23
<mborzecki> morning
<mup> PR snapd#4726 opened: [2.31] systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4726>
<mborzecki> mvo: morning
<mvo> hey mborzecki, good morning
<mvo> mborzecki: thanks for opening this pr!
<mborzecki> mvo: do we have any idication that we'll be doing another point release?
<zyga> good morning
<mvo> hey zyga, good morning
<mborzecki> zyga:hey
<zyga> hey guys
<zyga> mvo did the release happen
<zyga> there were some issues last night
<mvo> zyga: yeah, it happened but according to bret they use phased updates to push it out
<zyga> mvo +1 to merge 4724
<zyga> mvo ah, good, I stopped following at around midnight
<mborzecki> btw. i was browsing archlinxu forum the other day, and noticed this: https://bbs.archlinux.org/viewtopic.php?id=234301 apparently thre's a problem installing snaps when behind a firewall
<mborzecki> i think we could set HTTP_PROXY in /etc/environment (or an equivalent) but that would be inconvenient if you change networks, eg. there's a need for a proxy on one network but not on another
<mvo> mborzecki: hm, yeah, so I think one fix would be that snap (the client) passes the clients proxy env to snapd and snapd uses that. should be simple
<zyga> mvo I think the way this is handled in real networks is different
<mvo> mborzecki: iirc I talked to gustavo about it but he did not like it, but I don't remember why
<zyga> mvo there's a function to call for each URL that gives you proxy data
<mvo> zyga: thats how libproxy will do it
<zyga> (or information not to proxy)
<zyga> exactly
<zyga> so depending on how far we are willing to go with it
<mvo> tricky for us to do because of the snapd daemon restriction
<zyga> I think it's still a bit simplistic as in corporations the auth is integrated but at least it is better than all-or-nothing
<mborzecki> looked through stdlib source code, and it seems that HTTP_PROXY is supported
<mvo> mborzecki: yes, but snapd will only read it from /etc/environment
<mvo> there is a forum discussion but unfortunately inconclusive
<mborzecki> uhh right, i meant i used that as indication that net/http can do proxy
<mvo> aha, yes :)
<mvo> https://forum.snapcraft.io/t/improve-proxy-configuration-for-snapd/942 fwiw
<mborzecki> heh, all this proxy stuff is actually a bit awkward to me, i'm used to this being handled transparently by whatever trickery cisco or netgear employed
<mborzecki> can #4719 be merged?
<mup> PR #4719: timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4719>
<mvo> mborzecki: how is the autostart going? anything interesting new here?
<mup> PR snapd#4719 closed: timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4719>
<mborzecki> mvo: trying to finish with timer services first, maybe i'll look into autostart a bit later today
<mvo> mborzecki: yeah, timers are more important. thank you
<mborzecki> linode:ubuntu-14.04-64:tests/main/refresh-all-undo failed again https://paste.ubuntu.com/p/wGwqr8MDSp/
<pstolowski> heyas!
<mvo> hey pstolowski ! good morning
<zyga> hey :)
<mvo> pstolowski: thanks for your review, I love the attrer stuff, much nicer than the naked map access
<pstolowski> mvo, cool!
<mborzecki> pstolowski: hey
<pstolowski> #4716 anyone? it's trivial
<mup> PR #4716: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <https://github.com/snapcore/snapd/pull/4716>
<mvo> pstolowski: looking
<pstolowski> mvo, ty!
<mup> PR snapd#4716 closed: tests: make sure snapd is running before attempting to remove leftover snaps <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4716>
<zyga> mvo can I land 4724
<zyga> it's just a trivial preparation for upcoming cleanup
<kalikiana> good morning
<zyga> hey kalikiana
<mup> PR core#81 closed: 14-set-motd.chroot: updated based on the suggestions from Mark <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/core/pull/81>
<mup> PR snapd#4726 closed: [2.31] systemd, wrappers: start all snap services in one systemctl call <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4726>
<zyga> thanks mvo!
<mup> PR snapd#4724 closed: osutil: aggregate mockable symbols <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4724>
<zyga> hmm I think chipaca already mentioned this before
<zyga> but I'm getting this
<zyga> advisor/backend.go:199: literal copies lock value from *db: github.com/snapcore/snapd/vendor/github.com/snapcore/bolt.DB contains sync.Pool contains sync.noCopy
<mvo> pstolowski: do you think we can get the limited reader into 2.32? would be nice to have that fix
<mvo> pstolowski: is the status that it just needs a re-review?
<pstolowski> mvo, yes, it needs re-review from Gustavo, but I applied the snippet he suggested (with only minor change), so perhaps you can make a call
<mvo> pstolowski: thanks, this now looks very nice, I think its uncontroversial
<mup> PR snapd#4584 closed: hooks/strutil: limit the number of data read from the hooks to avoid oom <Created by stolowski> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4584>
<pstolowski> \o/
<pstolowski> mvo, shall I cherry-pick it and prepare a PR?
<mup> PR snapd#4727 opened: many: simplify mocking of home-on-NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4727>
<zyga> mvo this is a mostly red follow up I was talking about
<zyga> this should also help with one of jdstrand's branches that adds overlayfs data to system key
<mvo> zyga: my understanding is that 4140 just needs the rename and then things are ok? if so, sounds like something worth doing for 2.32 - wdyt?
<mvo> zyga: it has +1 from jamie and you already and gustavo only objected the name afaict
<zyga> yes, I agree
<zyga> I can handle that if you want
<zyga> ok, I'll carry on with mount business
<mvo> zyga: either way is fine
<pedronis> mvo: hi,  how are things? when will we cut 2.32 ?
<mvo> pedronis: once tests are green for the default-provider PR, looks like the store is a bit unhappy currently, but maybe it fixed itself
<mvo> pedronis: anything you want in there?
<pedronis> mvo: no, mostly wondering about my reorg/refactor PR that are green, whether IÂ should hold them for post 2.32
<pedronis> or not
<pedronis> mvo:Â you can look,  #4715  #4722
<mup> PR #4715: store: reorg auth refresh <Created by pedronis> <https://github.com/snapcore/snapd/pull/4715>
<mup> PR #4722: store: cleanup test naming, dropping remoteRepo  and UbuntuStore(Repository)? references <Created by pedronis> <https://github.com/snapcore/snapd/pull/4722>
<mvo> pedronis: holding it for a little bit would be great
<mup> PR snapd#4728 opened: store: move infoFromRemote into details.go close to snapDetails <Created by pedronis> <https://github.com/snapcore/snapd/pull/4728>
<Chipaca> mo'in peeps
<mvo> hey Chipaca ! good morning
<pedronis> Chipaca: hi, if IÂ understood the discussion yesterday, this would make refreshed/InstalledDate report a value closer to the intention:  https://pastebin.ubuntu.com/p/4G8TDSQFsr/
<pedronis> ?
<pedronis> as you said with that change no test fails, at least in daemon
<pedronis> :/
<mvo> jdstrand: I was renaming the gnome-online-accounts-service to accounts-services as requested by gustavo. it looks like the store (basedeclartion) and review tools need an update (store is rejecting my test snap right now)
<mvo> zyga: do you know if it is safe to just override this via manual review -^
<zyga> mvo I don't know if it is safe but I suspect that's what manual review is for
<Chipaca> pedronis: I've got a branch already on spread for this
<Chipaca> pedronis: and, well, close
<Chipaca> pedronis: that'd work for squashes
<Chipaca> pedronis: for it to work for everything you'd want it to be Lstat
<Chipaca> my branch does that, but â¦ then it takes a stand :-)
<pstolowski> any known issue with lxd today? got 2 failures https://api.travis-ci.org/v3/job/345155633/log.txt
<pedronis> Chipaca: anyway probably time to move this to methods on snap.Info I think
<pedronis> whatever the stand
<pedronis> Chipaca: I'm mostly interested in installedDate for snaps from the store
<pedronis> fwiw
<Chipaca> pedronis: I think you'll like my PR
<zyga> pstolowski look at this
<zyga> E: Type 'curity' is not known on line 50 in source list /etc/apt/sources.list
<Chipaca> mborzecki: why do you sometimes ask 'merge?' on PRs that are green and have two +1s?
<zyga> "security" became "curity"
<mborzecki> Chipaca: ahh, cause there's +1 with some comments, so just double checking that the changes i pushed are ok for those who reviewed
<pstolowski> zyga, missed that, thanks. interesting
<Chipaca> mborzecki: for myself, if I've +1'ed it with nits, it's because (a) i won't block the landing even if you don't fix them, and (b) i trust you to fix them; also (c) i'll shout if you mess it up and (d) git reset --hard @^^^^^
<mborzecki> hahah ok :)
<pstolowski> zyga, that's inside the container, i don't think we generate sources.list do we?
<zyga> I don't know
<mup> PR snapd#4103 closed: snapstate: auto install default-providers for content snaps <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4103>
<mup> PR snapd#4677 closed: cmd/snap: introduce `snap run --timer` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4677>
<mup> PR snapd#4680 closed: snap: pass full timer spec in `snap run --timer` <Created by bboozzoo> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/4680>
<mup> PR snapd#4729 opened: many: drop snaps' InstallDate, introduce Updated <Created by chipaca> <https://github.com/snapcore/snapd/pull/4729>
<Chipaca> pedronis: ^_^
<mborzecki> zyga: pstolowski: can you take another look at #4695 ?
<mup> PR #4695: wrappers: generator for systemd OnCalendar schedules <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4695>
<pedronis> Chipaca: I have bad news for you
<Chipaca> pedronis: is it about potato fungus
<pedronis> Chipaca:  you expect last updated to be the creation time of the revision?
<pedronis> on the store
<Chipaca> pedronis: it â¦ seemed to be; isn't it?
<pedronis> IÂ don't know
<Chipaca> pedronis: bah, I guess it might be the creation time of the last revision, which might not be the one being pointed at?
<pedronis> bu that's what the new api has
<Chipaca> pedronis: that == creation time of the revision?
<Chipaca> that's perfect :-)
<pedronis> yes, but for the new api
<Chipaca> right
<pedronis> the old I don't know
<pedronis> I can check
<pstolowski> mborzecki, sure
<pedronis> just that this value might be a bit confusing for remote for a bit
<Chipaca> pedronis: please check (no rush); depending on what it is, the confusion might not be terrible
<Chipaca> for example if it's the timestamp of the latest revision, i don't mind
<Chipaca> if it's the timestamp of the last time you changed something via the web, i do mind :-)
<pedronis> Chipaca: no, it's the timestamp of the creation of the revision under consideration also for the old api
<pedronis> at least as server by modern infra
 * Chipaca dances
<pedronis> (it might have been something else at some point in the past)
<pedronis> Chipaca: your PR and my last PR will conflict :/
<Chipaca> pedronis: I don't mind deconflicting
<Chipaca> pedronis: hurry up and land it :-D
<Chipaca> mine is small (if spread out)
<pedronis> mvo told me to wait
<pedronis> anyway IÂ need reviews, but is trivial:  #4728
<mup> PR #4728: store: move infoFromRemote into details.go close to snapDetails <Created by pedronis> <https://github.com/snapcore/snapd/pull/4728>
<Chipaca> psh, who listens to mvo
<Chipaca> pedronis: conflict! :-)
<pedronis> not on that PR
<pedronis> I suppose on the based one
<pedronis> or maybe yes
<pedronis> ah, conflict with mvo stuff
<pedronis> I'll have fun for a bit I fear
<pedronis> mmh, not, it's really only this one
<pedronis> I'll just wait at this point
<Chipaca> I could stack mine on yours
<Chipaca> that'd make it a fun review for people
<Chipaca> I hear they really like wading through huge changes
<pedronis> Chipaca: my in progress new api stuff is +-3000 lines  (I will split it,  but a chunk will still be +1000 mostly tests)
<Chipaca> I shall endeavour to nitpick it to death in detail
<mborzecki> prereqSuite.TestDoPrereqRetryWhenBaseInFlight failed on master https://paste.ubuntu.com/p/qwbkSCGm3K/
<mborzecki> i've restarted the travis build, see if reproduces again
<zyga> I saw a few failures related to store hicckups todaty
<zyga> *today
<zyga> but nothing major
<zyga> (just annoying)
<Chipaca> fatal: unable to access 'https://go.googlesource.com/crypto/': The requested URL returned error: 502
<Chipaca> if that's any consolation, I've got a failure related to google hiccup
<pedronis> Chipaca: couple of initial small comments
<Chipaca> pedronis: I'm not sure my 'open question' is clear: I thought of having it show "updated" (or even "last-updated") for remotes, but that leaves locals with "refreshed" which IMHO isn't ideal either
<pedronis> update is strange for remotes
<pedronis> let me think
 * Chipaca lets pedronis think, and goes off to physio
<pedronis> Chipaca: I don't think we want to print something for remotes
<pedronis> we would want dates in the channel
<pedronis> s
<pedronis> we don't print a top revision either
<pedronis> for remote infos
<pedronis> it's a bit strange to put a date there without the revision
<pedronis> Chipaca: are you seeing what I'm referring to?
<Chipaca> I think we do want dates in the map, yes
<pedronis> I'm saying if you put a date at top-level
<Chipaca> the confusing munge of revisioned and revisionless info in the store results is confusing, yes
<pedronis> is very unclear what it refers to
<pedronis> unless you mention the channel
<zyga> Chipaca on your way, can you look at the idea behind https://github.com/snapcore/snapd/pull/4727
<mup> PR #4727: many: simplify mocking of home-on-NFS <Created by zyga> <https://github.com/snapcore/snapd/pull/4727>
<Chipaca> but I do think having it is valuable, as long as it refers to what the user gets when they just ask for the snap without qualifying it
<Chipaca> (which is, i think, what it does)
<zyga> just mocking the function instead of what the function depends on
<pedronis> Chipaca: last-stable-updated ?
<pedronis> I just fear whatever we do right now, we will regret/have to change it again
<pedronis> Chipaca: or you could think how you want dates in the channels,  and start putting in only the one for stable?
<Chipaca> that'd work rather well actually
<Chipaca> bah
<Chipaca> sorta-kinda
<pedronis> but also IÂ don't know
<pedronis> how to add a date
<pedronis> there
<pedronis> without thinking as breaking format
<Chipaca> pedronis: note I try to use the exact same layout for 'installed:' as I do for channels
<Chipaca> but it'd be weird for that to change when you installed the snap
<Chipaca> hmmmm
<pedronis> yes, it's a bit the problem IÂ mentioned, it is strange to use one field for a value that is available remotely
<pedronis> but turns into a different value locally
<Chipaca> pedronis: how about, for local snaps just leave it as 'refreshed', and for remotes just add the one for the latest stable as a comment to channels
<pedronis> might be ok
<Chipaca> ie: channels:        # latest stable from YYYY-mm-ddTHH:MM:SSZZZ
<pedronis> ah
<pedronis> like that
 * pedronis was confusing notes and comments
<Chipaca> pedronis: do you think 'updated' is ok in the api?
<pedronis> it's getting a baroque
 * Chipaca prefers the term 'neo-rococo'
<pedronis> :)
<pedronis> Chipaca: my question is whether we want different fields for local vs remote
<pedronis> that's annoying in different ways though
<Chipaca> I mean, if we're going for full clarity we'd go with "last-stable-revision-created-on" and "snap-downloaded-on" and "try-created-on"
<Chipaca> Â¯\_(ã)_/Â¯
<zyga> 4th failure on trivial PR :/
<zyga> oh, this time racy unit tests
<zyga> FAIL: handlers_prereq_test.go:155: prereqSuite.TestDoPrereqRetryWhenBaseInFlight
<zyga> handlers_prereq_test.go:186:
<zyga>     // check that t is not done yet, it must wait for core
<zyga>     c.Check(t.Status(), Equals, state.DoingStatus)
<zyga> ... obtained state.Status = 4 ("Done")
<zyga> ... expected state.Status = 3 ("Doing")
<mborzecki> ok, so it's only me seeing this
<mborzecki> reproducible locally
<ogra_> mvo, pedronis https://forum.snapcraft.io/t/using-content-for-a-role-system-data-partition-makes-it-not-be-system-data-anymore
<pedronis> sounds a ubuntu-image issue
<pedronis> IÂ don't think prepare-image deals at level
<mvo> mborzecki: uh, that race looks like I caused it. sorry for this
<pedronis> *at that level
<mborzecki> mvo: are you looking into it or should i?
<mvo> mborzecki: I am not looking right now, need to prepare lunch in a wee bit :(
<mborzecki> mvo: ok, i'll take a look then
<zyga> mborzecki I'm not looking either, sorry
<mvo> mborzecki: thank you! if you get stuck let me know
<mup> PR snapd#4730 opened: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE <Created by stolowski> <https://github.com/snapcore/snapd/pull/4730>
<pstolowski> mvo, can you take a look at #4730 ^ ?
<mup> PR #4730: userd/tests: Test kdialog calls and mock kdialog too to make tests work in KDE <Created by stolowski> <https://github.com/snapcore/snapd/pull/4730>
<pstolowski> we fail on KDE currently :}
<zyga> sigh
<zyga> (not about kde)
<zyga> gaaah
<pstolowski> mvo, the prereq unit test seems to be flaky
<pstolowski> mvo, https://pastebin.ubuntu.com/p/k5MpksjvrN/
<zyga> so
<pstolowski> mvo, (this is from master)
<zyga> I now feel I need to implement a little bit of path traversing, mount table traversing logic in userspace
<pstolowski> mvo, also got this failure in travis a moment ago on my pr - https://api.travis-ci.org/v3/job/345185500/log.txt
<zyga> the simple check grew a little bit that I started to write prose comment that barely fits on my 27" screen :/
<zyga> pstolowski mborzecki ran into it too
<zyga> (and me too)
<pstolowski> zyga, ah indeed, just looked at the backlog
<mborzecki> pstolowski: i'm looking into it atm
<pstolowski> mborzecki, great, thanks
<zyga> jdstrand I'm a bit depressed again :)
<zyga> about that mount verification
<zyga> it's one notch harder than I thought yesterday
<zyga> and that's with constraints I don't know if are reasonable (not a generic solution for sure)
<zyga> this is all because there's no frelling MS_NOFOLLOW in mount
 * cachio_ afk
<mborzecki> ok, so here's a small problem with that test, it assumes that tasks are run in the runner in a specific order, however the runner takes the list of tasks to run by calling State.Tasks(), interlly State.tasks is a map, so when you range the order is not guaranteed, and so it happens that sometimes one task runs before the other
<pstolowski> mborzecki, is there a reason we don't translate mon-fri to mon..fri, but expand all the days? not biggie at all, just curious; i guess it's just more straightforward to always expand?
<mborzecki> pstolowski: yes, easier to expand
<pstolowski> mborzecki, in certain cases we force the order by task.WaitFor(another task)
<pstolowski> mborzecki, ack, that's fine, thanks
<mborzecki> pstolowski: i think the idea in this case is not to use waitfor, but rather detect that a change we need is in flight and retry later
<pstolowski> mborzecki, right, i see that now
<pstolowski> mborzecki, perhaps we need a dummy task that holds link-snap task, then we mark it done in a controlled way, and that unblocks prereq task
<zyga> mborzecki nice analysis
 * pstolowski lunch
<Chipaca> zyga, ondra: bug#1750059 might be of interest to you
<Chipaca> for different reasons
<Chipaca> you know that thing where you plan to replace a bit of hardware because it's getting old, and it immediately starts showing even more signs of old age, as if resenting its replacement? my notebook now chirps when i adjust the brightness
<ondra> Chipaca :)
<ondra> Chipaca thanKs for bug info!
<Chipaca> ondra: integration-y thing with a workaround, thought you'd like to have it on the radar
<pedronis> mborzecki: pstolowski: IÂ think  s.snapmgr.AddAdhocTaskHandler can probably be abused to get a controllable link-snap
<pedronis> for that test
<zyga> Chipaca ack, queued
<mborzecki> pedronis: and return state.Retry{} in the handler?
<pedronis> mborzecki: or wait on a channel before returning
<mborzecki> pedronis: right, i've started adding some mocks to taskrunner, but your suggestion may be better
<zyga> Chipaca interesting
<Chipaca> I wonder if there's a way to tell systemd "this service uses that path"
<pedronis> mborzecki: is just a way to get to call AddTaskHandler again,  that is already there... the latter seems not to worry about overriding. is used in a very controlled way so seems fine as is
<pedronis> sorry AddHandler
<mborzecki> Chipaca: one of the BindsTo or one of it's friends perhaps?
<ogra_> pedronis, so looking through the sources i'm not that sure it is an ubuntu-image issue ... prepare-image unpacks the gadget but does not move the content to the "image" dir ... https://paste.ubuntu.com/p/6MbNxJ6574/
<Chipaca> mborzecki: MagicallyFrobnicatesInto
<Chipaca> mborzecki: somebody should write https://git-man-page-generator.lokaltog.net/ but for systemd directives
<zyga> jdstrand around?
<pedronis> ogra_: afaik the only bit that prepare-image is the bootloader conf, and cloud bits
<pedronis> *prepare-image copies
<ogra_> pedronis, right thats the issue i guess
<ogra_> if i'm allowed to define "content:" in the yaml for the writable partition it should copy that too ...
<pedronis> it does even look at Volumes
<ogra_> ... and if i'm not allowed it should error out and not silently swallow the files
<pedronis> it's a ubuntu-image problem
<pedronis> as far as I understand
<pedronis> content: is definitely a problem of ubuntu-image
<pedronis> we don't even read the gadget.yaml afaict
<pedronis> anyway, mvo may be a better person to discuss this with
<ogra_> k
<zyga> anyone interested in reading a bit of prose about an algorithm I'm writing
<zyga> to spot any logic holes?
<Chipaca> zyga: o/
<mvo> pstolowski: thanks, I will look at the prereq unit test, mborzecki did some analyisis as well
<mvo> ogra_: I have a look at the forum post in a little bit
<zyga> Chipaca https://pastebin.ubuntu.com/p/Jnw6KSHsrj/
<ogra_> mvo, thx
<zyga> Chipaca this will be in a PR sometime after standup, I'm still working on the logic below the comment
<zyga> s/ant/and/
<zyga> (in the text)
<ogra_> btw .. for everyones friday entertainment ... https://github.com/npm/npm/issues/19883
<mborzecki> ogra_: sudo thing?
<ogra_> mborzecki, well, npm thing :)
<ogra_> (randomly changing permissions if it can ... if sudo is used it changes them to the uid of the calling user, not to root ... if you do it as root user everything becomes 777 root:root )
<pstolowski> wow
<pstolowski> havoc
<Chipaca> zyga: is the second column in mountinfo the minor?
<zyga> no
<zyga> parent mount id
<Chipaca> zyga: ah, mount id, parent, major:minor?
<zyga> correct
<Chipaca> zyga: I followed that explanation
<zyga> Chipaca standup :)
<Chipaca> zyga: as an intro it's nice
<Chipaca> zyga: missing chapter 2, the attack, and chapter 3, the narrow escape
<niemeyer> Sorry, running late for the standup
<niemeyer> Will be there in ~2min
<zyga> Chipaca and I should name characters better
<Son_Goku> zyga, did you get a chance to fix the new error from gcc8?
<zyga> Son_Goku no, sorry, I will task switch to that as soon as the standup is over
<zyga> I'm sorry about that, I'll ensure it builds on f27
<jdstrand> mvo: yes, they would. let me look
<zyga_> jdstrand hey :)
<zyga_> jdstrand I will have some things to discuss with you today
<zyga_> one more important than other, let me know when it would be a good time for you
<jdstrand> zyga_: hey, saw your pings
<jdstrand> gimme a little bit (just came online)
<zyga_> sure, no rush :)
<mup> PR snapd#4729 closed: many: drop snaps' InstallDate, introduce Updated <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4729>
<jdstrand> mvo: can you request a manual review of the snap?
 * kalikiana lunch time, omnomnom
<mup> PR snapcraft#1950 closed: elf: better debug messages <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1950>
<ogra_> wow
<ogra_> so my hexchat just stopped working out of the blue ...
<ogra_> ... window greying out being completely unresponsive
<ogra_> (this is the snap )
<jdstrand> zyga_: MS_NOFOLLOW - tell me about it
<ogra_> checking syslog is see:
<ogra_> Feb 23 14:32:46 acheron kernel: [88729.701886] audit: type=1326 audit(1519392766.679:127): auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=8453 comm="hexchat" exe="/snap/hexchat/17/bin/hexchat" sig=31 arch=c000003e syscall=93 compat=0 ip=0x7f11a51c0337 code=0x0
<jdstrand> zyga_: ok, I read backscroll and the paste
<zyga_> jdstrand haha, it's just my wish for a simpler life
<ogra_> jdstrand, how can that happen ^^^... i'm using that snap since over a month without probs
<zyga_> jdstrand so, my main request to you is to look at the pastebin you have to see if the text makes sense
<zyga_> jdstrand my 2nd request is to look at this denial
<zyga_> [13:08:31]  <sparkiegeek>	[341123.064261] audit: type=1400 audit(1519387698.054:1895): apparmor="DENIED" operation="mount" info="failed flags match" error=-13 profile="lxd-snapstore-clean-test_</var/lib/lxd>" name="/tmp/snap.rootfs_XZQtTO/var/lib/snapd/lib/vulkan/" pid=11221 comm="snap-confine" flags="ro, remount"
<jdstrand> ogra_: it took a code path that you never hit before. maybe it rotated a log or something?
<zyga_> this is inside a container on 17.10 (the container is 16.04)
<jdstrand> ogra_: chown strikes again
<zyga_> we can discuss that separately
<jdstrand> ogra_: snapcraft-preload may help. but tyhicks and mvo are discussing the eperm PR trying to come up with how to land it
<zyga_> jdstrand or and just 3rd thing that came up a second ago: https://forum.snapcraft.io/t/screen-inhibit-control-denial-interface-broken/4173/5?u=zyga
 * zyga_ gets back to the standup
<jdstrand> zyga_: I read the pastebin. I think it is pretty ingenious tbh. I want to think about it a little
<zyga_> that last thing is a one character patch for the interface rules
 * zyga_ blushes 
<jdstrand> I thought I fixed that interface with a one char patch! dang it
<zyga_> jdstrand not in master :)
<jdstrand> zyga_: I didn't fix that one. I'm happy to send that up as penance if you haven't already
<zyga_> no, I haven't yet :)
<zyga_> I'm bad at keeping multiple git trees and I don't like to stash mid-patch like that
<ogra_> (i actually had to install the deb to chat here now ... the snap worked fine for the time i use it and there are no other denials like this before it started to hang hard)
<ogra_> (syscall 93 is fchown ... it doesnt call that usually)
<ogra_> (neither core nor the snap were updated either)
<ogra_> jdstrand, well, i'm only a user of that snap ... but it is a really bad experience if your app all of a sudden turns unresponsive (in the middle of typing) without and error or anything ... and also doesnt start anymore
<ogra_> (i know that snapcraft-preload helps .. but how would my mom know that if her app suddenly stops working )
<ogra_> we might need to make snapcraft-preload mandatory ..
<ogra_> (i.e. a builtin thing that everyone uses)
<jdstrand> zyga_: sparkiegeek should file a snap bug, with exact steps to reproduce, including kernel version, lxd version, distro, core snap version, command, etc
<zyga_> jdstrand ack, I will reproduce this and explore
<zyga_> jdstrand I don't understand why that profile name shows up running snap-confine there
<zyga_> I was expecting snap-confine's profile
<jdstrand> ogra_: your mom isn't expected to fix that. the developer of the snap is expected to make sure the snap is usable. forcing existing applications that weren't designed to run in a sandbox is always going to be tricky, and applications are complex
<ogra_> i totally understand that ... but even a developer wouldnt know ...
<jdstrand> ogra_: so your snap unfortunately hit a code path it never did before. you could grep the source looking for chown, but it might be in a lib
<ogra_> and an enduser would probably not even report it to upstream or the dev
<jdstrand> I would report it. "my snap all of a sudden stopped working". just like you did :)
<jdstrand> I mentioned the PR for a reason though
<jdstrand> the snap, today, isn't in a position to handle the kill signal
<ogra_> right ... if i run it from a terminal i cant even ctrl-c it
<ogra_> (killing the pid from another terminal works)
<jdstrand> but the pr I mentioned turns the kill into an eperm which means that if the snap didn't check the error code (many don't with chown(myuid, mygroup)) then it continues to work
<jdstrand> if it does check the error code, it can bubble that up to the user
<ogra_> thats good
<jdstrand> that pr got hung up, but I started poking people about it and they're thinking about ways to unwedge it
<jdstrand> the real fix will be the user/group stuff
<jdstrand> because part of that work will be allowing the use of chowning to yourself unconditionally
<ogra_> right ...
<jdstrand> (since, why not?)
<ogra_> i just wouldnt want to see random desktop snaps to just stop working like that
<jdstrand> but that is dependent on a tricky issue that is fixable in libseccomp
<jdstrand> of course
<ogra_> if there is a fix in the works that is acting globally thats fine i guess
<jdstrand> chown aside, unless you have full coverage in your blackbox testing, you'll never *really* know if the application-not-designed-for-confinement doesn't have a lurking bug in a rarely used code path
<ogra_> indeed
<Chipaca> niemeyer: mborzecki 1.9 added monotonic clocks
<Chipaca> fwiw
<mup> PR snapd#4731 opened: overlord/snapstate: fix task iteration order in TestDoPrereqRetryWhenBaseInFlight <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4731>
<mborzecki> mvo: ^^
<mup> PR snapd#4140 closed: interfaces: add an interface for gnome-online-accounts D-Bus service <Created by jhenstridge> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/4140>
<ogra_> ogra@acheron:~/Devel/branches/hexchat$ grep -r chown *
<ogra_> ogra@acheron:~/Devel/branches/hexchat$
<ogra_> *sniff* ...
<ogra_> no obvious chown call in the source
<jdstrand> probably in an underlying lib
<jdstrand> does it use sqlite?
<ogra_> not by what i can see from the deb dependencies
<ogra_> Depends: hexchat-common (= 2.10.2-1ubuntu3), libc6 (>= 2.14), libcanberra0 (>= 0.2), libdbus-glib-1-2 (>= 0.88), libgdk-pixbuf2.0-0 (>= 2.25.2), libglib2.0-0 (>= 2.41.1), libgtk2.0-0 (>= 2.24.0), libnotify4 (>= 0.7.0), libpango-1.0-0 (>= 1.29.4), libproxy1v5 (>= 0.4.11), libssl1.0.0 (>= 1.0.0)
<Chipaca> of those, i'd start looking at libproxy
<ogra_> funnily if i wipe all user data it works
<ogra_> so it must try to move something around in the cache, logs or whatnot i guess
<niemeyer> Chipaca: But was the bug really only fixed in 1.9?
<Chipaca> niemeyer: it's not a bug
<niemeyer> I had secret hopes that the bug would have been fixed earlier
<Chipaca> :-)
<Chipaca> the kernel has two clocks, before 1.9 go only used the one that goes to sleep with the machine
<Chipaca> after it, every time.Time is _two_ times
<niemeyer> Chipaca: It is a bug from the perspective of the Go API specifically, in the sense of breaking the most obvious expectation
<mvo> niemeyer, pedronis desktop team meeting?
<Chipaca> niemeyer: yes, obviously
<Chipaca> niemeyer: I was more making fun at googlers never putting their servers to sleep
<pedronis> mvo: there's no HOÂ specified afaict
<niemeyer> mvo: Where is it?
<mvo> pedronis: I /msged it
<mup> PR snapd#4732 opened: [2.31] timeutil: account for 24h wrap when flattening clock spans <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/4732>
<jdstrand> mvo: fyi, I updted the review-tools for accounts-service. please request a manual review for the snap (I still don't see it). it won't be in prod til next week
<mborzecki> Chipaca: is the snapd.refrehs.timer enabled by default on ubuntu?
<jdstrand> ah, roadmr must've sensed I was looking for him
<jdstrand> roadmr: good morning! :)
<roadmr> hi jdstrand  :)
<zyga_> jdstrand I'm going ahead with implementation and tests, if you find a loophole in the idea please let me know
<roadmr> how can I help?
<jdstrand> roadmr: can you make that r1005 instead?
<roadmr> jdstrand: totally!
<jdstrand> roadmr: just a small rename of an interface
<Chipaca> mborzecki: it is, or it has been at some point
<jdstrand> zyga_: getting back to it now
<roadmr> jdstrand: sure thing!
<cjwatson> ~/wg 40
<cjwatson> gah, sorry
 * jdstrand wonders why *every* morning has a gagillion little things
<zyga_> not every morning, just weekdays :-)
<jdstrand> zyga: well, they are there on the weekends too. monday is a 1/2 to 3/4 of a day of little things. some not so little ;)
<roadmr> jdstrand: I bet because people in Europe spend *their* morning devising ways to make yours more interesting ;)
<jdstrand> haha
<jdstrand> roadmr: sometimes I really do wonder about that :)
<zyga> haha, that's actually regularly true :)
 * zyga loves the moment when jdstrand joins
<jdstrand> zyga: let me summarize the paste so I have it all straight
<jdstrand> zyga: before doing anything, you snag mountinfo. you reconstruct it in the way described. we know that we can depend on st_dev because the kernel keeps track of that sensibly
<jdstrand> zyga: so we can map the st_dev to the mount from before. we do the operation, and check that we have a (st_dev)/thing
<jdstrand> if we do, then we're good, if we don't, it 'mismounted'
<jdstrand> (or failed, but we would've already died if we failed)
<zyga> more or less yes
<jdstrand> yes, I was summarizing
<zyga> the reconstruction happens on the "after" []mountinfo
<jdstrand> so, all of this is happening on tmpfs, which is the problem
<zyga> we use before and after together to see what is new
<zyga> and only consider those entries as possible solutions
<jdstrand> and XDG_RUNTIME_DIR is tmpfs
<jdstrand> so /run/user/uid needs to be mapped to the st_dev
<zyga> yeah, that's fine
<jdstrand> zyga: doesn't this lift the requirement that it must not be a mount point?
<zyga> yes, it does
<zyga> I dropped that
<jdstrand> right
<zyga> oh
<zyga> it's not in the paste :D
<zyga> https://pastebin.ubuntu.com/p/bPZv9mPnxk/
<zyga> those are the new rules
<zyga> 3 is the "no race" thing
<zyga> and that's all
<jdstrand> zyga: ok
<zyga> I dropped the writability and mount entry constraints
<zyga> as the race detector should be a superset of that anyway (for malicious intents)
<zyga> jdstrand I'll break for lunch now but if you think about anything that I missed just drop me a note please
<Chipaca> pedronis: have you an opinion on where 'InstallDate' should live, if I were to add it to something info-ish?
<Chipaca> otherwise I'll keep this PR super-minimal
<jdstrand> zyga: so, you are using the diff between before and after to narrow down what you need to look at, correct?
<jdstrand> zyga: so for something like /some/arbitrary/mount/point, you'll see /some/arbitrary/mount/point show up, so then you look for /some/arbitrary/mount, /some/arbitrary, /some and / to calculate the st_dev to look for? (in that order)
 * Chipaca goes with minimal
<pedronis> Chipaca: I'm in a meeting
<Chipaca> pedronis: no worries
<Chipaca> i can do followups
<kalikiana> re
<mvo> jdstrand: ta, I can accept those too
<mvo> jdstrand: thanks for adding it
<mvo> jdstrand: I will later push s390x, armhf etc binaries for testing
<jdstrand> mvo: if you request the manual review, you can't accept it yourself
<jdstrand> mvo: or if you do the upload
<jdstrand> so, if you need me, ping me
<mvo> ta
<zyga> jdstrand the before after view is indeed to look at the diff and constraint the set of allowed solutions to the diff
<brunosfer> Does anyone knows where to find good documentation regarding the upload of snaps to the store?
<jdstrand> zyga: and you go bottom up looking for the parent st_dev?
<zyga> jdstrand as for the second question, if I understand you correctly that is indeed how we find what is /some/arbitrary/mount/point
<zyga> yes
<jdstrand> right
<zyga> when thinking about this I also considered something else:
<zyga> using mount id, parent id to construct a tree of mounts
<zyga> but I don't know if that is needed for any of the results yet (maybe it is but we haven't seen a case that shows this)
<pedronis> Chipaca: I think it should go at the level of Broken
<jdstrand> ok. please proceed. this is a nice idea considering the limitation of the mount api
<jdstrand> zyga: I don't think that is necessary otoh
<zyga> thanks! :-)
<jdstrand> zyga: I'm probably going to ask Tyler to do a final review after you and I are happy
<zyga> thanks
<zyga> I also wondered if anyone else solved this
<zyga> it seems like a common problem for software
<roadmr> software sucks?
<zyga> roadmr without doubt :)
<zyga> if it was a hardware problem we could recycle it
<zyga> in software we have to support it :)
<roadmr> hah well my mom has this ancient PC from the 1990s and I have to support it :(
<roadmr> probably the last PC on the planet with a 5.25" floppy drive
<ikey> s/5.25"//
<zyga> I have a USB floppy drive
<ikey> that seems wrong
<ikey> lol
<zyga> I could plug it to my thunderbolt port via an adapter
<zyga> :D
<zyga> thunderfloppy
<ikey> hispeed â¢
<zyga> feeling the 40GB/s bandwidth right
<zyga> of that *high-density* floppy
<ogra_> you typoed a G there ..
<ikey> xD
<zyga> I think that's hippiespeed :)
<ikey> ah they were simpler times
<ikey> when tapes and floppies challenged us with write protect tabs and we lol'd
<zyga> and we had non-rootkit copy protection :)
<ikey> ah see we approached that idea differently there :P
<zyga> and computer magazines (and no interneet)
<ikey> i thought i was a yuppie the first time i ever burnt a CD
<ikey> tbf i had to "save up" all the things i wanted downloaded before i used the CD to transfer them
<ikey> cuz CD-Rs were expensive >_>
<ikey> im not proud to admit the JDK was on that.
<zyga> I paid a colleague who carried the money to a guy across town, who had a recorder
<ikey> like the instrument or an actual recorder?
<ikey> cuz one makes more sense
<zyga> I mean a CD recorder :)
<ikey> xD
<ikey> sorry having a friday yolo mood here. :p
<zyga> that's all right
<zyga> I deal with mount tables
<zyga> I have that mood all the time
<ikey> yeah saw the tweet
<zyga> :D
<ikey> my heart goes out to you
<zyga> but hey
<zyga> I'm proud I wrote something nice for a change
<zyga> https://pastebin.ubuntu.com/p/Jnw6KSHsrj/
<ikey> "pls mount read-only" "yes i will" "why is it writable" "remount as RO pls"
<zyga> or why kernel should have gotten that flags argument on mount to support MS_NOFOLLOW but.. yeah
<ikey> mm
<ikey> broken heap of ouch
<ikey> that.. is quite the doc
<zyga> yeah, would be easier to add MS_NOFOLLOW
<ikey> anyone else ever read that MS as.. yknow.. that MS?
<roadmr> multiple sclerosis? :(
<Pharaoh_Atem> I know it as Mississippi mostly :P
<ikey> nah
<ikey> (my cousin has that so i wouldnt personally make that connection in that sense)
<ikey> nah i meant Microsoft
<roadmr> I see :) yes, sometimes
<zyga> jdstrand drat
<zyga> jdstrand we need the parent-child association
<zyga> man, I will write a paper about this
<jdstrand> zyga: what is the test case that blew up?
<zyga> (irc doesn't like leading slashes)
<zyga>  /foo/bar
<mup> PR snapcraft#1951 opened: repo: do not pull in libc6-dev by default for stage-packages <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1951>
<zyga>  /foo
<zyga> (those are mountinfo entries)
<zyga> now we look for /foo/bar/froz
<zyga> we need to model /foo/bar being shadowed by /foo
<mvo> pedronis: do you think you could have a look at 4731? the last piece for 2.32 afaict
<zyga> and I think we need to model child-parent to understand what path traversal means
<jdstrand> isn't it sufficient to know that /foo/bar and /foo/bar/baz are the same st_dev? /foo will have a different st_dev, no?
<zyga> unless I can do some simpler check that /foo is shorter than /foo/bar and it is later in the table so it hides /foo/bar (which can be ignored now)
<zyga> they could all have same st_dev sadly
<zyga>  /foo/bar can be a mount entry for /foo/unrelated
<Chipaca> pedronis: hmm. Right now what I've done is given Info a CurrentTimestamp(), which seems to avoid the issue of having it in info when it's only there for local
<zyga>  and /foo can be a bind mount of the original device
<zyga> so you effectively unmount /foo/bar
<jdstrand> oh, cause /foo might be tmpfs (new st_dev), but /foo/bar might be a bind mount (same st_dev)?
<zyga> this is a contrived example that preserves same st_dev
<zyga>  yes
<jdstrand> right
<zyga> isn't this stuff fun :)
<zyga> :-)
<jdstrand> I was just thinking
<jdstrand> "fun!"
<pedronis> Chipaca: that works too
<jdstrand> zyga: I think that the before/after diff is really key here since this is happening within the ns and an unpriv user isn't going to be able to fiddle with the mount table for this (non-user mount) namespace
<jdstrand> zyga: so you're able to trust that before and after are ok
<jdstrand> we may want to consider fusermount (eg, user races with fusermount instead of just a symlink), but that might just be verifying that after doesn't have any fuse* mounts
<jdstrand> that said...
<jdstrand> zyga: before and after should only have a diff of '1' if you call before just before the mount, right? (ie, we're in the ns)
<zyga> yes, that's correct
<zyga> well
<zyga> hmmm
<zyga> no?
<zyga> there are two cases that would change that:
<zyga> 1) /media mounts can happen asynchronously
<zyga> 2) interface connections can be inherited from the parent ns
<zyga> and by 2) I mean we are in a MS_SLAVE ns but we will see mount events propagating into us
<jdstrand> so an interface connection happens at the time of the mount?
<zyga> yes
<jdstrand> right
<zyga> realistically I think the /media case is more likely to happen
<pedronis> Chipaca: we don't seem to use Timestamp much outside of assertions, typically we have Time ort nothing
<jdstrand> sure
<jdstrand> but either are possible
<zyga> diff will *usually* be 1 but it may be legitimately longer
<pedronis> Chipaca: IÂ mean in method/field names
 * Chipaca nods
<zyga> jdstrand I'll think about how to model shadowing best
<zyga> shadowing beast :)
<jdstrand> zyga: with the parent child tree, then that should detect any weird fusermount stuff too
<pedronis> Chipaca: LinkTime ? too obscure
<jdstrand> zyga: cause we are looking for a specific child with a specific parent, so if it isn't found, die
<pedronis> Chipaca: sadly Current and CurrentTime have both the wrong connotation
 * jdstrand notes this underscores the complexities of root messing around in user owned dirs
<zyga> yeah
<jdstrand> it's just like a thousand times more difficult with the crappy mount api
<zyga> I don't understand how the mount maintainer cannot see that perfect is the enemy of good here, waiting for some mythical mount design we have to pay the price of MS_NOFOLLOW not being a thing
<zyga> Pharaoh_Atem fedora 27 looks good in 5K :)
<ogra_> 5k ? is that dual monitor ? 4K + VGA ?
<zyga> 5K screen
<ogra_> i didnt know thats a thing
<zyga> yeah :)
<ogra_> (only know 4K)
<zyga> oops
<zyga> imgur crashes on 5K images ?:D
<zyga> https://twitter.com/zygoon/status/967066654785056774
<zyga> not sure if there's a "get original" thing in twitter
<nacc> when a part has a relatively unstable (it seems in practice) http server/git server, does it make sense to ship the tarball in the snap directory  directly?
<nacc> and is there a 'best practice' doc for doing so (cough anonscm cough)
<mvo> anyone up for review for 4731?
<mup> PR snapd#4733 opened: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4733>
<zyga> yep
<jdstrand> mvo: is there going to be another 2.31? (thinking of ^)
<mvo> jdstrand: maybe, there are some indication for it
<mvo> jdstrand: but not urgent
<jdstrand> mvo: what we have in 2.31 isn't a regression, just an incomplete fix (therefore also not urgent imo)
<jdstrand> mvo: ok, I'll create a branch and milestone it, then you can do with it what you will
<jdstrand> mvo: incidentally, does this ring any bells:
<mvo> jdstrand: ta
<jdstrand> $ ./run-checks
<jdstrand> ...
<jdstrand> Running vet
<jdstrand> overlord/ifacestate/handlers.go:580: github.com/snapcore/snapd/overlord/state.Retry composite literal uses unkeyed fields
<jdstrand> exit status 1
<mvo> (in a meeting right now so might be slow)
<jdstrand> mvo: no worries. this is my 16.04 dev environment in lxd if you recall
<mvo> jdstrand: does not ring a bell right now
<mup> Issue snapcraft#1952 opened: add support for in test release information <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1952>
<mup> Issue snapcraft#1953 opened: Add in test architecture <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1953>
<mup> PR snapd#4734 opened: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.31 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4734>
<zyga> hmm hmm hmm
<zyga> https://pastebin.ubuntu.com/p/VwtktKq7cc/
<jdstrand> mvo: fyi, 4734 for 2.31
<zyga> jdstrand both +1'd
<jdstrand> yep, thanks!
<zyga> I pasted something that shows the problem we talked about earlier
<zyga> and found something unexpected
<mup> Issue snapcraft#1704 closed: Add unit tests for error classes <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1704>
<mup> Issue snapcraft#1954 opened: Implement support for `common-id` <Created by sergiusens> <https://github.com/snapcore/snapcraft/issue/1954>
<mvo> jdstrand: \o/
<mup> PR snapd#4731 closed: overlord/snapstate: fix task iteration order in TestDoPrereqRetryWhenBaseInFlight <Created by bboozzoo> <Merged by zyga> <https://github.com/snapcore/snapd/pull/4731>
<zyga> heh
<zyga> so the kernel does allow a mount event to propagate back to ... itself
<zyga> kind of
<zyga> I just realized this by reading parent ids
<zyga> jdstrand in the paste above mount 405 (/tmp2) is mounted on top of 390 which is /tmp2
<Chipaca> pedronis: vvv
<mup> PR snapd#4735 opened: daemon, snap: fix InstallDate, make a method of *snap.Info <Created by chipaca> <https://github.com/snapcore/snapd/pull/4735>
<pedronis> in another meeting
 * Chipaca hugs pedronis 
<jdstrand> zyga: yeah
<jdstrand> zyga: so, an unpriv user isn't going to sneak a bind mount in there. what does a fuse mount look like in that situation?
<zyga> hmm, what can I mount
<zyga> any fuse mount?
<jdstrand> sure
<zyga> holly crap
<zyga> there's bindfs
<zyga> which is like mount --bind
<jdstrand> they look like this:
<zyga> and it's FUSE
<jdstrand> $ grep fuse /proc/self/mountinfo
<jdstrand> 53 22 0:45 / /sys/fs/fuse/connections rw,relatime shared:31 - fusectl fusectl rw
<jdstrand> 3500 1411 0:97 / /run/user/1000/gvfs rw,nosuid,nodev,relatime shared:428 - fuse.gvfsd-fuse gvfsd-fuse rw,user_id=1000,group_id=1000
<jdstrand> zyga: yeah, we talked about that once before
<jdstrand> for remapping uids
<jdstrand> (but discarded it)
<zyga> jdstrand fuse looks mostly like a normal filesystem
<jdstrand> zyga: my line of thinking was that *perhaps* we don't have to worry about a bind mount getting snuck in, but if a fuse one did, die
<jdstrand> zyga: fstype is going to have 'fuse' in the name though
<zyga> well, it doesn't have to, does it?
<jdstrand> zyga: yes, it does
<jdstrand> zyga: fuse.sshfs, fuse.gfvsd-fuse, etc
<zyga> is that done by the kernel or just a convention by each fuse process?
<jdstrand> zyga: this is why in the fuse-support interface we use: mount fstype=fuse.* ...
<zyga> I see
<zyga> cool, I didn't know that
<zyga> so, back to your idea
<zyga> why are fuse mounts more dangerous than bind moutns?
<zyga> because we don't know what they can bring?
<jdstrand> zyga: in and of themselves, they aren't
<jdstrand> zyga: what is different is that a normal user needs privs to do a bind mount. fusermount is setuid, so a normal user can use it
<zyga> ah, I see
<zyga> another snap-confine situation
<zyga> ok, I'll look at the algorithm for what we talked about so far
<jdstrand> zyga: all this is about is a non-root unconfined user playing tricks to escalate
<jdstrand> zyga: we aren't worried about unconfined root
<ogra_> just bundle fuse with npm (that apparently just does a chmod -R 777 /* ... all security issues fixed)
<zyga> I'd patch npm to use 2777, the colors in ls are nicer, presentation matters!
<Chipaca> ogra_: there's a lesson in there about running npm as root, but it's not a new lesson and I doubt many people care
<ogra_> yeah, just send a patch for https://github.com/npm/npm/issues/19883
<ogra_> Chwell, there might be a lesson for people reading the bug ... people reading that howto they found on this internet thing will just follow it and use sudo npm
<jdstrand> zyga: for completeness, there are also user mount namespaces, but they shouldn't be in play because snap-update-ns is already in a system mount namespace, and the user won't be able to affect it
<ogra_> bah
<ogra_> Chipaca, ^^^
<Chwell> there, fixed it
<ogra_> lol
<zyga> user mount namespaces
<zyga> or user namespaces
<jdstrand> oh that is an awesome bug
<zyga> :D
 * kalikiana wrapping up for the week
<jdstrand> too bad npm as a snap is classic
<ogra_> jdstrand, i knew you would love it
<zyga> and here I was thinking the kernel was coming to address our issues :)
<jdstrand> s/npm/node/
<Chipaca> zyga: cp `which false` `which npm`
<jdstrand> zyga: the mount user namespace? :)
<zyga> jdstrand the cake namespace
<jdstrand> per-user mounts in the snaps system mount namespace aren't affected by mount user namespaces
<zyga> jdstrand so the thing you stated for completeness, what did you mean there
<jdstrand> how is that for a parseable sentence?
<zyga> that user namespaces are not a risk?
<zyga> it's okay but I have a question
<zyga> what are mount user namespaces?
<jdstrand> zyga: I'm saying that user namespaces shouldn't be in play, because be the time we do before, mount, after, s-u-n is in the system mount namespace of the snap, so the user shouldn't be able to fiddle with it
<jdstrand> and we already unshared
<zyga> ahh, ok
<zyga> :)
<zyga> man, the adjective order in english
<jdstrand> right
<zyga> with a few cases like in polish it would be easier to parse :)
<jdstrand> it is all messy
<jdstrand> mount namespace (system, need privs), mount user namespace (don't need privs), and snap namespace (system)
<jdstrand> user namespaces are what lxd uses these days by default
<zyga> we should call those rooms, not namespaces
<zyga> it's such a geeky thing
<zyga> my root user in this room is not the same as the root user in that room
<zyga> and there's a root user in the room that contains the other two rooms
<zyga> it almost sounds sensible!
<Chipaca> zyga: I think somebody took âNamespaces are one honking great idea -- let's do more of those!â a bit too much to heart
<zyga> and you can say "go to your room" if your kids are naughty and don't want to do homework
<Chipaca> zyga: and you can shuffle the whole bunch of groups around every time somebody tries to change rooms
 * Chipaca wonders if 'the cube' is too old
<zyga> Chipaca ooh
<zyga> yes
<zyga> the cube is the perfect analogy
<niemeyer> Saviq: ping
<Saviq> niemeyer: as you were, looks like they had some kind of hiccup
<mvo> just fyi - I branched 2.32 and will hopefully do a beta later tonight
<niemeyer> Saviq: Hm?
<niemeyer> Saviq: Not sure if my IRC client is buggy.. but it looks like I'm missing part of the sentence
<niemeyer> Saviq: I was going to talk about the image.. did you sort it out?
<Saviq> niemeyer: thought you were pinging about my issue yesterday (missing 17.10 images)
<niemeyer> Saviq: Yeah, it was about it indeed
<Saviq> Right, yes, that - it was a hiccup on their side
<Saviq> So we're back in business, thanks
<niemeyer> Saviq: I wouldnt' be surprised if they just removed the image
<niemeyer> Saviq: and then people complained
<Saviq> Possible, yeah
<niemeyer> Saviq: Our experiences with dynamic usage in Linode show they're not quite there yet
<niemeyer> Saviq: They still hold a lot of the old school way of thinking, where you create a machine and hold it
<Saviq> I went to their IRC channel, someone said the image was still there in new API, but missing in old or something of the sort
<niemeyer> Saviq: The other day I got a Terms Violation notice, for example, for a machine that we used for 23 minutes.. the timing of abuse report was off for several hours from our use
<niemeyer> Saviq: We're also observing corruption of machine state when we do a lot of API calls next to each other
<Saviq> Aha... We've had some intermittent issues, but it's been fine overall
<niemeyer> Saviq: For that sort of reason, I have a Google Compute Engine backend pretty much good to go
<niemeyer> Saviq: Preliminar tests look very promising
<Saviq> Nice!
<niemeyer> Saviq: Other than the image itself being perhaps slightly different, you shouldn't have to change anything on your end
<Saviq> Let me know if you want us to test anything
<niemeyer> Thanks, will do
<Chipaca> niemeyer: the forum is saying it's offline
<niemeyer> WAT? I'm typing on it!
 * niemeyer looks
<mvo> Chipaca: hm, same here, it does not respond
<niemeyer> The machine looks completely down..
<niemeyer> (speaking of Linode...)
<niemeyer> https://usercontent.irccloud-cdn.com/file/44QXUsr8/image.png
<mvo> cachio_: hey, I was just looking at the SRU of snapd, lets plan to do the sru verification early next week
<cachio_> mvo, hey, sure
<cachio_> which version 2.31.1?
<mvo> cachio_: yes
<mvo> cachio_: I push 2.32~pre1 to beta hopefully tonight but no need to validate that before monday, its just there for people to play with
<cachio_> mvo, sure
<cachio_> mvo, let's validate it on monday in that case
<mvo> cachio_: yes
<mvo> cachio_: that is what I was trying to say :)
<cachio_> :)
<cachio_> mvo, 2.32 contains layouts, right?
<mvo> cachio_: yes and autoconnect tasks and auto install of default providers
<mvo> cachio_: some dangerous stuff :)
<cachio_> rotundo82
<cachio_> mvo, yes
<niemeyer> What..
<niemeyer> error: cannot read snap file: app description field 'command' contains illegal "bin/gopkg
<niemeyer>        -acme=$SNAP_DATA/certs -http=:80 -https=:443" (legal: '^[A-Za-z0-9/. _#:$-]*$')
<niemeyer> What happened there!?
<niemeyer> Chipaca: Do you know anything about this?
<niemeyer> Ah, I disabled the adapters..
<niemeyer> Looks like we need to make this logic a bit more flexible
<Chipaca> niemeyer: I don't know what happened there, that doesn't contain anything that doesn't match
<niemeyer> Chipaca: Yeah, we probably have something to fix..
<happyaron> hey the forum seems to be down...
<Chipaca> niemeyer: do you have the snap handy?
<happyaron> and my edit get lost...
<Chipaca> happyaron: I think that's what niemeyer is on
<niemeyer> Phew.. ok.. gopkg.in is up on the secondary
<mup> Issue snapcraft#1819 closed: Detect and clear executable stack binaries <bug> <Created by sergiusens> <Closed by sergiusens> <https://github.com/snapcore/snapcraft/issue/1819>
<mup> PR snapcraft#1945 closed: elf: clear execstack by default <bug> <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/1945>
<happyaron> long fight, :(
<pedronis`> mvo: will you branch 2.32 tonight ?
<sergiusens> niemeyer: I thought `S` was now allowed, we discussed it with jdstrand and mvo and agreed it was good
<sergiusens> there must be a forum post somewhere but I cannot search it now
<Chipaca> pedronis`: <mvo> just fyi - I branched 2.32 and will hopefully do a beta later tonight
<Pharaoh_Atem> zyga: \o/
<pedronis`> Chipaca: ah, cool
<pedronis`> can land some of my stuff
<Chipaca> pedronis`: :-)
<Chipaca> niemeyer: when you have a moment, the snap.yaml that threw that error would help
<mvo> pedronis: yes, I branched it now
<mvo> s/now/some minutes ago/
<mup> PR snapd#4715 closed: store: reorg auth refresh <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4715>
<pedronis> mvo: thank you
<mvo> yay, thank you for all the nice PRs that can land now
<mup> PR snapd#4722 closed: store: cleanup test naming, dropping remoteRepo  and UbuntuStore(Repository)? references <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/4722>
<niemeyer> Chipaca: Thanks, will reproduce once I take my head above the water
<Chipaca> niemeyer: no probs
<niemeyer> Chipaca: https://gist.github.com/niemeyer/8270aeb96b6facd8ee1bc2129086e4b3
<niemeyer> Forum is back up
<niemeyer> Or, stating more correctly, the entire data center has connectivity again
<niemeyer> Chipaca: Also: https://forum.snapcraft.io/t/better-field-name-for-refreshed-in-snap-info-output/4150/6
<Chipaca> niemeyer: hah
<Chipaca> niemeyer: I had that change in the PR that I closed during the standup :-)
<Chipaca> glad we're aligned
<niemeyer> Chipaca: Which of the three? :P
<Chipaca> niemeyer: https://github.com/snapcore/snapd/pull/4729/files#diff-6ac026a08342873c6b9ada7333f66224R378
<mup> PR #4729: many: drop snaps' InstallDate, introduce Updated <Created by chipaca> <Closed by chipaca> <https://github.com/snapcore/snapd/pull/4729>
<Chipaca> niemeyer: moving installed to the bottom
<niemeyer> \o/
<pedronis> Chipaca: so refreshed is not defined if the snap is inactive?
<Chipaca> pedronis: correct
<pedronis> it's ok in info, it's a bit strange in the snap api
<pedronis> heh
<pedronis> I mean daemon api
<Chipaca> pedronis: if you have a good definition of this for when the snap is inactive, I can implement it, no problem :-)
<pedronis> Chipaca: mtime of the revision snap blob?
<pedronis> we have a Current even if we are inactive nowadays
<Chipaca> pedronis: that's hard to explain, though: enable the snap, its 'refreshed' changes
<pedronis> Chipaca: we are still mixing concepts I fear
<pedronis> the current link is a good approx of installe-date, only ignoring revert, enable/disable etc
<pedronis> something got to give
<niemeyer> Chipaca's take sounds reasonable to me as well.. what are we missing
<niemeyer> ?
<niemeyer> I mean, if you have three different snap revisions and they are all disabled, it's hard to argue that a particular one of them should be shown there
<pedronis> I'm not unhappy about the snap info display,   my issue is with the rest api field which is still called installed-date
<niemeyer> That said, do we show the version?
<niemeyer> Chipaca: ?
<niemeyer> In "installed" that is
<Chipaca> niemeyer: yes
<niemeyer> Okay, it seems a bit inconsistent
<pedronis> niemeyer: we do show a version in installed even if the snap is disabled
<Chipaca> niemeyer: but
<niemeyer> Then I agree with pedronis
<Chipaca> but maybe we shouldn't
<pedronis> because we have a current concept (that is different from active)
<Chipaca> i mean, maybe we shouldn't show 'installed' if it's disabled
<pedronis> well, it's what you would get
<pedronis> if you did snap enable
<niemeyer> Chipaca: pedronis has a point I think.. maybe that's just fighting against the real model we have, which in general means we'll have cascading issues
<niemeyer> Chipaca: e.g. it's also what we show in "snap list" isn't it?
<pedronis> the line is like this:   installed:   0.2.26 (8) 2MB disabled
<pedronis> we say disabled there
<pedronis> but there is also a version
<pedronis> (what you get if you enable)
<Chipaca> so.
<niemeyer> Yeah, so showing the refreshed time at all times sounds right
<jdstrand> zyga: arg 4727 makes me have to redo a bunch of stuff
<niemeyer> It's consistent with everything else at least
<Chipaca> niemeyer: but what is the refresh time of a disabled snap?
<pedronis> what is a refresh time of a reverted snap
<niemeyer> Chipaca: It's the refresh time of the _current_ revision
<Chipaca> pedronis: the timestamp of current
<pedronis> that our current interpretation
<pedronis> usually refreshed means from the store
<pedronis> not strobed client side
<pedronis> though we have corner cases
<pedronis> you can refresh to revisions you already have
<ackk> hi, is it possible to specify version constraints on "stage-packages" ?
<Chipaca> niemeyer: we don't have the 'refresh time' anywhere, though
<Chipaca> pedronis: yep, and in this context i don't think there's a non-weird answer for revert
<niemeyer> Chipaca: Agreed
<Chipaca> bah, the non-weird thing would be to keep (last action, timestamp) and show that
<niemeyer> Chipaca: So isn't it the timestamp of the link anyway?
<Chipaca> so you get installed/enabled/disabled/reverted/refreshed: <timestamp>
<niemeyer> Chipaca: When we disable, do we kill the link?  I thought we had changed that
<Chipaca> niemeyer: the link isn't there if the snap is disabled
<pedronis> we kill the link
<Chipaca> niemeyer: we keep 'current' in the state
<niemeyer> Chipaca: Except installed is taken.. oops :)
<niemeyer> Chipaca: I almost wrote as part of that post that we should change the field name at the same time we fix its meaning
<niemeyer> For that reason
<Chipaca> niemeyer: the revision descriptions are growing a timestamp, it all lines up
<Chipaca> :)
<niemeyer> Chipaca: I'm sold ;)
<Chipaca> OTOH we could go with 'current' for the current version description line
<Chipaca> s/version/revision/
<niemeyer> Chipaca: I like that..
<Chipaca> ok, so, baby steps
<niemeyer> Chipaca: So, just to go back to that point I'm still missing: you say we currently use the link time
<Chipaca> niemeyer: yes
<niemeyer> Chipaca: Isn't the link always there even when it's disabled?
<Chipaca> bah, in the PR that's up
<Chipaca> niemeyer: no, the link is not there if it's disabled
<niemeyer> Ah, pedronis also answered that.. I missed it, okay
<Chipaca> long week, and long day :-)
<niemeyer> Chipaca: So.. I think we can fix the output, and if we cannot find the proper data for all cases, we can approach it and have more data as we find the time to polish it up
<niemeyer> Chipaca: But, I suggest we do those fixes at once.. at least the key ones
<Chipaca> I can rename it to 'current' as part of the move
<pedronis> that seems a big change
<pedronis> but IÂ don't know if people parse it a lot (or not)
<Chipaca> it's ok, i'll change it one letter at a time
<pedronis> :)
<Chipaca> :-D
<niemeyer> LOL
<Chipaca> pedronis: I hope they aren't, because I'm pretty sure there are more corner cases than not where it's not valid yaml
<niemeyer> It's not the kind of change we should be doing very often for sure
<mup> PR snapd#4736 opened: interfaces/screen-inhibit-control,network-status: fix dbus path and interface typos - 2.32 <Created by jdstrand> <https://github.com/snapcore/snapd/pull/4736>
<niemeyer> But I think it's worth it doing it if we plan to have more times there, which I think we do
<pedronis> Chipaca: I didn't say they parse as yaml
<Chipaca> pedronis: (but the change is still going to disorient people that rely on it)
<pedronis> those people could use the api
<Chipaca> pedronis: ah
<pedronis> I'm more thinking the grep and cut and awk sort of people
<Chipaca> pedronis: i gotcha
<niemeyer> It's just awkward to have refreshed next to installed with completely different meanings, and it's double awkward because installed could actually BE A TIMESTAMP
<jdstrand> zyga: oh I thought you said it was committed
<Chipaca> pedronis: do you reckon a heads-up forum post would be enough?
<pedronis> it's a start
<jdstrand> zyga: if your pr is committed, I'll update mine, but I don't want to mix in an unapproved approach at this time
<Chipaca> pedronis: niemeyer: and because this is for snap info, we can make an additive change to SnapState to keep track of (last action, timestamp), and have code that grabs it if it exists but doesn't die if it doesn't, and we'll be set
<Chipaca> that's a change for next week though
<Chipaca> although knowing us, it should probably be a map[action]timestamp
<pedronis> heh
<pedronis> and then you sort them, and take the last?
<Chipaca> pedronis: unless the last is $x that we later decided to ignore :-)
<pedronis> last action timestamp,  download time, revision creation time, release timestamp
<pedronis> Chipaca: I also wonder whether we should start from thinking what IÂ user might really find useful
<Chipaca> pedronis: I thought we were (in a bumbling, chatty kind of way)
<Chipaca> niemeyer: btw in https://forum.snapcraft.io/t/4150/6 you had installed twice in the first example, and with me having moved it to the bottom I'd gotten used to seeing it there so it took me a bit to understand what you meant
<pedronis> Chipaca: one of my questions is that is unclear those times help answering, is the thing IÂ have here old
<niemeyer> Chipaca: Oops, sorry.. cleaned it
<pedronis> Chipaca: refreshed is sort of that (except if you strange local refreshes)
<Chipaca> pedronis: that you can only answer with the store's timestamps though
<pedronis> the ones we don't plan to show anywhere :)
<Chipaca> pedronis: oh? i thought we were going to have a day in the chan map
<pedronis> yes
<Chipaca> 16-2.31.1+git587.d3e52a0 (4133, from 2018-09-24) 85MB core
<Chipaca> or sth
<pedronis> though we haven't decided what that date is here yet
<pedronis> it can be the revision date, or the release date
<Chipaca> hopefully, gregorian
<pedronis> or we need both (oh my)
<pedronis> star date
<Chipaca> internet time!
 * pedronis should go afk
<niemeyer> popey: ping
<popey> niemeyer: pong
<niemeyer> popey: Heya
<niemeyer> popey: Would you have 5~10mins for a quick catch up?
<popey> Sadly not right this second. I need to go out and get my daughter from dance class.
<popey> But I'll be back a little later
<niemeyer> popey: Sounds good, I'll be around, so will ping you again later
<niemeyer> popey: Talk soon
<popey> kk, will let you know when I'm back
<niemeyer> Thanks!
<mup> PR snapcraft#1955 opened: meta: make sure adapter does not propagate <bug> <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/1955>
<mup> PR snapd#4737 opened: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4737>
<Chipaca> huh, why did i think snap names had max length 40
<Chipaca> niemeyer: I can't do the alignment you're now asking for in the pr, without a ton of work
<niemeyer> Chipaca: My naive mind reacts in disbelief about adding a couple of spaces in a line being a ton of work.
<Chipaca> niemeyer: ok
<niemeyer> That's such a great conversation.. it must be Friday :P
<Chipaca> niemeyer: i was just writing
<Chipaca> niemeyer: it's friday and i'm very tired, so maybe it's easy and i'm not seeing it, but i'm going to call it mostly-eod right here
<niemeyer> Type faster!    <GIF of someone typing really fast>
<niemeyer> Chipaca: Certainly sounds fair
<Chipaca> niemeyer: snap info is messy; if it were nice and clean this would be easy
<niemeyer> Chipaca: Agreed.. we can look into it again with fresh post-weekend eyes on Monday
<Chipaca> I did see the problem with the alignment when the channel map is missing, fwiw, and looked at fixing it, and noped out
<niemeyer> Chipaca: We might hack it by tuning the spacing specially for that line, and serializing it independently
<niemeyer> Or something something
<Chipaca> niemeyer: yeah, that's the nope scenario (you'd have to keep track of what the last thing you printed even was)
<Chipaca> (there are a ton of "if it has this, then print this")
<Chipaca> (and people care about the order, wouldn't you know :-) )
<niemeyer> Chipaca: Not printed, but whether a channel map exists.. we have semantic context at hand in the info impl itself
<niemeyer> Chipaca: Yeah, I know.. I'm sure we could spent 5 years on a modern yaml parser and  do it very nicely
<Chipaca> actually, i can show you a diff that would do the job, and you tell me if it's worth it
<Chipaca> niemeyer: https://pastebin.ubuntu.com/p/4xRZx4vdyH/
<niemeyer> Chipaca: WFM!
<Chipaca> niemeyer: iterated it a bit though, because i can't help myself
<Chipaca> niemeyer: pushed
<popey> niemeyer: i assume the catch up was regarding the various docs threads. It's late here. Shall we catch up early next week?
<zyga> dooooh
 * zyga solved a bug :)
<Chipaca> no snapcrafters around! and me with a bug
 * zyga hugs Chipaca 
<zyga> I found a super silly bug in my code
<zyga> and I found out why core and layouts didn't work
<Chipaca> zyga: yay?
<Chipaca> zyga: zyga! zyga. Are you on bionic?
<zyga> I have a VM on bionic available
<zyga> but I'm on artful
<Chipaca> I don't think it'll work in artful yet
<Chipaca> zyga: bionic ships with "ls --hyperlink"
<zyga> what are you thinking about?
<Chipaca> gnome terminal
<Chipaca> in bionic
<Chipaca> supports hyperlinks
<Chipaca> it's weird, and exciting, and wrong :-)
 * zyga checks
<Chipaca> and of course coreutils use them
<zyga> wait, WAT!
 * zyga doesn't believe this
<Chipaca> hahah
<Chipaca> zyga: https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda
<zyga> w...t...f..
<zyga> how does it work?
<Chipaca> IKR
<zyga> hollly
<Chipaca> zyga: escape sequences, of course
<Chipaca> and a particularly gnarly one to parse
<Chipaca> if I were one to be writing a de-ansifier, that is
<zyga> it also works in F27
<zyga> so you bumped into this because it broke something
<Chipaca> heh, everything I've found so far has broken with a lot less
<Chipaca> but yes, this broke my thing
<zyga> man, thank you for sharing this
<zyga> this is pretty cool actually
<Chipaca> zyga: most de-ansifiers broke with just
<zyga> but man
<Chipaca> printf '\033(0lqwqk\nx x x\ntqnqu\nx x x\nmqvqj\n\033(B')
<zyga> this will be exploited
<Chipaca> uh, remove the trailing )
<zyga> snaps can even abuse this
<zyga> someone who did this will add a "preload" feature next
<nacc> ok so they removed the ability to title the terminal, but added this!? )
<nacc> :)
<Chipaca> nacc: they whaaaa
<nacc> Chipaca: it's been gone for a few releases now
<Chipaca> nacc: you mean, in the ui? or with escapes?
<nacc> Chipaca: in the UI
<Chipaca> ah! psh
<nacc> Chipaca: i can try with escapes, do you have an example?
<Chipaca> that was just confusing because your escapes would override it
<Chipaca> nacc: you have an example in your .bashrc :-)
<Chipaca> it's in the skeleton bashrc
<Chipaca> your PS1 is probably doing it
<nacc> Chipaca: oh sure, I know that part
<nacc> it's a hassle to write a per-terminal instance PS1 though :)
<Chipaca> nacc: yup
<Chipaca> nacc: my favourite complaint is that they add or remove features and there's no way to detect them
<nacc> that's a fact :)
<Chipaca> like, how would an implementer know whether the terminal has hyperlinks? 24-bit rgb? properly wide emojis?
<nacc> right
<nacc> and then wait til someone puts it in backports :)
<Chipaca> and, and, it sets TERM to xterm-256color
<Chipaca> and xterms do _so much more_!
<nacc> heh
<Chipaca> and faster, also
<Chipaca> I can measure the width taken by every unicode character on an xterm in under five minutes, wheras I need 10 instances running gnome terminal for an hour
<Chipaca> anyhow. silly rant over.
<zyga> echo -e '\e#8'
<zyga> this is fun :)
<Chipaca> 'alignment test'?
<zyga> indeed
<Chipaca> man
<Chipaca> heh, you want to hear a funny one
<Chipaca> microsoft added support for DEC graphics charset to their terminal recently
<zyga> good
<zyga> at least microsoft documents stuff now :)
<Chipaca> but in the dec character chart
<Chipaca> they have some codepoints with things like
<Chipaca> â
<Chipaca> microsoft thought they were carriage returns :-D
<Chipaca> https://vt100.net/docs/vt220-rm/table2-4.html for reference
<Chipaca> so on windows if you do  printf '\033(0c\033(B\n'
<Chipaca> it throws an actual form feed at you
<Chipaca> (compare with https://vt100.net/docs/vt220-rm/table2-1.html)
 * Chipaca shuts up about obscure silliness and gets back to fixing snapcraft
<gsilvapt> Hello all. Need some help as I never done this kind of work. I contributed to snapcraft a few months ago and haven't update my remotes for a while
<gsilvapt> So if I checkout to master, do git pull upstream (upstream...) master and git push origin (my fork) master should update my fork as well?
<Chipaca> gsilvapt: hmm... that's not how I do it
<mup> PR snapcraft#1956 opened: snap: actually plug the completer in <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1956>
<Chipaca> gsilvapt: I do: git checkout master, then git fetch upstream, then git merge upstream/master, then git push origin
<Chipaca> gsilvapt: but git is hairy enough that these two might be equivalent
<Chipaca> Â¯\_(ã)_/Â¯
<gsilvapt> Chipaca, uhh, I'm noob in open source projects. I'm only used to work in a single remote :P
<gsilvapt> That makes sense too
<Chipaca> fwiw I've stashed it all into a single command 'git sync', https://github.com/chipaca/bin/blob/master/git-sync
<Chipaca> gsilvapt: a neat trick of git is that any command that you call git-foo in your path, git'll happily use as 'git foo'
<Chipaca> so if aliases aren't enough you can do that
<gsilvapt> Chipaca, thanks!
<gsilvapt> Chipaca, I was checking the commit logs in my remote and they seem right in comparison to the upstream's: https://github.com/gsilvapt/snapcraft/commits/master
<gsilvapt> Guess we both learned something, haha :D
<Chipaca> gsilvapt: :-)
<Chipaca> gsilvapt: good thing is, if they're the same, it'll tell you
<Chipaca> so you can push/pull again if in doubt
<gsilvapt> Chipaca, you mean using the aliases? Hum, never did that before. Interesting!
<Chipaca> gsilvapt: no i mean, git push origin; git push origin -> second one says "meh"
<gsilvapt> Chipaca, ahh! I see
<gsilvapt> elopio, you around?
#snappy 2018-02-24
<zyga> ok, it's time to EOW
<zyga> see you next week John!
<zyga_> o/
<Chipaca> jdstrand: you around by chance?
<Son_Goku> huh
<Chipaca> something's broken with completion
<Chipaca> :-(
<Chipaca> ohh maybe it's just the snap
<Chipaca> yuss
<Chipaca> stgraber: you here?
<Chipaca> woo, i have code in lxd!
 * Chipaca stretched the definition of code *so much*
<Chipaca> zyga: you around?
<zyga> Yes
<zyga> how are you? :)
<zyga> *disclaimer: I'm not *always* here :)
<Chipaca> zyga: hiya
<zyga> hi :)
<Chipaca> zyga: procrastinating so hard from tiding up my mess of cables, I'm looking at spread failures
<Chipaca> (also: it's freezing, and i'm in bed where it's nice and warm, and the cables are out in the inhospitable cold)
<Chipaca> zyga: seeing this:
<Chipaca> AppArmor parser error for /etc/apparmor.d/snap.core.4142.usr.lib.snapd.snap-confine in /etc/apparmor.d/snap.core.4142.usr.lib.snapd.snap-confine at line 11: Could not open '/var/lib/snapd/apparmor/snap-confine.d'
<zyga> it's -11 now, I hope it's not that cold in UK
<zyga> oh, that's curious
<zyga> that .d directory is created by snapd and is in packaging
<Chipaca> zyga: nah, just reaching zero
<zyga> do you have the seed?
<zyga> ah, so "literally freezing" :)
<Chipaca> log is https://api.travis-ci.org/v3/job/345729874/log.txt
<Chipaca> zyga: seed is -seed=1519502376
<zyga> I think chasing those is somewhat annoying as it's a never-ending game without better automation which would say "oops, this test didn't clean up properly"
<zyga> I'm looking at the log
<zyga> oh
<zyga> -R
<zyga> -R is *remove*
<zyga> which is so ... silly here
<zyga> we want to remove a profile
 * Chipaca is no wiser
<zyga> but we cannot because #include thing is missing
<zyga> is this master or some PR?
<Chipaca> .. because it was removed just prior?
<Chipaca> i mean, it's a PR, but it doesn't touch any of that
<Chipaca> https://github.com/snapcore/snapd/pull/4737
<mup> PR #4737: cmd/snap: tweaks to 'snap info' (feat. installed->current rename) <Created by chipaca> <https://github.com/snapcore/snapd/pull/4737>
<zyga> yeah
<zyga> hmm hmm
<zyga> Chipaca I'll run this and see if it happens
<Chipaca> k
<zyga> after 18.04 I plan to redo prepare/restore thing
<zyga> it's wrong wrong wrong IMO
<gsilvapt> Is there a particular reason to have a vscode folder in the snapcraft repository? just wondered
<Chipaca> gsilvapt: I don't know, but looking at its contents it seems to help people using vscode run the unit tests from the ide
#snappy 2018-02-25
<mup> PR snapcraft#1957 opened: schema: improve the snap name's validator <Created by chipaca> <https://github.com/snapcore/snapcraft/pull/1957>
<zyga> 2.29.4.2+17.10 gives me lut 25 22:08:15 fyke kernel: audit: type=1400 audit(1519592895.774:1751): apparmor="DENIED" operation="exec" profile="/usr/lib/snapd/snap-confine" name="/usr/lib/snapd/snap-device-helper" pid=39793 comm="snap-confine" requested_mask="x" denied_mask="x" fsuid=0 ouid=0
<zyga> https://pastebin.ubuntu.com/p/sj6s9qNzFQ/
<zyga> nothing in snapd logs
<zyga> I'm running 2.29.4.2+17.10
<zyga> my installed core is 4144
<zyga> and it seems that al snaps fail on snap-device-helper
<mup> PR snapd#4738 opened: snap: unify snap name validation w/python; enforce length limit <Created by chipaca> <https://github.com/snapcore/snapd/pull/4738>
#snappy 2019-02-18
<mup> PR snapd#6517 closed: tests: disable trusty-proposed for now <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6517>
<mup> PR snapcraft#2474 opened: build providers: remove dead code <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2474>
<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
<sil2100> mvo: hey! Regarding the trusty linux-lts-xenial issue, did you file a bug by any chance?
<sil2100> (is it actually still an issue?)
<mup> PR snapd#6506 closed: overlord/snapstate: add some randomness to the catalog refresh <Squash-merge> <â  Critical> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6506>
<mvo> sil2100: https://bugs.launchpad.net/ubuntu/+source/linux-meta-lts-xenial/+bug/1816390
<mup> Bug #1816390: trusty-proposed not installable <linux-meta-lts-xenial (Ubuntu):New> <https://launchpad.net/bugs/1816390>
<mvo> sil2100: hope this is providing enough context? sorry its a bit terse
<mup> PR snapd#6511 closed: daemon/api: fix error case for disconnect conflict <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/6511>
<sil2100> mvo: thanks! That's enough, actually I'm confused as when I poked you about it I was not able to reproduce it on my schroot
<sil2100> mvo: ...but now I am able to
<sil2100> mvo: confusing ;)
<sil2100> apw: ^
<sil2100> (strange, it seems to not be able find the signed packages, although they're there and fully published)
<mup> PR snapcraft#2475 opened: sources: avoid marking changes to the snap directory as dirty <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2475>
<ogra> mvo, where does the initrd for core18 images come from ? afaik it isnt shipped in the core18 snap, is it ?
<apw> sil2100, ?
<mvo> ogra: correct, still in core for the snapcraft plugin or from ppa:snappy-dev/iamge for the canonical kernel
<apw> sil2100, was that over night?  as -signed was not published over night
<mup> PR snapcraft#2474 closed: build providers: remove dead code <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2474>
<sil2100> apw: it's happening even now, at least on my chroot
<sil2100> apw: which is strange, since at first I was not able to reproduce, now I can reproduce it again
<sil2100> Weird
<sil2100> Still busted it seems
<apw> sil2100, ok
<mup> PR snapd#6516 closed: interfaces/seccomp: generate global seccomp profile <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6516>
<kyrofa> nessita, roadmr, cprov: referring to https://dashboard.snapcraft.io/docs/api/macaroon.html#restricted-upload-rights , is there a way to request a macaroon that can upload to edge/<hotfix> channels? Just "edge" seemingly doesn't include them. Can I do "edge/*" or something?
<cprov> kyrofa: it's a recent change, you can do edge/*
<kyrofa> No waaay, awesome
<kyrofa> Is that actually a pattern? Can I take that even further? edge/prefix-* for example? Or is <risk>/* a specific thing?
<cprov> kyrofa:  it's a simple glob, risk/*
<cprov> No prefix/ regex
<kyrofa> cprov, works great, thank you :)
#snappy 2019-02-19
<mvo> oh no - build failure on snapd in disco https://launchpad.net/ubuntu/+source/snapd/2.37.3+19.04/+build/16406481
<mborzecki> mvo: can you upload the source packages to github releases page?
<mvo> mborzecki: yes, on it
<mborzecki> mvo: thank you!
<mvo> mborzecki: done
<mborzecki> mvo: yay!
<mborzecki> arch updated to 2.37.3
<mup> PR snapd#6518 opened: release: 2.37.3 <Created by mvo5> <https://github.com/snapcore/snapd/pull/6518>
<zyga> Chipaca: https://twitter.com/Alhenamedia/status/1097443153500663810
<Chipaca> zyga: niemeyer: https://en.wikipedia.org/wiki/Atta_laevigata
<oSoMoN> jdstrand, hey, would it be acceptable to request the u2f-devices to be auto-connected for the chromium snap?
<Chipaca> sergiusens: should snapcraft still be suggesting $snap-$username ?
<mup> PR snapd#6519 opened: squashfs: unset SOURCE_DATE_EPOCH in the TestBuildDate test <Created by mvo5> <https://github.com/snapcore/snapd/pull/6519>
<mup> PR snapd#6520 opened: wrappers: Add an X-SnapName field to desktop files <Created by robert-ancell> <https://github.com/snapcore/snapd/pull/6520>
<mup> PR snapd#6518 closed: release: 2.37.3 <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6518>
<mup> PR snapd#6512 closed: overlord: fix random typos <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6512>
<mup> PR snapcraft#2476 opened: tests: disable spread colcon tests <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2476>
<mup> PR snapcraft#2477 opened: ci: shallow clones for CLA checks on travis <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2477>
<zyga> Pharaoh_Atem: hey, I will release 2.37.3
<zyga> Pharaoh_Atem: into fedora
<zyga> Pharaoh_Atem: it's been too long since the last time I got involved
<mup> PR snapd#6497 closed: features,cmd/libsnap: add new feature "refresh-app-awareness" <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6497>
<Son_Goku> zyga, okay :)
<Son_Goku> to note, there are intentionally differences in the spec files between fedora and upstream
<Son_Goku> so try to account for them
<zyga> Son_Goku: yeah
<zyga> Son_Goku: quick question, are you uploading .no-vendor tarball as just the plain name
<Son_Goku> spectool -g snapd.spec gets you the tarballs I use ;)
<zyga> k, thank you
<Son_Goku> just bump the version then run the command
<Son_Goku> and don't forget to merge in the changelog entries, you can see how the changelog is structured for previous releases
<Son_Goku> at some point, I need to sync those back into upstream
<Son_Goku> it makes it less painful in the future
<zyga> Son_Goku: looking now
<zyga> Son_Goku: that's odd, so you get the vendorized sources
<zyga> is there a reason for that?
<zyga> Son_Goku: I think the build is straightforward, my memory is just rusty
<zyga> running now
<Son_Goku> zyga, I pick up the vendor tarball for EL7
<zyga> ah
<zyga> but you get  snapd.tar.gz
<zyga> and snapd.only-vendor.tar.gz
<zyga> that's odd, no?
<Son_Goku> nope
<zyga> only-vendor, what is that for?
<Son_Goku> snapd.tar.gz comes from github
<zyga> aaah
<zyga> you should get no-vendor.tar.gz
<Son_Goku> I haven't switched to the release no-vendor tarball yet
<zyga> it's explicitly uploaded by mvo
<zyga> and debian/suse use it too
<zyga> ah, ok
<zyga> that explains it
<zyga> thanks!
<zyga> I may consider switching after .3
<Son_Goku> I was planning on changing it in 2.38, when the selinux stuff lands
<Son_Goku> the original reason for relying on the github tarball was that mvo wasn't always consistently uploading them
<Son_Goku> that's no longer the case, so I can switch to them
<zyga> yeah, it's fixed now
<zyga> it's automated
<zyga> Pharaoh_Atem: the patch I have is:
<zyga> https://paste.fedoraproject.org/paste/SbZ7PBk1Bq3jtp-GA~pQzw
<Son_Goku> commit message in Git is wrong, and changelog merge is missing
<Son_Goku> and your email address is missing from your changelog entry
<zyga> how is the commit message wrong?
<Son_Goku> "Release 2.37.2 to Fedora (RH#1678603)"
<Son_Goku> I already did 2.37.2
<Son_Goku> you're doing 2.37.3
<zyga> ohh
<Son_Goku> and the changelog entry should also be this message
<Son_Goku> but when I was referring to the changelog merge, I'm referring to the upstream entry mvo makes
<zyga> https://paste.fedoraproject.org/paste/nJEJBAS7unjzP2TZM3mzdg
<Son_Goku> the one with the details
<zyga> ahhh
<zyga> ok
<zyga> do you just merge that manually?
<Son_Goku> yep
<zyga> duure
<zyga> sure
<zyga> Son_Goku: https://paste.fedoraproject.org/paste/CQdWC7JvmHwoxpqycq5fYA
<Son_Goku> perfecto!
<zyga> I think this looks good now
<zyga> cool
<zyga> commiting
<zyga> :)
<zyga> (new sources added)
<zyga> well, pushiing
<zyga> shall I merge this into F29 and F30/
<Son_Goku> fedpkg push && fedpkg build
<Son_Goku> and merge it into f30, f29, f28, and epel7
<Son_Goku> and do fedpkg build for each of them
<zyga> ok
<zyga> question, do I need separate permissions for EPEL?
<Son_Goku> nope
<zyga> good :)
<zyga> thank you!
<zyga> refreshing my memory is useful
<Son_Goku> after fedpkg build for everything, then you'll need to do fedpkg update
<zyga> that's bodhi?
<Son_Goku> yep
<zyga> cool
<zyga> gladly :)
<zyga> let me do the other branches first
<Son_Goku> you'll need to do that in each branch except master
<Son_Goku> yep
<Son_Goku> they have to build successfully in each branch first before you do update
<zyga> ok
<Son_Goku> looks like there's no f30 branch yet
<zyga> Son_Goku: is there a ppc64 non le (that is big endian) arch used in practice in fedora?
<Son_Goku> so it's just f29, f28, and epel7
<Son_Goku> in fedora 28 yes
<zyga> mmm
<Son_Goku> but it's excluded, I think?
<zyga> we don't support it
<zyga> ok, just checking
<Son_Goku> and it's been dropped since f29
<zyga> thank you, I'll churn the rest of the update now
<zyga> koji is working :)
<zyga> Pharaoh_Atem: what is phx2
<zyga> what kind of architecture is that?
<zyga> Pharaoh_Atem: koji for rawhide passed, doing f29 now
<zyga> I just merged master and doing a local mock build
<zyga> Notification time stamped 1970-01-01 00:00:00 UTC <- from notifications@fedoraproject.org
<zyga> Pharaoh_Atem: do I need to edit  https://bugzilla.redhat.com/show_bug.cgi?id=1678603
<zyga> I tried to log in but it would bounce me around some sites and fail
<diddledan> can someone try a snap that connects hardware-observe please? I'm connecting my makemkv snap to the interface but it seemingly has zero effect on the apparmor profile
<diddledan> this is the supposedly-connected profile: https://paste.ubuntu.com/p/pbC9PSk7nY/
<diddledan> @jdstrand might be interested here?
<diddledan> snap interfaces makemkv: https://paste.ubuntu.com/p/fST3YGrK5Q/
<diddledan> snap version: https://paste.ubuntu.com/p/MNn82fQFGz/
<mup> PR snapd#5822 opened: wrappers: allow user mode systemd daemons <Created by jhenstridge> <https://github.com/snapcore/snapd/pull/5822>
<zyga> Son_Goku: fedpkg update misbehaves for me, am I doing something wrong
<zyga> [zyga@10-155-118-225 snapd]$ fedpkg update
<zyga> Could not execute update: Could not generate update request: ServerError(https://bodhi.fedoraproject.org/updates/, 400, Error returned from json module while processing b'https://bodhi.fedoraproject.org/updates/': b'Expecting value: line 6 column 1 (char 5)'
<zyga> ^ then tons of garbage thml
<zyga> *html
<Son_Goku> welp
<Son_Goku> no
<Son_Goku> there was a new deploy of bodhi
<Son_Goku> looks like there's a bunch of bugs
<zyga> fun :)
<zyga> should I just wait and retry at some point later
<Son_Goku> let bowlofeggs know in #fedora-devel
<zyga> k
<zyga> thank you
<Son_Goku> he should be able to advise you on the best course
<zyga> Son_Goku: bodhi updates https://bodhi.fedoraproject.org/updates/FEDORA-2019-733be62cc6 and https://bodhi.fedoraproject.org/updates/FEDORA-2019-38b02b2953
<zyga> sorry, one  has vanilla karma,
<zyga> got confused by the bodhi bug
<zyga> fixedn ow
<zyga> *fixed now
<zyga> Son_Goku: thank you for the help, the update is ready for testing
<Son_Goku> what about epel7?
<zyga> ohooh
<zyga> doing :)
<zyga> thanks' forgot about it
<zyga> building  now
<mup> PR # closed: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2464, snapcraft#2469, snapcraft#2470,
<mup> snapcraft#2473, snapcraft#2475, snapcraft#2476, snapcraft#2477
<mup> PR # opened: snapcraft#1649, snapcraft#1720, snapcraft#1875, snapcraft#2020, snapcraft#2135, snapcraft#2176, snapcraft#2229, snapcraft#2239, snapcraft#2398, snapcraft#2413, snapcraft#2433, snapcraft#2444, snapcraft#2445, snapcraft#2463, snapcraft#2464, snapcraft#2469, snapcraft#2470,
<mup> snapcraft#2473, snapcraft#2475, snapcraft#2476, snapcraft#2477
<zyga> Son_Goku: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-db69fd722a
<zyga> Son_Goku:                "diag" : "File <var>/usr/libexec/snapd/snap-confine</var> is setuid root and setgid root but is not on the setxid whitelist.",
<zyga> Son_Goku: how can we get on the setxid whitelist?
<Son_Goku> I don't know, it's worth asking, though
<zyga> mhm
<Laney> hi
<Laney> would you be opposed to adding systemd user environment generators as well as the profile.d ones?
<Laney> the profile.d things aren't run in all situations (for example, for me with zsh)
<zyga> Laney: we had some issues with generators lately
<zyga> I'm also using zsh but I think we want to just be careful since it's such a powerful thing that can break many thinigs
<mup> PR snapd#6521 opened: daemon: make ucrednetGet not loop <Created by chipaca> <https://github.com/snapcore/snapd/pull/6521>
<mup> PR snapd#6522 opened: tests: add regression test for LP: #1813365 <Created by zyga> <https://github.com/snapcore/snapd/pull/6522>
#snappy 2019-02-20
<mup> PR snapd#6522 closed: tests: add regression test for LP: #1813365 <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6522>
<mup> PR snapd#6519 closed: squashfs: unset SOURCE_DATE_EPOCH in the TestBuildDate test <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6519>
<Laney> zyga: oh yeah, do you have some references?
<zyga> Laney: not at the moment, we had some woes with systemd bugs regarding environment generators that resulted in us disabling them until those bugs are fixed
<Laney> hmm
<Laney> afaik you could basically duplicate the profile.d scripts in there
<Laney> just being careful to not add dupes of course
<Laney> I'll play with it
<zyga> Laney: please, if you can get it to work we will take it
<zyga> Laney: we just got burned by injecting environment into the system
<zyga> jdstrand: if you have a moment today, could you please look at https://github.com/snapcore/snapd/pull/6499
<mup> PR #6499: cmd/snap-confine: allow moving tasks to pids cgroup <Created by zyga> <https://github.com/snapcore/snapd/pull/6499>
<jdstrand> zyga: I commented
<kjackal> Hi snappy people, I see this strange behavior when "snapcraft cleanbuild". The build seems stuck with "Network connection established" on the terminal and waits for input from the kyeboard
<zyga> jdstrand: thank you
<kjackal> https://pastebin.ubuntu.com/p/bZP5NWrJZm/
<kjackal> Any ideas how to debug/increase log verbosity?
<mup> PR snapcraft#2476 closed: tests: disable spread colcon tests <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2476>
<mup> PR snapcraft#2477 closed: ci: shallow clones for CLA checks on travis <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2477>
<mup> PR snapd#6523 opened: snap, wrappers: support StartTimeout <Simple ð> <Created by chipaca> <https://github.com/snapcore/snapd/pull/6523>
<mup> PR snapd#6521 closed: daemon: make ucrednetGet not loop <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6521>
<mup> PR snapd#6524 opened: tests: add attribution to helper script <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6524>
<zyga> Chipaca: https://github.com/snapcore/snapd/pull/6524
<mup> PR #6524: tests: add attribution to helper script <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/6524>
<mup> PR snapcraft#2478 opened: meta: handle symlinked hooks <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2478>
<mup> PR snapd#6524 closed: tests: add attribution to helper script <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6524>
 * dot-tobias says hi
<mup> PR snapd#6525 opened: interfaces/wayland: allow wayland server snaps function on classic too <Created by gerboland> <https://github.com/snapcore/snapd/pull/6525>
<mup> PR snapd#6526 opened: tests: run tests on opensuse leap 15.0 instead of 42.3 <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/6526>
<mup> PR snapd#6527 opened: cmd/snap: produce better output for help on subcommands <Created by chipaca> <https://github.com/snapcore/snapd/pull/6527>
<mup> PR snapcraft#2478 closed: meta: handle symlinked hooks <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2478>
<Chipaca> pstolowski|sprnt: https://forum.snapcraft.io/t/config-files-not-updated/8422/21
<oSoMoN> cwayne, I'd like to discuss automated testing of the chromium snap, when you have a moment
<cwayne> oSoMoN: sure, Friday's good for me
<ogra> Feb 20 13:12:10 tinkerboard initrd: date set from /scripts/local-bottom/fixrtc-mount (Wed Feb 20 13:12:08 UTC 2019)
<ogra> hrm ... no mvo
<mup> PR snapd#6528 opened: tests/main/nfs-support: use archive mode for creating fstab backup <SELinux> <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6528>
<mup> PR snapd#6529 opened: daemon, client, cmd/snap: snap debug base-declaration <Created by chipaca> <https://github.com/snapcore/snapd/pull/6529>
<zyga> stgraber: hey, does lxd manage bpf filesystem inside containers
<stgraber> zyga: no, bpf isn't particularly namespaced AFAIK and it's also completely unsafe to use for non-root users (the kernel will usually disallow it)
<Wimpress> Join Snapcraft Live to learn how to publish apps in the Snap Store - https://www.youtube.com/watch?v=h2Dp_D7PZh8
<zyga> stgraber: thank you for responding
<mup> PR snapd#6496 closed: many: collect time each task runs and display it with `snap debug timings <id>` <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6496>
<diddledan> layout fails with symlink for /etc/wgetrc:
<diddledan> - Setup snap "makemkv" (unset) security profiles (cannot update mount namespace of snap "makemkv": cannot update preserved namespace of snap "makemkv": cannot update snap namespace: cannot create symlink in "/etc/wgetrc": existing file in the way)
#snappy 2019-02-21
<mup> PR snapd#6528 closed: tests/main/nfs-support: use archive mode for creating fstab backup <SELinux> <Simple ð> <Created by bboozzoo> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/6528>
<Chipaca> mborzecki: what was the pr you wanted reviewed?
<mborzecki> Chipaca: #6079
<mup> PR #6079: cmd/snap: `snap connections` command <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/6079>
<Chipaca> mborzecki: sorry i can't review things on the second page
<Chipaca> mborzecki: shouldn't we revisit the "interface first" thing to see what the decision is/was first?
<Chipaca> mborzecki: I'll ask pedronis
<mborzecki> Chipaca: it's just a column, we can shift it any time
<Chipaca> mborzecki: that's what *she* said!
<Chipaca> mborzecki: i need to wait for spread to finish here before i cna build and test it :-)
<Chipaca> mborzecki: but yeah, on it
<mborzecki> Chipaca: thanks!
<Chipaca> mborzecki: pushed validation and spread tests to the start-timeout thing
<ackk> hi, is an interface required to run xdg-open in a snap?
<mup> PR snapd#6530 opened: overlord/ifacestate: fix migration of connections on upgrade from ubuntu-core <Squash-merge> <Created by stolowski> <https://github.com/snapcore/snapd/pull/6530>
<mborzecki> ackk: desktop interface should be enough
<ackk> mborzecki, this this change recently? ISTR xdg-open was in core before
<mborzecki> ackk: no, there was no change, maybe i misunderstood your question, you can run xdg-open regardless of having desktop interface being connected, but it only does useful things iff the interface is connected
<ackk> mborzecki, I get an error if I try to run /usr/bin/xdg-open  from a snap run --shell
<mborzecki> ackk: hm, my bad --> /usr/bin/xdg-open ixr <-- that's from desktop interface apparmor profile, so you can run it iff desktop is connected after all
<ackk> mborzecki, I see, thanks. it didn't use to be the case though, we had snaps that worked without that interface
<zyga> https://wiki.linaro.org/Platform/LAB/LMP_in_practice
<Gargoyle> diddledan: Is the snapcraft forum the best place for issues to be reported (tl;dr = cant open EPS in snap version, but works fine in apt version)?
<Gargoyle> ^^ for GIMP
<ackk> mborzecki, I now get this error (with the desktop interface connected): user-open error: exec: "dbus-launch": executable file not found in $PATH
<mborzecki> ackk: is there no session bus started?
<ackk> mborzecki, I'm running it on my desktop so I guess so :)
<ackk> mborzecki, this is not a --classic snap if it matter
<ackk> *matters
<cjwatson> core18 is now supported on build.snapcraft.io; have fun
<mup> PR snapcraft#2479 opened: store: support registering to a specific store <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2479>
<dot-tobias> I'm trying to use the shutdown interface in a strictly confined snap, but am getting permission denied on systemd/reboot.target. Any quick pointers to where I'm missing something are appreciated: https://forum.snapcraft.io/t/system-reboot-from-within-a-strictly-confined-snap/10080
<diddledan> Gargoyle: thanks for alerting me :-)
<diddledan> I'll see what I can do to fix it
<Gargoyle> diddledan: NP. I saw the "call for testing" thread and saw it was loooong and old. Wasn't sure if it was the place to add it.
<Chipaca> dot-tobias: https://forum.snapcraft.io/t/how-to-reboot-device/1142
<Chipaca> dot-tobias: in particular https://forum.snapcraft.io/t/how-to-reboot-device/1142/3?u=chipaca
<dot-tobias> Chipaca: Thank you! I guess my search queries on the forum were too specific as this thread didn't turn up (at least on pages 1+2 ð )
<Chipaca> dot-tobias: yeah i had to search in a few ways and only persevered because i knew it was there somewhere
<mup> PR snapcraft#2481 opened: meta: handle symlinked hooks (#2478) <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2481>
<mup> PR snapcraft#2482 opened: docs: update pull request template <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2482>
<mup> Bug #1683942 changed: Startup logs showed after the "Please Enter to configure" message <Snappy:New> <subiquity:New> <https://launchpad.net/bugs/1683942>
<mup> PR snapd#6527 closed: cmd/snap: produce better output for help on subcommands <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6527>
<mup> PR snapd#6531 opened: cmd/snap: fix error messages for snapshots commands if ID is not uint <Created by stolowski> <https://github.com/snapcore/snapd/pull/6531>
<zyga> mborzecki: https://github.com/sharkdp/hyperfine
<mup> PR snapd#6520 closed: wrappers: Add an X-SnapInstanceName field to desktop files <Created by robert-ancell> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6520>
<mup> PR snapd#6532 opened: daemon: allow downloading snaps blobs via .../blobs <Created by chipaca> <https://github.com/snapcore/snapd/pull/6532>
<mup> PR snapd#6523 closed: snap, wrappers: support StartTimeout <Simple ð> <Created by chipaca> <Merged by chipaca> <https://github.com/snapcore/snapd/pull/6523>
<diddledan> Gargoyle: `snap refresh --stable gimp` :-D
<Gargoyle> Works! Sweet!
<Gargoyle> Is there a fix for browsing network shares in snaps - I get the "does not support mount" error which I have seen elsewhere too.
<Gargoyle> I'm guessing it's related to this:- https://github.com/snapcrafters/gimp/issues/32
<Gargoyle> Personally, I keep almost all project files on a NAS drive on my LAN. :/
<Gargoyle> Would that not be an issue if I "properly" mounted my NAS drive shares instead of just browsing to them on demand?
<luk3yx> Whenever I try and set my snap's license to "LGPL 2.1 or later", I get an "Invalid symbols sequence such as (A B) for token: "-" at position: 8 " error.
#snappy 2019-02-22
<jibel> sergiusens, Hi, I'm rebuilding snaps of java apps against core18 and get an error: Failed to load plugin: unknown plugin: 'jdk'
<jibel> sergiusens, what's the name of the plugin now?
<jibel> or is it completely gone
<sergiusens> jibel: we only have maven and ant now
<sergiusens> jibel: that `jdk` just added `stage-packages` so it made little sense to carry it forward
<jibel> k, thanks
<mup> Bug #1637145 changed: console-conf breaks working wifi when rebooting before user is created <Snappy:Fix Released> <subiquity:Fix Released> <https://launchpad.net/bugs/1637145>
<kjackal> hi snappy people, I have good reason to believe the autotools plugin is broken for at least classic confinement
<kjackal> opened a bug https://bugs.launchpad.net/snapcraft/+bug/1817300
<mup> Bug #1817300: autotools plugin fails to build in classic confinement <Snapcraft:New> <https://launchpad.net/bugs/1817300>
<pstolowski|sprnt> greyback: hey, before i forget: https://forum.snapcraft.io/t/interface-hooks/8214
<greyback> pstolowski|sprnt: ah, excellent, thank you!
<pstolowski|sprnt> greyback: to complete the picture, the Go implementation of the interface (the *ConnectedPlug/Slot methods) can be enhanced to understand attributes set by interface hooks
<pstolowski|sprnt> greyback: that means the security snippet the interface generates can take these attributes into account
<greyback> pstolowski|sprnt: ok, that's interesting
<pstolowski|sprnt> greyback: the only "limitation" is that we don't re-run them on reboots to see if anything changed in the runtime; they only run on `snap connect ..`
<greyback> pstolowski|sprnt: which is reasonable
<greyback> well for what I'm thinking of
<greyback> pstolowski|sprnt: thanks, that's given me an option to think about
<pstolowski|sprnt> greyback: np; i was thinking about your case, i not grashing all the details but i've a feeling the above can help
<pstolowski|sprnt> *i'm not
<thresh> hey.  I screwed up by doing snapcraft register for a wrong account.  Is there a way to transfer ownership of a snap on a store?
<mup> PR snapd#6533 opened: interfaces/seccomp: increase filter precision <Created by zyga> <https://github.com/snapcore/snapd/pull/6533>
<greyback> thresh: you could ask on https://forum.snapcraft.io/c/store
<thresh> greyback, thanks!
<mup> PR snapcraft#2483 opened: cli: Handle legitimate provider exec errors <Created by cmatsuoka> <https://github.com/snapcore/snapcraft/pull/2483>
<mup> PR snapcraft#2484 opened: project loader: remove special LD_LIBRARY_FLAGS handling for classic <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2484>
#snappy 2019-02-23
<thresh> how can I know which interfaces are autoconnected on a snap published via store?
<mup> PR snapd#6534 opened: tests: remove snapweb from tests <Created by mvo5> <https://github.com/snapcore/snapd/pull/6534>
<mup> PR snapcraft#2484 closed: project loader: remove special LD_LIBRARY_FLAGS handling for classic <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2484>
#snappy 2019-02-24
<mup> PR snapd#6534 closed: tests: remove snapweb from tests <Created by mvo5> <Merged by zyga> <https://github.com/snapcore/snapd/pull/6534>
#snappy 2020-02-17
<amurray> mwhudson: https://bugs.launchpad.net/ubuntu/+source/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>
<mwhudson> amurray: good morning
<amurray> hey mwhudson :)
<mwhudson> yes i see "apparmor="DENIED" operation="connect" profile="snap.chromium.chromium" pid=41956 comm="pool" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/home/mwhudson/.cache/ibus/dbus-FTeGlGGx" peer="unconfined"" too
<mup> PR snapd#8141 opened: interfaces/desktop-legacy: ibus socket path has moved in focal <Created by alexmurray> <https://github.com/snapcore/snapd/pull/8141>
<mup> PR snapd#8141 closed: interfaces/desktop-legacy: ibus socket path has moved in focal <Created by alexmurray> <Closed by alexmurray> <https://github.com/snapcore/snapd/pull/8141>
<amurray> hah I should read scrollback from all channels before diving into stuff - jdstrand already sent a PR for this on friday (PR #8139)
<mup> PR #8139: interfaces/{desktop-legacy,unity7}: adjust for new ibus socket location <Simple ð> <Created by jdstrand> <https://github.com/snapcore/snapd/pull/8139>
<mup> PR snapd#8139 closed: interfaces/{desktop-legacy,unity7}: adjust for new ibus socket location <Simple ð> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8139>
<mborzecki> morning
<mvo> hey mborzecki - good morning
<mborzecki> mvo: hey
<mborzecki> mvo: how was your weekend?
<zyga> good morning!
<zyga> mvo: hey,
<zyga> mvo: I merged a small patch last night
<zyga> mvo: I was thinking we should dput that patch into focal
<zyga> mvo: as it breaks snap X input for some users
<zyga> mvo: the patch in question is in https://github.com/snapcore/snapd/pull/8139
<mup> PR #8139: interfaces/{desktop-legacy,unity7}: adjust for new ibus socket location <Simple ð> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8139>
<zyga> mvo: it consists of extra permissions to talk to the current ibus api over dbus
<zyga> er. unix
<zyga> (not dbus, sorry)
<mvo> mborzecki: hey, sorry for the delay, was reviewing #8078. weekend was good, a bit windy yesterday and tonight, another storm here
<mup> PR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>
<mvo> mborzecki: how was yours?
<mvo> zyga: hey, let me see
<mvo> zyga: aha, I see
<zyga> mvo: let me know if I can help
<zyga> mvo: I think I cannot dput to the archive (even snapd)
<zyga> mvo: but if you want I can try
<mvo> zyga: should be trivial, let me just finish my current stuff and then I will do it
<mborzecki> zyga: hey
<zyga> hey maciek :)
<mborzecki> wow that ibus thing, saw the emails
<mborzecki> guess a lot of folks were unhappy :/
<zyga> :D
<zyga> yeah, it's still the dev release but I guess people noticed
<mborzecki> zyga: afaik it broke chromium too
<zyga> brb
<zyga> mborzecki: hey
<zyga> mborzecki: on Friday I was working on modernizing services code
<zyga> mborzecki: and port it over to syncdir
<zyga> mborzecki: I will post some of that today
<zyga> I noticed I got a review from jamie so I'll part everything and handle that first
<zyga> mborzecki: oh and a small one for you 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>
<mup> PR snapd#8134 closed: interfaces: use commonInteface for desktopInterface <Created by zyga> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8134>
<mup> PR snapd#8127 closed: interfaces/cpu-control: allow to control cpufreq tunables <Created by alexmurray> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8127>
<mvo> 8078 needs a second review, then it can go in
<mvo> zyga: uploaded to focal
<zyga> mvo: thank you so much!
<zyga> the download API has evolved, I see
 * mwhudson installs snapd from https://launchpad.net/ubuntu/+source/snapd/2.43.3+git1.8109f8/+build/18717296
<mwhudson> yay i can type again
<zyga> haha, same here :)
<pstolowski> morning
<mborzecki> pstolowski: hey!
<mvo> hey pstolowski
<zyga> good morning pawel!
<Saviq> hey guys, on focal my snapped firefox (and actually some other app prior) lost its gtk runtimeâ¦ discarding ns helped https://pastebin.canonical.com/p/yZNy7mNjrv/ - but is there a known problem?
<Saviq> anything else I can dig out?
<Saviq> zyga: FYI â
<zyga> Saviq: 1-2-1 now
<Saviq> nw
<zyga> Saviq: hmmm
<zyga> Saviq: it might be, perhaps, let me look
<zyga> hmm
<zyga> not sure, we have one thing that fixes a class of bugs like that that's not enabled by default
<zyga> so without extra digging I cannot say with certainty that the issue you experienced is covered by that change
<zyga> Saviq: I'm thinking about 8089
<zyga> this changes the default on an experimental setting
<zyga> Saviq: I'll try to get it ready for 2.44
<Saviq> zyga: it's not like I have a reproducer, but it did happen twice on two different snaps for me
<Saviq> I'll let you know if it's back, maybe we can dig live
<zyga> thank you
<zyga> Saviq: if you want you can also set the config option
<zyga> Saviq: snap set core experimental.robust-mount-namespace-updates=true
<pedronis> #8078 needs a 2nd review
<mup> PR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>
<zyga> pedronis: going through it now
<zyga> reviewed with some questions
<zyga> I also requested a review from jamie
<zyga> mvo: ^ fyi
<mvo> zyga: ta
<pedronis> mvo: to be clear I don't think it needs to be blocked on jamie given that there is no special bypassing of the usual auth checks, I answerd some of the comments there
<mvo> pedronis: ta, i add some tests around the range header now, that was indeed under-tested
<mup> PR core20#21 closed: Add bash-completion support <Created by xnox> <Merged by xnox> <https://github.com/snapcore/core20/pull/21>
<mborzecki> from the forum `> I run a once annual update` why would someone do this to themselves?
<zyga> mborzecki: clearly it is when their asteroid comes in close proximity with earth
<mborzecki> otoh users seem to have come up with some bizarre ways to worakroudn the auto update, maybe we should just allow disabling it and default to auto update? then any support requests start with -> please update to the latest version
<zyga> mborzecki: on that thread, do we still have the refresh timer?
<mborzecki> zyga: not sure we ship it anymore
<zyga> brb, more tea
<mvo> pedronis: hey, a quick question about the download client api (client/snap_op.go). For Client.Download() we currently pass "SnapOptions", for the download with resume we need to add peekHeader and resumeToken, should I add a new DownloadOptions that embeed SnapOptions or rather add the two fields to SnapOptions?
<zyga> re, sorry, some interrupt at home
<zyga> back now
<pedronis> mvo: probably a new struct
<pedronis> if you look the server is also a bit like that
<pedronis> mvo: are you pushing anything more to download-resumt atm?
<mvo> pedronis: I'm done with download-resume for now
<mvo> pedronis: was looking at the client bits
<pedronis> mvo: I pushed some small changes to it
<zyga> if you are okay with it I will support merging download as is
<zyga> we can ask for a security review later, I think the answers given by samuele are sufficient
<mvo> pedronis: thank you! I have a look
<mvo> pedronis: and will add the new struct in my other PR
<pedronis> mvo: do you understand what this is talking about: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1861648 ?
<mup> Bug #1861648: When booting 20.04 an 'ld-2.23.so' process consumes 100% CPU for minutes <champagne> <focal> <performance> <snapd (Ubuntu):New> <https://launchpad.net/bugs/1861648>
<pstolowski> cachio: hey
<mup> PR snapd#8142 opened: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <https://github.com/snapcore/snapd/pull/8142>
<mvo> pedronis: I suspect that is fontconfig
<mvo> pedronis: at least that's my gut feeling
<cachio> pstolowski, hey
<zyga> pedronis, mvo: I saw that bug and I came to the same conclusion - perhaps the way we linked fontconfig could be optimzed and we are not using the dynamic linker correctly (lots of relocations?)
<pstolowski> cachio: hi, did you find anything about kill-timout with preseed test on focal? i've been debugging it, added a bunch of debug statements to the test and .sh helpers; it seems to be always killed at the same spot at the end of prepare, but it doesn't make sense.. when i'm dropped in the shell i can do the next operation of the test (actual preseeding) without problem
<mvo> pedronis: I replied in 1861648
<pedronis> thx
<mvo> zyga: I replied in the bug, I suspect it's really the generation of either v6 or v7 or something is off in 20 and there is a v8 that we are not aware of
<zyga> mvo: yeah, could be a good idea to reproduce it
<zyga> mvo: perhaps it would be good to ask about their system as well
<zyga> mvo: I can understand slow cache gen
<zyga> mvo: but it doesn't seem to go to "minutes"
<zyga> mvo: more like 20 seconds
<zyga> mvo: that is: we could be running the same thing over and over, for each snap (perhaps)
<zyga> mvo: or it could be a particularly low-end PC
<zyga> mvo: or we have gazillion symbols
<zyga> mvo: or all at once
<cachio> pstolowski, I was testing it a bit on friday
<cachio> pstolowski, I am going to run with thte profiler now to see the system resources
<cachio> because it completes the prepare and then gets stuck
<cachio> I moved the prepare as part of the execute
<cachio> and it completes all that code and a bit more and then gets stuck
<cachio> not sure why
<cachio> yet
<pstolowski> cachio: i see; what's weird though is when I run the critical operation (snap-preseed command) manually in the shell after it timeouts, it works
<pstolowski> cachio: thanks for looking into it!
<cachio> pstolowski, np
<pstolowski> cachio: something must have changed, cause it worked a few days earlier, and i run it several times before
<cachio> pstolowski, I updated the image
<pstolowski> aah
<cachio> apt updated/upgrade
<cachio> pstolowski, just that
<pstolowski> cachio: yeah, but on focal that means lots of updates atm, maybe something unexpected has changed
<cachio> pstolowski, yes, I know
<BlackDex> Hello there, i am having some issues with the latest spotify snap, it does not want to start. And if i check the journalctl i see the following output: https://pastebin.com/wTiE8jB6
<zyga> Hello
<diddledan> o/
<zyga> BlackDex: can you tell me the output of snap version please
<zyga> BlackDex: I fixed part of the stuff you see 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>
<zyga> BlackDex: let me read the rest though
<BlackDex> snap/snapd: 2.43.3-1 - series: 16
<zyga> BlackDex: are you on arch?
<BlackDex> zyga: Yes
<zyga> right, this is where I saw this problem before
<zyga> having said that, I don't know if the errors there are strongly related to the eventual crash / failure of spotify
<zyga> mborzecki: ^ can you please check what happens on your arch system
<zyga> mborzecki: can you run spotify
<zyga> mborzecki: and perhaps cherry pick the patch into the AUR package
<zyga> BlackDex: perhaps also report a bug with this pastebin as attachment
<BlackDex> at the snapcraft launchpad?
<zyga> BlackDex: launchpad.net/snapd please
<BlackDex> done
<BlackDex> https://bugs.launchpad.net/snapd/+bug/1863613
<mup> Bug #1863613: spotify fails to load (Trace/breakpoint trap (core dumped)) <snapd:New> <https://launchpad.net/bugs/1863613>
<zyga> BlackDex: thank you, we'll check it out
<BlackDex> I do see a some what similar report
<BlackDex> that is for openSuse
<zyga> refer to it, perhaps it is the same issue
<BlackDex> but seemed to be resolved and was in 2018
<zyga> hmm
<BlackDex> i will change my report
<zyga> thanks!
<mborzecki> BlackDex: does that happen only on stable channel?
<BlackDex> mborzecki: stable channel of what? Arch? Snapd? Spotify?
<BlackDex> Since the spotify snap has been updated today it seems
<mborzecki> BlackDex: spotify snap, but nvm, looks like they updated it today?
<mborzecki> BlackDex: you can also `snap revert spotify`
<mborzecki> and then check if it works
<BlackDex> yea, i did that, that seemed to work. Then i went debugging, and in the end removed that revision :(
<cachio> pstolowski, well
<mborzecki> BlackDex: well, dumps core here too
<cachio> it is really really weird
<cachio> I prefiled it and mem and cpu are ok
<mborzecki> zyga: i don't think the patch is related at all, the spotify process has already started
<cachio> it finishes the execution
<zyga> mborzecki: the patch would remove a lot of the leading noise
<cachio> pstolowski, but it does not return the execute script
<mborzecki> wth is libcef?
<cachio> I see all the output
<cachio> pstolowski, and see how it runs everything but I is not returning
<zyga> mborzecki: no idea
<cachio> pstolowski, perhaps something related to ssh?
<mborzecki> huh, i only see it in spotify package, steam package, and spotify snap
<zyga> CEF
<zyga> hmm
 * zyga checks one thing
<zyga> mborzecki: haha
<zyga> mborzecki: it's chrome
<zyga> mborzecki: chromium embedded framework
<zyga> mborzecki: aka, OS in a .so file
<mborzecki> hm the aur pacakge is at 1.1.10, wonder why
<BlackDex> ok
<mborzecki> any clue whether it works on ubuntu?
<diddledan> CEF is similar, but also different, to electron
<mborzecki> or fedora?
<BlackDex> i just copied over all the files from /var/lib/snapd/snap/spotify/41/usr/share/spotify to ~/bin/spotify and started spotify
<BlackDex> that seems to work
<diddledan> of course that'll work, because you're removing the confinement :-)
<BlackDex> i only had to install libcurl-gnutls as an extra package
<BlackDex> yea, but i just wanted to know if it isn't spotify which crashes on my system
<zyga> brb
<BlackDex> i could try and disasble apparamor
<BlackDex> see what that does
<mborzecki> BlackDex: not much, coredupms as well
<mborzecki> BlackDex: zyga: so it works on fedora, but consistently coredumps on arch, even with --devmode
<BlackDex> same here
<BlackDex> i also tried to start snap within a lxd container, but that also didn't worked :S
<BlackDex> i could try a nspan with ubuntu as a base see what happens
<BlackDex> but seems a bit much of a hassle
<mborzecki> BlackDex: just to be sure, do you have the -lts kernel? iirc it's 5.4 now?
<BlackDex> i'm using the zen latest one
<BlackDex> 5.5.4
<mborzecki> BlackDex: right, mine is 5.5.4 too, though the stock repo one
<BlackDex> i could try the lts
<BlackDex> let me reboot
<mborzecki> fedora has 5.4.xx atm
<ijohnson> hello folks
<zyga> hey Ian :)
<BlackDex> on 5.4.20-1 i get the same result
<pstolowski> cachio: perhaps upgrade 20.04 image again?
<pedronis> ijohnson: hi, there's probably a few more places in makebootable.go that can use Filename
<ijohnson> hi pedronis zyga
<pedronis> unrelated to the new code
<ijohnson> pedronis: yes I missed some when rebasing
<pedronis> ijohnson: maybe not though, I think we need to be careful, because I don't think Path always has name_rev format there
<ijohnson> well I specifically was trying to limit usage of that new function to places where we were doing filepath.Base(sn.MountFile())
<pedronis> yea, indeed
<ijohnson> I just grepped for that pattern of filepath.Base\(.*MountFile\(\)\)
<ijohnson> anyways SU now?
<mborzecki> BlackDex: hah, thanks for checking
<BlackDex> i will update my report
<mborzecki> hm flatpak has the same revision as aur
<BlackDex> yea, i checked the repo, but that is still on an old version 1.10 or something
<mborzecki> wonder whtehr there's something off with the version 1.1.20
<zyga> mborzecki: I'm checking if spotify works on ubuntu now
<zyga> it does
<BlackDex> and which snapd version is that?
<BlackDex> maybe there is a small difference
<mborzecki> zyga: what's the version of the spotify snap you installed?
<zyga> mborzecki: stable
<mborzecki> zyga: rev 41?
<zyga> yes, 41
<mborzecki> hmmm
<BlackDex> i just tested older versions of snapd, but no success
<mborzecki> BlackDex: no, imo it's a problem with spotify snap
<mborzecki> tried to disable gpu acceleration, but no luck there
<cachio> pstolowski, hey
<cachio> did you see what I wrote?
<cachio> pstolowski,  the line > qemu-nbd -c /dev/nbd0 "$CLOUD_IMAGE"
<pstolowski> cachio: yep, about qemu-nbd?
<pstolowski> right
<cachio> in the function mount_ubuntu_image
<pstolowski> cachio: interesting
<pstolowski> cachio: qemu-nbd doesn't return or what happens?
<cachio> pstolowski, this is affecting sshe somehow
<pstolowski> huh
<cachio> when I remove this line the systemd does not get stuck anymore
<cachio> in fact what is getting stuck is ssh
<cachio> the script is executed 100%
<cachio> but ssh never returns
<mup> PR snapcraft#2944 opened: add github action ci/cd <Created by sd-hd> <https://github.com/snapcore/snapcraft/pull/2944>
<cachio> pstolowski, don't know why
<pstolowski> cachio: weird.. thanks, i'm trying to re-arrange this test a little bit
<zyga> pstolowski: is my comment on services sensible, should I send a patch?
<pstolowski> zyga: yes it is, thanks, i can do it, thanks for spotting!
<pstolowski> cachio: bingo!
<pstolowski> cachio: i've re-arranged the test to setup and restore qemu-nbd in execute:
<pstolowski> cachio: and it passed
<cachio> pstolowski, nice
<cachio> pstolowski, perfect
<pstolowski> cachio: it may have something to do with what zyga said in the standup (holding fds?)
<cachio> please leave a note in the code :)
<mup> PR snapd#8143 opened: github: add github workflow <Created by sd-hd> <https://github.com/snapcore/snapd/pull/8143>
<sdhd-sascha> Hi
<zyga> hey sdhd-sascha
<sdhd-sascha> :-)
<sdhd-sascha> Is 8143 useful ?
<zyga> sdhd-sascha: that's a question for mvo and cachio
<cachio> sdhd-sascha, there is already a procedure for creating/releasing snapd snap, perhaps mvo could clarify
<cachio> sdhd-sascha, thanks for proposing this btw
<sdhd-sascha> cachio: i know. But i need a custom build, because i waiting for some PRs
<sdhd-sascha> So i build the patched version on github
<mvo> sdhd-sascha: in a meeting right now, but this looks interessting, does it mean we get a snap for each commit basicly? if so, where is that stored? that might be cool for some people to test etc
<sdhd-sascha> mvo: foreach `git tag`
<pstolowski> cachio: thanks for finding this! and it's weird 19.10 is happy
<sdhd-sascha> mvo: here are the results from snapcraft https://github.com/sd-hd/snapcraft/releases
<cachio> pstolowski, yaw
<sdhd-sascha> mvo: then i do this for installation `snap install --dangerous <(wget -q -O- https://github.com/sd-hd/snapcraft/releases/download/3.9.9-0sdhd2/snapcraft-snap-3.9.9-0sdhd2)
<sdhd-sascha> mvo: we can rewrite this, to get a build from each commit, too
<mvo> sdhd-sascha: in a meeting still, will get back to you
<BlackDex> i'm almost tempted to create a aur package based upon the .snap squashfs file ;)
<mborzecki> BlackDex: well, there's an aur package, but it extracts a *.deb afaik
<BlackDex> i know, that is why i was thinking of using the .snap
 * cachio lunch
<pedronis> mborzecki: #8136 needs a 2nd review
<mup> PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136>
<BlackDex> mborzecki: if i check the coredump it seems to fail after the libc-2.27.so
 * zyga afk / dinner
<ijohnson>  /me missed many tests in using Filename() it seems, had test*.go excluded in my grep :-|
<mup> PR snapd#8144 opened: tests: use Filename() instead of filepath.Base(sn.MountFile()) <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8144>
<ijohnson> mvo: oh also I just realized that the next PR I have for snap-bootstrap will break foundations' pi work w/o us also supporting ExtractedRunKernelImageBootloader for uboot because my next PR needs that interface in the initramfs-mounts :-(
<ijohnson> I will propose that PR today, so maybe in the AM you can think about what to do about this
<ijohnson> pedronis: ^
<mvo> ijohnson: ok, thank you! please just add a note about it in the PR and I can look tomorrow
<ijohnson> mvo: sure I will also put it in my SU notes before my EOD, also unfortunately I found a bigger issue with the current kernel verification in initramfs: https://github.com/snapcore/snapd/pull/8136#issuecomment-587100038
<mup> PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <â Blocked> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136>
<ijohnson> oh darn just missed him
<ijohnson> oh well
<pedronis> ijohnson: I asked some questions there
<ijohnson> pedronis: did you see the other comment I left on my PR ?
<ijohnson> pedronis: the attack is that if they switch the symlinks around, then effectively they prevent the system from ever booting the new kernel
<ijohnson> (with the current code that I had proposed)
<pedronis> ijohnson: yes, but I'm trying to understand what we are trying to fix,  there are other ways to achieve that
<pedronis> or brick the device
<pedronis> what we don't allow is to open the disk
<ijohnson> yes or brick the device
<pedronis> ijohnson: they can also remove try-kernel completely
<pedronis> they can empty boot
<ijohnson> right but specifically switching the symlinks around should break something in the boot
<ijohnson> currently it wouldn't
<ijohnson> so I am refactoring the initramfs-mounts code I have to make the assumption that current_kernels[0] is _always_ the fallback kernel and current_kernels[1] (if it exists) is always the try kernel
<ijohnson> then the boot would fail if an attacker switched the symlinks around
<ijohnson> I guess the concern is that they switch the symlinks around and we still perform a boot without detecting that the attack happened
<pedronis> ijohnson: the issue here, is what distinguish a bad filesystem vs an attacker
<ijohnson> how does bad filesystem play into this ?
<pedronis> ijohnson: we might try to boot without a try-kernel at all
<ijohnson> Yes they could so other malicious things and in that case we would successfully either fail to boot (because we are broken/untrusted) or we would detect the issue and fail
<ijohnson> Sorry my point is specifically that we wouldn't be able to know anything happened if they switched the symlink around
<ijohnson> Unless we enforce an ordering to the modeenv kernels setting
<pedronis> ijohnson: my point is that the point we can check that we openend the disk
<pedronis> anyway
<pedronis> so if the old kernel is bad in some ways
<pedronis> well if openend the disk
<ijohnson> When I say switch I mean literally switch, i.e make kernel.efi point to what we set try-kernel.efi to in boot
<ijohnson> Hmm I suppose that's another way we could check, seems like more work though
<pedronis> ijohnson: do you understand my point? any check based on having opened the disk is maybe interesting but slightly too late
<pedronis> and by definiton anything can be written to boot
<ijohnson> Perhaps I should also mention that the code in the boot pkg as of my PR doesn't detect this swapping either
<ijohnson> So even if we get to userspace we don't detect that kernel.efi was changed and try-kernel.efi was changed
<ijohnson> Maybe I should share my notes on this rather than try to explain over IRC
<pedronis> ijohnson: sorry, my point is that either of the try kernel and the kernel will let us open the disk
<ijohnson> Yes I understand that, one minutes while I finish typing the attack in a doc to share
<pstolowski> pedronis: hey, ok to land #8046 with small spread test fix for 20.04 (just need to push one more)? i don't think it warrant re-reviews
<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> pedronis I shared you a gdoc can you see it?
<pedronis> ijohnson: not yet
<ijohnson> pedronis: https://docs.google.com/document/d/1Z4A4tYCaW_ew7tOLxQjJ0vaQ8E6v4lPWVi46fg4aE8Y/edit?usp=drivesdk
<pedronis> ijohnson: I need to go have dinner, also I can't even comment in that doc
<ijohnson> Oh sorry let me add comments
<ijohnson> We can discuss tomorrow morning, I don't mean to keep you
<cachio> I am with a power outage here
<cachio> if someone needs me please telegram me
<mup> PR snapd#8145 opened: cmd/snap-bootstrap: verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8145>
<mup> PR snapd#8146 opened: tests/core: add swapfiles test <Simple ð> <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8146>
<pedronis> ijohnson: what happens if we reboot just before the point where we rewrite modeenv but we have already manipulated the symlinks ?
<pedronis> that was the isue why we thought we couldn't track which is which
<ijohnson> pedronis: hmm in the boot pkg ?
<pedronis> yes
<pedronis> remember that originally we planned to have try_kerne and kernel in modenev
<pedronis> and then we found issues with that plan and fell back to just having a list
<pedronis> what has changed?
<ijohnson> pedronis: for kernel snap setNext() we set the modeenv first
<pedronis> no, the issue is more with mark successful I think
 * ijohnson looks at markSuccessful
<ijohnson> with markSuccessful we are only removing kernels from the modeenv, and we do that last, because if we did that first and got rebooted we would not be able to finish boot in the initramfs
<ijohnson> pedronis: ^
<pedronis> yes, but before we remove it
<pedronis> the first kernel is the old kernel that might not be there
<pedronis> I mean for a bit the symlinks point to the same thing
<pedronis> then they point just to the new one
<pedronis> but only after the modeenv is adjusted
<ijohnson> for markSuccessful the symlinks are moved before the modeenv is written ? so if we got rebooted right before writing the modeenv, kernel.efi -> new kernel, and new kernel is still in the modeenv
<pedronis> it is but the new code in your branch
<pedronis> in your new branch
<pedronis> seems very opinonated about what it expects where
<ijohnson> ah I see what you mean now
<pedronis> that's the point of it
<ijohnson> hmm yes that does introduce a problem then
<pedronis> but will it work with those intermediate states?
<pedronis> I mean that's where we started
<pedronis> I mean maybe it's tractable but it needs quite a bit of tests about all these states
<ijohnson> yes I think the code is vulnerable right now, but I think we can move modeenv earlier
<ijohnson> * move writing the modeenv earlier
<pedronis> then we have the reverse problem
<pedronis> anyway my point is that this needs testing infrastructure to double check these things
<ijohnson> yes I think this is why we went with the list in the first place :-/ because there's no way to avoid that short period of time where we really don't want to be rebooted
<pedronis> and I don't see an easy win here
<pedronis> atm
<ijohnson> I will think on this a bit
<ijohnson> be back in a bit, need to reboot to finish upgrade to focal
<mup> PR snapd#8147 opened: cmd/snap-bootstrap: verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8147>
<mup> PR snapd#8145 closed: cmd/snap-bootstrap: strictly verify kernel snap is in modeenv before mounting it <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8145>
<wxl> not sure this is the best place to ask this but the chromium snap has a sandboxed $HOME, right? so ~/Downloads is not /home/`whoami`/Downloads?
<mup> PR snapcraft#2945 opened: ci: only run docker builds for cron <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2945>
<wxl> nevermind answered my own question (yes) XD
 * ijohnson is now a focal fossa
<roadmr> what even is a fossa :)
#snappy 2020-02-18
<mborzecki> morning
<mborzecki> school run, back in 30
<mborzecki> re
<mborzecki> mvo: hey!
<mvo> hey mborzecki ! good morning
<mvo> mborzecki: 8146 and 8144 are easy wins I think
<doko> the chromium snap and others don't accept keyboard input anymore in focal. is this known, or where should this be reported?
<mborzecki> doko: afaik it's fixed in master, and mvo uploaded a patched snapd to ubuntu
<mvo> doko: upload should already be in focal, I think I got the focal-proposed -> focal mail last night
<doko> ahh, ok, a reload helped
<mup> PR snapd#8146 closed: tests/core: add swapfiles test <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8146>
<mup> PR snapd#8144 closed: tests: use Filename() instead of filepath.Base(sn.MountFile()) <Simple ð> <Test Robustness> <Created by anonymouse64> <Merged by bboozzoo> <https://github.com/snapcore/snapd/pull/8144>
<mvo> mborzecki: \o/
<pstolowski> morning
<mvo> hey pstolowski - good morning
<mborzecki> pstolowski: hey
<zyga> good morning
<zyga> sorry for a late start
<zyga> let's get to work!
<pstolowski> hey zyga
<zyga> hey :-)
<mup> PR snapd#8148 opened: overlord/configstate/configcore: add support for backlight service <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>
<sdhd-sascha> hello
<mvo> sdhd-sascha: good morning!
<sdhd-sascha> mvo: :-)
<zyga> hey sdhd-sascha :)
 * zyga munges breakfast while catching up on email
<sdhd-sascha> I just started to add some variables to the build-action. So every repo on github can configure, if the action should run...
<sdhd-sascha> I use `github secrets` for variables...
<zyga> oh boy, I have 342 bugs in fedora on selinux denials
<zyga> and it's my bug triage day
 * zyga cries a little
<mborzecki> zyga: some of those are probably fixed
<mborzecki> some are probably caused by anaware users :/
<mborzecki> s/anaware/unaware/ ofc
<mup> PR snapd#7624 closed: snap: make `snap download` download via snapd if available <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/7624>
<zyga> mborzecki: yeah but which
<zyga> mborzecki: I'll try to do something smart about them
<pedronis> mborzecki: hi, did you see that #6708 failed on a some task.yaml formatting issue?
<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> pedronis: fixed
<zyga> pedronis: it's funny because maciek added the checks :)
<mborzecki> pedronis: thanks for spotting, spread-shellcheck didn't complain but i obviously forgot about the multiline check :/
<mborzecki> zyga: heh, yeah the irony of it :P
<mborzecki> hm maybe this should become part of spread-shellcheck at some point
<pedronis> it failed somewhere in the static checks afaict
<zyga> pedronis: it failed on lack of | in prepare
<mborzecki> pedronis: it complained about `tests/main/buildmode-pie/task.yaml:9:prepare:` not bneing `prepare: |`
<zyga> technically it is parsing but not as people expected
<pedronis> #8003, #8078 and #8101 need reviews or 2nd reviews (they should all be close to landable)
<mup> PR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
<mup> PR #8078: daemon: support resuming downloads <Created by chipaca> <https://github.com/snapcore/snapd/pull/8078>
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<zyga> pedronis: I'll look at 8003 after going through new bugs
<zyga> I can look at the rest as well though 8078 can probably be merged
<zyga> I see there's one change since my last review
<zyga> I'll read it and probably approve
<zyga> pedronis: let's land 8078
<zyga> thank you for pushing this forward!
<pedronis> thx
<pstolowski> doh, getting something green on travis seems very hard again
<zyga> https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/263 is interesting to read
<sdhd-sascha> I just added some `secrets` to control the github-action-workflow
<sdhd-sascha> mvo: any idea to make the github-action more usable ?
<mvo> sdhd-sascha: is it trivial to run unit tests in it?
<sdhd-sascha> mvo: i think it's possible. If you look at jhenstridge github action. It's super readable typescript
<sdhd-sascha> And you can run, any shell script ...
<mvo> sdhd-sascha: I think the building in GH is less interessting for us, we have LP building stuff for us and I think that's fine, has the nice store integration so we auto-upload builds to the store and get the assertions etc. but I can see actions as a nice way to do a first level checking, i.e. what we do today with travis static checks. not sure about the details though, haven't really looked at this myself
<sdhd-sascha> mvo: true. I also added upload to the store. As i have said, i need for classic-snap's, because of the approval
<mup> PR snapd#8078 closed: daemon: support resuming downloads <Created by chipaca> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8078>
<sdhd-sascha> mvo: i have to install a github-runner locally, to better understand how it works internal
<mvo> sdhd-sascha: upload to the store> interessting
<mvo> sdhd-sascha: keep me updated please, it sure looks like fun :)
 * mvo really hopes it is
<sdhd-sascha> mvo: i too :-)
<pstolowski> pedronis: ok to land https://github.com/snapcore/snapd/pull/8046 ? i pushed small changes to the spread test for focal. and it's finally green
<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>
<pedronis> pstolowski: do we understand why prepare is different?
<pstolowski> pedronis: yes and no, we understand that qemu-nbd gets stuck if it's part of prepare. i reorganized the test to do this in execute
<pedronis> but we don't know why it gets stuck?
<pstolowski> pedronis: yep, we don't
<pedronis> ok
<pstolowski> pedronis: i can try to investigate and maybe have a followup; fwtw it's unrelated to the functionality and what we're testing
<pedronis> pstolowski: anyway it is fine to land,  we don't have the same problem in restore, right?
<pstolowski> pedronis: no
<pstolowski> thanks
 * pedronis lunch
<mup> PR snapd#8046 closed: many, tests: integrate all preseed bits and add spread tests <Complex> <Needs Samuele review> <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8046>
<mup> PR snapd#8149 opened: snapmgr, backends: maybe restart & security backend options <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8149>
<sdhd-sascha> mvo: did you know, that it is possible to run services on github: https://github.com/actions/example-services
<zyga> oh
<zyga> that's ... interesting!
<sdhd-sascha> :-)
<ogra> well ... https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930
<ogra> ;)
<mvo> sdhd-sascha: I had no idea
<pedronis> pstolowski: I re-reviewed #8130, the logic is not quite what I expected
<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>
<pstolowski> oh
<pstolowski> pedronis: ok, thanks
<pstolowski> i must have misunderstood the details
<mborzecki> ijohnson: mvo: cmatsuoka: a little script for repacking the kernel snap with changes to initramfs https://gist.github.com/bboozzoo/010ed5e94ee0f695d1aeece43513a018
<pedronis> pstolowski: the change is not big, anyway see my comment there
<pedronis> but the tests will need adjusting too
<cmatsuoka> mborzecki: ah thanks, it's nicer than the one I'm currently using
<mvo> mborzecki: woah, nice!
 * pstolowski lunch
<zyga> ondra, ogra, plars: hey guys
<zyga> I tried reproducing https://bugs.launchpad.net/snapd/+bug/1846397
<zyga> (perhals sil2100 ^ as well as you were in the bug)
<mup> Bug #1846397: snapdragon uc18 image fails to boot (current stable) <snapd:In Progress by ondrak> <https://launchpad.net/bugs/1846397>
<zyga> can you guys tell me that we successfully test-boot current core18 images on the dragon board?
<zyga> I'll try the release image to double check
<cwayne> zyga: that bug should be marked as fixed
<zyga> cwayne: can you mark it as such with a comment please
<cwayne> done
<zyga> cwayne: hmm, given that you are here, do you remember if there's anything special that is needed to boot that board?
<zyga> I wonder why I cannot get ubuntu core on it
<zyga> (as my last message in the bug indicated)
<cwayne> was that with the latest stable?
<zyga> I tried the release image we advertise on the website
<zyga> https://ubuntu.com/download/qualcomm-dragonboard-410c
<zyga> http://cdimage.ubuntu.com/ubuntu-core/18/stable/current/ubuntu-core-18-arm64+snapdragon.img.xz
<zyga> but I suspect the image may be correct - I don't think I actually even attempted to boot it for some reason
<zyga> I have the card inserted now and I'm running some old debian from linaro
<zyga> I can poke around the SD
<cwayne> zyga: i'd ask plars when he's around, I don't have this board (but i feel like there's some dipswitch needed or something)
<zyga> yeah, I set those up
<zyga> could be a wonky card, I'll try with another one
<zyga> yeah
<zyga> werd
<zyga> weird
<zyga> the card works but would not boot
<zyga> I used another and boom,
<zyga> it's okay
<cwayne> phew, you scared me there zyga
<zyga> I'll make sure it works past registrationa
<zyga> and that I can refresh
<zyga> and adjust the bug
<cwayne> also it wasnt really appropriately logged, IIRC it was an issue with the gadget not snapd at all
<zyga> yeah, that's common, snapd is the catch-all-project
<cwayne> ah right, fair enough
<ogra> wasnt there some switch on the db410 that you need to flick to have it boot from SD?
<ogra> (i havent touched any dragonboard in probably 1.5y)
<cwayne> neither has anyone else lol
<cwayne> ogra: it turned out to be a bad sd card
<ogra> in general ondra is our qualcomm guy though
<zyga> heeey
<ogra> haha
<zyga> look at what I got
<zyga> Press enter to configure.
<zyga> :D
<zyga> that's a small wonder there
<zyga> I'm in
<ijohnson> morning folks
<cwayne> Imagining you saying that like a hacker in a movie
<cwayne> GUYS IM IN
 * ijohnson almost got crushed by a car this morning
<zyga> ijohnson: good morning, are you okay? what happened?
<zyga> cwayne: that's unix, I know this
<zyga> cwayne: AWW SNAP
 * zyga googles how to work with snaps on stackoverflow
<ijohnson> yeah I'm fine, just very icy outside and an SUV couldn't stop at a stop sign and so slid through the intersection
<ijohnson> great way to end yoga though
<plars> zyga: yes, the core18 images currently in stable should boot just fine for you, and upgrading to the latest gadget snap will not cause any problems, but you could get the problem if you build a fresh image with the current gadget snap
<cwayne> Gotta re-tense after yoga
<zyga> ijohnson: ouch
<ijohnson> cwayne: exactly
<zyga> is it common to use chains on icy days?
<ijohnson> no not in the cityu
<zyga> plars: confirmed, it's all good
<ijohnson> you just wait for the city to put ice down, or you drive carefully :-)
 * cwayne has never used snow chains
<cwayne> Or snow tires
<zyga> plars: I see, do you know what is the problem with the gadget snap?
<ijohnson> my grandpa showed me how to put them on, but I have never used them and don't own any
<roadmr> cwayne: aren't winter tires mandatory in your neck of the woods, in winter?
<cwayne> Nah
<ogra> cwayne, didnt you grow up in new hampshire ?
<cwayne> Heavily suggested
<cwayne> ogra: Massachusetts :)
<ogra> well, close
<cwayne> Took my driving test in a blizzard
<ogra> how can you never have used snow tires there
<ijohnson> it used to be mandatory where my grandpa lives in rural wisconsin because the roads were plowed so infrequently
<plars> zyga: I believe it was a u-boot issue - some new bug that came with it getting updated
<ogra> it definitely is in germany ...
<zyga> plars: I see, another bug for another time
 * zyga is reviewing in-progress bugs
<ijohnson> time to SU
<kenvandine> zyga: i'm still seeing this ibus/snapd issue in focal with all the updates installed
<kenvandine> zyga: wiping ~/snap/irccloud-desktop/common/.cache fixed it for irccloud-desktop
<kenvandine> but not for other snaps
<kenvandine> all very weird
<zyga> kenvandine: uh, weird, do you know how ibus works enough to debug this?
<zyga> I'm essentially green
<zyga> do you see any more denials?
<kenvandine> no idea
<kenvandine> Feb 18 09:23:06 trabajo kernel: [  667.096071] audit: type=1400 audit(1582035786.790:404): apparmor="DENIED" operation="connect" profile="snap.chromium.chromium" pid=39109 comm="pool" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/home/ken/.cache/ibus/dbus-MQguChWC" peer="unconfined"
<kenvandine> i think oSoMoN understands it
<zyga> I'll go and grab some food now
<zyga> see you guys later :)
<sil2100> zyga: hey!
<sil2100> zyga: commented on the bug o/
<sil2100> So once you're back, have a look :)
<mup> PR core18#147 closed: Add bash-completion support <Created by xnox> <Merged by sil2100> <https://github.com/snapcore/core18/pull/147>
<ijohnson> kenvandine: I just upgraded to focal yesterday and had the same problem with ibus, it wasn't fixed with snapd from focal-proposed or the core snap edge either, I had to rebuild snapd from master and use that
<kenvandine> ijohnson: interesting
<kenvandine> the fix seems to have worked for some snaps
<ijohnson> kenvandine: it might be possible that the fix from jdstrand hasn't made it to edge yet somehow
<kenvandine> i haven't really figured anything out though
<ijohnson> kenvandine: the snap I immediately noticed the problem with was irccloud
<kenvandine> me too
<kenvandine> firefox and chromium are working for me now too
<kenvandine> but gedit isn't
<ijohnson> is gedit a snap now?
 * ijohnson still has gedit from deb pkg on focal
<jdstrand> ijohnson, kenvandine: the snapd in focal has the fix
<ijohnson> jdstrand: the deb ? why doesn't the edge snap have the fix ?
<kenvandine> jdstrand: it should... and it's working for some snaps
<jdstrand> ijohnson: the deb yes. I don't know about edge if it doesn't
<kenvandine> jdstrand: i had to wipe ~/snap/chromium/common/.cache to get chromium to work
<kenvandine> gedit is still seeing denials
<kenvandine> i have avoided wiping the cache to keep the test case around
 * ijohnson tries snapd from deb pkg w/irccloud again, brb
<jdstrand> kenvandine: you are still talking about ibus?
<kenvandine> jdstrand: yes
<jdstrand> kenvandine: I think all you need to do is make sure all the chromium processes are gone
<jdstrand> kenvandine: that is all I had to do with firefox and chromium
<jdstrand> and gedit works fine
<kenvandine> that could have been the case there
<kenvandine> gedit is still a problem for me
<kenvandine> Feb 18 09:49:52 trabajo kernel: [ 2272.927989] audit: type=1400 audit(1582037392.623:434): apparmor="DENIED" operation="connect" profile="snap.gedit.gedit" pid=104786 comm="pool" family="unix" sock_type="stream" protocol=0 requested_mask="send receive connect" denied_mask="send connect" addr=none peer_addr="@/home/ken/.cache/ibus/dbus-MQguChWC" peer="unconfined"
<jdstrand> kenvandine: can you paste /var/lib/snapd/apparmor/profiles/snap.gedit.gedit ?
<ijohnson> hmm the deb seems to work w/ irccloud and the gedit snap now for me, with re-exec disabled
<ijohnson> trying with re-exec enabled
<kenvandine> jdstrand: https://paste.ubuntu.com/p/xwBCYrr6Yt/
 * jdstrand notes he has the stable core, so the deb comes up as newer
<jdstrand> kenvandine: yeah, that doesn't have the new rule
<jdstrand> kenvandine: what is the output of snap version?
<ijohnson> jdstrand: yeah with edge core snap and re-exec enabled I can't type now again
<kenvandine> https://paste.ubuntu.com/p/qFdSkXvpq2/
<kenvandine> yeah, i have core from edge
<jdstrand> sounds like edge doesn't have the fix yet
<jdstrand> refresh to stable and it should work again
<ijohnson> cachio: where's the snapd vendor LP project we build core snap from edge again? I think core snap edge channel is behind a bit
<jdstrand> https://github.com/snapcore/snapd/pull/8139 was merged two days ago. no idea why that wouldn't be in edge
<mup> PR #8139: interfaces/{desktop-legacy,unity7}: adjust for new ibus socket location <Simple ð> <Created by jdstrand> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8139>
<cachio> ijohnson, it is because the issue I explained with spread-cron
<ijohnson> cachio: ahhh right I remember you saying this in SU
<cachio> ijohnson, the job to update the lp repo has been executed 30 minutes ago
<cachio> ijohnson, so next core is gonna containd everythin
<ijohnson> great, sounds good
<cachio> ijohnson, this is the project in lp https://launchpad.net/snapd-vendor
<ijohnson> cachio: thanks I should have just tried snapd-vendor :-)
<cachio> :)
<ijohnson> kenvandine: jdstrand: I added a note to the bug about needing to wait for the edge channel to be refreshed or needing to manually switch to stable channel to pick up the fix (counter-intuitively)
<ijohnson> s/refreshed/updated/
<kenvandine> is the fix in stable?
<kenvandine> no...
<ijohnson> no, but due to how re-exec works when the version of the core snap is less than the deb, snapd will not re-exec into the snap
<ijohnson> the issue is that the edge channel has a higher version number than the deb, but is actually behind
 * cachio lunch
<mup> PR snapcraft#2946 opened: store: temprorarily remove support for progressive releases <Created by sergiusens> <https://github.com/snapcore/snapcraft/pull/2946>
<jdstrand> ijohnson: thanks!
<zyga> jdstrand: good morning
<ijohnson> pedronis: let's chat tomorrow if that's alright with you?
<pedronis> ijohnson: ok
<pedronis> zyga: does #8123 needs jdstrand to review it?
<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> Yes
<zyga> But is has lower priority
<pedronis> zyga: should we close 8113 ?
<zyga> Checking
<zyga> Yes but after a review from Jamie for comparison
<zyga> I think it is really one review
<zyga> And two ideas
<pedronis> ok
<pedronis> I request him on both them, is there enough context in them to know what to do?
<pedronis> *I requested
<pedronis> mvo: I made a slightly annoying comment on #8148
<mup> PR #8148: overlord/configstate/configcore: add support for backlight service <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>
<mvo> pedronis: interessting, I think it makes sense
<mup> PR snapd#8117 closed: tests: add preseed test for classic <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8117>
<zyga> pedronis: I think so, I also mentioned it to jamie a while ago but the priority is indeed lower than others
<zyga> jdstrand: I think https://github.com/snapcore/snapd/pull/7825 is ready for a re-review
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> er
<zyga> I meant https://github.com/snapcore/snapd/pull/7980
<zyga> but the other one too
<zyga> just in the opposite order
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<zyga> don't you guys find it annoying
<zyga> when you look at a PR comemnt
<zyga> *comment
<zyga> that out of the blue cannot be replied to
<zyga> and it belongs to the same review
<zyga> by the same person
<zyga> and the code is not outdated
<zyga> I mean
<zyga> why
<zyga> but then if I go to diff view
<zyga> I can reply there
<zyga> but I only see SOME comments there
<zyga> *why*
<pedronis> pstolowski: reviewed #8149, +1 with a question
<mup> PR #8149: snapmgr, backends: maybe restart & security backend options <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8149>
<pstolowski> pedronis: thanks, will check it
<sdhd-sascha> mvo: update at the end ;-)
<sdhd-sascha> https://forum.snapcraft.io/t/call-for-testing-github-action-for-snapcrtaft/14930/17
<sdhd-sascha> I didn't tested it yet, but it's a snap for `github action runner's`. For local building of github actions.
<mvo> sdhd-sascha: woha, you made a snap from the runner? and even strictly confined it? that's nice
<sdhd-sascha> mvo: next, i need to figure out the interfaces
<sdhd-sascha> ...
 * mvo nods
<sdhd-sascha> hmm, hope until tomorrow, i will get it run
<sdhd-sascha> mvo: it's seems to be `nodejs` stuff, with some `dotnet`. i will see
<mvo> good luck!
<pstolowski> pedronis: updated #8130, let me know if this is what you meant (i need to check if my the overlord/devicestate tests still make sense after this change, but state_test.go should be ok)
<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>
<sdhd-sascha> mvo: after short thinking, should i change it to classic. I see no other chance :-(
<sdhd-sascha> Then it's only on github and not on the store ...
<mvo> sdhd-sascha: sometimes we make exceptions for classic snaps in the store, go for example
<zyga> jdstrand: were you successful with SNAP_REEXEC=0
<zyga> jdstrand: I must confess I was puzzled by your comment, everything looked godo
<zyga> *good
<zyga> jdstrand: but I was running this code on fedora and ubuntu many times
<zyga> jdstrand: and there are tests that show it really operates
<zyga> jdstrand: so ... I don't know
<zyga> jdstrand: the last thing I want to change in that PR is the UUID pattern
<zyga> jdstrand: but I would like to do it in a followup as it's an annoying change across this PR (in many places) and I would like to have a dedicated patch for that
<jdstrand> I was in a meeting and doing follow ups after, so haven't look at it yet
<zyga> jdstrand: ack, I'm looking at that rexec aspect now
<mup> PR snapd#8150 opened: tests: ask tar to speak English <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8150>
<mup> PR snapcraft#2946 closed: store: temprorarily remove support for progressive releases <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2946>
<zyga> stgraber: I think there's a small bug in the lxd snap meta-data that affects the configure hook
<zyga> stgraber: the details are in the last two comments of https://bugs.launchpad.net/snapd/+bug/1863772
<mup> Bug #1863772: apparmor missing read permission for /var/lib/snapd/hostfs/usr/lib/os-release <snapd:Invalid> <snapd (Ubuntu):Invalid> <https://launchpad.net/bugs/1863772>
<zyga> stgraber: do you want me to add an lxd task or mirror it elsewhere?
<stgraber> zyga: the lxd-support interface wouldn't do any good
<jdstrand> zyga: hey, sorry had some internet woes. did you reproduce? I tried again and explecitly disabled reexec. I am still not seeing what I expect
<stgraber> zyga: all that interface does is allow the use of aa-exec which we're not using in the hook
<stgraber> zyga: for that matter, the hook also never attempts to access os-release
 * jdstrand notes in the denial: comm="snapctl"
<zyga> stgraber: that interface allows for access to that file
<zyga> stgraber: (I specifically looked at the denial, if there's more I didn't see that)
<jdstrand> I think stgraber is saying that before the update, snapctl didn't need the access. now it does
<zyga> jdstrand: it's the configure hook, I don't understand why snapctl would reach out to /var/lib/snapd/hostfs but perhaps my memory is rusty and it does
<zyga> jdstrand: interesting
<zyga> maybe something bigger broke
<stgraber> zyga: oh, you're right that someone added os-release to lxd-support, no idea why that was done though :)
<zyga> stgraber: I can git blame...
<stgraber> zyga: we never access os-release prior to calling aa-exec, so it feels wrong for the interface to allow something we shouldn't need
<jdstrand>     audit: type=1400 audit(1510219691.912:133): apparmor="DENIED" operation="open"
<stgraber> zyga: if snapd itself requires it somehow, then it would feel more appropriate for this to be somewhere else :)
<jdstrand>            profile="snap.lxd.lxc" name="/var/lib/snapd/hostfs/usr/lib/os-release" pid=29008
<jdstrand>            comm="snap-exec" requested_mask="r" denied_mask="r" fsuid=0 ouid=0
<jdstrand> Maciej said he added that to the interface to fix snap-exec ^
<stgraber> zyga: 7beabf5b9f back in 2017, doesn't give a lot of context though
<zyga> https://github.com/snapcore/snapd/commit/7beabf5b9f5f7062e9630325b30f52ccf4448410
<zyga> yeah
<stgraber> zyga: it's effectively attempting to fix snap-exec which had the same issue as snapctl
<zyga> so it's certainly not new
<zyga> and the comm is different
<zyga> snap-exec
<zyga> weir
<zyga> *weird
<pedronis> we have code to read os-release in release
<pedronis> so I expect it can crop easily anywhere
<zyga> pedronis: but we don't read it via hostfs, do we?
<stgraber> yeah, still feels wrong to dump that in the lxd-support interface but I guess I can add that interface to the hook for now to silence things :)
<zyga> pedronis: don't read it via hostfs (I checked now)
<jdstrand> stgraber: is it just noise?
<stgraber> jdstrand: yeah
<pedronis> we don't use hostfs a lot
<zyga> jdstrand: perhaps not, we're debugging an issue that showed up just now in snappy-internal
<zyga> jdstrand: maybe something did break
<zyga> I think this is noise but the question is, why now?
<stgraber> might just be that nobody noticed :)
<stgraber> lxd hosts are full of apparmor noise already
<pedronis> zyga: no, not via hostfs
<jdstrand> stgraber: use system-observe instead if you're working around
<jdstrand> way less privilege :)
<stgraber> I think I know where the hostfs thing comes from, it's because the configure hook is run within the LXD mntns which has its own copy of /etc with a weird layout. snapctl then just looks at /etc/os-release and hits a symlink to the host path
<zyga> ah!
<stgraber> jdstrand: ah yeah, sounds a bit less crazy indeed
<zyga> that explains it
<zyga> stgraber: can you paste that line into the bug
<zyga> you just saved me some debug time :)
<zyga> so it's all understood now and we can just silence that, I think
<jdstrand> ok, cool
<zyga> ijohnson: snapd-failover failed
<zyga> https://www.irccloud.com/pastebin/T22XZ91h/
<zyga> there's more debug
<ijohnson> zyga: well that's sad
<zyga> https://www.irccloud.com/pastebin/sb9D5gYY/
<ijohnson> zyga: is that all of the debug ? seems cut off at the end
<zyga> there's more
<zyga> but lots of repeats
<zyga> https://api.travis-ci.org/v3/job/652108951/log.txt
<zyga> then some more
<ijohnson> thanks I was jsut gonna ask for the travis log
<zyga> perhaps you can make heads and tails out of that
<zyga> I don't see anything about snapd-failure.service
<ijohnson> yes I've seen this before but haven't been able to fully debug it
<ijohnson> I thought that mborzecki's change from a couple days ago would have helped this
<ijohnson> which PR is this ?
<zyga> ijohnson: it failed on a PR that has one liner change in totally unrelated place
<zyga> https://github.com/snapcore/snapd/pull/8150
<ijohnson> but was that PR based off of master or an older commit ?
<mup> PR #8150: tests: ask tar to speak English <Simple ð> <Created by zyga> <https://github.com/snapcore/snapd/pull/8150>
<zyga> ijohnson: master
<zyga> I just made it
<zyga> I _think_
 * zyga checks
<ijohnson> ah I see it
<ijohnson> yeah looks like it was on top of master
<zyga> yeah
<ijohnson> thanks for point it out to me, but this log is the same as one I have saved locally so you can restart the job if you like
<ijohnson> *pointing
<mup> PR snapcraft#2947 opened: remote-build: pass through 'source-subdir' property <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2947>
 * cachio afk
<mup> PR snapd#8151 opened: cmd/snap-bootstrap/initramfs-mounts: only write modeenv if it changed <Simple ð> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8151>
#snappy 2020-02-19
<mup> PR snapd#8152 opened: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8152>
<mborzecki> morning
<mborzecki> school run, back in 30
<mborzecki> re
<mborzecki> mvo: morning
<mvo> hey mborzecki ! good morning
<pstolowski> morning
<zyga> re
<zyga> good morning
<zyga> tests are somewhat unhappy
<zyga> I've seen snapd-failover fail a lot yesterdat
<zyga> I know Ian was looking into that but perhaps it needs more eyes
<zyga> and snap-run hangs, oh my
<pstolowski> zyga: right, i saw snapd-failower failures as well
<zyga> so
<zyga> I need bionic
<zyga> and I need tests that run as user
 * zyga gets to work
<zyga> ok, test written, let's run it
<zyga> mborzecki: do you expect https://bugs.launchpad.net/snapd/+bug/1863859 to be true given our environment generators?
<mup> Bug #1863859: Using su removes /snap/bin from PATH <snapd:New> <https://launchpad.net/bugs/1863859>
<zyga> mborzecki: I just noticed this in tests
<mborzecki> zyga: su - ?
<zyga> su test -c "snap run foo" vs su test -c "foo"
<mborzecki> zyga: try su -l
<zyga> mborzecki: k
<mborzecki> or . $TESTSLIB/user.sh and then as_user_simple ?
<mborzecki> zyga: simple will not load the profile
<zyga> I'll look at some tests that suffer from this
 * zyga loves calls with baby crying next door
<mup> PR snapd#8153 opened: [RFC] "snap run --explain" with different formating <Created by mvo5> <https://github.com/snapcore/snapd/pull/8153>
<zyga> mvo: I'll review in a moment, need to check what the crying is all about
<mvo> zyga: no rush, thank you!
<zyga> re
 * zyga debugs all kinds of things through one failing test
<zyga> mborzecki: quick question
<zyga> https://www.irccloud.com/pastebin/B2mlykUV/
<zyga> (this is test-snapd-sh without arguments
<zyga> spawning endless loop of bad substitution
<zyga> why would our argv[0] cause this?
<zyga> I'm patching snap-exec to show what's going on at that layer
<zyga> it is driving me crazy, I want to finally fix it
<zyga> mborzecki: it's a dash specific message
<zyga> that's interesting
<zyga> I think we do something incorrectly
<zyga> oh well, let me grab coffee
<zyga> desktop 18.04 install in progress
<zyga> I think we have a problem with systemd there :/
<zyga> but I think my test setup is not doing what is right
<zyga> brb
<zyga> ha
<zyga> got it
<zyga> found a bug in spread
<zyga> PS1 breaks dash
<zyga> becuase SPREAD_PATH is unset
<zyga> is it just me or is this a quiet channel?
<sdhd-sascha> zyga: hey :-)
<zyga> hey
<zyga> how are you?
<sdhd-sascha> zyga: i'm fine. thank you. Little bit tired. But fine :-) And you ?
<zyga> a bit scared I missed something big that came up yesterday evening
<zyga> debugging it now
<sdhd-sascha> oh, good luck
<sdhd-sascha> i'm just started to fix the snap for the github actions.
<sdhd-sascha> zyga: on which point it's best to do chmod of a script ? I have a /run.sh and snapcraft says it's not executable. I use chmod at `override-build` currently.
<zyga> sdhd-sascha: are you building on windows?
<sdhd-sascha> `Failed to generate snap metadata: The specified command 'run.sh' defined in the app 'runner' is not executable.`
<zyga> sdhd-sascha: it's best to keep it executable in the tree
<sdhd-sascha> I wonder, why the generated tar isn't executable ... i will see
<sdhd-sascha> zyga: if i go into `multipass exec ` ... Then inside of `/root/parts/runner/build/run.sh` it's executable.
<sdhd-sascha> ```
<sdhd-sascha> apps:
<sdhd-sascha>   runner:
<sdhd-sascha>     command: run.sh
<sdhd-sascha> ```
<sdhd-sascha> But i still get: `Failed to generate snap metadata: The specified command 'run.sh' defined in the app 'runner' is not executable.`
<sdhd-sascha> hmm
<zyga>  oh great
<zyga> killing dash killed gnome-terminal
<sdhd-sascha> wow
<zyga> anyway
<zyga> just more bugs
<cmatsuoka> ijohnson: thanks for the PR
<cmatsuoka> ijohnson: it seems that tests failed in a strange way
<cmatsuoka> command systemctl is-active snapd.failure.service keeps failing after 30 attempts
<cmatsuoka> and snapd.service: Failed to execute command: Exec format error
<cmatsuoka> zyga: does that sound familiar to you?
<zyga> cmatsuoka: hey
<zyga> yeah, there's something really broken
<zyga> it's worse recently perhaps the test is new or something related changed
<zyga> it fails left and right
<cmatsuoka> EXEC spawning /snap/snapd/x2/usr/lib/snapd/snapd: Exec format error
<zyga> I haven't looked into it yet
<zyga> cmatsuoka: yeah, the test is trying to install corrupt snapd
<zyga> to check failover
<zyga> but failover never kicks in
<zyga> the exec format error is expected and harmless noise (for the test)
<cmatsuoka> ah ok
<mup> PR snapd#8154 opened: tests: reset PS1 before possibly interactive dash <Created by zyga> <https://github.com/snapcore/snapd/pull/8154>
<zyga> mborzecki: ^
<zyga> this caused me some grief
<zyga> cmatsuoka: I can look after I investigate more systemd stuff
<ijohnson> cmatsuoka: zyga: yes I was looking into this a bit yesterday, I think that the patch mborzecki recommended to snap-failure is useful here, I had that small change proposed in my larger core spread PR, but perhaps I should break it out just to get that merged
<ijohnson> and morning folks btw
<mborzecki> ijohnson: hey!
<ijohnson> hey mborzecki
 * ijohnson is here for real this morning
<mborzecki> `The dash bug has been reported to the dash mailing list (there is no bug tracker).` hahah welp
<zyga> mborzecki: oh well
<zyga> mborzecki: it's very unixy
<zyga> mborzecki: mailing list archive, CCing people
<zyga> mborzecki: 3-character names
<zyga> thank you for the review guys
<mvo> I see a lot of red in the most recent spread runs, has anyone investigated yet?
<zyga> mvo: snapd-failover
<zyga> it's failing ... over and ... I'll shut up now ;)
<cmatsuoka> :D
 * zyga returns to debugging systemd 
<mup> PR snapd#8155 opened: tests: mv ubuntu-core-snapd{,-failover} to core/ suite <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8155>
<ijohnson> mvo: I opened ^ which I think will help with the snapd-failover test
<cachio> ijohnson, zyga failover test started failing a time ago but with external backend
<cachio> now is started failing on travis too
<ijohnson> cachio: interesting you mean on the lab machines ?
<ijohnson> cachio: do you have logs?
<cachio> ijohnson, http://paste.ubuntu.com/p/DXD9WN7CtJ/
<cachio> this is from the 2.43.3
<cachio> line v
<cachio> 1330
<cachio> I though it was related to our configuration for the external backend
<cachio> because it was not possible to reproduce on travis
<cachio> using gce
<cachio> but seems to be something else
<ijohnson> yeah that seems to fail the same it's failing on travis now
<ijohnson> the issue is that snapd.failure.service is not being started ever by systemd
<cachio> the weird part is that when using the external backend the test is not failing 100% of the times
<cachio> right
<ijohnson> yes I don't think it is failing 100% of the time on travis either, indeed when I tried reproducing yesterday I didn't hit it
<cachio> a time ago I shared more info about the error, I am trying to find it
<cachio> I remember I sent the error to mvo
<cachio> failover was trying to find core and core snap was not installed
<cachio> ijohnson, but I cant find the logs
<ijohnson> cachio: hmm that sounds different
<cachio> the error is the same you see in the log I sent you
<cachio> I'll reproduce it
<cachio> and share the logs again, give me 15 minutes
<zyga> google:ubuntu-18.04-64 .../tests/main/cgroup-tracking# test-snapd-sh.sh
<zyga> $
<zyga> google:ubuntu-18.04-64 .../tests/main/cgroup-tracking#
<zyga> ^ getting this feels like this day is already worth it
<ijohnson> thanks cachio
<zyga> mborzecki: but it was worth reporting, it's a known problem
<zyga> https://patchwork.kernel.org/patch/11343121/
<zyga> and there's a patch
<mvo> nice
<mup> PR snapd#8156 opened: [RFC] cmd/snap-bootstrap: subcommand to detect if we want a chooser to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<mborzecki> mvo: ^^ the key-watching thing
<mborzecki> pedronis: mvo: we should probably discuss the naming there
<zyga> oh
<zyga> I wanted to mention that yesterday
<zyga> about recovery and prompt and stuff
<zyga> something to keep an open mind
<zyga> smart IOT bulbs
<zyga> do recovery
<zyga> if ...
<zyga> you turn them on and off five times in a row with specific time delay
<zyga> our discussion about key detection feels incorrect
<zyga> it should not be something we mandate
<codingpanic> Hello all. I instaleld snapd on a raspbian based pi today. Unfortunately, none of the built-in interfaces/slots are available. What creates these?
<pedronis> zyga: we don't mandate it, we need a reference experience
<codingpanic> Since they dont exist, snaps are unable to connect to anything
<ijohnson> codingpanic: did you install snapd as a deb pkg ?
<codingpanic> ijohnson: yes
<ogra> hrm
<ogra> ubuntu@localhost:~$ snap version
<ogra> snap    2.43.3+git1047.g6b52b37
<ogra> snapd   unavailable
<ogra> series  -
<ogra> ubuntu@localhost:~$ snap list
<ogra> error: cannot list snaps: cannot communicate with server: timeout exceeded while waiting for response
<ogra> ubuntu@localhost:~$
<ijohnson> codingpanic: what's `snap list` ?
<ogra> ubuntu@localhost:~$ ps ax|grep snapd
<ogra>  8932 ?        Ssl    0:00 /snap/snapd/6521/usr/lib/snapd/snapd
<ijohnson> ogra: why did you break your snapd
<ogra> this is how i found one of my qemu machines this morning
<ijohnson> well don't leave it like that :-)
<ogra> seems it got some reboot-triggering update yesterday evening
<zyga> ogra: journalctl -u snapd.service
<ijohnson> ogra: anything in the system journal for snapd?
<codingpanic> pi@raspberrypi:/var/log $ snap list
<codingpanic> Name     Version   Rev   Tracking  Publisher     Notes
<codingpanic> core18   20200124  1671  stable    canonicalÃ¢ÂÂ    base
<codingpanic> scummvm  2.1.1     3126  stable    snapcrafters  -
<codingpanic> I've also tried retroarch
<zyga> codingpanic: snap install core
<ogra> https://paste.ubuntu.com/p/xvRDVNPW4S/
<ogra> the last part simply repeats over and over
<zyga> codingpanic: it's a known bug
<codingpanic> zyga: got it, thank you!
<zyga> ogra: Feb 19 08:11:22 localhost snapd[824]: panic: cannot checkpoint even after 5m0s of retries every 3s: write /var/
<zyga> ogra: did you run out of disk space
<zyga> ?
<codingpanic> zyga: that fixed it
<ogra> zyga, bah, yeah
 * zyga hugs ogra 
<zyga> been there done that (too many times)
<zyga> I need a coffee
<zyga> brb
<ijohnson> pedronis: I need to run an errand right after SU (3:30 PM your time to be specific), can we put something on the calendar for 4:30 PM your time ?
<ijohnson> zyga: I thought we fixed that bug though ?
<zyga> ijohnson: no, that's a separate bug
<zyga> ijohnson: look at snap list output
<zyga> ijohnson: according to our design you have 0 interfaces in that case
<zyga> ijohnson: you must get snapd or core
<ijohnson> zyga: but I thought we fixed the bug where the core snap was not installed when you to go install only a snap with `base: core18` ?
<zyga> ijohnson: also this is raspbian so probably runs an older copy
<ijohnson> zyga: ah right yes probably older version of snapd with the bug still in place
<zyga> yep
<ijohnson> zyga: we should probably update snapd in raspbian, seems to happen somewhat frequently now I think
<zyga> ijohnson: I don't think we can
<zyga> ijohnson: we should update snapd in debian
<zyga> it very old
<ijohnson> zyga: who handles snapd update in debian?
<zyga> nobody
<zyga> us
<zyga> sometimes
<zyga> when $fire
<ijohnson> also doesn't raspbian have it's own archives based on, but separate from debian? perhaps I'm misremembering
<ogra> hrm ... freeing up 120MB and rebooting just gets me back to that state :/
<zyga> ijohnson: it does
<zyga> ijohnson: but we don't have any way to change it
<ogra> bah ... because it is secretly upgrading ... it just rebooted again
<ijohnson> hooray now ogra's ephemeral qemu VM is more secure
<jdstrand> zyga: hey, fyi, https://github.com/snapcore/snapd/pull/7825#discussion_r381277068
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> hye
<zyga> hey*
<zyga> ack
<zyga> I'm still looking into this
<zyga> and especially what happened to your interactive blackbox testing
<jdstrand> zyga: that's fine. I just wanted you to be aware of that weird thing I saw where I semi-started a transient unit and couldn't get it to go away in case it saves you some time
<zyga> thank you
<jdstrand> zyga: otoh, can you also make sure that these tests aren't skipped on core? you mentioned trusty but I thought I remembered something about user sessions on sore.... that said, xenial is starting systemd --user so hopefully it is all ok
<zyga> jdstrand: I will
<zyga> jdstrand: I  think this approach was picked specifically to support 16.04 desktop
<jdstrand> that sounds familiar :)
<jdstrand> that was a long time ago :)
<jdstrand> zyga: fwiw, I'm really bought into the technique and like the PR overall :)
<jdstrand> just need to make sure systemd does what we need everywhere
<zyga> jdstrand: yeah, I just hope I didn't miss anything
<jdstrand> zyga: I did notice yesterday that runc was using StartTransientUnit for at least something... could look there to build confidence. but one of the things I like about this is we are just asking systemd to take care of things for us. so long as we use the api correctly (which it appears you are), we should be good (barring bugs (systemd or otherwise))
<zyga> jdstrand: the only thing I'm worried about is --user
<zyga> the API is sold and supported for a long time
<zyga> but user session is more complex
<zyga> systemd --user is asked to stuff
<zyga> but cannot
<zyga> so asks system systemd to do it
<jdstrand> zyga: kinda like how we ask it to manage starting and stopping services. we tell it a little bit and say "thanks for doing this for me!". same here
<zyga> and that path I believe is somewhat new
<zyga> I'm digging into this now
 * jdstrand nods
<jdstrand> zyga: well, it isn't *terribly* new if it is in bionic (I didn't test xenial), but there is definitely some different behavior
<jdstrand> which might be cherrypicks, etc
<zyga> I think it's all the way back to xenial, but give me a moment to debug it
<jdstrand> zyga: we always have in out back pocket runtime detection and gracefully degrading too (not saying we need it yet)
<jdstrand> s/in out/in our/
<zyga> yes, it's not essential in a way
<cachio> ijohnson, this is the output https://paste.ubuntu.com/p/qNnRgrHktg/
<mvo> mborzecki: thanks, looking
<cachio> from a local run on core-18
<cachio> ijohnson, at the end you can see the issue that I raised a time ago snap-failure[9015]: cmd_snapd.go:124: restoring invoking snapd from: /snap/core/current/usr/lib/snapd/snapd
<ijohnson> thanks cachio, I'm looking now
<cachio> also the error snapd.service: Failed at step EXEC spawning /snap/snapd/x1/usr/lib/snapd/snapd: Exec format error
<ijohnson> cachio: the EXEC spawning issue is very odd, because it should be x2 that has the Exec format error
<jdstrand> zyga: so it is crystal clear: the reproducer is: take a desktop vm install, install snapd/enable the feature/blah, in the graphical session, open a terminal, use hello-world.sh/snap run --shell/etc and it works (find /sys/fs/cgroup -name '*.scope'). ssh in/console login and try the same and it doesn't (but not errors in SNAPD_DEBUG=1 or anywhere else I could find
<jdstrand> )
 * zyga nods 
<zyga> let me check that quickly
<zyga> I was going via spread and I hit another issue there
 * jdstrand nods
<cachio> ijohnson, I have a debug session opened
<cachio> ijohnson, if you need any output please tell me
<jdstrand> I figured it might be easier to see what to recreate if you saw the problem
<ijohnson> I think there is a known issue in that snap-failure should be more robust in trying to restart the socket, and isn't
<ijohnson> cachio: ^
 * jdstrand leaves zyga to it
<ijohnson> cachio: sorry let me keep reading I'm not sure what I would like you to run in the debug session
<zyga> jdstrand: wwo
<zyga> jdstrand: so
<zyga> jdstrand: it works on a fresh install of bionic
<zyga> jdstrand: desktop session
<zyga> jdstrand: I recorded bustle (dbus traffic analyzer) dumps
<jdstrand> zyga: right, in the desktop session, it works
<zyga> and even confirmed it the simple way
<zyga> https://www.irccloud.com/pastebin/pENvRQqK/
<zyga> oh? I missed that
<zyga> when didn't it work?
<jdstrand> zyga: ssh in or do console login and it doesn't
<zyga> ah
<zyga> I see
<zyga> okay that's much clearer now
<zyga> thanks, I'll focus on that
<jdstrand> zyga: that is what made it tricky for me to diagnose :)
<zyga> jdstrand: but I'm 99% sure it's because there's no session bus there
<zyga> and this is a dbus interaction
<jdstrand> zyga: I saw systemd --user started with just ssh
<zyga> jdstrand: ok, I'll debug both cases (console login and ssh)
<zyga> jdstrand: were you logging into the same user as the interactive session?
<zyga> jdstrand: or another user
<jdstrand> zyga: but yeah. maybe there is an activation thing or something. idk
<jdstrand> I sopped looking when I ran out of day
<jdstrand> stopped
<zyga> ok
<zyga> I'll explore those
<zyga> because previously it was a bit magic
<jdstrand> zyga: I was
<zyga> as to why it worked in places I checked
<jdstrand> (same user)
<zyga> ok
<zyga> that would explain the systemd --user aspect
<jdstrand> zyga: well, no. I logged into core a few minutes ago before asking about adding uc tests and there was --user
<zyga> jdstrand: ok, please give me a day to get to the bottom of this
<zyga> jdstrand: if you could review any of the other PRs I mentioned I could perhaps make progress on those
<zyga> jdstrand: but for this one, I know what to do
<jdstrand> that doesn't mean there is a dbus session bus...
<zyga> jdstrand: right
<jdstrand> yes, that was the plan
<zyga> jdstrand: perhaps 18.04 doesn't have enough activation
<zyga> testing is paramount
<zyga> I'll try to cover those
 * jdstrand nods
<sdhd-sascha> mvo: fyi. github runner tries to create config files in the binary directory. This needs to be fixed first. Seems to be hardcoded path's.
<sdhd-sascha> https://github.com/sd-hd/runner-snap/releases
<zyga> jdstrand, mvo: fyi https://github.com/snapcore/snapd/pull/7825#discussion_r381296772
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<mvo> zyga: 0.05s? that is not bad :)
<zyga> mvo: that's wall clock time
<zyga> mvo: the actual new code is 1ms
<ogra> you have a wall clock that measures 0.05s ?!?
<roadmr> ogra: well if you look hard enough a lot of wristwatches measure 0.25s (seconds hand moves at 4hz)
<roadmr> that's mechanical wind-up wristwatches mind you
 * roadmr now looks really old and anachronistic â
<ogra> haha, yeah
<zyga> jdstrand: reproduced
<zyga> https://www.irccloud.com/pastebin/lg1cEV4Q/
<zyga> jdstrand: ^ that's bionic over ssh as user
<zyga> jdstrand: running systemd-run --user --scope ls
<zyga> jdstrand: on the up side, I now have systemd --user running as my user (remote ssh activated it)
<zyga> jdstrand: on the down side, no idea why it failed yet
<zyga> but I can dig
 * jdstrand nods
<jdstrand> I <3 reproducers
<zyga> jdstrand: but that's really weird, raspbian (older) works okay
<zyga> jdstrand: but I'll dig
<zyga> jdstrand: I'll check 20.04 and 16.04 as well
<zyga> jdstrand: _complexity_ :)
<jdstrand> zyga: yes. hopefully it isn't too deep (I recall how the snap_daemon spun out cause of bugs, bugs, bugs. I hope very much that isn't the case here (I don't think it is))
<zyga> I think it's just configuration (famous last words?)
<mborzecki> jdstrand: zyga: your ssh shell should already be part of a user slice/session scope (?)
<zyga> it is
<mborzecki> zyga: same when you log in on a tty, though no clue who arranges that, pam & logind maybe?
<mborzecki> s/who/what/
<zyga> mborzecki: the problem is why remote cannot systemd-run
<zyga> smells like polkit to me
<zyga> I'll look after the standup
<mborzecki> hmm hmm intersting
<roadmr> jdstrand, pedronis : is there a non-system-files interface that would allow write access to /etc/ssh/ssh{,d}_config ?
<roadmr> if not, is it acceptable to grant system-files in this case (it's a device-specific snap in a brand store, so mostly well-scoped)
<zyga> mborzecki: it's polkit
<zyga> mborzecki: give me a while to get the bits in place
<mborzecki> zyga: polkit?
<zyga> yep
<zyga> it's always polkit ;)
<mborzecki> it's always /pluseaudio/polkit/snapd/
<mborzecki> heh forgot systemd
<zyga> I need to take the dog out
<roadmr> who let the dogs out? woof wof...
<mborzecki> zyga: doesn't look like polkit to me
<mborzecki> openat(AT_FDCWD, "/sys/fs/cgroup/unified/user.slice/user-1000.slice/user@1000.service/run-rbcaa5f3010d646e38684382cacc4aa70.scope/cgroup.procs", O_WRONLY|O_NOCTTY|O_CLOEXEC)
<mborzecki> = 34
<mborzecki> fcntl(34, F_GETFL)                      = 0x8001 (flags O_WRONLY|O_LARGEFILE)
<mborzecki> write(34, "2821\n", 5)                  = -1 EACCES (Permission denied)
<mborzecki> uh, w8 that's on focal ;)
<mborzecki> hm weird, there's this sequence
<mborzecki> openat(AT_FDCWD, "/sys/fs/cgroup/unified/user.slice/user-1000.slice/user@1000.service/run-r51cceeed963d4c33ace8cf029e2657d5.scope/cgroup.procs", O_WRONLY|O_NOCTTY|O_CLOEXEC)
<mborzecki> = 30
<mborzecki> write(30, "2504\n", 5)                  = -1 EACCES (Permission denied)
<mborzecki> close(30)
<mborzecki> followed by opening *.scope directory and getdents()
<mborzecki> anyways, the message is Failed to add PIDs to scope's control group: Permission denied which kind of makes sense in this context
<zyga> re
<zyga> mborzecki: which systemd is that?
<zyga> ah, focal
<zyga> mborzecki: systemd --user should ask system to to that write
<zyga> mborzecki: that's what I read from sources
<zyga> mborzecki: anyway, I'll keep digging
 * zyga went outside for a moment and finally cooled the fever of his laptop while using google meet
<pedronis> roadmr: I don't think there is one atm
<roadmr> pedronis: :( any objections with using system-files for this then?
<pstolowski> mvo:  thanks for the suggestion re version check!
<zyga> dns timeouts ugh
<zyga> Feb 19 07:03:47 bionic systemd-resolved[618]: Grace period over, resuming full feature set (UDP+EDNS0) for DNS server 172.16.153.2.
<pedronis> roadmr: no deep objections as long it's scoped, we might add something like sshd-control at some point but not immediately
<jdstrand> roadmr (cc pedronis): there isn't one. if this is in a brand store, 'no', but they can certainly hurt themselves
<jdstrand> pedronis: I might suggest 'snap set core' things instead of sshd-control
<pedronis> jdstrand: yea, but we need clear use cases
<pedronis> to get tehre
<pedronis> get there
<jdstrand> yes
<jdstrand> pedronis: they can be added one by one to snap set. sshd-control is risky and security sensitive
<jdstrand> imho
<pedronis> jdstrand: I understand, the surface of the config is large though
<jdstrand> roadmr: but yeah, no objections for system-files in a brand store so long as they know the risk
<pedronis> anyway not something we'll do soon
 * jdstrand nods
<roadmr> jdstrand: yep, like pedronis said this can be scoped to the specific store to limit risk. I can tell them there is indeed a risk so they are super aware
<roadmr> thanks jdstrand pedronis
<pedronis> roadmr: but if they can tell use what kind of config they are changing it could help us design something later
<pedronis> s/use/us/
<roadmr> pedronis: sure thing, I'll also ask
<pedronis> roadmr: thx
<zyga> jdstrand: FYI https://github.com/snapcore/snapd/pull/7825#discussion_r381360336
<mup> PR #7825: many: use transient scope for tracking apps and hooks <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/7825>
<zyga> github is kind of slow for me today
<zyga> but new notifications are really cool, a big improvement over YOU HAVE NAN NOTIFICATIONS
<jdstrand> github is both slow and broken for me today
<jdstrand> 500 on the above url
<zyga> also 500 often
<zyga> haha
<zyga> yeah, just reload a few times
<zyga> it works eventually
<jdstrand> not able to expand resolved conversations...
<zyga> jdstrand: at some point we can say that github is slow because new core snap refreshes ;-)
<jdstrand> heh
<zyga> jdstrand: the comment says that cgroup v2 doesn't have pids, it's just one big flat tree
<zyga> jdstrand: in v1 we _could_ scope it but current code doesn't require it
<zyga> jdstrand: scoping it mainly requires us to know more about systemd, we could do it at a low cost but I deem it non-essential now
<zyga> jdstrand: certainly something we can improve ahead of making this stable
<zyga> jdstrand: I don't know how you develop locally but I find a desktop (workstation) installation (vm) of fedora 31 is very useful for exploring a full complex system that uses pure v2 mode
<jdstrand> zyga: I obviously need some practical v2 experience since I can never remember how the layout is. I occasionally have a fedora vm, but I find by the next time I need to look at fedora, the one I have is eol ;P
<jdstrand> zyga: I replied
<zyga> jdstrand: :)
<ijohnson> okay I think that I have the snapd-failover test working again
<ijohnson> will push my fix up
<zyga> ijohnson: great news
<pedronis> great
<zyga> ijohnson: cannot wait to see what it was
<ijohnson> StartLimitInterval{,Sec}=0 doesn't play well with OnFailure, because the OnFailure only runs after the unit is in "totally really absolutely failed" state, which systemd only considers after it has exhausted the start limits
<ijohnson> so in our spread tests we specifically set StartLimitInterval=0, which breaks the OnFailure
<roadmr> jdstrand: how can I combine allow-installation constraints? I have used "on-store" by itself, and "plug-attributes" by itself but for this one I need both to apply (ANDing them). I can provide both snap.yaml and my partial snap-decl plugs thingy
<ijohnson> It's unclear why this broke now, I think it may have been a systemd bug that this test worked at all on spread before, and they just now fixed the bug that makes it resiliently fail
<jdstrand> roadmr: please supply both. feel free in privmsg
<roadmr> jdstrand: coming up!
<ijohnson> cachio: zyga: mvo: can y'all (re-)review #8155? I think the test is fixed now, but I want to be sure that there's not unintended consequences to setting StartLimitInterval=100
<mup> PR #8155: tests: mv ubuntu-core-snapd{,-failover} to core/ suite <Test Robustness> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8155>
<zyga> y
<zyga> another new github feature? https://usercontent.irccloud-cdn.com/file/m2oxIZH8/Zrzut%20ekranu%202020-02-19%20o%2017.02.13.png
<mborzecki> zyga: the first bit was from focal, the sencod from bionic
<zyga> ijohnson: I cannot find StartLimitInterval documentation
<zyga> ijohnson: but there is StartLimitIntervalSec
<zyga> ijohnson: and also StartLimitIntervalBurst
<ijohnson> zyga: it was renamed to StartLimitIntervalSec in systemd 230 I think
<zyga> ijohnson: are both names supported?
<ijohnson> zyga: I'm pretty sure, but let me double check
<zyga> ijohnson: interesting, I would love to understand why it worked before
<zyga> ijohnson: perhaps there's more to it than that
<zyga> ijohnson: I think that the explanation on how the value 0 interacts with OnFailure is good but I need to cross check it with documentation
<ijohnson> leonard has some comments on bug reports explaining the interaction, does that count :-)
<ijohnson> zyga: see comment 7 https://bugs.freedesktop.org/show_bug.cgi?id=87799
<ijohnson> but then of course see comment 8 right below it :-)
<zyga> ijohnson: indeed, we should reference in the code there
<zyga> https://bugs.freedesktop.org/show_bug.cgi?id=87799#c7
<ijohnson> should we add a comment in the code or the commit message ?
<cachio> ijohnson, nice, reviewing it
<zyga> in the code I think
<zyga> easier to keep track of
<ijohnson> hmm I guess if it was in the override I would have seen it much quicker in the running system
<ijohnson> yeah good point I'll add it to the code
<pedronis> pstolowski: I re-reviewed 8130
<pstolowski> pedronis: just saw it, thank you!
<ijohnson> okay I have it added to the override unit we put in the spread image, I will put it in a followup PR so that as soon as this one is green we can merge
<pstolowski> ijohnson: can you take another look at #8003 when you have a moment?
<mup> PR #8003: o/ifacestate, api: implementation of snap disconnect --forget <Needs Samuele review> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8003>
<ijohnson> pstolowski: I'll try to look this afternoon or tomorrow morning
<pstolowski> thx
<zyga> ijohnson: reviewed, please look
<zyga> I'll be back shortly
<ijohnson> zyga: it looks like StartLimitInterval is only valid in [Service] in systemd 229 and below, and for systemd 230 and above, StartLimitInterval is supported in systemd 230+ in [Service], but StartLimitIntervalSec is only supported in [Unit], so we are fine to keep using StartLimitInterval in [Unit] like the test does
<ijohnson> see https://lists.freedesktop.org/archives/systemd-devel/2017-July/039255.html, but this is poorly documented in systemd docs
<ijohnson> zyga: how would you like me to document that in the PR?
<ijohnson> zyga: see the corresponding commit too https://github.com/systemd/systemd/commit/f0367da7d1a61ad698a55d17b5c28ddce0dc265a
<zyga> ijohnson: a code comment will suffice
<zyga> I just felt it is a bit too magic to leave as-is
<mup> PR snapcraft#2948 opened: Regenerate the GDK pixbuf loaders cache file if for whatever reason it isn't there (LP: #1863801) <Created by oSoMoN> <https://github.com/snapcore/snapcraft/pull/2948>
<ijohnson> zyga: a follow-up okay for the comment then?
<zyga> ijohnson: is it green now?
<ijohnson> Ah debian seems unhappy now
<roadmr> ð  <- debian
<cwayne> I love how roadmr is just like the dad of all IRC channels
<roadmr> I am everywhere.
<roadmr> Iam inevitable ð
 * zyga needs a nap
<zyga> ijohnson: feel free to discard my review and land with a comment
<zyga> I will be back in 2 hours
<zyga> So sleepy now
<mup> PR snapd#8157 opened: tests: using google storage when downloading ubuntu cloud images from gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8157>
 * cachio afk 
<cachio> going to the doctor
<zyga> re
<zyga> *ah, I needed that*
<zyga> so now nfs-support fails
<zyga> ijohnson: do you think that is related to the change?
<zyga> that's an 18.04 failure
<zyga> but actually, not
<ijohnson> zyga: yes I noticed now that fails on the PR
<ijohnson> zyga: I have a fix for that
<zyga> across the board
<zyga> do you know what happened?
<ijohnson> I was setting StartLimitInterval wrong, that's just the, well, interval, not the number of times starts can happen
<ijohnson> StartLimitBurst is the number of times it can start
<zyga> aha
<zyga> ok, let's try that
<ijohnson> So I changed it to set both StartLimitBurst and StartLimitInterval and now it's good
<ijohnson> let me push it up
<zyga> thanks!
<ijohnson> was in the middle of UC20 debugging
<zyga> no worries, I just woke up
<mup> PR snapcraft#2949 opened: Fix clean on Windows <Created by NickZ> <https://github.com/snapcore/snapcraft/pull/2949>
<mup> PR snapd#8158 opened: tests: disable archlinux system <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8158>
<ijohnson> cachio: should we use the no-spread label on that PR?
<mup> PR snapd#8158 closed: tests: disable archlinux system <Skip spread> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8158>
<mup> PR snapcraft#2933 closed: remote-build: introduce --launchpad-snapcraft-channel option <Created by cjp256> <Closed by cjp256> <https://github.com/snapcore/snapcraft/pull/2933>
<mup> PR snapd#8159 opened: snap-bootstrap: remove created partitions on reinstall <UC20> <Created by cmatsuoka> <https://github.com/snapcore/snapd/pull/8159>
#snappy 2020-02-20
<mup> PR snapcraft#2950 opened: meta: Snap to_dict() cleanup <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2950>
<mup> PR snapd#8148 closed: overlord/configstate/configcore: add support for backlight service <â Blocked> <Created by EthanHsieh> <Closed by EthanHsieh> <https://github.com/snapcore/snapd/pull/8148>
<mborzecki> morning
<mborzecki> school run
<mup> PR snapd#8160 opened: overlord/configstate: add backlight option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8160>
<mborzecki> re
<mborzecki> mvo: hey
<mvo> mborzecki: good morning
<zyga> good morning
<mborzecki> hmm looks like my git filter-branch incantations on #8156 were not good enough
<mborzecki> zyga: hey
<mup> PR #8156: [RFC] cmd/snap-bootstrap: subcommand to detect if we want a chooser to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<zyga> hmm
<zyga> didn't I review https://github.com/snapcore/snapd/pull/8160 already?
<mup> PR #8160: overlord/configstate: add backlight option <Created by EthanHsieh> <https://github.com/snapcore/snapd/pull/8160>
<zyga> or something just like it?
<mvo> zyga: I think the config var got tweaks
<zyga> meanwhile master is still red
<zyga> Ian sent a fix but it seems to be insufficient or also broken somehow
<zyga> hmm, what is curious is that the failure is only present on core18
<zyga> I wonder if that's because of the extra logic on how snapd is started there
<mvo> zyga: I run a debug session now
<mvo> good morning pstolowski
<pstolowski> morning
<zyga> hey Pawel, good morning
<mvo> zyga: it's a bit annoying, also it's super unclear why it's starting now
<mborzecki> pstolowski: morning!
<mvo> zyga: actually - new systemd in bionic since 2020-02-17
<zyga> ohhh
<mvo> zyga: I think this is roughtly when the trouble started?
<zyga> that's a good trail
<zyga> yeah, let's see the changelog
<mvo> zyga: we could run core18 tests with stable core18, that still has the old version
<zyga> wow, that's true, that's brilliant
<zyga> if that passes we know for sure it's the base OS that changed
<mvo> zyga: the changelog has a smoking gun
<zyga> reading it now
<zyga> og
<zyga> OnFailure job something
<zyga> don't trigger ONFailure
<mvo>     - Only trigger OnFailure= if Restart= is not in effect (LP: #1849261)
<mup> Bug #1849261: Update systemd for ubuntu 18.04 with fix for interaction between OnFailure= and Restart= <architecture-s39064> <bionic> <bugnameltc-182011> <ddstreet> <id-5de127a738dabd05006e38e8> <severity-high> <systemd> <targetmilestone-inin1804> <verification-done> <verification-done-bionic>
<mup> <Ubuntu on IBM z Systems:Fix Released by canonical-foundations> <systemd (Ubuntu):Fix Released> <systemd (Ubuntu Xenial):Won't Fix> <systemd (Ubuntu Bionic):Fix Released by ddstreet> <systemd (Ubuntu Disco):Fix Released> <systemd (Ubuntu Eoan):Fix Released> <https://launchpad.net/bugs/1849261>
<mvo> zyga: exactly, this looks super suspicious
<mvo> zyga: also wrong, I mean, if it fails to restart for n times we need to go into failure
<mvo> anyway
<zyga> hmm hmm hmm
<zyga> mvo: but it passes in 20.04
<zyga> so something changed there
<zyga> the patch is https://github.com/systemd/systemd/pull/9158/files
<mup> PR systemd/systemd#9158: trigger OnFailure= only if Restart= is not in effect <pid1> <Created by poettering> <Merged by keszybz> <https://github.com/systemd/systemd/pull/9158>
<zyga> I'll check if that got changed further down the line
<mvo> zyga: cool, thank you
<mvo> zyga: I think this is it, kind of annoying
<mvo> zyga: but at least we know now what to do
<zyga> mvo: the test does run on 20.04, right?
<mvo> zyga: lol - no
<mvo> zyga: it has a TODO:UC20: "does not work for unknown reasons"
<zyga> pfff
<zyga> hahahaha
<zyga> so it's broken
<zyga> and now we need to live with it
<zyga> ok
<mvo> zyga: well
<mvo> zyga: let me try something
<zyga> the code didn't change since that patch, systemd master still behaves the same way it does in 18.04
<zyga> ok
<zyga> so
<zyga> I think we need to change how snapd restarts
<zyga> if we limit that to a fixed number
<mvo> zyga: I hope we just need to change the startlimitinterval
<zyga> then on failure will trigger again
<zyga> no, not the interval
<mvo> zyga: then the failure will be triggered again
<mvo> zyga: no?
<zyga> we need to allow snapd to really fail
<zyga> that's how I understand this fragment:
<zyga> https://www.irccloud.com/pastebin/phqUSrfE/
<zyga> let me read the diff again
<mvo> zyga: right, my understanding is that once we hit the restart interval it will actually go into failed state and then the OnFailure is run
<mvo> zyga: but I just infered this, did not read the patch
<zyga> we need to check
<zyga> I mean
<zyga> just do
<ijohnson> zyga: mvo: what I think is the best fix to fix this with the new systemd is 2 things, 1 nfs-support test needs to also reset-failed on snapd.socket and 2 snap-failure needs to reset-failed before trying to start the socket unit
<zyga> https://github.com/systemd/systemd/pull/9158/files#diff-a89a9b6f80aada989d298b4c2c3a9d64R2435
<mup> PR systemd/systemd#9158: trigger OnFailure= only if Restart= is not in effect <pid1> <Created by poettering> <Merged by keszybz> <https://github.com/systemd/systemd/pull/9158>
<zyga> so, as long as the service will auto restart
<zyga> we don't get failed state
<zyga> ijohnson: good mornign!
<zyga> (it's kind of early, wow :)
<ijohnson> Yeah couldn't sleep but probably will try to go back to bed shortly
<mvo> ijohnson: woha, hey
<mvo> ijohnson: good evening :)
 * mvo hugs ijohnson 
<ijohnson> mvo: indeed :-)
<mborzecki> ijohnson: hey! already adjusting to CET timezone?
<zyga> mvo: I need to handle an errand at home, I'll be back in 20
<mvo> zyga: no worries
<mvo> zyga: testing a patch now
<ijohnson> Anyways snap-failure needs to be a bit more robust about starting the snapd.socket service anyways
<mvo> ijohnson: thanks, that's good to know
<ijohnson> Because cachio ran into another problem with this test that happens because the socket is still lying around
<mvo> ijohnson: I'm poking at it now, a bit annoying since it takes forever to run each test
<ijohnson> Haha yes that was most of my day yesterday waiting for spread and fixing other random things in the meantime
<ijohnson> mvo: but also see my comment about the nfs-support test, it calls reset-failed on _only_ snapd, it should also call that on snapd.socket too
<mborzecki> stepping out for a bit to get the papers to my accountant, and then will probably work from some place in the city
<mup> PR snapd#8161 opened: tests: set StartLimitInterval in snapd failover test <Created by mvo5> <https://github.com/snapcore/snapd/pull/8161>
<mvo> ijohnson: thanks, I check these area too but it seems the current issue is about the StartLimitInterval
<zyga> re
<zyga> there's some chaos at home today
<zyga> I'm heading out
<ijohnson> mvo: what I was trying to say is that the nfs-support test will start failing too when you make adjustments to the StartLimitInterval that are favorable to snapd-failover because that test is flaky due to not resetting the failed count of the snapd.socket service
<zyga> don't want to be a part of this
<zyga> (family life and living with parent-in-law)
 * mvo hugs zyga 
<mvo> ijohnson: aha, thanks. my current approach was to adjust the StartLimitInterval  only in this one test
<mvo> ijohnson: i.e. just enough to get us on our feed again, not at all against fixing more
<ijohnson> Ah okay nvm me then
<mvo> ijohnson: let's talk some more later, I really don't want to keep you from sleep :)
<ijohnson> It's fine no worries
<zyga> mvo: re
<zyga> mvo: small observation
<zyga> mvo: perhaps we want to consider a spread suite that does run in autopkgtest and gates classic systemd
<zyga> mvo: we would catch this if that test was a part of that set
<zyga> mvo: something to consider after this is resolved
<zyga> mvo: I'll work on my tasks from Jamie's review - please pull me into a review once you have the fix
<zyga> mvo: and it's also a good good catch about this test, if we had disabled that test and released a new core we could really have a bad day
<mvo> zyga: it's an interessting idea, we did have autopkgtest for snapd but it was terrile unreliable
<mvo> zyga: we would have caught this thought
<zyga> yeah, perhaps we can turn some knobs to make it better though
<zyga> dunno
 * mvo nods
<zyga> totally offtopic, I noticed that systemd --user runs for gdm
<zyga> we should probably not run snap services for gdm
<pedronis> mvo: hi, is it expected there's no standup in the calendar today?
<mvo> pedronis: not expected, uh, let me fix this
<mvo> pedronis: thanks for catching that
<pedronis> #8130 needs a 2nd review
<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>
<mup> PR snapd#8162 opened: features: enable "parallel-installs" by default <Created by mvo5> <https://github.com/snapcore/snapd/pull/8162>
<mborzecki> yay
<mborzecki> mvo: that's for 2.44?
<zyga> mvo: that's great to see, thank you!
<mvo> mborzecki: that's something to discuss
<mvo> mborzecki: 2.44 means it's ready for 20.04 and most likely on the CD
<mvo> mborzecki: which is great
<mvo> mborzecki: but also risky
<mborzecki> ayy ;)
<mvo> mborzecki: let's talk at the standup
<mborzecki> mvo: ok
<mvo> also - amazon linux is failing to install packages right now :(
<mborzecki> mvo: duh, got logs?
<mvo> mborzecki: yes, on sec
<mvo> mborzecki: I move it to unstable for now, look like some repo issue
<mvo> mborzecki: probably transient
<mvo> mborzecki: https://travis-ci.org/snapcore/snapd/jobs/652883253?utm_medium=notification&utm_source=github_status
<mvo> yay, 8161 unbreaks the snapd-failover test
<pedronis> mvo: we really need to do something about aliases before turning on parallel installs by default
<mborzecki> mvo: yeah, looks like inconsistency in amazon's repos
<mborzecki> mvo: and kinda basic, iproute, iptables :/
<mup> PR snapd#8162 closed: features: enable "parallel-installs" by default <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8162>
<mvo> pedronis: ok, closing this again then until we have time for this
<mvo> mborzecki: yeah, that was my impression as well, hopefully transient
<mborzecki> pedronis: thanks for the review
<pedronis> mvo: yea, sadly it needs more work, but I think the current experience is suboptimal
<pedronis> and we turn it on we are stuck with the behavior forever
<mvo> reviews for 8161 would be appreicated
<mvo> (should be super simple)
<mvo> and fixed the snapd-failover test - at least in the one run that happened there :)
<zyga> mvo: what's the context of amazon linux and unstable
<zyga> the commit message has no other information
<pedronis> <mvo> also - amazon linux is failing to install packages right now :(
<mup> PR snapd#8163 opened: tests: enable snapd-failover on uc20 <Simple ð> <Created by mvo5> <https://github.com/snapcore/snapd/pull/8163>
 * pedronis reboots
<mup> PR snapd#8164 opened: snap: use the actual staging snap-id for snapd <Simple ð> <Created by pedronis> <https://github.com/snapcore/snapd/pull/8164>
<mborzecki> pedronis: got a question about https://github.com/snapcore/snapd/pull/8156#discussion_r381881462 you'd see the WaitTriggerKey() be moved to some other file right and just keep the interfaces and related structs in triggerwatch.go?
<mup> PR #8156: [RFC] cmd/snap-bootstrap: subcommand to detect if we want a chooser to run <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<pedronis> mborzecki: not quite,  I think the structs should go where they are used as input or output to functions
<pedronis> mborzecki: this is go so the interfaces can be defined on the consuming side
<pedronis> mborzecki: I mean keyEvent etc should be in evdev.go
<mborzecki> pedronis: hmm right, the only concern i have is that keyEvent is a concrete type, so it's kind of shared between the consumer and producer, not sure if i'm explaining this right :)
<pedronis> mborzecki: you are, but is not a concern in go
<pedronis> the interfaces exist mostly for testing, no?
<pedronis> mborzecki: it's very unsual for a consumer to define structs it wants
<mborzecki> pedronis: yeah, well, maybe i'm trying to complicated it too har :)
<pedronis> mborzecki: let's put it this, way if you tried to stick evdev.go in its own package as is, it wouldn't work
<pedronis> mborzecki: does this ^ remark makes sense? I'm also happy to HO if I'm still confusing you
<mborzecki> pedronis: it's ok, i'm overcomplicating this, thought about a scenario when evdev went to a separate pacakge and KeyEvent would either need to be an iface, or one package would need to import the other to get the definition, but it makes no sense to restructure it this way
<pstolowski> cachio: hey! i've asked 2 questions under #8157
<mup> PR #8157: tests: using google storage when downloading ubuntu cloud images from gce <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8157>
<cachio> pstolowski, hi, I'll take a look
<cmatsuoka> mborzecki: just out of curiosity, what's the time difference between running the chooser trigger check from initramfs or early in the normal system?
<mborzecki> cmatsuoka: we can start the detection early, in my VMs it's like <1s earlier than early boot, but i guess it may be different on the actual devices
<mborzecki> cmatsuoka: and there's also a question, whether we'd be able to execute the gadget-provided trigger hook in initramfs, which i suspect we won't
<mborzecki> cmatsuoka: as i said during the standup, it's probably only to the benefit of a device that supports the trivial input method like keyboard or somesuch
<cmatsuoka> mborzecki:  I had this feeling that initramfs should execute really fast
<cmatsuoka> mborzecki: but yeah I don't know how slow real devices could be
<jdstrand> zyga: hey, fyi, https://github.com/snapcore/snapd/pull/7980 is -><- close
<mup> PR #7980: packaging,snap-confine: stop being setgid root <Created by zyga> <https://github.com/snapcore/snapd/pull/7980>
<zyga> jdstrand: cool
<zyga> jdstrand: I'll check soon
<zyga> jdstrand: going through coverity, last one to fix
 * pstolowski lunch
<mborzecki> moving back home
<mborzecki> bbiab
<cmatsuoka> mvo: the enable failover tests failed for some reason
<zyga> jdstrand: https://github.com/snapcore/snapd/pull/8165
<mup> PR #8165: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <https://github.com/snapcore/snapd/pull/8165>
<mup> PR snapd#8165 opened: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <https://github.com/snapcore/snapd/pull/8165>
<zyga> jdstrand: replied to setgid, I'll jump there immediately now as it's so low hanging and it could be done shortly
<zyga> jdstrand: the bigger branch is still in progress, I'm working on improving the testing setup and resolving the issue you highlighted in remote access to 18.04 system
<zyga> jdstrand: it is real but for reasons I need to dig deeper to understand
<zyga> mvo, jdstrand: FYI - I will make coverity scan automatic, this is just the first step
<zyga> jdstrand: btw, I think we got remarkably little things flagged by coeveity
<zyga> Coverity
<zyga> I was bracing for a huge list
<zyga> It is a really cool tool
<zyga> mvo: it seems core 20 needs more love for failover
<zyga> mvo: /bin/bash: line 89: /usr/bin/snap: No such file or directory
 * zyga small coffee & pÄczek break
<cmatsuoka> PÄczki look delicious!
<zyga> cmatsuoka: it's fat Thursday here
<zyga> cmatsuoka: so pÄczki are everywhere
<pedronis> mvo: is it known that snapd snap ships the code in /snap ?
<cmatsuoka> pedronis: you mean the go source code? yes, but it's to be solved with ijohnson's patch to use base: core in snapcraft.yaml
<zyga> we back up like real men
<zyga> by shipping all code to each user in production
<zyga> Dear $NAME; This is not a scam. Can you send us your core snap back please? We lost all disks in a thunderstorm. kthxbye
<mborzecki> re
<zyga> I just jumped through initrd break=premount
<zyga> fun
<zyga> I think I will head back
<zyga> better to have the standup in a private setting
<zyga> I'll finish my coffee and walk home
<ijohnson> Speaking of my branch it should be ready to land when the Snapcraft in candidate goes to stable
<mvo> cmatsuoka, zyga re core20 failover> it is strange, I ran this locally and it worked, oh well. needs investigation
<pstolowski> mvo: your fix for master failed on preseed test during image download. Perhaps it would make sense to land cachio's 8157 first (and flag it with 'skip spread')
<sdhd-sascha> zyga: Can you explain what syntax/grammer of the mount command here has? And where receive the command then?
<sdhd-sascha> ```
<sdhd-sascha> emit("  mount options=(bind, rw) %s -> %s,\n", bindFile, path)
<sdhd-sascha> emit("  mount options=(rprivate) -> %s,\n", path)
<sdhd-sascha> emit("  umount %s,\n", path)
<sdhd-sascha> ```
<sdhd-sascha> I mean: who receives the message?
<sdhd-sascha> zyga: wait. it's in the comments. Thank you
<mvo> pstolowski: hm, I can cherry pick his fix into my PR
<pstolowski> mvo: that works too
<zyga> re
<zyga> sdhd-sascha: that's apparmor mount specification
<zyga> sdhd-sascha: I'm glad you asked about grammar
<zyga> sdhd-sascha: that's about the only thing that is very thoroughly documented :)
<zyga> sdhd-sascha: go to http://manpages.ubuntu.com/manpages/bionic/man5/apparmor.d.5.html
<zyga> sdhd-sascha: and check the MOUNT RULE = part
<cmatsuoka> mvo: Thursdays SUs are in a different room now?
<sdhd-sascha> zyga: :-) thank you, again.
<sdhd-sascha> i'm looking for a way to mount when a classic snap service restarts. Think the install hook is not enough.
<zyga> sdhd-sascha: can you summarize as to what you want to detect and what you want to do in response please
<mvo> cmatsuoka: not really, sorry, silly calendar
<zyga> hmm
<zyga> should I join what meet proposes
<zyga> I'm in the standp
<zyga> nobody there
<cmatsuoka> zyga: use the regular one I guess
<zyga> can you spare the link
<sdhd-sascha> zyga: the github-runner, needs write access in the same directory. so i create /var/lib/runner/$SNAP_NAME/_work directory on install-hook. Then i want to be sure, that this is mounted to $SNAP/usr/lib/runner/_work
<zyga> I just go to meet.google.com
<zyga> mvo: can you share the correct link
<sdhd-sascha> zyga: it's classic, because i don't know what the github-action-runner-scripts can do
<sdhd-sascha> zyga: on classic, the layout in snapcraft.yaml is not executed...
<zyga> sdhd-sascha: layouts don't do anything during classic confinement
 * sdhd-sascha nod
<sdhd-sascha> Would be nice if layouts in classic mode would also work.
<zyga> sdhd-sascha: what would you expect them to do?
<zyga> sdhd-sascha: change the host?
<zyga> sdhd-sascha: what if two snaps want to have $SNAP/foo in /usr/lib?
<zyga> sdhd-sascha: who wins?
<sdhd-sascha> maybe, limit the mounts to `/var/lib/runner/$SNAP_NAME/$SNAP_REVISION/_work` like above
<zyga> sdhd-sascha: what is /var/lib/runner?
<sdhd-sascha> i mean, without runner
<mup> PR snapd#8166 opened: cmd/snap-bootstrap: create a new parser instance <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8166>
<zyga> sdhd-sascha: I think this is weird, a classic snap can just mount stuff there
<zyga> sdhd-sascha: perhaps I'm missing something but I think layouts are not meant for this
<sdhd-sascha> ok
<sdhd-sascha> thank you
<zyga> sdhd-sascha: layouts take something from the snap and put it somewhere in the view of the snap
<zyga> sdhd-sascha: but none of that changes the host for real
<mborzecki> cmatsuoka: btw. could we just mkfs rather than delete/remove partitions?
<cmatsuoka> mborzecki: right, I think we could just redeploy them instead of messing with the partition table
<mborzecki> cmatsuoka: just look at the attributes to know which ones we can wipe
<cmatsuoka> mborzecki: let's try that
<ackk> mvo, hi, sorry to ping again wrt #1817276, is there anything I can capture when this happens to help debugging? I see it quite frequently locally. it might be made worse by the fact that my laptop is a bit old
<mup> Bug #1817276: snapfuse use a lot of CPU inside containers <maas> <snapd:Fix Released by mvo> <https://launchpad.net/bugs/1817276>
<mvo> ackk: I need to appologize for this one, we still have not invstigated how this can happen
<cmatsuoka> mborzecki: I blocked the PR while I try those changes, but I'll work on the TPM cmdline measuring first
<mborzecki> cmatsuoka: cool, added a note there too
<ackk> mvo, np. I can't change the status of that bug. does it make sense to reopen or should I file a new one ?
<pedronis> mborzecki: ping me when the chooser PR is ready for re-review
<mvo> ackk: let me reopen it
<ackk> mvo, thanks
<mvo> ackk: reopened and updated the description. let me try to investigate again
<mvo> ijohnson: do you think you could have a look at 8161 ? it's green and seems to fix the snapd failover, if it's not wrong I'm in favor of merging and then we can merge your improvements next?
<mvo> ijohnson: it should unblock all the other PRs we have open
<ijohnson> mvo:  sure
<ackk> mvo, thanks
<ijohnson> mvo: approved
<mvo> pedronis: thanks for letting me know about the /snaps subdir in the snapd snap - I (strongly) suspect that snapcraft is acting silly here, will investigate
<ijohnson> mvo: it's fixed in modern snapcraft
<mvo> ijohnson: aha! so we just need to land your PR :) ?
<ijohnson> mvo: my PR open right now fixes that, but we just need to wait until snapcraft 3.10 on candidate channel is promoted to stable
<ijohnson> yes
<mvo> ijohnson: I guess I could change our build recipe to use snapcraft from candidate?
<mvo> ijohnson: let me try this
<ijohnson> mvo: yes that would let us land sooner, not sure if that's okay to build snapd that gets released with candidate? depends on how much you trust sergiusens I guess :-)
<ijohnson> mvo: the spread test we have is already using candidate
<ijohnson> (but that doesn't release anywhere, just makes sure it builds)
<mvo> ijohnson: I trust sergiusens a lot - plus the extra testing snapcraft would get this way is probably good
<ijohnson> sure sounds good then :-)
<mup> PR snapd#8161 closed: tests: set StartLimitInterval in snapd failover test <Test Robustness> <â  Critical> <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8161>
<sergiusens> ijohnson: I am mostly waiting on feedback from field, but I probably won't be releasing this week
<mvo> sergiusens: I switched our default snapd builds to use the snapcraft from candidate now, I think this makes sense anyway for testing your stuff earlier
<mvo> ijohnson: so just to double check 7904 will work with snapcraft 3.10 in candidate? so I can remove the blocked label?
<ijohnson> mvo: yes
<mvo> ijohnson: awsome
<sergiusens> thanks mvo, that will help!
<mborzecki> zyga: https://github.com/snapcore/snapd/pull/8165/files#r382057305
<mup> PR #8165: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <https://github.com/snapcore/snapd/pull/8165>
<mborzecki> zyga: found an example of use in qemu: https://github.com/qemu/qemu/blob/master/scripts/coverity-model.c
<zyga> mborzecki: looking
<mborzecki> cmatsuoka: can you take a quick look at https://github.com/snapcore/snapd/pull/8166 ?
<mup> PR #8166: cmd/snap-bootstrap: create a new parser instance <Simple ð> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8166>
<mvo> ackk: in the bugreport you write this happens inside a bionic container, this is puzzling. however it seems like I can explain why it's happening inside a disco container. but it's a bionic container?
<mvo> ackk: anyway, I will dig a bit deeper, if you have access to the container the output of "apt list squashfsfuse" would be nice
<mvo> ackk: to the problematic container
<ackk> mvo, well yeah I've seen it in bionic, but also on focal while testing maas upgrade from deb to snap
<mvo> ackk: ok, I keep diging
<ackk> mvo, in this scenario I launch a bionic container, install maas from deb, do-release-upgrade to focal which updates to the transitional deb (which installs the snap). once services in the snap start, snapfuse eats all cpu (along with python for the services)
<mvo> ackk: in a meeting right now, will get back to you (and try this out)
<sdhd-sascha> Is it possible to backup a snap installation and restore them on a new installation as blob ?
<sdhd-sascha> It could be faster on github-actions if the installation of "snap", "lxd", "snapcraft" could be shortend with a tar-package
<zyga> sdhd-sascha: ish, it's not trivial
 * zyga is busy and won't respond now, sorry
<cmatsuoka> mborzecki: thanks, that's very useful!
 * mborzecki figures it's better to rebuild initramfs before repacking the kernel snap /o\
<mvo> ackk: just one more question - what is your "host" os that you run lxd on ?
<mvo> ackk: just to make sure I get a realistic reproducer
<ackk> mvo, currently eoan
<ackk> mvo, lxd backend is btrfs (if that matters)
<ackk> (lxd 3.20)
<mvo> ackk: thank you
<ackk> mvo, np, let me know if you need any more info
 * cachio lunch
<mvo> ijohnson: 7904 is green :)
<mvo> can someone do a second review on 7904 please?
<zyga> y
<ijohnson> mvo: pstolowski reviewed and approved it a while ago
<ijohnson> but sure more reviews is never a bad idea
<ijohnson> :-)
<zyga> mvo: what does adopt-info snapd do?
<zyga> I remember the concept
<mup> PR snapd#8163 closed: tests: enable snapd-failover on uc20 <Simple ð> <UC20> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8163>
<zyga> but what's the data source for "snapd"?
<mvo> zyga: it means to get info like version from the snapd part
<zyga> aha, I see
<zyga> but where is the part defining anything that is adopted?
<zyga> is that set-version snapcraftctl?
<ijohnson> zyga: the data source for snapd when not specified defaults to "."
<ijohnson> err for any snapcraft part rather
<ijohnson> zyga: `adopt-info: snapd` means get metadata for the snap from the part named "snapd", which is a bit counter-intuitive since the whole snap is named snapd and we also have the magic `type: snapd` so it's not clear if it's a special value or just a part
<zyga> yeah
<ijohnson> zyga: if you like I could rename the part from snapd to `snapd-deb` as that's really what the part is building
<zyga> a comment would be nice
<zyga> followup material
<ijohnson> cool, yes I would prefer a followup if that's okay
 * ijohnson is not feeling lucky
 * ijohnson about tests today
<zyga> hahaha
<mup> PR snapd#8167 opened: o/standby: add SNAPD_STANDBY_WAIT to control standby in development <Created by pedronis> <https://github.com/snapcore/snapd/pull/8167>
<mup> PR snapd#7904 closed: snapcraft.yaml: use build-base and adopt-info, rm builddeb plugin <Created by anonymouse64> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/7904>
<mvo> ackk: one more question - in the bugrpeort you say that you see squashfuse generating a lot of cpu, it's squashfuse (and not snapfuse), right?
<ackk> mvo, let me confirm
<ackk> mvo, it seems it's actually snapfuse
<mvo> ackk: that's interessting
<mvo> ackk: the bugreport says "after installing core and rebooting". this is installing core in the container, I suppose but then rebooting the host?
<ackk> mvo, no, rebooting the container, but that might be a red herring, I tried reproducing it that way and didn't manage to. so it might have been something else
<ackk> mvo, what I did right now, though is just to install the maas snap, and initialize it
<ackk> not a clean container, just my dev onne
<ijohnson> pedronis: mvo: xnox mentioned to me a while back that we should consider upgrading the build-base of the snapd snap to build a newer libc/other tools, thoughts on this? I don't think we need to do this now, but I could add a TODO:UC20: to the snapcraft.yaml for the snapd snap so we don't lose this suggestion
<ackk> mvo, I take the more I/O the application does, the more snapfuse has to work as well?
<mvo> ackk: yes
<xnox> ijohnson:  if you do, you do need to check minumum kernel requirements from newer libc, and how it matches the platforms you support.
<mvo> ackk: I mean, snapfuse taking quite a bit of cpu is normal but we fixed using the wrong snapfuse binary a while ago and it puzzling that apparently this is not fully working for you
<ijohnson> also xnox in other news, you should now be able to cleanly build snapd snap from git master with candidate snapcraft :-)
<ijohnson> xnox: hmm good point
<xnox> but do note that trusty is no longer a support target for snapd
<ackk> mvo, I haven't seen issues with other snaps in containers, but maas does quite a lot of IO even just when starting up / setting up, so maybe the issue shows there more prominently
<ackk> mvo, plus, my laptop is old and non-nvme
<ackk> mvo, btw, the original issue reported by BjornT was on zfs, mine is on btrfs, so I was wondering if COW filesystems might play a role
<mup> PR snapcraft#2939 closed: pluginhandler: user directories scoped to partdir for snapcraftctl <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2939>
<ackk> mvo, I have a focal machine, I can try spawning a container there and see if it it's different
<mvo> ackk: interessting, could be. I'm trying in a clean 19.10 VM, all freshly created in qemu and see snapfuse hoover around 40% cpu which seems not that unexpected
<ackk> mvo, is that with maas?
<mvo> ackk: yes, with maas init
<mvo> ackk: I now see two snapfuse, one 65 the other 20%
<ijohnson> zyga: see ^ or v depending on how quick mup is
<mvo> ackk: I think you mentioned multiple ones with 100% ?
<mvo> ackk: but this is ext4, I need to try zfs/btrfs :/
<mup> PR snapd#8168 opened: snapcraft.yaml: add comments, rename snapd part to snapd-deb <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8168>
<ijohnson> there it is ^
<ackk> mvo, no just one, plus multiple python processes also using quite a lot of cpu, but that's expected during init
<mvo> ackk: yeah, I see python too but was assuming that is maas :)
<mvo> ackk: just one> but 100% cpu?
<mup> PR snapcraft#2947 closed: remote-build: pass through 'source-subdir' property <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2947>
<ackk> mvo, correct
<mvo> ackk: ok, I think I need to re-do this with a different fs, ext4 seems to not show it (or I'm doing something wrong)
<pstolowski> cachio: can you merge master into 8157?
<mvo> ackk: it runs for a long time, that is normal?
<ackk> mvo, yeah, although snapfuse stealing cpu makes it worse
<mvo> ackk: yeah :(
<ackk> mvo, fwiw in my container here maas init has finished but snapfuse is still running at 100%cpu
<mvo> ackk: will redo this now with a different fs
<mvo> ackk: uh, that's interessting
<ackk> mvo, that's what always happens
<mvo> ackk: can you check where snapfuse comes from? it should be /usr/bin/snapfuse from inside the container
<ackk> mvo, /usr/bin/snapfuse
<ackk> (from /proc/pid/exec)
<mvo> ackk: yeah, that should be fine (well, "should")
<ackk> err, exe
<mup> PR snapcraft#2943 closed: spread: capture developer debug information <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2943>
 * mvo add zfs or something to see if it makes a difference
 * ackk stops maas before laptop catches fire
<BjornT> ackk: let it burn and buy a new one already :)
<pedronis> mborzecki: 8136 needs a 2nd review
<ackk> BjornT, because of free mentining it I'm now kinda waiting for gen8
<mup> PR snapd#8166 closed: cmd/snap-bootstrap: create a new parser instance <Simple ð> <Created by bboozzoo> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8166>
<mup> PR snapcraft#2923 closed: requirements: Update PyYAML requirement to 5.3 <Created by NickZ> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2923>
<mup> PR snapd#8155 closed: tests: mv ubuntu-core-snapd{,-failover} to core/ suite <Test Robustness> <â  Critical> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8155>
<pedronis> mvo: #8153 needs more work
<mup> PR #8153: [RFC] "snap run --explain" with different formating <Created by mvo5> <https://github.com/snapcore/snapd/pull/8153>
<mborzecki> pedronis: cmatsuoka: i've updated #8156
<mup> PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<mborzecki> pedronis: as for naming, snap-boostrap core-chooser-trigger and snapd.core-chooser-trigger.service ?
<ackk> mvo, I started a bionic container and installed maas there on my other machine which is running focal, snapfuse is not using cpu there
<cachio> pstolowski, done
<cachio> pstolowski, thanks for the heads up
<pedronis> mborzecki: s/core/recovery/
<mborzecki> pedronis: recovery-chooser-trigger?
<mvo> ackk: oh? so on focal things are working for you?
<ackk> mvo, it seems so, I wonder what happens if I update my laptop
<pedronis> mborzecki: yes
<pstolowski> cachio: yw
<mvo> ackk: but I can reproduce the "keeps hogging cpu" issue in bionic
<ackk> mvo, oh, "good"
<pstolowski> cachio: i think only 19.10 and 20.04 images need to be re-downloaded often
<mvo> ackk: but I see a ton of run-supervisorctl restart <lots-of-services> in my ps output, so the snapfuse might be legit traffice because of all this activity in the container?
<mvo> ackk: like literally >200 supervisorctl restart
<mvo> ackk: is that expected? also it seems like its not actually restarting :(
<mvo> ackk: and the number fluctuates
<mvo> ackk: like I had 206 some moments ago, now 211, then 214, 215
<mvo> ackk: now 217
<pedronis> #8130 and #8136 could use a 2nd review
<ackk> mvo, you mean there are that many processes in parallel running?
<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>
<mup> PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136>
<mvo> ackk: correct
<mvo> ackk: I added that to the bugreport too
<ackk> mvo, can you check /var/snap/maas/common/log/supervisor-run.log ?
<mvo> ackk: I see a lot of waiting/stopped/spawned
<mvo> ackk: I can try to scp but i'm at >1600 process right now and I think this will soon OOM
<mvo> ackk: I am using 2.7/edge maybe edge was not a good idea :)
<ackk> mvo, you might wanna snap stop maas
<zyga> master is fixed, right?
<ackk> o
<pedronis> zyga: I have seen green things
<ijohnson> zyga: snapd-failover should be good now with mvo's PR
<ackk> mvo, oh, yeah although I don't think there's much difference with stable
<zyga> superb news
<ijohnson> can't speak to other things
<zyga> thank you everyone who pushed towards fixing that bug :)
<mvo> ackk: http://paste.ubuntu.com/p/MkgJwgfhnf/
<mvo> zyga: yeah, master should be green
<mvo> zyga: thank ijohnson mostly
<zyga> Thank you ijohnson :)
<mup> PR snapd#8164 closed: snap: use the actual staging snap-id for snapd <Simple ð> <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8164>
<mvo> ackk: should I attach the log to the bugreport too?
<mvo> ackk: I wonder if maybe this is causing this heat/cpu issue
<ackk> mvo, if you could grab a tarball of the whole log/ dir it would be great
<ackk> mvo, I can take a look at that
<mborzecki> pedronis: cool, pushed the naming update to #8156, it'd be great if mvo, cmatsuoka or ijohnson could take a look
<mup> PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<ijohnson> mborzecki: I'll try to take a look today, it was on my queue of things to look at
<cmatsuoka> mborzecki: will check asap, will finish a debug run here first
<mvo> ackk: sure, I will do and attach to the bug(?). it looks huge though
<mborzecki> ijohnson: cmatsuoka: if there's anything super silly feel free to push a patch, i'll pick it up in the morning
<ackk> mvo, yeah if you don't want to attach it just put it somewhere and I can download it
<ijohnson> mborzecki: sounds good
<mvo> ackk: the gzip version of this dir is ~1.2Gb
<ackk> oh boy
<mvo> ackk: yeah, I will upload to some gdrive, not sure if LP will like it if I attach to the bugreport
<ackk> heh
<mup> PR snapd#8169 opened: [wip] tests/many: don't use StartLimitInterval, StartLimitBurst anymore <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8169>
<ackk> mvo, thanks, I think you're probably now hitting some bug
<ackk> mvo, how did you reproduce the issue btw? just installing in a bionic container?
<mvo> ackk: correct. it's outlined in the original bug. I did use a clean 19.10 eon VM with 8g ram
<mvo> ackk: then installed snapd and lxd
<mvo> ackk: then lxd init with btfs as backend
<ackk> mvo, weird, on this focal machine I don't even see snapfuse using CPU while maas init is running
<mvo> ackk: then created an "lxc launch images:ubuntu/18.04 container" and "lxc exec <image> bash" and installed maas in there and ran "maas init"
<mvo> ackk: that's pretty cool, at least it means this problem will go away :)
<zyga> mvo: snap-confine bug?
<mvo> ackk: but yeah, frustrating
<mvo> zyga: do you have more details?
<ackk> mvo, yeah I hope so. I'll try upgrading my laptop to focal, the installer was crashing on me before, have to try a more recent daily
<zyga> mvo: no, I'm asking what this is about but now I see this is the snapfuse perf bug
<mvo> zyga: aha, yes, that's correct
<mvo> zyga: trying to reproduce their issue but no luck and apparently hitting a different bug
<zyga> mvo: what did you hit?
<ackk> mvo, it might be related, because I also usually see supervisord-managed process restarting a lot, but never seen so many running supervsiorctl calls
<mvo> zyga: I don't know but it's some sort of (slow) fork bomb
<mvo> ackk: interessting!
<ackk> mvo, I thought the restarts would be beacuse of timeouts caused by processes being slowed down by snapfuse
<mvo> ackk: could be but my VM is pretty fast, it's an ssd and has enough ram and the cpu load is not that high. still a possiblity of course
<mvo> ackk: shared my dir with you, please let me know if you need anything else before I stop this vm again
<mup> PR snapd#8170 opened: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<ackk> mvo, can you try starting the maas snap again? just to confirm if it starts happening again
<ackk> mvo, (downloading logs as we speak)
<mup> PR snapd#8167 closed: o/standby: add SNAPD_STANDBY_WAIT to control standby in development <Created by pedronis> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8167>
<ijohnson> pstolowski: reviewed 8003
<pstolowski> ijohnson: thank you! if it's green then i'd like to land it and address your suggestions in a followup; if it fails then i'll push to this PR
<ijohnson> pstolowski: sounds good
<ijohnson> seems travis is clogged up with jobs :-/
<pedronis> we opened too many new PRs especially considering that master was red
<ijohnson|lunch> yeah but this actually happens pretty regularly in the afternoon my TZ, not sure why, but my thinking is that everyone in EU submits things before they log off
 * ijohnson -> dentist
<NickZ> check yo teef
<kenvandine> jdstrand: it looks like firefox isn't auto-connecting the pulseaudio plug anymore  https://twitter.com/thecalmsprings/status/1230542924489875457
<kenvandine> love getting bug reports via twitter :)
<jdstrand> kenvandine: that's weird. I grandfathered that
 * jdstrand fixes and investigates
<kenvandine> jdstrand: thanks
<mvo> ackk: sure, let me retry this
<mvo> ackk: seems to be happening again, I see proxy, ntp, syslog
<mvo> ackk: then proxy again, it's now at 15
<mvo> ackk: now at 46
<mup> PR snapd#8149 closed: snapmgr, backends: maybe restart & security backend options <Preseeding ð> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8149>
 * ijohnson -> back
<ijohnson> cachio: do you have a reliable way to reproduce that issue with snapd-failover you had the other morning, i.e. where in the logs snap-failure couldn't start snapd.socket because the socket file already exists? I have a fix for that I'd like to confirm if it works but I have never been able to reliably reproduce that error condition
<mup> PR snapd#8165 closed: cmd/snap-confine: fix everything flagged by coverity <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8165>
<zyga> this PR title is a lie, there are three left that weren't "new"
<zyga> oh well
<cachio> ijohnson, yes I have
<cachio> but I am leaving in 2 mins
<cachio> I ll be back in 2 hours
<cachio> or just telegram me
<ijohnson> cachio: no problem, it can wait til tomorrow
<ijohnson> I will mention you on the PR I open I think, so if you could comment there tomorrow that would be great
<cachio> ijohnson, sure
<cachio> when I am back I'll comment
<cachio> sorry but I was working with the new arch image
 * cachio afk
<ijohnson> cachio: no problem, ttyl
<cmatsuoka> debug tpm unlocking inside the initrd is painful
<ijohnson> sounds quite painful
<raer> Hope this works now: Hey snap people. A question regarding an issue (https://github.com/keepassxreboot/keepassxc-browser/issues/439) with the KeepassXC browser plugin (Firefox, Chromium) talking to KeepassXC through NativeMessaging. Afaik this won't work with snap-packaged apps, because of sandboxing / security.
<raer> Ah. That looks better...
<mup> PR snapd#8171 opened: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171>
<raer> What would be the "correct" solution to connect e.g. a browser plugin to an application ouside of the sandbox?
<ijohnson> raer: it depends, I suggest starting a post on forum.snapcraft.io where more folks will be available to look at your issue
<raer> I'm reluctant to open that box...
<ijohnson> raer: AFAIK it's a known problem and oSoMoN has a bug filed somewhere about this issue with the chromium snap specifically
<raer> https://bugs.launchpad.net/ubuntu/+source/chromium-browser/+bug/1741074 ?
<ijohnson> (and notable oSoMoN is offline right now)
<mup> Bug #1741074: [snap] chrome-gnome-shell extension fails to detect native host connector <snap> <chromium-browser (Ubuntu):Triaged> <https://launchpad.net/bugs/1741074>
<raer> dat :)
<ijohnson> it seems so
<ijohnson> I'm not familiar enough with the chromium snap to answer myself without more details about how plugins work with chromium and you're sure to find the right folks on the forum so that would be my recommendation
<ijohnson> you could also try asking in EU tz morning time
<raer> It is broken for 2 years now
<raer> A workaround is to install from repo, which is kind of ridiculous.
<raer> Might ask oSoMoN in the morning. Not keen on signing up for yet another forum...
<ijohnson> if you have a LP account I believe that the ubuntu forums at discourse.ubuntu.com are tied to your LP account so you don't have to create another account
<ijohnson> and oSoMoN is around there as well
<raer> ok. thanks.
<NickZ> ijohnson: did you ever get multipass working on the raspberry pi 4?
<ijohnson> NickZ: no I haven't tried for some time, but I think the required kvm options were added to the kernel now
<ijohnson> NickZ: IIRC there was some other problem with multipass not qemu/kvm related
<NickZ> yeah, I was lookinga t your issue
<NickZ> that issue seems resolved now, but im having another one
<NickZ> I was just wondering if anyone else had gotten this working
<ijohnson> what's the new issue ?
<Saviq> NickZ: do you know if Pi3 kernel also got those?
<NickZ> can't say, haven't tried, although I heard that hardware virtualization is only supported on arm64 hosts
<NickZ> ijohnson: https://github.com/canonical/multipass/issues/1376
<Saviq> NickZ: thanks, we'll have a look - it's weird that -machine would be required, maybe the default can be set somewhere
<ijohnson> hmm yeah I can't say I know anything about that but I bet Saviq can be of more help :-)
<NickZ> yeah, it seems unique for raspi hosts, dunno why
<mup> PR snapd#8157 closed: tests: using google storage when downloading ubuntu cloud images from gce <Simple ð> <Created by sergiocazzolato> <Merged by anonymouse64> <https://github.com/snapcore/snapd/pull/8157>
<mup> PR snapd#8172 opened: snapcraft.yaml: add python3-apt, tzdata as build-deps for the snapd snap <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8172>
<cmatsuoka> ijohnson: found the problem
<ijohnson> cmatsuoka: what was the problem?
<cachio> ijohnson, hey
<cachio> ijohnson, I'll run the test in a loop
<cachio> the fix is in the code? or in the tests?
<ijohnson> cachio the fix in the PR I mentioned was in the code for snap-failure
<ijohnson> At least what I think is a fix
<ijohnson> I don't entirely understand the root cause but this should at least let snap-failure get past the issue and still recover
<cachio> ijohnson, mmmm, in that case it is not so simple to test
<cachio> because I need to create an image with the fix
<cachio> is this PR still open?
<ijohnson> Yes one sec let me get you the link
<ijohnson> cachio: https://github.com/snapcore/snapd/pull/8171
<mup> PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171>
<cachio> ijohnson, I'll run it in google
<cachio> ijohnson, the other way I can reproduce it is difficul because I need an image
<ijohnson> Great, the tests all passed for that PR in Travis which is a good sign
<ijohnson> cachio it can certainly wait til tomorrow to
<ijohnson> *too
<cachio> ijohnson, yes, I'll test it tonight and add a note in the PR
<ijohnson> Awesome thanks
<cachio> yaw
#snappy 2020-02-21
<cachio> ijohnson, hey
<cachio> I left a comment in the PR
<cachio> the issue can be reproduced
 * cachio dinner
<mup> PR snapd#8150 closed: tests: ask tar to speak English <Simple ð> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8150>
<mup> PR snapcraft#2951 opened: snap-packaging: remove broken host-compatibility check for runner <Created by cjp256> <https://github.com/snapcore/snapcraft/pull/2951>
<mup> PR snapd#8173 opened: tests: adding arch-linux execution <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8173>
<mborzecki> morning
<mborzecki> hm https://community.spotify.com/t5/Desktop-Linux/Spotify-Snap-randomly-stopped-working/td-p/4901987
<mup> PR snapd#8172 closed: snapcraft.yaml: add python3-apt, tzdata as build-deps for the snapd snap <Created by anonymouse64> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8172>
<pedronis> mvo: hi, can you review or get a review for #8130 ?
<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>
<pedronis> mborzecki: #8136 needs a 2nd review from you
<mup> PR #8136: boot: write current_kernels in bootstate20, makebootable <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8136>
<mborzecki> pedronis: hi, will do
<mborzecki> mvo: morning, evdev sucks, golang-evdev and python-evdev are buggy ;)
<mborzecki> i'm not sure how libinput author didn'g go crazy
<mvo> pedronis: hey, good morning
<mvo> pedronis: sure, let me review this
<mvo> mborzecki: uh, oh no
<mvo> mborzecki: even for our (relatively) simple use-case it sucks?
<mborzecki> mvo: yeah, good to use different test systems, the laptop keybiard and VM input device behaves completely differntly than my other keyboard
<mvo> mborzecki: oh, woah
<mvo> mborzecki: I did test with vm and with my thinkpad keyboard and for the simple things I did it was ok but sad to hear that it's so annyoing
<mborzecki> mvo: some devices emit repeated keys, some do not, so we need to sync the initial state, then we have to actually look at key up/down rather than repeating event
<mborzecki> also, golang-evdev SetRepeatRate() is buggy and parameter meaning/order is swapped than what i see in the kernel code that interprets them ;)
<mborzecki> (same for python-evdev)
<mborzecki> nonetheless, SetRepeatRate() does nothing with my other keyboard, there's no repeat at all :P
<pedronis> mborzecki: does any of this correlate with reported capabilities or it's random?
<pedronis> I mean can we know from caps if it does repeat or not?
<mborzecki> pedronis: no, there's no capability that states that you get repeat events
<pedronis> ok
<mborzecki> oh, and libinput ignores kernel autorepat events
<mborzecki> like totally
<pedronis> yesterady I was reading something and it sounded like there are hardware auto-repeat, and some at higher levels
<mborzecki> https://gitlab.freedesktop.org/libinput/libinput/blob/master/src/evdev-fallback.c#L537 afaict they synthesize their own events
<pedronis> and they might even interfere
<mborzecki> e->value corrsponds to our KeyHold
<zyga> good morning
<mborzecki> pedronis: so i'm refactoring this to get the initial state of the keys as libinput does it, and then observe the up event and look at the time key is held
<mborzecki> zyga: hey
<zyga> are we low level input engineers now too? :)
<mborzecki> and, fwiw the golang-evdev does not include a wrapper to get the initial state of keys :P so had to pull out the ioctls and do it myself
<mvo> mborzecki: hm, if we only get up/down reliable that would make the UX really not nice
<mborzecki> mvo: right, thus it's check initial state, then observe down if it appears and see if it's down for <n> amount of time
<mborzecki> and the goroutine leaks, bc we have the same problem as with netlink socket
<mvo> mborzecki: aha, nice
<mvo> mborzecki: that makes sense
<zyga> mborzecki: do you want my fix for that?
<pedronis> mborzecki: which reminds me, can you review #8101
<mborzecki> zyga: it's not critical, it's a short lived process, but ultimately we'll need a fix, either yours or the Stopper thing
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<zyga> ack
<mborzecki> oh, and will have to step out for a bit late to some blood tests
<pstolowski> morning
 * zyga recalls he has to do blood tests as well but needs to get an appointment first
<zyga> hey pawel
<pedronis> mborzecki: what's the status of #8081 ?
<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>
<mborzecki> pedronis: it should be good to go
<mborzecki> let me merge master there
<pedronis> mborzecki: so it works in other distros but not ubuntu/debian ?
<mborzecki> pedronis: zsh? yes, there's a lp bug i linked there
<mborzecki> fwiw zsh has a sh compat mode for loading /etc/profile, it's used on fedora, arch and and probably suse too
<mborzecki> the downside is that there's no standard way to do drop-in files for zsh like /etc/profile.d, otherwise we could fix it easily
<pedronis> yes, that bug doesn't seem to be going anywhere
<mborzecki> and it's been there for a while now
<zyga> hmm
<zyga> mborzecki: I'm using zsh on my mac for a while
<zyga> is there really not standard way?
 * zyga looks at zsh in Ubuntu
<zyga> mborzecki: can you please review https://github.com/snapcore/snapd/pull/8171 -- the failover test is still causing some pain
<mup> PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171>
<mborzecki> zyga: added a note https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1640514/comments/30
<mup> Bug #1640514: /snap/bin is not added to the PATH when using zsh <patch> <Snappy:Fix Released> <snapd (Ubuntu):Confirmed> <zsh (Ubuntu):Invalid> <snapd (Ubuntu
<mup> Xenial):Confirmed> <zsh (Ubuntu Xenial):Invalid> <snapd (Ubuntu Bionic):Fix Released> <zsh (Ubuntu Bionic):Invalid> <https://launchpad.net/bugs/1640514>
<mborzecki> doubt this will help the bug move forward
<zyga> mmm
<zyga> yeah, I see
<zyga> man, everything is hard
 * mborzecki has 3 keyboards connected to his pc now
<pedronis> mvo: I reviewed #8142
<mup> PR #8142: client: add support for "ResumeToken", "HeaderPeek" to download <Created by mvo5> <https://github.com/snapcore/snapd/pull/8142>
<mup> PR snapd#8130 closed: overlord, state: don't abort changes if spawn time before StartOfOperationTime (2/2) <Preseeding ð> <Created by stolowski> <Merged by pedronis> <https://github.com/snapcore/snapd/pull/8130>
<mvo> pedronis: nice, thank you
<pstolowski> yay, thanks for reviews
<pstolowski> pedronis: would you like to take a quick look at https://github.com/snapcore/snapd/pull/8120 or can I land (has +2 already)
<pstolowski> ?
<mup> PR #8120: cmd/snap-preseed: snapd version check for the target <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8120>
<pedronis> pstolowski: I did skim it
<pedronis> pstolowski: related to reviews, can you finish reviewing #8101
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<pstolowski> pedronis: i made 2 or 3 comments there
<pedronis> pstolowski: I know, do you want to block it on them?
<zyga> I need to fetch something, back in 30
<pstolowski> pedronis: no, it's fine as a potential followup (if the comments make sense at all)
<pedronis> pstolowski: I expect the gc test to be a bit of a pain to write tbh
<pstolowski> pedronis: i've never played with this aspect in go... wouldn't runtime.GC() make it deterministic for the test?
<pedronis> pstolowski: possibly, somebody has to try
<pedronis> about the comment, I'm happy to mention the GC in a follow up, if there no more comments
<pedronis> I asked mborzecki to review #8101
<pedronis> as well
<mup> PR #8101: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<pedronis> pstolowski: is not just the GC, is also finalizers, I don't remember in which thread they are run
<pedronis> pstolowski: the docs have this to say:  The finalizer is scheduled to run at some arbitrary time after the program can no longer reach the object to which obj points.
<pstolowski> pedronis: i see, it's tricky, you probably looked at https://medium.com/a-journey-with-go/go-finalizers-786df8e17687
<pedronis> pstolowski: I meand, maybe it's trivial, maybe not
<pedronis> mvo: you have a weird code typo in 8142 now, also made a nitpick suggestion given it needs at least another commit
<mvo> pedronis: I just noticed and force pushed the typo thing, sorry for that
<pedronis> mvo: +1, it needs a 2nd review now, maybe pawel or zygmunt
<ackk> hi, is the snapd version which supports default tracks targeted to be in focal?
<mvo> pedronis: thank you
<mvo> ackk: yes, we plan to go with 2.44
<ackk> mvo, nice, thanks
 * zyga looks forward to end of winter holidays on Monday
<zyga> mvo: which branch is that?
<mvo> zyga: what branch?
<zyga> to review
<mup> PR snapd#8154 closed: tests: reset PS1 before possibly interactive dash <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8154>
<mvo> zyga: 8142
<ackk> mvo, is there an ETA for that? asking since we'd like to have the maas transitional package point to the default track
<zyga> hey ackk
<ackk> hi zyga
<zyga> I heard there is some progress on the issue you were long plagued by
<zyga> I hope we can get to the bottom if ot
<zyga> *of it
<ackk> zyga, the snapfuse one? well I can't reproduce it on another machine with 20.04, I hope I can reinstall my laptop soon w/20.04 and test there
<mvo> ackk: 4-5 weeks until it's in stable
<ackk> otoh mvo sort of managed to reproduce it
<ackk> mvo, will you also upload to focal? or will it just be in the snapd snap ?
<mvo> ackk: we plan to upload to focal
<ackk> mvo, awesome, thanks
<zyga> mvo: done
<mvo> zyga: thank you!
<mborzecki> hmm so, the input seems ot be working
<mvo> mborzecki: yay
<mup> PR snapd#8101 closed: netlink: fix/support stopping goroutines reading netlink raw sockets <Created by mvo5> <Merged by mvo5> <https://github.com/snapcore/snapd/pull/8101>
<mborzecki> mvo: heh, it's super ugly ;)
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8170#discussion_r382491439
<mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<pstolowski> zyga: ty
<mborzecki> damn, i'm late for the blood tests, got to go
<mborzecki> pushed the changes to #8156
<mup> PR #8156: cmd/snap-bootstrap: subcommand to detect UC chooser trigger <UC20> <â Blocked> <Created by bboozzoo> <https://github.com/snapcore/snapd/pull/8156>
<pedronis> pstolowski: I made a comment in 8170
<pedronis> zyga: whats the status of 8133 ?
<zyga> pedronis: I think it is non-essential but I want jamie to look at it first
<zyga> pedronis: after 7614 lands it is no longer needed
<zyga> pedronis: if it doesn't land it may be a factor for device assignment on arch
<zyga> pedronis: but I didn't debug deeper to know
<pedronis> what's the highest priority of these: https://github.com/snapcore/snapd/pulls?utf8=%E2%9C%93&q=is%3Aopen+is%3Apr+review-requested%3Ajdstrand+author%3Azyga
<zyga> pedronis: currently 8123 - jamie was looking at yesterday evening but said he will finish in the morning as priority request came in and he had to stop
<zyga> then 7614
<zyga> apart from that last one I'm no longer blocked
<zyga> I'm iterating on 7825 and it will be ready soon
<pedronis> I labeled the first and I'm tagging 7614 for 2.45
<zyga> thank you
<zyga> that's great
<zyga> https://www.irccloud.com/pastebin/eM7kmuRb/
<zyga> FAIL: overlord_test.go:694: overlordSuite.TestEnsureLoopPruneAbortsOld
<pedronis> ah fun
<pedronis> pstolowski: ^
<zyga> darn, my shell still sucks
<zyga> brb, need to get coffee
<zyga> pstolowski: the PR it failed on changes some C code, not related to any overlord bits
<zyga> brb
<pstolowski> pedronis,zyga : ah, overlordSuite.TestEnsureLoopPruneAbortsOld seems flaky, checking
<pedronis> pstolowski switching to take control over the ticker channel is probably the best way forward
<pedronis> if there's no easy fix
<pstolowski> pedronis: i can prep a quick PR to bump sleep to 1500 (currently 1000) to match all other overlord tests. then will work on proper change in a followup?
<pedronis> pstolowski: if that helps
<pedronis> pstolowski: I made another comment in 8170
<pedronis> unrelatedly
<pedronis> pstolowski: I made a nitpick comment in 8210, can be taken care in a follow up,  I think it can be merged otherwise
<zyga> back with coffee
<pstolowski> pedronis: great, thanks, will do a followup
<zyga> ok, let's fix that shell mistake
<zyga> and land another big branch :)
<mup> PR snapd#8174 opened: tests: bump sleep time of the new overlord tests <Simple ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8174>
<zyga> pstolowski: looking at preseed.sh
<zyga> pstolowski: umount_ubuntu_image can be simplified
<zyga> pstolowski: you can just umount -l "$IMAGE_MOUNTPOINT/sys"
<zyga> pstolowski: or better yet, use mount-tool to iterate over them
<zyga> pstolowski: just nitpick on the code
<zyga> the part about qemu-nbd is interesting
<zyga> I need to look at it closer later today if I can
<zyga> pstolowski: and in setup_preseeding, I would add head -n 1 to ensure that find only gives us one result
<pstolowski> zyga: nice, thanks, i can address this when later (and i didn't forget about the other issue you found in error path of service wrapers, on my list)
<pstolowski> s/when//
<zyga> pstolowski: sure, just looking at it because it said mount :)
<pstolowski> heh
<zyga> and I'm waiting for spread to prepare to see if my new shell expression is better
<mup> PR snapd#8153 closed: [RFC] "snap run --explain" with different formating <Skip spread> <Created by mvo5> <Closed by mvo5> <https://github.com/snapcore/snapd/pull/8153>
<zyga> mvo: hey, what's going on with explain there?
<zyga> mvo: I should be able to help soon
<zyga> mvo: this looks important https://bugs.launchpad.net/snapd/+bug/1864096
<mup> Bug #1864096: Incomplete search path(s) for xdelta3 executable <snapd:New> <https://launchpad.net/bugs/1864096>
<zyga> mvo: we may be hitting the store for more downloads than necessary
<zyga> pedronis: ^
<mvo> zyga: it's not clear to me how to push this forward or if the pr I just closed is even the right direction so I closed it to avoid wasting ppls time
<mvo> zyga: let me look
<zyga> mvo: can we chat about it (explain) later today
<zyga> mvo: just pull me into a call if you have a moment and feel like it
<mvo> zyga: ok
<mvo> zyga: do you look into this xdelta thing or should I ? should be a simple fix but yeah, agreed that it's annoying
<zyga> mvo: let me, I'm waiting for another cycle of spread
<zyga> yeah
<zyga> mvo: and something for 2.44
<zyga> to save on all the bits over all the fiber
<pedronis> mvo: zyga: there's little point discussion explain without me, I don't think mvo PR was too far off, but it's all in the details at this point
<zyga> pedronis: aha
<zyga> pedronis: is there something we can do to make it progress?
<pedronis> it's probably best to just sketch the api somewhere with usage examples
<pedronis> than modify the full PR
<zyga> k
<zyga> ok
<pedronis> my issue with the last iteration, is mostly how you had to use explain and start_section independently to into a section, even though conceptually is one thing
<mvo> zyga: if you want you have a look at my latest code, maybe you have creative ideas, anyway, we can have a quick brainstorm to sketch some api
<pedronis> s/to into/to intro/
<mvo> pedronis: right, yeah, that's a problem
<mvo> pedronis: there could be a _start_section(text) and "explain_indented()". but probaly needs a bit more time to sketch out something. anyway, having a brainstorm with zyga is probably a good idea and then we can get back to you
<pedronis> ok
<pedronis> mvo: also ideally there should be only one function to add a string entry and one for key: value. that probably needs some more state
<mvo> zyga: can we close 8113 now that it looks like we go with 8123 ?
 * zyga checks the numbers :)
<zyga> I don't remember branch names that well
<zyga> mvo: I think so but jamie said he will review both today morning
<zyga> mvo: let's wait one more morning please
<zyga> mvo: he was looking into it last night but something urgent pulled him
<mvo> pedronis: yeah, the in-list could be part of the state, we will explore that
<pedronis> mvo: the point of that it should be hard to add a non "-" prefixed entry in the middle of a list, etc
<mvo> pedronis: ok
<mvo> pedronis: https://github.com/snapcore/snapd/pull/7728/files#diff-e4c8d0c72c7b412376e0a04e6ad4db41R37 is an example where this is mixed
<mup> PR #7728: cmd: implement snap run --explain <Created by zyga> <https://github.com/snapcore/snapd/pull/7728>
<mvo> i.e. - Creating new per-snap mount namespace
<mvo>       desired mount profile: /var/lib/snapd/mount/snap.test-snapd-sh.fstab
<mvo> pedronis: but maybe the output should change
<zyga> but that's by design
<zyga> that was what the output was meant to look like
<pedronis> mvo: I don't understand in which sense it's mixed
<pedronis> there's a list that containts k: v sections
<pedronis> these thing need to next to some extent
<pedronis> s/next/nest/
<mvo> pedronis: the list-item has a different indent than the following line, that's what I mean
<pedronis> mvo: I'm probably being obtuse, I still don't understand
<mvo> pedronis: let me look at your suggestions with fresh eyes I'm probably just haven't thought it through yet
<pedronis> mvo: I can try to write down a strawman of api signatures, if that helps
<pedronis> mvo: https://paste.ubuntu.com/p/qRvD3thMdz/
<mup> PR snapd#8120 closed: cmd/snap-preseed: snapd version check for the target <Preseeding ð> <Created by stolowski> <Merged by stolowski> <https://github.com/snapcore/snapd/pull/8120>
<mvo> pedronis: thank you
<mborzecki> re
<zyga> hey maciek
<zyga> hmm
<zyga> errtracker tests are failing for me on 20.04
 * zyga looks
<zyga> https://twitter.com/ubuntu/status/1230795310756245505
<mborzecki> brace yourselves, bug reports are coming? :)
<zyga> brb,
<mborzecki> hmm random unit test failure in overlord ensure loop? https://paste.ubuntu.com/p/3sxTTChNzh/
<sdhd-sascha> hey :-)
<sdhd-sascha> Is there a way, to do something like that:
<sdhd-sascha> ```
<sdhd-sascha> $ sudo snap install --dangerous --classic <(wget -q -O- https://github.com/sd-hd/runner-snap/releases/download/v2.165.2-19/runner-snap-v2.165.2-19)
<sdhd-sascha> error: cannot open: "/dev/fd/63"
<sdhd-sascha> ```
<sdhd-sascha> The problem here seems to be `sudo`
<sdhd-sascha> With `root` it works.
<zyga> mborzecki: PaweÅ sent a PR for that failure
<mborzecki> ah, cool, my mind is still stuck with input and debuild/dpkg -i snapd & ubuntu-core-initramfs loop
<sdhd-sascha> I can't find a option for sudo, to preserve the file descriptors on fork :-(
<sdhd-sascha> Oh, i found it `sudo -C <num>` . Now i get `sudo: you are not permitted to use the -C option`
<sdhd-sascha> Thank you. I will figure it out now.
<pedronis> sdhd-sascha: either way, snap install takes only snap names or filenames, it doesn't install from stdin
<mborzecki> haha, so got the chooser trigger and service into initramfs and in my vm, the initramfs pivots earlier than the trigger is fired ;)
<sdhd-sascha> pedronis the `<( ... )` inside bash, creates a file descriptor
<sdhd-sascha> pedronis: so it's like a local file. But wget is non `sudo/root` but `snap install` is uid=0...
<sdhd-sascha> pedronis if often do this: `diff <(grep ....) <(grep ...)
<sdhd-sascha> pedronis: this is nice:
<sdhd-sascha> ```
<sdhd-sascha> $ ls -l <(echo "hello world")
<sdhd-sascha> lr-x------ 1 sascha sascha 64 Feb 21 13:34 /dev/fd/63 -> 'pipe:[22821730]'
<sdhd-sascha> ```
<zyga> hmm
<zyga> anyone here using 20.04
<zyga> or otherwise, can anyone run errtracker tests?
<zyga> they keep failing for me and I cannot see why
 * zyga digs into that
<zyga> bah, another spread wasted on prune failure
<sdhd-sascha> pedronis: i got it :-)
<sdhd-sascha> I added this line to /etc/sudoers: `Defaults        closefrom_override`
<sdhd-sascha> Then this works:
<sdhd-sascha> `sudo -C 99999 snap install --dangerous --classic <(wget -q -O- https://github.com/sd-hd/runner-snap/releases/download/v2.165.2-19/runner-snap-v2.165.2-19)`
<sdhd-sascha> Thank you :-)
<pstolowski> cachio: hi, have you enabled manual/preseed test in nightly?
<zyga> gaah
<zyga> I debugged it
<zyga> missing mocking
<mup> PR snapcraft#2948 closed: Regenerate the GDK pixbuf loaders cache file if for whatever reason it isn't there (LP: #1863801) <Created by oSoMoN> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2948>
<zyga> lp times out
<zyga> eh
<zyga> ok
<zyga> I'm parking this for now: https://bugs.launchpad.net/snapd/+bug/1864197
<mup> Bug #1864197: errtracker unit tests interact with real whoopsie.service <snapd:New> <https://launchpad.net/bugs/1864197>
<sdhd-sascha> Can i give snapcraft a default configuration for a snap? Or better use hooks for setting them ?
<sdhd-sascha> Wait. I ask on #snapcraft. Sorry
<zyga> sdhd-sascha: 1) no 2) it could
<sdhd-sascha> zyga: thank you :-)
<mup> PR snapd#8175 opened: store: rely on CommandFromSystem snap to find xdelta3 <Created by zyga> <https://github.com/snapcore/snapd/pull/8175>
<zyga> mvo: I opened https://github.com/snapcore/snapd/pull/8175 as draft, I have a small second patch that improves CommandFromSystemSnap but it's not essential
<mup> PR #8175: store: rely on CommandFromSystemSnap to find xdelta3 <Created by zyga> <https://github.com/snapcore/snapd/pull/8175>
<zyga> pstolowski: master is broken on TestEnsureLoopPruneAbortsOld
<zyga> pstolowski: what's the state of your PR, I see it is yellow
<pstolowski> zyga: PR is already up but fails on random stuff
<zyga> which stuff?
<pstolowski> zyga: timed out on prepare
<zyga> aha
<zyga> oh well :)
<pedronis> mvo: I did a pass on #8100, the main issue there is how we name things
<mup> PR #8100: httputil: add support for extra snapd certs <Created by mvo5> <https://github.com/snapcore/snapd/pull/8100>
<zyga> pstolowski: do you know why it got worse?
<zyga> I see it now even in travis-ran quick run of tests
<zyga> even before spread starts
<pstolowski> what do you see? the failure of TestEnsureLoopPruneAbortsOld?
<zyga> yes
<zyga> https://github.com/snapcore/snapd/pull/8175 look here https://travis-ci.org/snapcore/snapd/builds/653455121
<mup> PR #8175: store: rely on CommandFromSystemSnap to find xdelta3 <Created by zyga> <https://github.com/snapcore/snapd/pull/8175>
<pstolowski> zyga: i didn't get worse, it landed yesterday and we probably were lucky. I used 1000ms timeout instead of 1500 like every other test does in this testsuite
<zyga> mmmm
<zyga> I see
<zyga> ok
<zyga> let's fix that with spread pass-through maybe
<zyga> it's super annoying when master breaks and we restart everything like a stuck computer
<pstolowski> zyga: ok, added the label although i wonder what happens after it already is in progress. perhaps it needs to pass anyway ;). it would only help on opening the pr?
<zyga> dunno
<zyga> we'll find out
<zyga> thank you! :)
<sdhd-sascha> Should `snapctl get <key>` return an error, if the key does not exist ? Maybe as additional param ?
<sdhd-sascha> `parts/snapd/src/overlord/hookstate/ctlcmd/get.go`
<sdhd-sascha> Then i could use on bash this: `user=$(snapctl get --errror-on-missing || echo "root")`
<sdhd-sascha> i mean: `user=$(snapctl get --errror-on-missing userkey || echo "root")`
<zyga> pstolowski: it is in
<pstolowski> zyga: great; did it pass?
<zyga> it got green
<mup> PR snapd#8174 closed: tests: bump sleep time of the new overlord tests <Simple ð> <Skip spread> <â  Critical> <Created by stolowski> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8174>
<zyga> but I didn't look
<zyga> I just want it in, we can iterate more now
<zyga> pstolowski: it did pass
<zyga> pstolowski: it ran a full iteration of tests
<pstolowski> good
<pedronis> mborzecki: #6708 seems to have a real failure atm
<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>
<pedronis> ijohnson: what's the status with #8152, will push more to it? should we close it until it's more ready?
<mup> PR #8152: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8152>
<ijohnson> pedronis: it's fine to close it I need to push more changes to it, but it will likely look different
<pedronis> ijohnson: then better to close it, there is still quite a chain behind it anyway
<pedronis> afaiu
<ijohnson> yes, also I'll close 8151 too
<mup> PR snapd#8151 closed: cmd/snap-bootstrap/initramfs-mounts: only write modeenv if it changed <Simple ð> <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8151>
<ijohnson> pedronis: are you going to close it or should I?
<jdstrand> zyga, pedronis: fyi, finish PR 8123
<mup> PR #8123: interfaces/network-control: bring /var/lib/dhcp from host (approach b) <Bug> <Security-High> <Created by zyga> <https://github.com/snapcore/snapd/pull/8123>
<zyga> jdstrand: ack
<zyga> jdstrand: can we close the (a) variant now?
<jdstrand> (I did PR 8113 yesterday)
<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>
<jdstrand> zyga: I think you need to read my PR review :)
<zyga> ok
<zyga> jdstrand: this PR will create /var/lib/dhcp on the host when it exists
<zyga> did you mean to say
<zyga> when it not exists?
<zyga> or do I parse that wrong?
<jdstrand> zyga: typo, reload
<zyga> ok
<jdstrand> so, my opinion on closing 8113 is that it is up to you. 8123 can be made ok, but perhaps it should come later
<zyga> I see, I have no strong preference to either - I did (b) based on a comment on (a) -
<jdstrand> zyga: the future is definitely b
<pedronis> on that agree
<pedronis> we really want to move to the style of b
<zyga> I only have one thing that I feel stronger about - if the interface promises write access to $foo and $foo is a read only empty place-holder in the core snap we have a problem - it needs to be resolved somehow
<jdstrand> zyga: but up to your team's priorities on how to tackle it
<pedronis> because things in snap-confine don't scale
<zyga> I think in this case making the directory is the actual correct thing to do, even if that's perhaps a new thing snapd does
 * ijohnson goes to close #8152
<mup> PR #8152: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8152>
<zyga> as for the rest, I'll read the feedback carefully
<zyga> I'll discuss with pedronis and mvo as to what to do for 2.44
<zyga> and beyond
<jdstrand> zyga: that bit about auto ns rules is just me thinking out loud
<jdstrand> I feel pretty strongly that we shouldn't leak the dir creation to hostfs
<zyga> jdstrand: but that's the actual intent, to interact with the host - that's how I understand the interface
<zyga> otherwise access to /var/lib/dhcp is meaningless because there is nothing there
<jdstrand> zyga: but the act is hollow. there is nothing on the host looking at /var/lib/dhcp
<mup> PR snapd#8152 closed: managers_test: add uc20 kernel snap update happy and panic tests <Test Robustness> <UC20> <Created by anonymouse64> <Closed by anonymouse64> <https://github.com/snapcore/snapd/pull/8152>
<zyga> jdstrand: the question is time, yet, perhaps the snap will put files there and users will follow docs to go and find them
<pedronis> jdstrand: notice though that the directory could be created in the host later than connection time
<zyga> jdstrand: perhaps later on classic app goes to loop
<zyga> jdstrand: it's not such clear cut IMO
<jdstrand> zyga: the snap can put anything it wants there. the *host* is not looking at them
<jdstrand> zyga: we aren't trying to create an alternate storage location, we're trying to let the snap interact with the host via things in this dir
<zyga> jdstrand: perhaps a monitoring solution does, you can install dhcpd from a snap and tie it to something else; I think it's not out of the question that is a possible use case
<jdstrand> zyga: a dhcpd snap is going to use content then
<pedronis> well the interface gives rw access under there
<zyga> I think we need to consider three options: 1) change the interface so that this is not a problem 2) do not create the directory 3) create the directory
<zyga> and pick something sensible out of that set
<pedronis> jdstrand: to be clear not creating it is fine, but what if it gets created in the host after the interface was connected?
<jdstrand> I don't know how else to say it. the apparmor rules are there because at one time they meant something. on a system without /var/lib/dhcp, they don't mean anything
<zyga> pedronis: interface connection creates it on the host
<zyga> pedronis: it's really visible in /var/lib/dhcp that's the logic of (b) now
<pedronis> zyga: yes, but jdstrand doesn't want that behavior
<zyga> ah
<pedronis> but what behavior does he want
<zyga> sorry, I misunderstood your question
<pedronis> in that case
<jdstrand> eg, on a system with no /var/lib/dhcp, the snap starts, the dir is created, it puts a lease file in there. *nothing* on the host will do anything with *anything* the snap puts in there
<jdstrand> it is a hollow act
<zyga> jdstrand: sure but maybe that's good enough
<zyga> jdstrand: because users are trained to look there
<jdstrand> if the dir exists, the monitor might be looking for things in there that will *never* come
<zyga> (e.g. admins)
<jdstrand> huh?
<zyga> jdstrand: I can install core system
<zyga> jdstrand: install a dhcp solution there
<zyga> jdstrand: and get it to operate my network
<zyga> jdstrand: I can go to /var/lib/dhcp
<zyga> and even though it wasn't there before, I see files the snap has put there
<jdstrand> zyga: that is a totally different thing
<zyga> logs, leases, etc
<zyga> jdstrand: (on second though that system could be either core or classic)
<jdstrand> zyga: this is about implied plugs, you are talking about a slot
<mvo> zyga: in a meeting right now, will try to read backlog
<zyga> jdstrand: I think I'm talking about neither - just the user experience of installing a snap and seeing lease files in a familiar location
<zyga> jdstrand: but perhaps I don't understand your point of view
<zyga> jdstrand: because I think I'm saying the same thing now
<jdstrand> zyga: the user experience is already different on a system without a dhcpd solution. there is no /var/lib/dhcpd
<jdstrand> zyga: that is the implied case, which is all network-control implements
<jdstrand> zyga: a slot implementation for dhcpd would either need a new interface or network-control adjusted accordingly to be either implied or slot provided
<zyga> jdstrand: I think the question is, if you have no /var/lib/$foo and a snap managing it is installed, should it see a private copy of $foo and the host is not altered or not
<zyga> jdstrand: isn't dhcpd just a network socket? you can probably implement one with network-bind already
<zyga> jdstrand: I can see a point where /var/lib/$foo is really stored in $SNAP_DATA
<zyga> (and layouts can be used to make the per-snap view more familiar)
<zyga> but I can also counter that to say that we give snaps host access for a reason (there are specific interfaces and implicit mounts performed by snap confine)
<zyga> I really think it's not a correctness POV just a policy of what we want to do
<zyga> either way is fine if we are consistent and it is documented well
<pedronis> jdstrand: anyway, you haven't answered what is your expectation, if the directory gets created host side after a snap is connected. should we just ignore this, should we monitor creation and try to patch the rules and namespace after the fact?
<jdstrand> jdstrand: ime, it doesn't make sense for an *implied* plugs interface to create a dir. the implied interface is about interacting with core or classic. by definition, if /var/lib/dhcp doesn't exist on core/classic, there can be no interaction with core/classic via /var/lib/dhcp
<zyga> jdstrand: for the record, it does exist on core but some classic distributions do not have it in the images we use
<jdstrand> pedronis: I put in the PR a suggestion. I think we need the equivalent behavior of .is_optional. ie, at runtime, snap-update-ns sees if it exists, if it does, cool, do what is in the PR now. if not, move along
<jdstrand> zyga: that's fine. it is probably a bug on core if it ships the directory but isn't using it, but that is a different issue
<zyga> jdstrand: we can do that, though creation on the host is not monitored by anything so it would not be "plugged" into the app at a later stage until some other mount operation did it by coincidence
<zyga> jdstrand: it works on core16 + core16 because of implicit sharing
<zyga> jdstrand: it is broken on core18 because then sharing is not automatic (hence (a) was quickly made)
<zyga> that's just for context, it's not changing what you said
<jdstrand> zyga: snap-update-ns may need to be updated then, sure. this is getting at why I thought 8113 first would at least fix the bug. we already have thought about this by introducing .is_optional btw. with 8123, we just need to think through what the right implementation would be for when to perform the mount
<zyga> jdstrand: I understand, I think for that we'd need a component to monitor directories and react (snapd, inotify, etc) but it's somewhat fragile and racy by its very nature (100% uptime of said component)
<zyga> but we could come up with something
<jdstrand> zyga: basically, my suggestion is that the PR is as it is now, but with snap-update-ns being modified to know when to check for dir existence and skip the creation if it doesn't
<zyga> I wonder what the snap should see before that directory exists on the host
<zyga> an empty directory from the base?
<jdstrand> zyga: I didn't see it as that complicated, but maybe I am being naive
<zyga> jdstrand: I understane
<zyga> *d
<jdstrand> zyga: eg, snap-update-ns on first run/after discard does the check and skips if not there
<jdstrand> zyga: that would by 'enough' for me to approve the PR. trying to handle avoiding a snap-discard-ns after someone installs dhcpd via deb/rpm could be a later step. of, snap-update-ns notices that it now exists but there is a mount namesapce, so it dtrt
<pedronis> zyga: I don't think we need to monitor directories until somebody really needs it
<jdstrand> s/of,/or,/
<pedronis> dchp is not such a case
<zyga> mhm
<jdstrand> pedronis: ?
<pedronis> I was answering to: zyga> jdstrand: I understand, I think for that we'd need a component to monitor directories and react (snapd, inotify, etc) but it's somewhat fragile and racy by its very nature (100% uptime of said component)
<jdstrand> I don't think we need a monitor
<zyga> note that technically handling it like .is_optional is not hard, if that's the semantics we are after I can make the changes easily
<zyga> if that's the agreement I will get to work
<jdstrand> I mean maybe we could, it is not that different from connecting a content interface I guess, but it doesn't seem unreasonable to restart the snap if dhcpd is installed after the fact. that is up to you. we don't really doing anything that I am aware of with already running snaps when things change in other things exposed via implied interfaces
<pedronis> I think it works for now, there may be use cases where it doesn't make sense, but shouldn't stop to progress a bit
<jdstrand> (and by restart the snap, I am saying that is user-driven, not snapd)
<pedronis> I mean that doing what is_optional does
<zyga> ack
<zyga> sure, I'll make that happen
<pedronis> how close is a) to land?
<zyga> a) could land now I guess
<zyga> I can undo a) in an iteration of b)
<zyga> let me double check
<pedronis> jdstrand: I don't see a review by you in a) ?
<pedronis> zyga: jdstrand: anyway I would be fine landing a) in 2.44 and trying to aim for b) in 2.45
<jdstrand> pedronis: I will approve now. I didn't yesterday (I left a comment) because I didn't want a second approval to accidentally imply 'merge me now'
<zyga> ok
<pedronis> assuming a) gets 2 +1
<zyga> that's fine with me, we fix the bug for 2.44 and make it nicer as we move on, most of the code in (b) is good, there's a small improvement on how some bits are computed that Jamie suggested and a few tweaks to implement is_optional semantics
<zyga> and a revert of a)
<zyga> and we should be able to have it next week
<zyga> are we in agreement?
<jdstrand> 8113 is approved
<jdstrand> zyga: note, those auto-rules aren't a requirement. it just feels like a missed opportunity, but maybe with more thought, we can't (or we can only do some safely)
 * jdstrand is fine with whatever you decide in terms of priorities
<zyga> I suspect we can. Your comment there was spot on. It will be hard to understand in a short while otherwise
<pedronis> anyway that comment is why I think it feels like 2.45 material
<jdstrand> that was my feeling as well, but again, I defer
<pedronis> it would be good to make doing such things reasonable
<pedronis>  /readable
<zyga> Yes I think thatâs a worthy goal :-)
<zyga> Ok I think we are in agreement now
<zyga> I take your silence as a yes
<jdstrand> while we are in agreement, I will also mention since you said this is actually a cross-distro thing, that if snapd created /var/lib/dhcp, a fedora/arch/whoever user would probably file a bug asking why snapd is littering the filesystem
<jdstrand> (I can almost read the report in my head ;)
<jdstrand> so it is good to avoid that bug as well :)
<pedronis> I moved b to 2.45
<zyga> jdstrand: Iâm not sure. Itâs just the package selection we have. Installing some other bit in those systems would create that directory
<jdstrand> zyga: right, but if they *don't* install it but snapd is just putting it there, I can easily see someone complaining
<zyga> Yeah, but only when connecting to something that might use it
<zyga> Not just out of the box
<jdstrand> regardless, we are in agreement for other reasons so my thoughts on avoided potential bugs doesn't really mean anything :)
<zyga> Yes!
<zyga> Iâll get to it after current branches move
 * jdstrand has a *lot* of experience with rather, shall we say, opinionated users in dealing with triaging random bugs flagged as security in Ubuntu ;)
<jdstrand> perhaps I'm jaded... :)
 * cachio lunch
<jdstrand> anyway, cool
<jdstrand> again, sorry it took awhile to get to these. while 8113 and 8123 weren't terribly time consuming, they were behind 7825 and I needed a big hunk of time for that one that was really hard to find
<jdstrand> 7980 needed a fair chunk as well
<jdstrand> anyhoo, past all those. unfortunately, there are other big ones in my list...
<jdstrand> but hey, it is all before 2.44 so... :)
<jdstrand> (not to mention 8165 that floated in. coverity is really awesome, but investigating its findings takes time)
<zyga> Oh, about that the Coverity is confusing and there are 3 things from the scan in 2017
<zyga> Iâll fix them next week
<zyga> They are shown in a different list
<zyga> back from dinner
<mup> PR snapd#8113 closed: cmd/snap-confine: bring /var/lib/dhcp from host, if present (approach a) <Bug> <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8113>
<mup> PR snapd#8175 closed: store: rely on CommandFromSystemSnap to find xdelta3 <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/8175>
<zyga> jdstrand: one more thing, do you think you can quickly look at https://github.com/snapcore/snapd/pull/8133 and tell me if that's something we should even do - it pops up on arch with apparmor when using device assignment
<mup> PR #8133: cmd/snap-confine: allow snap-confine to load nss libs <â Blocked> <Created by zyga> <https://github.com/snapcore/snapd/pull/8133>
<zyga> jdstrand: the diff is just 5 lines of snap-confine profile
<jdstrand> yeah, I planned to
<zyga> I'm somewhat meh, probably not worth it but I don't have arch and didn't see it myself
<zyga> and it will go away with the changes in snap-confine anyway
<zyga> thanks!
 * zyga is down to 11
<jdstrand> zyga: I have an opinion and context for it
 * jdstrand is responding
<zyga> thanks!
<zyga> https://github.com/snapcore/snapd/pull/8171 needs a 2nd review
<mup> PR #8171: cmd/snap-failure/snapd: also rm snapd.socket if it still exists <Simple ð> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8171>
<zyga> cachio: can you rebase https://github.com/snapcore/snapd/pull/8173
<mup> PR #8173: tests: adding arch-linux execution <Simple ð> <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8173>
<zyga> pedronis: I summarized the discussion on https://github.com/snapcore/snapd/pull/8123#issuecomment-589719128
<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>
<mborzecki> mvo: pedronis: slightly meh, but i added Before=console-conf@tty1 and changes the service to Type=oneshot, consoleconf now waits for trigger to exit, so we don't have to stop it explicitly, the downside its that console-conf start is delayed by the amount of time we wait for the trigger
<mup> PR snapcraft#2951 closed: snap-packaging: remove broken host-compatibility check for runner <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2951>
<mvo> mborzecki: I think that's not too bad, how long do we wait?
<pedronis> mborzecki: yea, we'll need to rethink this but for now at least is correct
<mborzecki> mvo: i can set the deafult timeout to say 10s, and the key must be held for 2s to trigger the event, upon which it exits right away, so if you hold the key the delay isn't as problematic
<jdstrand> zyga: done
<zyga> I read
<zyga> thanks
<zyga> that's my understanding as well
<zyga> I'll flip it around and merge with your implicit approval, is that okay?
<jdstrand> zyga: well, I requested changes. just ping me and I'll scan/approve
<jdstrand> it is still morning here so I'm not going anywhere for a while :)
<zyga> jdstrand: ack
<zyga> I'll just do it now
<zyga> jdstrand: done
<jdstrand> zyga: well, sorry, but I'd prefer them at the every end with the other explicit denials. having it here clutters that section
<zyga> jdstrand: sure
<jdstrand> thanks!
 * jdstrand is poised to approve
<zyga> done
<ijohnson> cachio: let me know if you want me to remove the changes adding snap-auto-import-asserts-spools, snap-auto-import-asserts and snap-auto-mount tests for ARM devices, I'm happy to enable those later and land #8140 sooner, I'm adding your requested changes now
<mup> PR #8140: tests: enable more tests for UC20/UC18 <Test Robustness> <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8140>
 * zyga high-fives jdstrand for fast review cycles :)
<ijohnson> cachio: I made the other changes except for the uc20 arm model names, do we know what those model names will look like? will it be the same as the uc18 ones just with s/18/20/ ?
<mup> PR snapcraft#2950 closed: meta: Snap to_dict() cleanup <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2950>
 * zyga breaks for a moment to let the laptop charge and back up
<jdstrand> zyga: done
<jdstrand>  5
<jdstrand> o/
<zyga> :-)
<cachio> ijohnson, nice
<cachio> yes, I prefer to enable those tests later for arm
<ijohnson> cachio: ack
<ijohnson> Did you see my questing about the name of the arm model
<cachio> ijohnson, no yet, I am with amazon linux, I'll see that in 5 minutes
<ijohnson> Sure no rush
<zyga> pstolowski: https://github.com/snapcore/snapd/pull/8170/files#diff-eb9825aa18d9bbbcc41ca31728af8157R88 still needs work, right?
<mup> PR #8170: snap-preseed: support for preseeding of snapd and core18 <Preseeding ð> <Created by stolowski> <https://github.com/snapcore/snapd/pull/8170>
<zyga> I am on child care service now
<zyga> fingers crossed she doesn't wake up for a few hours
<zyga> $wife and $kids went for groceries now
<pstolowski> zyga: yes, it needs work
<zyga> ok
<zyga> pedronis: does this ring a bell?
<zyga>  Feb 20 20:41:39 jbl-ThinkPad-P53 snapd[1101]: stateengine.go:150: state ensure error: devicemgr: cannot resolve prerequisite assertion: account (EH9A6Xg1QtCjYt4v3QlBVTPLAHDvEIn6)
<cachio> ijohnson, answered
<pedronis> zyga: what's the context
<ijohnson> thanks cachio
<cachio> but no idea
<zyga> pedronis: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864113
<mup> Bug #1864113: snapd.seeded.service never starts <amd64> <apport-bug> <focal> <rls-ff-incoming> <snapd (Ubuntu):Confirmed> <https://launchpad.net/bugs/1864113>
<zyga> pedronis: seeded never completes
<pedronis> somebody didn't build the seed properly
<zyga> this is focal server ISO
<zyga> perhaps we need to ping foundations?
<pedronis> yes
<zyga> should I reach out to steve?
<pedronis> I don't know, it's not snapd bug though
<pedronis> it's an image bug
<mborzecki> idk if it's related but built core20 and the install got stuck and never completed
<cachio> ijohnson, perhaps we could just skip the test on uc20 until we have the names
<ijohnson> cachio: I think I'll just have the test be skipped on uc20 arm
<ijohnson> pedronis: zyga: sounds like the issue that was just reported in #snappy-internal a while ago
<zyga> aha, thank you, I'll check
<cachio> ijohnson, makes sense, thanks
<mborzecki> wondering whether we should limit the chooser only to specific ttys eg. tty1 & ttyS0
<pedronis> mborzecki: that's what I asked
<pedronis> it should be at least an option at some point
<mborzecki> ok, so i've got the patches for subiquity, ubuntu-core-initramfs, core20 and snapd now
<mborzecki> there's one weird sceanrio when i'm trying to invoke the chooser when the system boots right after install, for some reason the chooser-trigger service does not start consistenty
<mborzecki> but it's just fine on subsequent boots
<mborzecki> nvm, more on monday probably
<mup> PR snapd#7980 closed: packaging,snap-confine: stop being setgid root <Created by zyga> <Merged by zyga> <https://github.com/snapcore/snapd/pull/7980>
<zyga> that's in, woot
<ijohnson> nice zyga so that's the last of the opensuse requested changes ?
<zyga> ijohnson: close
<zyga> ijohnson: there are a few more, I need to revisit
<zyga> we need to fix SNAP_COOKIE
<zyga> ijohnson: they also asked for a group to control snap-confine executability
<ijohnson> zyga: ah right I remember this now too
<zyga> so that it's group executable only
<zyga> I think that's a low hanging fruit
<zyga> jdstrand: ^ right? snap-confine being root:snapd-users and only g+x
<zyga> ijohnson: I may apply that last bit in a suse specific patch though
<zyga> and there's the issue of +s snap-confine in core
<jdstrand> otoh, I do seem to remember that
<mup> PR snapd#8176 opened: tests: adding amazon linux to google backend <Created by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8176>
<jdstrand> 4750 root:something
<zyga> I need to look if I can mount core without setuid root
<zyga> jdstrand: mhm
<pedronis> zyga: I fixed SNAP_COOKIE
<zyga> pedronis: oh, cool, I didn't know that
<pedronis> I think
<zyga> I'll go through their review next week and update the bug on monday
<zyga> but I think this is a hell lot closer now :)
<jdstrand> zyga: we probably need some niceties in snap run to fail gracefully in that environment for people not in the group
<zyga> jdstrand: indeed
<jdstrand> zyga: or at least, double check it :)
<zyga> jdstrand: but fortunately that's in snap-run so not security critical and can be easily made to be nice
<pedronis> zyga: jdstrand: https://github.com/snapcore/snapd/blob/master/overlord/snapstate/cookies.go#L152
<zyga> that's great!
<zyga> Thanks for the reference, I'll use it in the review of their review
<pedronis> and https://github.com/snapcore/snapd/blob/master/randutil/crypto.go
<jdstrand> zyga: yep
 * cachio afk - doc appointment
<mup> PR snapcraft#2932 closed: elf: resolve paths in `ldd()` to purge relative path components <Created by cjp256> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2932>
<mup> PR snapd#8177 opened: cmd/snap-bootstrap/initramfs-mounts: mount the snapd snap in run-mode too <UC20> <Created by anonymouse64> <https://github.com/snapcore/snapd/pull/8177>
<mup> PR core20#22 opened: run-snapd-from-snap: don't try to load a snapd snap from the seed anymore <Created by anonymouse64> <https://github.com/snapcore/core20/pull/22>
<sdeziel> hello, I'm trying to export a custom variable for a snap but can't find how/where to do that
<ijohnson> sdeziel: you mean in a snap you are developing?
<sdeziel> ijohnson: no, sorry I was not clear. I want to export it in a snap I *use* (chromium to be precise)
<ijohnson> can you just do `VAR=thing chromium` ?
<ijohnson> err is there a reason you can't just do that ?
<sdeziel> ideally, it would work when I click the chromium's icon
<sdeziel> ijohnson: I was thinking of something like /etc/environments in the snap's FS
<ijohnson> AFAIK, /etc/environment should work for snaps too
<sdeziel> right but that's system-wide, not snap specific
<ijohnson> Hmm, I don't think we have something like that that's per-snap and per-installation. Since you want it when you click an icon, you might be able to fiddle with the desktop file
<sdeziel> ijohnson: isn't the desktop file recreated on every snap refresh?
<ijohnson> hmm perhaps they are. I'm not super familiar with how desktop files work, perhaps you could ask someone in #ubuntu-desktop ?
<sdeziel> ijohnson: "MESA_GLSL_CACHE_DISABLE=true chromium" didn't run which I would be inclined to think is normal assuming there is some env scrubbing going on
<sdeziel> s/didn't run/didn't work/
<ijohnson> hmm that's odd
<ijohnson> that works for me:
<ijohnson> https://www.irccloud.com/pastebin/v4uNy7Ru/
<ijohnson> and if I try that with the chromium snap it works too, at least with --shell.
<ijohnson> it's possible that the chromium snap specifically is doing some sort of env scrubbing
<sdeziel> ijohnson: my bad, I had another chromium instance running which prevented the flag to be picked
<sdeziel> it does work to use that var=$val prefix
<sdeziel> ijohnson: thanks for your help btw
<ijohnson> np happy to help, good luck with the desktop icon thing
<sdeziel> ijohnson: I do have a workaround but I still believe it's not a special edge case to want to export vars per-snap. Any idea where I could make that wishlist request?
<ijohnson> you could file a bug at bugs.launchpad.net/snapd or you could make a forum post at forum.snapcraft.io about it
<sdeziel> thx
<sdeziel> to close the loop: https://bugs.launchpad.net/ubuntu/+source/snapd/+bug/1864240
<mup> Bug #1864240: [wishlist] allow setting per-snap environment variables <snapd (Ubuntu):New> <https://launchpad.net/bugs/1864240>
<sdeziel> thanks again ijohnson, have a nice weekend!
<NickZ> pedronis: what's up with this? Are we getting this in the near future? https://github.com/snapcore/snapd/pull/7490
<mup> PR #7490: interfaces/app-launch: support confined snaps launching other snaps <Needs Samuele review> <Created by AlanGriffiths> <Closed by pedronis> <https://github.com/snapcore/snapd/pull/7490>
<mup> PR snapcraft#2940 closed: build providers: remove use of cloud-init <Created by sergiusens> <Merged by sergiusens> <https://github.com/snapcore/snapcraft/pull/2940>
<NickZ> I'm having issues with my snaps; It seems that it's not actually registering my apps with their associated file types, even though I have specified the Mime types in the desktop file. Has anyone else gotten this working?
<zyga> jdstrand: store rejects new snap-confine mode
<zyga> Just FYI
<jdstrand> ah, yes, it would
 * jdstrand adjusts tools 
<jdstrand> zyga: where are you seeing this? core? core18? core20? snapd? all of the above?
<zyga> I got a mail https://launchpad.net/~snappy-dev/+snap/snapd-master/+build/843779
<zyga> But probably snapd and core need rule updates
<ijohnson> jdstrand: I assume that this will be for just snapd and core snaps, core18 and core20 don't ship snap-confine
<zyga> Core18 and core20 are devoid of snapd
<jdstrand> ijohnson: ah, yes. thanks
<zyga> Thank you Jamie. I didnât think about this beforehand
 * cachio afk
<kinghat> snaps take a while to start up but subsequent launches of the same app are "snappy". does that mean they are held in memory or how does that work?
<roadmr> kinghat: which snap?
<zyga> kinghat: snap install snapd-hacker-toolbelt
<zyga> kinghat: time snapd-hacker-toolbelt.busybox true
<zyga> kinghat: time snapd-hacker-toolbelt.busybox true
<zyga> kinghat: I can answer your questions later if you stay on IRC (or hop back tomorrow)
<zyga> as it's 11PM here
<kinghat> roadmr: most all of them. though i just started htop and it was "snappy". postman wasnt.
<roadmr> ð
<roadmr> kinghat: well htop is a CLI application while postman is graphical (IIRC) and there were some issues with e.g. font caches needing regeneration for graphical snaps. So the slow first startup time is due to e.g. fonts being rebuilt, and subsequent runs are faster because fonts are built :) snaps are not cached in memory, at least not beyond possibly OS-managed disk caching
<kinghat> chromium too. most of my snaps take time to load initially then are fine after until im in a new session.
<roadmr> kinghat: note I say "were", as I thought it had been fixed
<roadmr> https://forum.snapcraft.io/t/improving-first-run-performance-of-desktop-app-snaps/2944
#snappy 2020-02-22
<mup> PR snapd#8137 closed: tests: skipping interfaces-openvswitch on centos due to package is not available <Simple ð> <Created by sergiocazzolato> <Merged by sergiocazzolato> <https://github.com/snapcore/snapd/pull/8137>
<sdhd-sascha> hey ;-)
 * sdhd-sascha i see it's diffcult these days. But i didn't see next month...
 * sdhd-sascha hey - i'm already on 2020 .... it works for me... only small things
 * sdhd-sascha i mean: i see next month coming... sorry ... for the mispelling
 * sdhd-sascha and sorry, if i ask something stupid things... nobody can know everything ! ... sorry  ;-) i'm comfortable with no answer
<sdhd-sascha> hey, is it diffurcult to use magnetic waves ? i think it's from time to time easier...
<sdhd-sascha> zyga: i think you would say, if i'm was annoying..
<sdhd-sascha> ijohnson: how about you? didn't search what you have done. But my feeling say, that you are very productive - maybe from reading!
<sdhd-sascha> zyga: don't know. but i know (i wouldnt't like to be hurt you ;-)) (never want to hit someonwe ;-))
<sdhd-sascha> hmm - sorry - maybe i'm jusr crazy ;-)
<sdhd-sascha> zyga: my prob... have a nice sleep ;=)
<pcbBob> Anyone knows what to do if I receive this message if I try to start Spotify via command line? `ln: failed to create symbolic link '/home/test/snap/spotify/41/.config/gtk-2.0/gtkfilechooser.ini': File exists?` `Gtk-Message: 19:57:38.152: Failed to load module "canberra-gtk-module"`
<mcphail> pcbBob: Does spotify launch? If so, ignore them
<pcbBob> No, it doesn't launch
<pcbBob> mcphail
<mcphail> let me install and see if it does the same here...
<pcbBob> I also get `Trace/breakpoint trap (core dumped)`
<pcbBob> It worked fine for the last months but since I installed `PlayOnLinux` today, I get this error
<NickZ> pcbBob: try `sudo snap remove --purge spotify` and reinstall, and see what happens?
<mcphail> pcbBob: I can't reproduce that here. There's a few moving parts to this problem so it might be worthwhile posting on forum.snapcraft.io . I wonder if there's some bug in the way the snap tries to inherit the gtk theme from the system?
<NickZ> pcbBob: incidentally, I'd recommend Lutris over spotify :P
<NickZ> er, PlayOnLinux
<pcbBob> I just reinstalled, and I get the same error message
<NickZ> you purged, right?
<NickZ> purging removes all the crap in your user data folder
<pcbBob> I did execute `sudo snap remove --purge spotify` and then `sudo snap install spotify`
<NickZ> Hmm
<NickZ> lemme look at the snapcraft.yaml...
<mcphail> Similar issue here: https://github.com/snapcrafters/discord/issues/31
<NickZ> pcbBob: try `snap revert core && snap refresh core`
<pcbBob> Didn't help, same error
<NickZ> hmmm
<mcphail> Are you using an old version of snapd or the cores? I see some comment suggesting this behaviour should have been fixed years ago
<NickZ> yeah, can you output `snap --version`?
<mcphail> https://github.com/ubuntu/snapcraft-desktop-helpers/pull/64/commits/9dd544efdad8654e912284fbe41938b2374ec63d - 2017!
<mup> PR ubuntu/snapcraft-desktop-helpers#64: Don't symbolic link gtk_configs if they already exist <Created by akgrant43> <Merged by didrocks> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/64>
<NickZ> dag
<pcbBob> $ snap --versionsnap     2.42.1-1snapd    2.42.1-1series   16manjaro  -kernel   5.3.11-1-MANJARO
<NickZ> mmmmm
<NickZ> Manjaro
<NickZ> I've had issues with snapd on manjaro
<NickZ> pcbBob: what does pacman say the latest version of snap is on manjaro? is it 2.42.1?
<NickZ> pcbBob: I'd suggest posting on the forums about this, like mcphail said; snapd support on Manjaro is unfortunately not great yet in my experience, and the commit logs suggest this problem should have been fixed long before 2.42.1
<NickZ> be sure to mention this issue: https://github.com/snapcrafters/discord/issues/31
<NickZ> and this commit: https://github.com/ubuntu/snapcraft-desktop-helpers/pull/64/commits/9dd544efdad8654e912284fbe41938b2374ec63d
<mup> PR ubuntu/snapcraft-desktop-helpers#64: Don't symbolic link gtk_configs if they already exist <Created by akgrant43> <Merged by didrocks> <https://github.com/ubuntu/snapcraft-desktop-helpers/pull/64>
<pcbBob> I didn't update my system for 3 months or so. I am just upgrading everything. Maybe it works
<NickZ> ok
<pcbBob> Thanks your help!
<NickZ> np
<mup> Issue # closed: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145
<mup> PR # closed: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134, core18#144, core18#146
<mup> Issue # opened: core18#56, core18#86, core18#89, core18#117, core18#129, core18#137, core18#142, core18#145
<mup> PR # opened: core18#43, core18#72, core18#90, core18#98, core18#126, core18#134, core18#144, core18#146
<sdhd-sascha> jdstrand: why did you call this function twice ? I'm sure you know. I'm also not perferct:
<sdhd-sascha> https://github.com/snapcore/snapd/blob/master/interfaces/builtin/utils.go#L102
<sdhd-sascha> jdstrand: don't be bad to me.
<sdhd-sascha> but,
<sdhd-sascha> it's possible that the compiler could optimize the call of `slot.Snap().GetType()`...
<sdhd-sascha> ...again... i didn't look at ...
<sdhd-sascha> jdstrand: i mean: great review. thank you
 * sdhd-sascha trink some more beer :-(
<NickZ> sdhd-sascha: You ok man?
<sdhd-sascha> NickZ: thank you ;-) i'm fine. I'm usally like this. I'm happy to find you all ;-)
<sdhd-sascha> I'm regret, that i didn't chat so much before...
<sdhd-sascha> NickZ: i'm with you. Thank you
<sdhd-sascha> all ok
<NickZ> cool
<sdhd-sascha> :-)
<sdhd-sascha> NickZ: life is life. Sometimes not so easy
<sdhd-sascha> NickZ: how are you?
<NickZ> understood
<NickZ> im doing alright
<sdhd-sascha> :-)
<NickZ> I recommend taking it easy, relaxing and not futzing with computer shit right now
 * sdhd-sascha i'm typing slower since i change german to englisch
<NickZ> work can wait :P
<sdhd-sascha> :-)
<sdhd-sascha> NickZ: yeah - right :-)
#snappy 2020-02-23
<mup> PR snapd#8178 opened: packaging: work around review-tools and snap-confine <â  Critical> <Created by zyga> <https://github.com/snapcore/snapd/pull/8178>
